TCP 客户端-服务器 SIGPIPE

发布于 2024-10-20 12:02:26 字数 583 浏览 0 评论 0原文

我正在设计和测试一个基于TCP套接字(互联网域)的客户端服务器程序。目前,我正在本地计算机上对其进行测试,无法理解有关 SIGPIPE 的以下内容。

*。 SIGPIPE 的出现相当随机。它可以是确定性的吗?

第一个测试涉及来自客户端的单个小(25 个字符)发送操作和服务器上的相应接收。相同的代码,在同一台机器上运行成功与否(SIGPIPE)完全不受我的控制。失败率约为45%次(相当高)。那么,我可以以任何方式调整机器来最小化这种情况吗?

**。第二轮测试是从客户端向服务器发送 40000 条小消息(25 个字符)(总数据量为 1MB),然后服务器响应其实际收到的数据总大小。客户端在紧密循环中发送数据,并且服务器上有一个单一的接收调用。它仅适用于发送的最大 1200 字节的总数据,并且再次出现这些不确定的 SIGPIPE,现在大约有 70% 的次数(非常糟糕)。

有人可以对我的设计提出一些改进建议吗(可能会在服务器上)。要求是在与服务器建立单个套接字连接后,客户端应能够发送中等到非常大量的数据(同样每条消息大约 25 个字符)。 我有一种感觉,针对单个接收的多个发送总是有损的并且效率非常低。我们是否应该将消息合并并仅在一个 send() 操作中发送?这是唯一的出路吗?

I am designing and testing a client server program based on TCP sockets(Internet domain). Currently , I am testing it on my local machine and not able to understand the following about SIGPIPE.

*. SIGPIPE appears quite randomly. Can it be deterministic?

The first tests involved single small(25 characters) send operation from client and corresponding receive at server. The same code, on the same machine runs successfully or not(SIGPIPE) totally out of my control. The failure rate is about 45% of times(quite high). So, can I tune the machine in any way to minimize this.

**. The second round of testing was to send 40000 small(25 characters) messages from the client to the server(1MB of total data) and then the server responding with the total size of data it actually received. The client sends data in a tight loop and there is a SINGLE receive call at the server. It works only for a maximum of 1200 bytes of total data sent and again, there are these non deterministic SIGPIPEs, about 70% times now(really bad).

Can some one suggest some improvement in my design(probably it will be at the server). The requirement is that the client shall be able to send over medium to very high amount of data (again about 25 characters each message) after a single socket connection has been made to the server.
I have a feeling that multiple sends against a single receive will always be lossy and very inefficient. Shall we be combining the messages and sending in one send() operation only. Is that the only way to go?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

苯莒 2024-10-27 12:02:26

当您尝试写入未连接的管道/套接字时,会发送 SIGPIPE。为信号安装处理程序将使 send() 返回错误。

signal(SIGPIPE, SIG_IGN);

或者,您可以禁用套接字的 SIGPIPE:

int n = 1;
setsockopt(thesocket, SOL_SOCKET, SO_NOSIGPIPE, &n, sizeof(n));

此外,您提到的数据量不是很高。可能某个地方存在错误,导致您的连接意外关闭,并发出 SIGPIPE。

SIGPIPE is sent when you try to write to an unconnected pipe/socket. Installing a handler for the signal will make send() return an error instead.

signal(SIGPIPE, SIG_IGN);

Alternatively, you can disable SIGPIPE for a socket:

int n = 1;
setsockopt(thesocket, SOL_SOCKET, SO_NOSIGPIPE, &n, sizeof(n));

Also, the data amounts you're mentioning are not very high. Likely there's a bug somewhere that causes your connection to close unexpectedly, giving a SIGPIPE.

半岛未凉 2024-10-27 12:02:26

引发 SIGPIPE 是因为您尝试写入已关闭的套接字。这确实表明可能存在错误,因此请检查您的应用程序以了解其发生的原因,并首先尝试修复该错误。

尝试仅屏蔽 SIGPIPE 并不是一个好主意,因为您并不真正知道信号来自哪里,并且您可能会屏蔽此错误的其他来源。在多线程环境中,信号是一个糟糕的解决方案。

在极少数情况下,如果您无法避免这种情况,您可以在发送时屏蔽信号。如果您在 send()/sendto() 上设置 MSG_NOSIGNAL 标志,它将阻止引发 SIGPIPE。如果您确实触发了此错误,send() 将返回 -1,并且 errno 将设置为 EPIPE。干净又简单。有关详细信息,请参阅man send

SIGPIPE is raised because you are attempting to write to a socket that has been closed. This does indicate a probable bug so check your application as to why it is occurring and attempt to fix that first.

Attempting to just mask SIGPIPE is not a good idea because you don't really know where the signal is coming from and you may mask other sources of this error. In multi-threaded environments, signals are a horrible solution.

In the rare cases were you cannot avoid this, you can mask the signal on send. If you set the MSG_NOSIGNAL flag on send()/sendto(), it will prevent SIGPIPE being raised. If you do trigger this error, send() returns -1 and errno will be set to EPIPE. Clean and easy. See man send for details.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文