插槽卡在CLOSE_WAIT中

Question

当我的两个守护进程互相交谈时，我在close_wait中遇到了套接字。在阅读了关于这个主题的不同问题和博客条目之后，我已经确认我正在从双方（发起者和接收者）关闭套接字。

该模型如下：

发信人： 建立连接，发送数据，等待确认，关闭连接

接收机： 接收连接，读取数据，发送确认，关闭连接

谁能告诉我我做错了什么？注意：我现在使用close（）来关闭连接。我也试过使用关机，它没有改变。任何提示都将不胜感激。

修改 关闭套接字后不久，接收守护进程就会分叉。我已经尝试将文件描述符传递给在子进程中再次分叉并显式关闭的函数，但这并没有解决我的问题。有没有其他方式可以影响这个过程？请注意，发送守护进程不会分叉。

Answer 1

在查看wireshark后，我看到最后的FIN_ACK说：

“[TCP ACKed lost segment] [TCP previous segment lost] ...”

事实证明，我的问题是由两个守护进程在同一个盒子上运行引起的（我们为测试添加了一些东西）。在多个盒子上再次尝试后，我们不再遇到这个问题。

Answer 2

当你有一个已经打开套接字的应用程序并且在做了一些发送接收之后它接受来自其对等体的FIN，从那些状态开始它进入CLOSE_WAIT状态。它可以永远保持在该状态，直到您明确调用close（）。希望你实际上是在close（）中传递正确的FD。

Answer 3

在我的（短期）经历中，很可能你正在关闭错误的f​​d，甚至根本没有达到“关闭”声明。我偶然发现后一个，第一个线索是我的应用程序变成了一个僵尸而不是关闭（特别是在关闭声明之前的一个简单的printf使它全部下地狱）。

可能值得花时间检查任务管理器/作业/系统监视器/＆lt;一些与您的操作系统相关的流程视图名称＆gt;。

Answer 4

实际上，这些是多线程服务器应用程序中常见的问题 您可以通过两件事来解决此问题：

1. 在套接字上使用FD_CLOSEXEC。
2. 在套接字上使用setsockopt并设置tcp_keepalive。

在* NIX和Microsoft上，上述两种解决方案的实现代码可能略有不同。差异仅在于语义差异。

我建议实施上述两项措施。

但是，如果您无法修改代码，那么您可以使用 libkeepalive