TCP TIME_WAIT after closing port
We have a batch of tests we perform on our code, which involves starting a program which listens for a TCP connection on a specific port.
Then we create a socket and connect to 127.0.0.1 on that port, and communicate with that program.
After the test, that program is terminated (killed, not shut down nicely; however it probably does not make any difference).
Then we immediately move on to the next test, which again involves starting that same program which listens for a TCP connection on the same port. We again create socket 127.0.0.1 for that port, and attempt to connect, and the connection is refused.
I suspect this has to do with TCP TIME_WAIT being 4 minutes.
We don't have control over the code for the program we start which listens for a connection on a specific port.
So I'm guessing we either need to add a 4 minute wait between tests (they run automatically so maybe no one cares), or, we find a way to not shut down the program between tests, (except that program may be wanted by numerous other concurrently running tests. Perhaps we need a way to reset that program without closing the port?)
My question is, is there a 3rd option i'm missing? Some clever way of dealing with this 4 minute wait problem? (That doesn't involve time travel, or Einstein's theory or relativity?)
You can try if killing the listening connection before or after killing the program helps. Use e.g. https://www.nirsoft.net/utils/cports.html with the /close option.
Sockets in TIME_WAIT are mandatory for the TCP protocol, the Fixed timeout on this should be 2 minutes.
TIME_WAIT would mean the socket is freed up... this is a remnant so any late arrival packets are known to a sessions and can be discarded.
You may be having another issue. The server didn't get the message the socket is close and is closed when the TCP session times out.
(also 2 minutes. Hence the 4 minute timeout).
You may need to close the socket on the server side sooner. Or design for multiple concurrent sessions...
(Not closing network sessions is common place in clients where the clients exits after having done it's thing, the OS will close the session).
On a server that keeps running closing stale sessions is really mandatory.
ASKER
Would closing the port make any difference? If the client closed the socket? Or if the server closed the TcpListener (C#)? Then could the server be restarted without wait? (I suspect not.)
The server should close the socket, and start accepting the next connection.
Until the next accept() is done, nothing happens on the server.
Closing a previous socket and look at a new one is an options
Or handling sessions in parallel by forking thread when listen() provides a new connection to be accepted().
It can also be done by creating non-blocking sockets and handling every chunk of data when it arrives.
The loop around listen() needs to be preserved, and all returning data needs to be processed.
Just don't do:
server() {
while ( next_session = listen(list_socket) ) {
accept(next_session)
while (read)next_session, buffer, ...) {
process(buffer);
}
close(next_session);
}
close(listen_socket);
}
ASKER
I will look into "reset packet". Thank you.
If you don't have control over the target systems you're pretty much stuck with the maximum timeout any of the test systems use, plus ten percent for safety.