Question

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.

Was it helpful?

Solution 3

This a known defect for qemu.

OTHER TIPS

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.

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)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top