用于双工回调的 WSDualHttpBinding
在现实场景中使用 WSDualHttpBinding 进行双工回调是否有效？ 假设我有一个使用随机端口的 .NET 应用程序，该服务是否能够解析客户端的基地址和回调端口？
Would using WSDualHttpBinding for duplex callbacks work in real-world scenarios? Say, I have a .NET application that uses a random port, would the service be able to resolve the client's base addresses and port for callbacks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的问题的完整答案取决于“真实场景”是 Intranet 还是 Internet 场景。 虽然 WSDualHttpBinding 在这两种情况下都适用，但有一些具体情况需要注意：
Intranet
WSDualHttpBinding 将在 Intranet 情况下使用预配置的自定义端口与您的 .NET 应用程序配合使用，并且“是”该服务将能够解析客户端的基地址和回调端口：具体如何解释如下。 下面解释的原因是 WSDualHttpBinding 主要设计用于在 Internet 上使用。
当您可以在客户端和服务器上使用 WCF 时，在 Intranet 方案中的双工回调最好通过使用 NetTcpBinding 或 NetNamedPipeBinding 来实现。 这些绑定分别使用 TCP 和 ICP 作为传输（而不是 HTTP）和自定义二进制编码，这就是双方都需要 WCF 的原因。 对于对客户端的回调，将重新使用用于通过绑定连接到服务的相同通道，而无需打开新端口。
互联网
在互联网场景中，有效的 HTTP 请求和响应仅在一个方向上传播，HTTP 被设计为一种单向协议。 因此，当使用 WSDualHttpBinding 时，WCF 会为回调创建一个单独的 HTTP 通道。 回答你的第二个问题：默认情况下，此回调到客户端的目标地址由客户端计算机主机名和端口 80 组成。 例如，如果客户端是开发机，并且安装了 IIS，则在某些情况下，端口 80 将被独占，这将导致与您的原型应用程序发生冲突。 这就是 这篇博文 提供了一个解决方案以及 ClientBaseAddress 属性旨在提供帮助的内容。 无论您使用哪个端口（默认端口或自定义端口），您都必须确保两侧的所有防火墙和路由器均已正确配置，以允许建立传出通道和单独的回调通道。
.NET 应用程序也可以表示 Silverlight 应用程序。 由于浏览器中运行的 Silverlight 应用程序无法接受新传入的 HTTP 连接，因此具有单独反向通道的 WSDualHttpBinding 将无法工作。 因此，PollingDuplexHttpBinding 首先在 Silverlight 2 中创建，这可以被认为是一个聪明的“技巧”，通过保持请求通道长时间打开（长轮询）并将其用作后台通道来绕过 HTTP 是单向的事实。回调给客户端。 这对客户端和服务器端都有许多影响，特别是与扩展相关的影响，有关更多详细信息，请参阅 这篇文章来自我的博客。
了解您的特定“现实世界场景”和您的用例，希望这将帮助您找出用于双工回调的正确绑定。
A complete answer to your question depends on the "real-world scenario" being either an Intranet or an Internet scenario. Although WSDualHttpBinding works in both scenarios there are specifics to be aware of:
Intranet
WSDualHttpBinding will work with your .NET application using a preconfigured custom port in an Intranet scenario and "Yes" the service will be able to resolve the client's base addresses and port for callbacks: exactly how is explained below. The reason it's explained below is that WSDualHttpBinding is primarily designed to be used over the Internet.
Duplex callbacks in an Intranet scenario when you can use WCF on both client and server is best achieved by using NetTcpBinding or NetNamedPipeBinding. These bindings use TCP and ICP respectively as transport (rather than HTTP) and a custom binary encoding which is why WCF is required on both sides. For calls-back to the client the same channel used to connect to the Service via the Binding is re-used without requiring a new port to be opened.
Internet
In an Internet scenario valid HTTP requests and responses only travel in one direction, HTTP is designed as a one-way protocol. When using the WSDualHttpBinding WCF therefore creates a seperate HTTP channel for callbacks. In answer to your second question: the destination address for this call-back to the client is composed of the client machine hostname and port 80 by default. If the client is a development machine for example and has IIS installed, port 80 will be exclusively reserved in some scenarios which will cause conflicts with your prototype application. This is what this blog post presents a solution for and what the ClientBaseAddress property is designed to help with. Regardless of which port you go with - the default or a custom one, you must ensure all firewalls and routers on both sides are configured correctly to allow both the outgoing channel and the seperate callback channel to be established.
A .NET application can also denote a Silverlight application. Because of the fact that a Silverlight application running in a browser cannot accept new incoming HTTP connections, WSDualHttpBinding with it's seperate back channel will not work. Hence PollingDuplexHttpBinding was created firstly in Silverlight 2 which can be thought of as a clever 'trick' to get around the fact that HTTP is unidirectional by keeping the request channel open for a long time (long polling) and using it as a back channel for calls back to the client. This has a number of implications on both the client and server side particularly relevant to scaling, for more detail please see this post from my blog.
With an idea of your particular "real-world scenario" and your use-cases hopefully this will help you work out the correct binding to use for duplex callbacks.
如果它是防火墙后面的应用程序，理论上是可以的。 这取决于你所说的“现实世界”是什么意思； 如果您的意思是“高性能”，也许 NetTcpBinding 是更好的方法。
If it's an application behind a firewall, theoretically yes. It depends on what you mean by "real world"; if by that you mean "high performance" perhaps NetTcpBinding is a better appraoch.