wcf - 用于双工回调的 WSDualHttpBinding

Question

将 WSDualHttpBinding 用于双工回调是否适用于实际场景？比如说，我有一个使用随机端口的 .NET 应用程序，该服务是否能够解析客户端的基地址和端口以进行回调？

Answer 1

您的问题的完整答案取决于“真实世界场景”是 Intranet 还是 Internet 场景。尽管 WSDualHttpBinding 在这两种情况下都有效，但有一些细节需要注意:

内网

WSDualHttpBinding 将在 Intranet 场景中使用预配置的自定义端口与您的 .NET 应用程序一起工作，并且"is"该服务将能够解析客户端的基地址和端口以进行回调:具体方法如下所述。下面解释它的原因是 WSDualHttpBinding 主要设计用于在 Internet 上使用。

当您可以在客户端和服务器上使用 WCF 时，在 Intranet 方案中的双工回调最好通过使用 NetTcpBinding 或 NetNamedPipeBinding 来实现。这些绑定(bind)分别使用 TCP 和 ICP 作为传输(而不是 HTTP)和自定义二进制编码，这就是为什么双方都需要 WCF。对于客户端的回调，用于通过绑定(bind)连接到服务的相同 channel 被重新使用，而无需打开新端口。

互联网

在 Internet 场景中，有效的 HTTP 请求和响应仅在一个方向传输，HTTP 被设计为单向协议(protocol)。因此，当使用 WSDualHttpBinding 时，WCF 会为回调创建一个单独的 HTTP channel 。回答您的第二个问题:此回调客户端的目标地址默认由客户端计算机主机名和端口 80 组成。例如，如果客户端是开发机器并且安装了 IIS，80 端口将在某些情况下独占保留，这将导致与您的原型(prototype)应用程序冲突。这就是 this blog post提供了解决方案以及 ClientBaseAddress 属性旨在帮助解决的问题。无论您使用哪个端口(默认端口或自定义端口)，您都必须确保正确配置两侧的所有防火墙和路由器，以允许建立传出 channel 和单独的回调 channel 。

.NET 应用程序也可以表示 Silverlight 应用程序。由于在浏览器中运行的 Silverlight 应用程序不能接受新的传入 HTTP 连接，因此带有单独反向 channel 的 WSDualHttpBinding 将不起作用。因此，PollingDuplexHttpBinding 最初是在 Silverlight 2 中创建的，这可以被认为是一个巧妙的“技巧”，通过保持请求 channel 长时间打开(长轮询)并将其用作反向 channel 来解决 HTTP 是单向的这一事实。回电给客户。这对客户端和服务器端都有很多影响，特别是与扩展相关，更多详细信息请参阅 this post from my blog .

了解您特定的“真实世界场景”和您的用例，希望这将帮助您制定正确的绑定(bind)以用于双工回调。