-1

I am currently in the process of debugging a server application which uses sockets to connect with clients. When I close the application, either gracefully which includes a socket.Close() or forcibly through visual studio or by terminating the process, the port remains bound and is still reported as listening, as confirmed by TCPView, netstat in command prompt, and AnVir Task Manager, all which show the port still bound to the one I chose, and indicate that it is still actively listening for connections. None of the tools I mentioned list a process associated with the connection.

Attempting to forcibly close the connection through TCPView, or AnVir, or any other tool does not have any effect. The only way I can unbind it is by logging off of windows entirely or restarting the PC.

How should I ensure that the port is unbound when my application exits? Shouldn't socket.Close() take care of this?

Nathan
  • 33
  • 1
  • 6
  • Are you closing all the connections? A Listener has a main socket which accepts all the listeners. Every time a new connection is made a new socket is created. So in the async accept method you can create a list object to get all the sockets. The when you close server you can enumerate through the list to close the sockets. Then close the main listening socket. – jdweng Oct 23 '17 at 01:31
  • I believe I am in the sense that there are no other connections to close. All i'm doing with the server app is starting it, then beginning the process of listening on the port, then closing the socket and then the app- no connections to the server are made from any client apps, so the sockets that would normally correspond to connected clients aren't relevant to this issue. – Nathan Oct 23 '17 at 01:43
  • Each connection is a clone connection with its own socket. Closing the main listening connection does not close the clone connections. If you run from cmd.exe > NetStat -a you will see all the TCP connections that are associated with you application by looking at the port number of your application. – jdweng Oct 23 '17 at 06:30
  • Indeed, I can see the connection you mention in netstat (though there is only one). When I leave the application running (with no clients connected), with the server listening on the given port, I can see in netstat result that matches with the debug process for the server, and seems to be well. However, when I exit the application, netstat shows that the same ip/port is still listening for connections, but does not have an associated process. When I try to relaunch the server application, I receive an exception stating that the port is already in use, which is confirmed by netstat. – Nathan Oct 23 '17 at 06:47
  • You can collect all the connection in the asyn accept method. There are probably other ways. I always knew these connections existed but never have seen code to close all the connections. Search the web you should find a solution. – jdweng Oct 23 '17 at 07:21
  • I greatly appreciate your attempts to assist me, but I'm getting the sense at this point that I'm not adequately communicating my issue. My issue has nothing to do with incoming connections in any way, and only involves the fact that, when I begin hosting on a port, when I close the application (without any clients connecting), the port remains bound and listening, despite the fact that I have closed the socket via socket.Close(). I was hoping to get some assistance in determining why the port is not freed and made available when I close the socket. – Nathan Oct 23 '17 at 07:44
  • The closest thing I could find to the problem online was this answer to a similar question: https://stackoverflow.com/a/2822376/6749566 which describes the issue I'm having in the comments, but without any resolution from what I can tell. – Nathan Oct 23 '17 at 07:45
  • See posting https://stackoverflow.com/questions/13806435/how-can-i-get-all-the-the-active-tcp-connections-using-net-framework-no-unmana. From endpoint you can check the port number. Then close connections with your port number. – jdweng Oct 23 '17 at 09:29
  • Thanks for the suggestion! I reproduced the issue, i.e. the state where my server application is not running but the port is active and listening, and then made a quick console application which used the code you linked to, and the list of active TCP connections that it returned did not contain the one I was using. Quite strange indeed. That would imply that it's not active, despite it showing up as such in netstat, TCPView, etc. – Nathan Oct 23 '17 at 21:44
  • jdweng, thank you for your assistance! I ended up downloading some windows updates that resolved the issue- see my answer below. – Nathan Oct 23 '17 at 22:04

1 Answers1

0

I hate to answer my own question, but it seems that I have stumbled upon some sort of resolution to this issue. After some deliberation, I decided on a whim to make sure I didn't have any windows updates that I needed to download (I'm on windows 7), and found several updates available for .NET (i.e. 'Security Update for Microsoft .NET Framework 3.5.1 on Windows 7...').

I allowed those to download and install, and found that, once they had finished, when I ran my application and then closed it gracefully with socket.Close(), I found that the port immediately became free! I also tested letting the server begin listening on the port, then forcibly closing the application via the 'stop debugging' button in visual studio, and found that the port automatically closed then as well.

Perhaps it was a bug that was fixed by the updates, or perhaps it was some bug that was coincidentally overwritten by files that were installed by the updates. Either way, it seems that it was not some issue with the code I had written, and socket.Close() can be trusted again!

Nathan
  • 33
  • 1
  • 6