I have a TCP server socket that listens for a single client connection on 127.0.0.1:8888. At startup, the client succesfully connects and so connection sockets are setup for both client and server in ESTABLISHED state. For an unknown reason, during run-time, the client seems to initiate the closing of the socket. The client socket (3719 below) is successfully closed, however the server socket remains stuck in CLOSE_WAIT. Attempts by the client to reconnect fail (as the should) with error socket in use.
netstat -a
TCP MYSERVER1:8888 MYSERVER1:0 LISTENING
TCP MYSERVER1:8888 MYSERVER1:3719 CLOSE_WAIT
I am surprised that
a) Windows does not seem to have a server CLOSE_WAIT timeout, and
b) the TCP protocol allows the client socket to complete the close and yet allow the server socket to remain in CLOSE_WAIT, and
c) my server thread remains blocked at recv() and therefore the server thread cannot call close itself on receipt of a socket receive error.
My client/server application protocol includes a poll message. One method of recovery from the CLOSE_WAIT is for the server's PollThread to close the connction socket when the client fails to respond to a poll. However this is not reliable because sometimes when the server socket gets into CLOSE_WAIT state, the PollThread is blocked on send() and therefore never gets to call close().
My main question is: Given point (c) above, is there no elegant way to close the socket without having to create a server monitoring thread that checks the state of the server socket and calls close() when it finds the socket in CLOSE_WAIT? E.g. implement a callback for when the server receives a FIN from the client.
PS: The solution can only be implemented on the server side as the client is untouchable legacy code. Both the server and the client run as Windows services on the same machine.
netstat -a
TCP MYSERVER1:8888 MYSERVER1:0 LISTENING
TCP MYSERVER1:8888 MYSERVER1:3719 CLOSE_WAIT
I am surprised that
a) Windows does not seem to have a server CLOSE_WAIT timeout, and
b) the TCP protocol allows the client socket to complete the close and yet allow the server socket to remain in CLOSE_WAIT, and
c) my server thread remains blocked at recv() and therefore the server thread cannot call close itself on receipt of a socket receive error.
My client/server application protocol includes a poll message. One method of recovery from the CLOSE_WAIT is for the server's PollThread to close the connction socket when the client fails to respond to a poll. However this is not reliable because sometimes when the server socket gets into CLOSE_WAIT state, the PollThread is blocked on send() and therefore never gets to call close().
My main question is: Given point (c) above, is there no elegant way to close the socket without having to create a server monitoring thread that checks the state of the server socket and calls close() when it finds the socket in CLOSE_WAIT? E.g. implement a callback for when the server receives a FIN from the client.
PS: The solution can only be implemented on the server side as the client is untouchable legacy code. Both the server and the client run as Windows services on the same machine.
