Click here to Skip to main content
15,394,809 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
I have developed tcplistener in using tcpServer.dll. ref C# TCP Server[^]
here everything work fine till there are 2-4 connection, but if connection size increases and i try to stop the listing, application closes. Next time i try to open the same port it shows me
Only one usage of each socket address (protocol/network address/port) is normally permitted

I know this means the port is already open. i have closed the port at stop and form close event
if i do
netstat -ano
there is no entry of the port which i am trying to open
but when i check in wireshark i can see continuous data receiving on the same port.

i cant even find port in netstat so that i can kill the process

What I have tried:

Private Sub btnClose_Click(sender As System.Object, e As System.EventArgs) Handles btnClose.Click
End Sub

Private Sub tcpServer1_OnError(server As tcpServer.TcpServer, e As Exception) Handles tcpServer1.OnError
   End Sub
Updated 6-Jan-22 20:24pm

1 solution

The problem is that the process who owned the socket (your tcplistener application) did not perform a proper shutdown of the related connections and / or sockets. In such cases, the port is blocked for some time - or even until reboot - before it can be reused.

To avoid this, you have to perform a graceful shutdown. That should also let the clients don't send packets anymore (providing they are handling such cases properly too).

See also Graceful Shutdown, Linger Options, and Socket Closure | Microsoft Docs[^]. While that is about the Windows socket API C functions, it describes what has to be observed.

The problem you have is also described at Using SO\_REUSEADDR and SO\_EXCLUSIVEADDRUSE | Microsoft Docs[^]:
This issue can become complicated because the underlying transport protocol may not terminate the connection even though the socket has been closed. Even after the socket has been closed by the application, the system must transmit any buffered data, send a graceful disconnect message to the peer, and wait for a corresponding graceful disconnect message from the peer. It is possible that the underlying transport protocol might never release the connection; for example, the peer participating in the original connection might advertise a zero-size window, or some other form of "attack" configuration. In such a case, the client connection remains in an active state despite the request to close it, since unacknowledged data remains in the buffer.

To avoid this situation, network applications should ensure a graceful shutdown by calling shutdown with the SD_SEND flag set, and then wait in a recv loop until zero bytes are returned over the connection. This guarantees that all data is received by the peer and likewise confirms with the peer that it has received all of the transmitted data, as well as avoiding the aforementioned port reuse issue.

Further help requires seeing much more of your code.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900