Sockets on server (c++) not closing all the way?

[joe_oej]

Abit of a problem - When a client disconnects from my server, the socket on the server doesn't fully close, instead of kind of hangs on CLOSE_WAIT. I dont know how to detect what state a socket is in (like that), so I cant really think of anyways to remedy this problem.

[EDIT] - I have found that this only seems to be happening on VB programs that use the winsock control... Maybe some other non vb programs, but generally when I connect with a vb application, it connects fine, then when it disconnects (and even when the app is closed), the server socket is lingering on CLOSE_WAIT - Aswell, there is a FIN_WAIT_2 state for the socket used by the vb program? I dont really understand what the deal is here ...

Any ideas?

[ntg]

This may sometimes happen if the disconnect wasn't done properly (one end of the conversation loses the connection and the other doesn't immediately disconnect) or may also happen if there are connection issues. If the TCP stack doesn't see the expected ACKs and stuff, then it waits a bit for them and places socket connections to appropriate states - I think CLOSE_WAIT is when one party has ended the conversation but the other doesn't close the socket while FIN_WAIT_2 happens when you have network problems and the TCP stack is trying to recover. Generally speaking though, you don't have any control over these with Winsock and you also don't get a notification about these situations.

Cheers,
NTG

[rooster2005]

I have found that following the MSDN documentation for the shutdown() function seems to eliminate the invasion of CLOSE_WAIT states for sockets. CLOSE_WAITS will eventually prevent further connections from occuring.

Use the four steps found under the shutdown() documentation and see if your CLOSE_WAIT problem disappears.

Check out the TCP helper functions also - especially GetTcpTable().

Hope this helps in some way...

[ccoder]

I found this a long time ago. Don't recall where, so I can't credit anyone!

The TIME_WAIT value is set to 2 times the maximum segment lifetime, which is related to the time-to-live (TTL) value of IP datagrams within the network. Simply put, this allows TCP to ensure that connections are properly closed. The side initiating the close must hang around long enough for the other side to send its final packet.

Here is the Microsoft workaround: http://support.microsoft.com/default...;EN-US;q173619

Please describe a typical connection scenario in detail. It may help pinpoint your problem. I have been doing sockets for about 10 years, mostly in C, with some VB and Java. I had a similar problem when I first started using VB's Winsock control. That is when I found the info listed above.