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?"

Was it helpful?

Solution

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;
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top