Question

I’ve read here: Error 10048 when trying to open TcpChannel

I am having what I thought to be a similar problem – apparently not. I took the advice of the first respondant to reset winsock (how does the winsock get corrupted, anyhow?) Anyway, here is my channel registration:

 channel = new TcpChannel(channelPort);
 ChannelServices.RegisterChannel(channel, false);

and the client call:

 // Create a channel for communicating w/ the remote object
 // Notice no port is specified on the client
 TcpChannel channel = new TcpChannel();
 ChannelServices.RegisterChannel(channel, false);

 // Create an instance of the remote object
 CommonDataObject obj = Activator.GetObject( typeof(CommonDataObject) ,
  "tcp://localhost:49500/CommonDataObject") as CommonDataObject;

This seems all too straightforward to be such a hassle to use. But, the problem seems to be with the server’s ChannelServices.RegisterChannel(…). Now, the reason I included the client portion is because the client instances, checks for the server object. If it can’t find it, then it ‘nudges’ the server to instance itself. What I was wondering is if checking for the object’s available first (a la: Activator.GetObject(…) ) would cause the ChannelServices to ‘think’ this tcp channel is already registered? It sounds dumb, but that is my only possible explanation. I have turned off the firewall, anti-fungal app, and rebooted. Still receive this

The channel ‘tcp’ is already
registered.

I looked at my stack trace and did notice:

   at System.Runtime.Remoting.Channels.ChannelServices.RegisterChannelInternal(IChannel chnl, Boolean ensureSecurity)
   at System.Runtime.Remoting.Channels.ChannelServices.RegisterChannel(IChannel chnl, Boolean ensureSecurity)

I wondered if the RegisterChannelInternal(…) might be what is causing the ‘already registerd’ issue. So, other than that, I am at a loss…

It’s possible that the call I’m making to check for that Channel is causing it. If that is the consensus, then my question changes to: How can I poll for the Channel?

UPDATE:
After removing the initial check for the server from the client and ‘assuming’ that the server needs to be instanced, I did discover that the client checking is causing the problem. I’ve managed to get the server going, and the client did get a ‘transparent proxy’ object. But the question still remains: “How can I poll to discover if the server is instanced?”

Answer 1

The answer is evidently, yes…when the client is registering the channel, it keeps the server from registering another Tcp channel. I have removed the client instancing of a Tcp channel and the registration.

Since I haven’t gotten an answer on pinging, I’m going through with a try/catch block on the obj = Activator.GetObject(…). If obj is returned null, then I ‘nudge’ the server, it fires up…and then the client connects with the CommonDataObject (derived from MarshalByRefObject).

So, in a sense, that is the polling technique I’m using. I’d like something more elegant – that is, an implementation that didn’t work by causing a failure. To me, that’s more of a hack work-around than a solution.

I found the answer here. Thanks to Abhijeet for the inadvertent solution!!! Btw…don’t forget to declare:

using System.Linq;