如果服务器断开连接，客户端如何检测？
我有一个带有 net.tcp DuplexChannel 的 WCF 自托管服务。在服务器上，我运行以下命令来断开客户端连接：
((ICommunicationObject)client.CallbackChannel).Close();
这工作正常，但如何在客户端上检测到它已断开连接？
我已经在回调的 InstanceContext 和服务器通道上连接了 Closed 和 Faulted-events：
InstanceContext callback = new InstanceContext(callbackImp);
callback.Closed += new EventHandler(callback_Closed);
但是
((ICommunicationObject)Channel).Closed += new EventHandler(Channel_Closed);
没有任何效果。我从来没有收到通知。我现在使用的解决方法是在回调中使用一个方法来触发与客户端的断开连接。但我宁愿不这样做。我特别不想让服务器等待用户断开连接。
编辑
我刚刚意识到，当与客户端断开连接时，我在服务合同中运行一个标有 IsTerminate = true 的方法：
[OperationContract(IsTerminating = true)]
void Disconnect();
我认为在回调合同上它会是相同的吗？我尝试将相同的方法添加到我的回调中，它确实从服务器的角度终止了回调通道，但我仍然没有在客户端收到通知......奇怪的
编辑
我发现了一些有关此的更多信息：
当服务器中止回调时 通道，故障传播回 客户，客户故障，我们得到 客户端上的错误事件。
当服务器关闭回调时 频道，会话仍然开放 直到客户发出关闭通知。
一旦客户端关闭通道 您将看到“关闭”事件。
根据这个声明，关闭事件并不是仅仅通过从服务器关闭回调通道来触发，客户端也必须关闭它。因此，我可以在回调的终止 Disconnect 方法中在客户端上运行 Close。或者我可以在回调服务器端使用 Abort 方法并跳过在回调上使用 Disconnect 方法。老实说，我不知道我更喜欢哪一个。嗯嗯。
编辑
我采用了中止方法。这似乎是最合乎逻辑的方法，而且效果非常好。客户端会收到有关回调实例上下文的故障事件通知。好的。
I have a WCF self-hosted service with a net.tcp DuplexChannel. On the server I run the following to disconnect a client:
((ICommunicationObject)client.CallbackChannel).Close();
This works fine but how do I detect on the client that it has been disconnected?
Ive hooked up to Closed and Faulted-events on both the InstanceContext of the callback and the channel to the server:
InstanceContext callback = new InstanceContext(callbackImp);
callback.Closed += new EventHandler(callback_Closed);
and
((ICommunicationObject)Channel).Closed += new EventHandler(Channel_Closed);
But nothing works. I never get notified. The workaround Im using now is to have a method in the callback that triggers a disconnect from the client-side instead. But I rather not do it this way. I especially dont want to let the server wait for a user to disconnect.
EDIT
I just realized that when disconnecting from client-side I run a method in the service-contract which is marked with IsTerminating = true:
[OperationContract(IsTerminating = true)]
void Disconnect();
I figured it would be the same on the callback-contract then? I tried adding the same method to my callback and it did terminate the callback-channel from the server point of view but I still didnt got notified on the client-side...weird
EDIT
I found out some more info about this:
When the server aborts the callback
channel, a fault travels back to the
client, the client faults and we get
the Faulted event on the client.When the server closes the callback
channel, the session is still open
until the client issues the close.Once the client closes the channel
you'll see the Closed event.
According to this statement the Close-event is not triggered mearly by closing the callbackchannel from the server, the client has to close it as well. So I could run Close on the client in the terminating Disconnect-method of the callback. Or I could use the Abort-method on the callback server-side and skip using a Disconnect-method on the callback. I dont know which one I preffer honestly. Hmmmm.
EDIT
I went with the Abort-approach. It seemed like the most logical method and it works really well. The client gets notified with the Faulted-event on the callback-instancecontext. Nice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您只需在关闭回调通道之前执行回调，告诉客户端您正在关闭通道。
所以就在这行代码之前：
You can simply do a callback just before closing the callback channel telling the client you're closing the channel.
So just before this line of code:
我采用了中止方法。这似乎是最合乎逻辑的方法，而且效果非常好。客户端会收到有关回调实例上下文的故障事件通知。
I went with the Abort-approach. It seemed like the most logical method and it works really well. The client gets notified with the Faulted-event on the callback-instancecontext.