第一次发送后未立即生成 SIGPIPE
我想知道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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
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).
我认为使用
SO_KEEPALIVE
选项可能会加快损坏链接的检测速度。I think using
SO_KEEPALIVE
option may speed up broken link detection.管道的另一端跨网络。该网络可能速度缓慢且不可靠。因此,管道的一端永远无法立即判断其伙伴是否还在那里。延迟可能会很长,因此操作系统也可能会做一些缓冲。这些考虑使得立即检测破裂的管道实际上是不可能的。
但是你为什么要这样做呢?管道在传输过程中随时可能破裂,所以无论如何你都必须处理一般情况。
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.
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.