我在一个众所周知的 TCP 端口上有一个服务器，一堆客户端连接到该端口。客户端使用非阻塞选项连接到服务器。
当我终止服务器进程时，客户端套接字进入 CLOSE_WAIT 状态。现在，如果我重新启动服务器进程并且客户端尝试再次连接，则 connect() 调用似乎会阻塞，即使它应该是非阻塞的。
实际的修复实际上可能是在服务器终止时关闭套接字。但我试图了解当前的行为..
- 当现有连接处于 CLOSE_WAIT 状态时，是什么阻止建立新连接？
- 为什么即使设置了非阻塞选项，连接也会阻塞？
这是在 Linux 2.6.3x 内核中看到的。
I have a server on a well known TCP port to which bunch of clients are connected. Clients use the non blocking option to connect to the server.
When I kill the server process, the client sockets go to CLOSE_WAIT state. Now if I restart the server process and the clients try to connect again, the connect() call seems to block even though its supposed to be non-blocking..
The actual fix might actually be to close the socket when the server dies. But I am trying to understand the current behavior..
- when an existing connection is in CLOSE_WAIT what is preventing a new connection being established ?
- Why is the connect blocking even though is non-blocking option is set ?
This is seen with Linux 2.6.3x kernel..
发布评论
评论（2）
听起来像是客户端中的一个错误。如果您将套接字设置为非阻塞，然后调用
connect，则connect调用没有理由阻塞。您能否粘贴创建套接字、将其设置为非阻塞并调用connect的客户端代码？另外，您确定它在connect调用本身中被阻止了吗？It sounds like a bug in the client. If you set the socket non-blocking and then call
connect, there is no reason theconnectcall should block. Can you paste the client code that creates the socket, sets it non-blocking, and callsconnect? Also, are you positive it is blocked in theconnectcall itself?我相信您的问题在此处得到了非常准确的解答，并且与
SO_REUSEADDR相关。关于答案 >使用 SO_REUSEADDR - 先前打开的套接字会发生什么？ 也相关。I believe your question is quite exactly answered here and related to
SO_REUSEADDR. The other answer to a question about Using SO_REUSEADDR - What happens to previously open socket? is also relevant.