12

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?

ulughbekula
  • 371
  • 1
  • 3
  • 12

2 Answers2

13

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

C.Evenhuis
  • 25,996
  • 2
  • 58
  • 72
  • 1
    Setting timeout to minimum value did help, but not much. Finally we were able to solve the problem by setting TCP_NODELAY parameter in client side. Thank you. – ulughbekula May 24 '12 at 01:23
  • I had same problem with TcpClient connecting to a MOXA. Setting TcpClient property NoDelay to true solved the problem for me. Thanks. https://learn.microsoft.com/it-it/dotnet/api/system.net.sockets.tcpclient.nodelay?view=netframework-4.7.2 – Ezin82 Apr 03 '19 at 16:01
1

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.

António Almeida
  • 9,620
  • 8
  • 59
  • 66
user2208901
  • 11
  • 1