TcpClient, TcpListener class reuse

  • Thread starter Thread starter Guest
  • Start date Start date
Is there any way to recreate a TcpClient &/or TcpListener object using the
same IP address/port? The objects ago out of scope so I assume the garbage
collector is destroying them, in which case I would think that I should be
able to create a new instance of these objects with the same address.
However, when I attempt to do so, I get the "Only one ussage of each socket
address (protocol/network address) is normally permitted" message.
 
this may happen if you do not call TcpListener.Stop method or
TcpClient.Close...

if your objects just went out of scope GC collector will not call these
methods, and unmanaged resources will still be allocated. Socket in this
example is an unmanaged resource. In terms of Win32 it is a handle that
describes the connection ( unmanaged resources ).

You'll have to ensure that these Stop/Close are called in order not to get
exceptions.
 
Thanks, Vadym, but I have called TcpClient.Close/TcpListener.Stop before the
objects go out of scope (I did not include that info in my original post
because those methods are always called in my code when their activity has
ended -- I just pressumed that would have been read as understood, -- so much
for presumption).

The error message occurs after the .Close (or .Stop) methods are called and
after the objects go out of scope and the objects are re-instantiated within
the same instance of the application. If the application is terminated and
then restarted, it works without error the first time the objects are created
and used, but after that (until the app shutsdown) I get this error. It
would seem to make sense to expose the SocketOption.ReuseAddress property in
these classes but I see no such methods. I presume the TcpClient and
TcpListener classes were derived from the Socket class, yes?
 
UPDATE:
I have just determined that when stepping the through the application in the
VS debugger, the recreated TcpClient/TcpListener objects work correctly EVERY
TIME. This would lead me to suspect that there are timing issues related to
the .NET runtime's release of the underlying Win32 Socket handles. Can
anyone confirm or deny this hypothesis?
 
At this point, posting a code sample that shows the issue would be most
helpful. I have not seen or heard about the issue you describe, so it may
be a code issue.
 
Thanks, William, but I just found the solution to the problem. Earlier in
this thread, Vadym Statsyak reminded me that TcpListener.Close must be called
before reopeing the object and I just found one execution path branch that
did not include that call. After putting it in, all works as it should.
Thanks.
 
Back
Top