WCF，4.0，双向

Question

.NET 4.0现在提供了...what选项，在某种程度上支持客户端的NAT (即NAT后的客户端)。

我更喜欢使用基于HTTP的东西，但这是一个弱条件-我认为中期我将有一些WCF外部的非http通信，所以代理遍历是我可以推迟的事情。

在.NET 4.0之前，基本上服务器->客户端通道将从服务器打开，这使得NAT无法穿透。

轮询是不可接受的-我们在这里讨论时间敏感的信息。

那么，我现在有什么选择呢？

Answer 1

您可以从客户端打开一个连接并使其保持打开状态。或将NAT上的端口转发到客户端，因此连接到NAT:34823将转到192.168.xxx.xxx:80。或者向微软支付一些钱来使用他们的Service Bus，这还没有完全完成，未来也不确定。或者做一些聪明的黑客，在客户端和服务器上安装Skype，通过API发送你的消息。

Answer 2

这不是特定于.net 4.0的，但你可以使用Windows Azure Service Bus。

如果您的应用程序需要双向连接，那么您实际上有两个选择:要么您押注于可用的变通方法并承担后果(就像BitTorrent那样)，要么您为您的应用程序构建和操作某种形式的中继服务。中继服务接受和维护来自防火墙和/或NAT客户端的连接，并在它们之间路由消息。实际上，所有聊天、即时消息、视频会议、VoIP和多人游戏应用程序以及许多其他流行的互联网应用程序都依赖于某种形式的中继服务。

中继服务面临的挑战是，它们难以以一种能够提供Internet规模的方式来构建，在这种规模下，它们需要像大型即时消息传递网络那样在数千甚至数百万个连接之间进行路由。一旦你有了一个可以支持这种规模的Relay，它的操作成本就会非常高。如此昂贵，事实上，所需的投资和由此产生的运营成本对绝大多数软件公司来说是完全负担不起的。连通性挑战是一个真正的创新障碍，代表着一个重要的进入障碍。

好消息是，微软.NET服务总线提供了一系列的双向、点对点连接选项，包括中继通信。您不必构建或运行自己的构建块；您可以使用此构建块来代替。.NET服务总线涵盖四个逻辑功能区域:命名、注册、连接和事件。

http://vasters.com/clemensv/PermaLink,guid,92d78bee-2cfd-4a29-95ab-c5abb9b905e7.aspx