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

【问题标题】：SIGPIPE not being generated immediately after 1st send第一次发送后未立即生成 SIGPIPE
【发布时间】：2012-02-14 00:46:54
【问题描述】：

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

【问题讨论】：

我觉得你要求太多了...
你如何检测到服务器宕机了？顺便说一句，它是如何下降的？
尝试从连接中读取时会发出关闭连接的信号。
@jpalecek .. 好吧，我通过 ctrl +c 选项杀死了服务器进程.. 在实时应用程序中，它可能由于多种原因而停机并启动..
当客户端发送 msg 时，它会收到 SIGPIPE 错误，但仅在执行 send() 两次之后.. Read 也会生成，但当前客户端没有读取任何内容...@todda ... LMAO！ !

标签： c++ sockets tcp send sigpipe

【解决方案1】：

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

管道的另一端穿过网络。该网络可能很慢且不可靠。因此，管道的一端永远无法立即判断其伙伴是否还在。延迟可能会很长，因此 O/S 也可能会做一些缓冲。这些考虑使得几乎不可能立即检测到破损的管道。

以及任何可能的解决方法

但你为什么要这样做？在传输过程中，管道随时可能破裂，因此您必须处理一般情况。

【讨论】：

如果不是立即，那么 ASAP 会这样做..是的，但一般情况是 sigpipe 在第二次发送之后返回，如果有人给出配置命令，那么套接字有可能在之前被破坏他发送了最后一个配置命令，但他不知道他错过了..
@Srinivas “就在他发送最后一个配置命令之前，他不知道他错过了它”所以你的真正的兴趣是知道，在发件人得到 aa SIGPIPE，接收方接收了多少数据？知道这并没有多大用处，因为发送者可能真的想知道接收者是否已经完成了对发送命令的操作。为此，您需要在 TCP/IP 之上构建一个协议，该协议让接收者发送完成命令的确认。
我希望客户端自动重新连接，这是我依靠信号处理程序来完成这项工作.. 是的 der 也是接收者在成功完成执行后的 ack 响应......但是说如果客户端没有收到最后一个 cmd 的 ack ，他不知道是由于套接字损坏还是由于接收器无法完成 cmd...

【解决方案2】：

TCP 堆栈只会在尝试一定次数的重传后抛出错误。 IIRC，TCP 重传计时器被初始化为一些小秒数，重传次数通常为 5-10。该协议不支持任何其他检测在数据交换期间变得无法访问的对等方的方法（例如，有人绊倒了服务器电源线）。

【讨论】：

TCP 堆栈只会在尝试重新传输一定次数后抛出错误。你能告诉我那个错误是什么吗？tcp 大约在多长时间后会抛出那个错误。
抛出的实际错误可能会有所不同 - 您可能会得到 ECONNRESET 或 ECONNABORTED 或 ETIMEDOUT。取决于服务器和/或路由器如何以及是否会消失并恢复，以及何时恢复。发出错误之前花费的时间取决于操作系统/配置，但在大多数操作系统上将是数十秒。如果某处的某些路由器试图建立替代路由，例如，它必须很长。通过拨打调制解调器或尝试在微波链路上获得一个插槽。该协议将非常努力地以某种方式传递数据，并且必须给予时间来尝试这样做。

【解决方案3】：

我认为使用SO_KEEPALIVE 选项可能会加快断开链接检测。

【讨论】：

SO_KEEPALIVE 通常每两个小时左右发送一次。我不建议将其作为检查连接状态的一种方式。
它是可调节的，但不，我不推荐它，我正在覆盖选项 :)
@user1158242，我猜如果您使用setsockopt 调整它，那么不会。如果您在系统范围内进行调整，那么显然可以。
你能给我设置特定套接字（而不是整个系统）的语法，以便在服务器关闭后 1 秒内发出信号或错误...
看这里，tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO 但一秒钟听起来确实要求太多了。