c# - 使用 WCF(或其他解决方案)保护双工通信的最佳方法

Question

我需要允许多个客户端(winforms 应用程序)通过互联网(在远程位置)连接到服务器，并启动双工通信，有时会发送大量流量。

目前，我们使用 WCF 通过 netTcpBinding 进行双工通信，使用我们自己的证书在传输层上进行保护。虽然这可行，但我担心一些事情:

• 设置起来很麻烦 - 我们为每个客户端创建一个证书以在服务器上识别它，并且需要在客户端机器和服务器上为每个客户端注册证书
• 因为我们在某个端口上使用 tcp，所以我们依赖于在客户端打开该部分，以便它可以通过 tcp 启动通信。一些客户地点不喜欢这样。
• 我们需要能够理想地保证交付

作为替代方案，我想知道是否使用 wsDualHttpBinding，使用单个 SSL 证书来保护它，并让每个客户端发送某种标识符来标识自己。这会解决防火墙问题吗？它在 http 而不是 tcp 上的性能是否足够？据我所知，如果您使用 http，WCF 将创建 2 个 channel 而不是一个 channel (因为 http 不支持双向通信)——所以这听起来可能会导致一些性能问题..

我的问题是，这个解决方案是否更好，或者是否有其他解决方案(例如 NServiceBus)可以使这更容易并解决这些问题？

编辑

从那以后，我了解到 wsDualHttpBinding 不适合我，因为:此绑定(bind)要求客户端具有为服务提供回调端点的公共(public) URI。这对我来说是不可能的。

Answer 1

让我分别解决每个问题:

1. 为什么不使用 TransportWithMessageCredential 而使用用户名和密码 - 这意味着您只需要管理用户名和客户端的密码和您的客户端证书问题消失

2. 使用 NetTcpBinding，服务器需要为入站打开端口流量 - 客户端只需要允许客户端连接到那个端口，他们不需要允许您的入站连接特定端口。他们对允许出站有问题吗连接到您的自定义端口？

3. NetTcpBinding 使用 Tcp，假设您有交付保证拓扑中没有 SOAP 中介。你想保证交货或加工？

WSDualHttpBinding 将强制您的客户端为入站 连接打开一个端口，因此几乎肯定不会被接受。我写了一个blog article前一段时间关于双工这可能有助于澄清问题

您可能还想看看 SignalR它是为这种场景设计的，虽然是为 web 应用程序设计的，但也有一个 .NET 客户端