TcpChannel注册问题
我在这里阅读:尝试打开 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
答案显然是,是的...当客户端注册通道时,它会阻止服务器注册另一个 Tcp 通道。我已经删除了 Tcp 通道的客户端实例和注册。
由于我还没有得到有关 ping 的答案,因此我将在 obj = Activator.GetObject(...) 上使用 try/catch 块。如果 obj 返回 null,则我“推动”服务器,它会启动...然后客户端与 CommonDataObject(派生自 MarshalByRefObject)连接。
所以,从某种意义上说,这就是我正在使用的轮询技术。我想要更优雅的东西 - 也就是说,一个不会因导致失败而无法工作的实现。对我来说,这更像是一种解决方法,而不是解决方案。
我找到了答案
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: