第一次发送后未立即生成 SIGPIPE

发布于 2024-12-28 02:26:56 字数 203 浏览 0 评论 0原文

我想知道tcp套接字是否可以立即报告任何损坏的管道错误。目前,当服务器出现故障时,我正在客户端捕获 sigpipe 信号...但我发现生成了 sigpipe 信号 仅在第二条消息从客户端发送到服务器之后。这可能是什么原因?如果另一个套接字端出现故障,则第一次发送必须返回 sigpipe .. 不是立即生成该信号吗?? 对于这种奇怪的行为有任何可能的解释吗?有什么可能的方法来解决这个问题吗?

I want to know whether its possible for tcp socket to report any broken pipe error immediately. Currently i am catching the sigpipe signal at the client side when server goes down ... but i found that the sigpipe signal is generated
only after 2nd msg is sent from client to server . what could be the possible reason for this?? If the other socket end went down , then the 1st send must return sigpipe .. y isnt that signal generated immediately..??
Is there any possible explanation to this peculiar behaviour?? And any possible way to get around this??

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

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

发布评论

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

评论(3

梦开始←不甜 2025-01-04 02:26:56

TCP 堆栈仅在尝试重传一定次数后才会抛出错误。 IIRC,TCP 重传计时器被初始化为一些小秒数,重传次数通常为 5-10 次。该协议不支持任何其他方式来检测数据交换期间无法访问的对等点(即有人被服务器电源线绊倒)。

The TCP stack will only throw an error after some number of retransmission attempts. IIRC, the TCP retransmission timer is initialized to some small number of seconds and the number of retransmissions is typically 5-10. The protocol does not support any other means of detecting a peer that has become unreachable during a data exchange, (ie. someone tripped over the server power cable).

你穿错了嫁妆 2025-01-04 02:26:56

我认为使用 SO_KEEPALIVE 选项可能会加快损坏链接的检测速度。

I think using SO_KEEPALIVE option may speed up broken link detection.

美人骨 2025-01-04 02:26:56

我想知道tcp套接字是否可以立即报告任何损坏的管道错误

管道的另一端跨网络。该网络可能速度缓慢且不可靠。因此,管道的一端永远无法立即判断其伙伴是否还在那里。延迟可能会很长,因此操作系统也可能会做一些缓冲。这些考虑使得立即检测破裂的管道实际上是不可能的。

以及任何可能的方法来解决这个问题

但是你为什么要这样做呢?管道在传输过程中随时可能破裂,所以无论如何你都必须处理一般情况。

I want to know whether its possible for tcp socket to report any broken pipe error immediately

The other end of the pipe is across a network. That network could be slow and unreliable. So one end of the pipe can never instantly tell whether its partner still there. The delay could be quite long, so the O/S is also likely to do some bufferring. These considerations make it practically impossible to immediately detect a broken pipe.

And any possible way to get around this

But why would you want to? The pipe could be broken at any time during trans mission, so you have to handle the general case anyway.

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