Menu
I have a client application, which uses a unmanaged dll for communicating with a server.
All network-related operations are perormed inside the unmanaged dll. After a number of operations with the server, the client is running out of TCP ports. If we check the state of netwotk using 'netstat -an', we get the following result:
...
TCP 192.168.11.55:56048 192.168.10.28:5000 FIN_WAIT_2
TCP 192.168.11.55:56049 192.168.10.28:5000 FIN_WAIT_2
TCP 192.168.11.55:56050 192.168.10.28:5000 FIN_WAIT_2
TCP 192.168.11.55:56051 192.168.10.27:5000 FIN_WAIT_2
TCP 192.168.11.55:56052 192.168.10.28:5000 FIN_WAIT_2
TCP 192.168.11.55:56053 192.168.10.27:5000 FIN_WAIT_2
TCP 192.168.11.55:56054 192.168.10.27:5000 FIN_WAIT_2
TCP 192.168.11.55:56055 192.168.10.27:5000 FIN_WAIT_2
TCP 192.168.11.55:56056 192.168.10.27:5000 FIN_WAIT_2
TCP 192.168.11.55:56057 192.168.10.28:5000 FIN_WAIT_2
TCP 192.168.11.55:56058 192.168.10.27:5000 FIN_WAIT_2
TCP 192.168.11.55:56059 192.168.10.28:5000 FIN_WAIT_2
TCP 192.168.11.55:56060 192.168.10.27:5000 FIN_WAIT_2
...
The ports are released only after the client is closed.
If I run the VS project in Debug Mode, it never runs out the ports. But, while running in Release mode, it is happening.
And I don't have access neither to server nor client source.
How to release or kill those ports which are in FIN_WAIT_2 state?
923
FIN_WAIT_2 seems to occur when the server has an active connection with a client and wants to shut down the TCP connection (probably in response to a normal application layer "exit"). The server sends the client a packet with a "FIN" bit set.
FIN_WAIT_1 indicates that the remote computer has closed the connection but the local application it is connected to still has not acknowledged it. FIN_WAIT_2 indicates that the local computer has closed the connection but the remote computer has not acknowledged it.
The CLOSE_WAIT state indicates that the remote end of the connection has finished transmitting data and that the remote application has issued a close(2) or shutdown(2) call. The local TCP stack is now waiting for the local application that owns the socket to close(2) the local socket as well.
When a socket is in FIN_WAIT_2, the local socket was closed and is waiting for the remote socket to send their close request. If this close request never arrives, the socket will remain in the FIN_WAIT_2 state for a while.
The reason behind this is that if the close request from the remote party would be delayed and arrive after another application reuses the socket, that new connection would be instantly closed.
You can change the timeout if you want, but in the end the unmanaged dll has not fully implemented the TCP shutdown sequence. For more information see
http://answers.microsoft.com/en-us/windows/forum/windows_7-networking/how-to-close-finwait2-connections-except-reboot/ba2fed9f-8b61-4b71-ab5b-d39dc9a387e3
108
The server side socket will read 0 bytes when you shutdown/close the client socket.
At this point, you should shutdown/close the server socket. Your connection will show as TIME_WAIT with PID0 and eventually go away.
I think that is as good as it gets.
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
