views:

974

answers:

3

Client close the socket first, when there is not much data from server, tcp connection shutdown is okay like:

FIN -->
   <-- ACK
   <-- FIN, ACK
ACK -->

When the server is busying sending data:

FIN -->
    <-- ACK,PSH
RST -->

And the server connection comes to CLOSE_WAIT state and hang on there for a long time.

What's the problem here? client related or server related? This happens on Redhat5 for local sockets.

This article talk about why "RST" is sent, but I do not know why the server connection stuck on CLOSE_WAIT, and do not send a FIN out.

[EDIT]I ignored the most important information, this happens on qemu's slirp network emulation. It seems to be a problem of slirp bug for dealing with close connection.

+1  A: 

This means that there is unread data left in in the stream, that the client hasn't finished reading.

You can force it off by using the SO_LINGER option. Here's relevant documentation for Linux (also see the option itself, here), and [here's the matching function2] for Win32.

It's the server side that is remaining open, so it's on the server side you can try disabling SO_LINGER.

unwind
It seems that the SO_LINGER only influence the close() call, but the server hang on write() call instead?
arsane
If the server's hanging on a write call then you've probably filled the TCP window and the stack is waiting for ACKs from the client before it can accept more data to send...
Len Holgate
A: 

It may mean that the server hasn't closed the socket. You can easily tell this by using "lsof" to list the file descriptors open by that process which will include TCP sockets. The fix is to have the process always close the socket when it's finished (even in error cases etc)

MarkR
The problem is that the server is hung on write call, and I can not detect error.
arsane
A: 

This a known defect for qemu.

arsane