PollingDuplex 是否适用于 Silverlight 客户端通知？答案

【问题标题】：Is PollingDuplex right for Silverlight client notification?PollingDuplex 是否适用于 Silverlight 客户端通知？
【发布时间】：2012-01-16 07:57:31
【问题描述】：

我正在尝试确定 PollingDuplex 是否是解决我的问题的正确方法。

这是我的场景： 1. 3rd 方应用程序将带有客户端 IP 地址的 UDP 数据包发送到服务器应用程序。 2. 服务端应用需要通知指定的客户端并发送一些数据。

客户端是 Silverlight 应用程序。

我一直在查看一些指南和示例代码 (http://petermcg.wordpress.com/2008/09/03/silverlight-polling-duplex-part-1-architecture/) 但我不明白如何使用 PollingDuplex 在服务器上识别客户端。我了解客户端向服务器注册并不断轮询消息。我如何确保只有正确的客户才能获得为该客户指定的消息？换句话说，服务器上的消息不应该广播给所有轮询客户端，而应该只发送给一个特定的客户端。

非常感谢任何帮助。

【问题讨论】：

标签： silverlight wcf

【解决方案1】：

轮询双工实际上是一个完全客户端的实现，仅存在于 Silverlight（没有常规的 .NET 框架版本，除了 Codeplex Microsoft 自己的内部咨询服务项目，它是为他们的高级客户开发的）。在服务器端并没有什么特别之处。

微软自己承认，它并不是真的要用于生产（我们公司有一位微软联系人坦率地向我们承认了这一点）。它不是很健壮或实施良好，并且可以/将在任何类型的卷下对您的服务器进行 DoS： http://forums.silverlight.net/p/89970/239380.aspx

您最好滚动自己的客户端轮询机制 - 或者（更好且更具可扩展性）在 Silverlight 4 中使用带有会话的 TCP，它提供真正的双工支持（因为连接不是无状态的，因此支持真正的推送通知）： http://www.silverlightshow.net/items/WCF-NET.TCP-Protocol-in-Silverlight-4.aspx.

【讨论】：

我会支持使用 Net.TCP 的建议。我们花了很多时间处理 HttpPollingDuplex 绑定，虽然我们或多或少地让它工作了，但它非常脆弱，而且似乎不需要花费太多时间就能使连接出错。一旦我们切换到 Net.TCP WCF 绑定，我们就更开心了。使用 HttpPollingDuplex 只有两个真正的原因：（1）如果您需要安全连接，即 SSL；或 (2) 您不能依赖端口 4502-4534 + 943 处于打开状态。
我同意 PollingDuplex 不稳定。

【解决方案2】：

无论您使用的是 Net.TCP 还是 HttpDuplexBinding，都可以使用 OperationContext.Current.Channel.SessionId 来识别客户端。更具体地说，您可以使用OperationContext.Current.GetCallbackChannel<IMyCustomServiceInterface>() 获取 WCF 用来与他们交谈的实际频道。您可以将它们存储在内存中，可能与客户端传递的其他一些标识符相关联，并且当您需要与相关客户端通信时（例如，将来自 UDP 数据包的数据传递给它们），您可以调用适当的方法该特定存储频道；并且客户会收到通知。

我应该注意，虽然我不特别推荐 HttpDuplexBinding，但除了它的怪癖、稳定性和性能问题之外，它应该适用于您正在做的事情，并且与网络.TCP。尽管客户端在技术上会“轮询”服务器，但这对你来说是隐藏的。您在服务器上所知道的只是您正在调用特定通道上的方法。底层绑定代码负责确保正确的客户端得到通知。

【讨论】：