TcpChannel注册问题

发布于 2024-08-18 13:23:35 字数 1613 浏览 1 评论 0原文

我在这里阅读:尝试打开 TcpChannel 时出现错误 10048

我我遇到了我认为类似的问题 - 显然不是。我采纳了第一个受访者的建议重置了winsock(winsock是如何损坏的?)无论如何,这是我的频道注册:

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

和客户端调用:

 // 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;

这看起来太简单了,使用起来很麻烦。但是,问题似乎出在服务器的 ChannelServices.RegisterChannel(...) 上。现在,我包含客户端部分的原因是因为客户端实例检查服务器对象。如果找不到它,它就会“推动”服务器实例化自己。我想知道的是,如果首先检查对象是否可用(例如: Activator.GetObject(...) )会导致 ChannelServices “认为”此 tcp 通道已注册?这听起来很愚蠢,但这是我唯一可能的解释。我已经关闭了防火墙、抗真菌应用程序,然后重新启动。还是收到这个

通道“tcp”已经存在 已注册。

我查看了堆栈跟踪并注意到:

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

我想知道 RegisterChannelInternal(...) 是否可能是导致“已注册”问题的原因。因此,除此之外,我不知所措......

可能是我为检查该频道而进行的呼叫造成的。如果这是共识,那么我的问题就变成:我如何轮询频道?

更新: 从客户端删除对服务器的初始检查并“假设”需要实例化服务器后,我确实发现客户端检查导致了问题。我已经设法让服务器运行,并且客户端确实获得了“透明代理”对象。但问题仍然存在:“我如何轮询以发现服务器是否已实例化?”

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

千寻… 2024-08-25 13:23:35

答案显然是,是的...当客户端注册通道时,它会阻止服务器注册另一个 Tcp 通道。我已经删除了 Tcp 通道的客户端实例和注册。

由于我还没有得到有关 ping 的答案,因此我将在 obj = Activator.GetObject(...) 上使用 try/catch 块。如果 obj 返回 null,则我“推动”服务器,它会启动...然后客户端与 CommonDataObject(派生自 MarshalByRefObject)连接。

所以,从某种意义上说,这就是我正在使用的轮询技术。我想要更优雅的东西 - 也就是说,一个不会因导致失败而无法工作的实现。对我来说,这更像是一种解决方法,而不是解决方案。

我找到了答案

using System.Linq;

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;
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文