.NET Remoting

Question

I have a Windows service that I have written that hosts a remotable object (a simple class with 3 or 4 methods.) I have another Windows service that serves as a client and accesses the remote object via an interface. Here is where my problem begins. Everything works great, with the exception of one thing. Once the remote object has been accessed, if I try to stop and restart the server, I get a "Service cannot be started. System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted 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(String name, Int32 port) at Publisher.PublisherService.OnStart(String[] args) at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)" Okay, now I know this means that essentially the TcpServerChannel could not be registered because something is either locking the port it is trying to bind to (port 2300), or garbage collection has not happened. After about 15minutes, the problem goes away, and I am able to start the service and the TcpServerChannel registers fine. The first thing I tried was to specify a System.String.Empty name for the TcpServerChannel, as the documentation specifed ...If you want to register more than one TcpServerChannel, each must have a unique name. Set this property to the Empty string ("") if you want to ignore names, but avoid naming collisions. The system will allow any number of channels with the String.Empty name". . But this did not work, for as soon as I accessed the remote object and then tried to restart the windows service, I get the same error as above. The next thing I tried was to force a GC.Collect in the OnStop event, but that did not work. The next thing I tried was to use netstat thinking that something is locking on to port 2300 and not letting go. I looked at "netstat -a" thinking that some process was locking the port, but nothing was locking the port. I checked via TaskManager to make sure my application was dead, and it is definitely dead. Now here is the shocker. I rebooted the box, and I still get the error, and the error only goes away after about approximately 10-15 minutes! Can anyone offer any suggestions, or anything else I can try to debug? Everything works wonderfully, no problems within the application or accessing the object or anything, but after the remote object is accessed, I cannot restart the application, until after approximately 10-15 minutes. Is this a GC issue?

Answer 1

Wow. I wouldn't have thought that. I was sure a switch was flaky. Hey, either way a fix is a fix, right :)

Answer 2

It was a firewall issue! Thanks chornberger for pointing me in the right direction. Glad to get this one solved. Thanks again, Roy

Answer 3

wow. get your network staff to sniff and track some packets. Sounds like you got a switch/router with a flaky blade. If it was the network card even, the power down would have cycled that. It's further up the chain. It's not a hub... hubs are dumb. It's either a switch or a router. I'm guessing a switch.

Answer 4

Yes I have tried it without the GC part. Tried a power down, but that did not work. But I have found something interesting! I was taking your suggestion about trying another box. So I started up my Windows service on my machine, had the client access the object, and then tried to shut down the Windows service and then restart it, same error. I then take the app and install the Windows service on another developer's machine, which has never had this application before, and when I installed it and tried to start it, I get the error! This tells me there is something going on at the network level. Am I on the right track, and if so, any suggestions on what I should be looking for?

Answer 5

Just for giggles, have you tried it without explicitly invoking GC?

Answer 6

Here is my code: protected override void OnStart(string[] args) { //Create the remote TCP object tscPublish=new TcpServerChannel(System.String.Empty,2300); ChannelServices.RegisterChannel(tscPublish); RemotingConfiguration.RegisterWellKnownServiceType(typeof(EI),"Publisher",WellKnownObjectMode.SingleCall); } protected override void OnStop() { //Begin garbage collection process tscPublish.StopListening(listener); ChannelServices.UnregisterChannel(tscPublish); GC.Collect(GC.GetGeneration(tscPublish)); tscPublish=null; } The listener variable is just an object variable with the port number assigned to it (2300), and it is simply there to satisfy the requirements of the StopListening property.

Answer 7

Reboots (without power down) don't really do anything to the hardware. All they really do is reload drivers. If you've got an issue on your LAN card... or just a really cheap lan card... or heck, maybe even a really *GOOD* lan card that does some intelligent stuff with what the software asks of it, maybe that's what's going on too. I'd guess it's a card issue just being flaky, tho'. I've heard of switches doing crazy things with ports and stuff, but I'd stick local to the box for diagnostics. What if you moved it to another box... does the issue remain?

Answer 8

PS... Reboot doesn't clear this but I bet a power-off clean boot will. I'm guessing you *might* have a lan-card or HAL issue.

Answer 9

can we see your tear-down code? I'm doing something similar in a project (Win2k Server, sp3?) and not having this problem.

Answer 10

Yes I am explicitly, with a clean exit, unregistering the channel. So there are no errors or anything, I am simply stopping the Windows serivce. I think my next step is to give Microsoft a call. Anyone else have suggestions?

Answer 11

Are you explicitly unregistering the channel or is something happening to cause an unclean exit? I know there was a problem a few years ago on Win9x boxes where the OS wasn't releasing sockets and the intrinsic timeout (I think it was 5? minutes) had to be used. But they fixed it with a service pack or something.

Answer 12

Forgot to mention that I have tried this on Windows 2000 SP3 and SP4 and Windows XP Professional SP1. I am using .NET v1.1