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;

友情链接