WCF 客户端-服务器同步：轮询与绑定
我正在开发 WCF 客户端-服务器应用程序。其中客户端必须不断与服务器同步（至少每 10 秒）。目前我正在轮询服务器以查看是否有任何更改。如果是这样，更改（有时是数十条数据库记录）将被拉到客户端。
我的设计感觉有点笨重，所以我研究了 gtalk（和其他 XMPP）客户端如何保持同步。根据这篇维基百科文章，XMPP 放弃了轮询方法并现在仅使用 HTTP 绑定。
我认为 WCF 也可以做同样的事情。我认为现在 99% 的 WCF 应用程序只是 1) 打开连接，2) 执行事务，3) 关闭连接。
所以我的问题是：
- 有谁知道一个例子 如何实施这样的 异步绑定方法 世界CF？
- 那有什么作用 取决于服务器的客户端数量 可以容纳，因为多个 连接必须是 维持。
- 还有其他缺点吗？
I am working on WCF client-server app. where the client has to be constantly synchronized with the server (at least every 10 seconds). At the moment I'm polling the server to see if anything has changed. If so, the changes (sometimes tens of db records) are pulled down to the client.
My design felt a bit clunky so I had a look at how gtalk (and other XMPP) clients keep in-sync. According to this Wikipedia article, the XMPP dropped the polling approach and is now using HTTP binding only.
I presume it is possible to do the same thing for WCF. I think 99% of the WCF apps today simply 1) opens a connection, 2) does the transaction, and 3) closes the connection.
So my questions are:
- Does anyone know of an example of
how to implement such an
asynchronous binding approach with
WCF? - What effect doe that have
on the number of clients a server
can accommodate, since multiple
connections will have to be
maintained. - Any other drawbacks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这种异步方法可以通过双工绑定来实现。 WCF 提供了 WSDualHttpBinding，它由两个相关的 http 传输组成。第一个是从客户端到服务器，第二个是从服务器到客户端。方法是在通信开始时从客户端调用服务器。服务器存储客户端回调通道并在需要时使用它来推送更新。这可以进一步扩展到完整的发布订阅消息交换模式。
默认情况下，服务器必须为每个连接的客户端代理（每个会话）维护服务实例。您必须正确设置服务限制以允许许多客户端的连接。对服务器和客户端数量的影响取决于服务实现。
WSDualHttpBinding 有局限性。例如 - 不允许传输安全 - 只能使用消息安全，不允许流式传输，需要可靠的会话等。实现中存在一些陷阱，例如长时间不活动的超时或导致通道故障的未处理异常。
Such asynchronnous approach can be implemented by duplex binding. WCF provides WSDualHttpBinding which consists of two corelated http transports. One from the client to the server and second from the server to the client. The approach is to call the server from the client at the beginning of communication. The server stores client callback channel and use it to push updates when needed. This can be futher extended to full Publish Subscribe message exchange pattern.
By default server has to maintain service instance for each connected client proxy (for each session). You have to correctly set up service throttling to allow connection of many clients. The effect on the server and number of clients depends on service implementation.
WSDualHttpBinding has limitations. For example - transport security is not allowed - only message security can be used, streaming is not allowed, reliable session is required, etc. There are some pitfalls in implementation like timeouts in longer inactivity or unhandled exceptions faulting the channel.