James Johnston

When registering and unregistering a TCP channel repeatedly, I often get a SocketException. It seems as though UnregisterChannel does not truly stop the TCP socket and unregister everything. The code below reproduces on my system. Am running .NET Framework 2.0 RTM / Visual Studio 2005 and no beta code was ever installed on this machine. The problem reproduces on two other machines but not a third.

 public static void Main(string[] args) {
  int i = 1;
  try {
  while (true) {
   ChannelServices.RegisterChannel(new TcpChannel(666), false);
   ChannelServices.UnregisterChannel(ChannelServices.RegisteredChannels[0]);
   i++;
  }
  } catch (Exception ex) {
  Console.WriteLine("Died at iteration {0}.", i);
  Console.WriteLine(ex.ToString());
  Console.ReadLine();
  }
 }

The output on my machine is:

Died at iteration 4.
System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted
  at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
  at System.Net.Sockets.Socket.Bind(EndPoint localEP)
  at System.Net.Sockets.TcpListener.Start(Int32 backlog)
  at System.Net.Sockets.TcpListener.Start()
  at System.Runtime.Remoting.Channels.ExclusiveTcpListener.Start(Boolean exclusiveAddressUse)
  at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.StartListening(Object data)
  at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.SetupChannel()
  at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(Int32 port)
  at System.Runtime.Remoting.Channels.Tcp.TcpChannel..ctor(Int32 port)
  at CrashMe.Program.Main(String[] args)

It never fails on the first iteration. Sometimes it fails on the 2nd iteration, or, as in this case, it may work a little longer and then die. On one machine it died at the 162 iteration on first run - the hard drive was quite active. After that it usually died on the 2nd iteration.

The problem appears to be timing related. If I add a "Thread.Sleep(100);" to the loop after the call to UnregisterChannel, it does not crash. Of course, this is not really an acceptable solution or workaround since in a production environment you cannot guarantee that your sleep interval will always work right!

Is there some way to get UnregisterChannel to immediately close instead of trying to do things in the background behind my back

Thanks for any help!

Best regards,

James Johnston



Re: .NET Remoting and Runtime Serialization SocketException when registering channel: Possible bug in .NET Remoting

Lucian Bargaoanu

It doesn't happen on my machine. Anyway, I think that this is related to how the underlying sockets work and there is not much you can do about it. Why are you trying to use channels this way I'm sure they were not designed for this usage.



Re: .NET Remoting and Runtime Serialization SocketException when registering channel: Possible bug in .NET Remoting

James Johnston

  1. It is a Windows service that can dynamically reconfigure itself.
  2. Register/UnregisterChannel are being called from tests in NUnit (and the calls are not being made directly from the test fixture, but from the Windows service which is being tested). So they get called repeatedly. I've had problems with tests mysteriously failing and was able to trace it to this bad UnregisterChannel behavior.




Re: .NET Remoting and Runtime Serialization SocketException when registering channel: Possible bug in .NET Remoting

bmoneil

I have the same issue with RemotingConfiguration.Configure in a Windows Service.

1. Start the service and call RemotingConfiguration.Configure.

2. Stop the service.

3. Start the service and get "System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted.".

If I wait a few seconds the service starts fine.





Re: .NET Remoting and Runtime Serialization SocketException when registering channel: Possible bug in .NET Remoting

John Justice - MSFT

Hi folks, Unregistering the service doesn't force a synchronous freeing of resources; instead, it marks the underlying structures as "available for cleanup". Given that, the actual timing of the cleanup will vary depending on system load, number of processors, etc. If you're going to be repeatedly stopping a and starting a service you'll need to 1) wait a few seconds before you startup and 2) if you see the SocketException, catch it, wait, and retry (a finite number of times in case you have a non-transient problem).

Cheers,

JJustice [MSFT]





Re: .NET Remoting and Runtime Serialization SocketException when registering channel: Possible bug in .NET Remoting

drVenkat

NA



Re: .NET Remoting and Runtime Serialization SocketException when registering channel: Possible bug in .NET Remoting

DaveInCT

I see this once in a while debugging new code that happens to be crashing my service. Waiting doesn't clear the problem. It's permanently stuck. This usually isn't a big deal, but today I'm on my third reboot b/c of this. Is there any way to reset/free the port again so this exception goes away without a reboot

thanks,

Dave






Re: .NET Remoting and Runtime Serialization SocketException when registering channel: Possible bug in .NET Remoting

Jonathan Tougas

Is there a way to wait for the resources to be released or query the status to find out if it's really unregistered