JJL088 is basically correct. WinSock does not set locally used sockets into TIME_WAIT on closure, but that's basically no use, since one wants to communicate over a network.
The basic problem is the reuse of a Listen port, any sockets associated with that port go into TIME_WAIT on closure and then one cannot bind again.
The solution is to use the SO_REUSE option after creating the socket but before association with a port (Bind). The downside is that you could get "out of band" data, ie on attempting to read from the socket you'll get this error - recovery is to ignore the data - or at the worst data which is meaningless.
If you stick to the programming style of creating a socket, making a Listen (optionally with SetSockOpt(SO_REUSE)) and then looping on accepts - ie: create the Listen socket once in your server application - you'll virtually never have any of these problems. I have had an Accept failure with out of band only once.
Main Topics
Browse All Topics
by: JJL088Posted on 2007-06-30 at 20:32:12ID: 19397695
Unfortunatly the TIME_WAIT serves an important purpose, because of the way TCP/IP works it is possible to have Duplicate packets flying around after the connections close, to solve the obvious problems of this the TIME_WAIT was born, it delays the reuse time on a ip/port combo to prevent a new connection from receiving packets from an old connection. Having said that i know that using VB6 and winsock control it is possible to close a "socket object" and immediatly reuse it, i dont know if thats just because of the way the control address's the sockets internally so maybe im not using the exact same socket *shrugs* anyways the TIME_WAIT is one of those problems that just dont have any easy Solutions. ofcourse i do not know everything so maybe with enough google time you can find a solution.