WCF，4.0，双向
....NET 4.0 现在有哪些选项可以支持客户端的 NAT（即 NAT 后面的客户端）。
我更喜欢使用基于 HTTP 的东西，但这是一个弱条件 - 我认为中期我无论如何都会在 WCF 之外进行一些非 http 通信，因此代理遍历是我可以延迟的事情。
在 .NET 4.0 之前，存在一个问题，即基本上服务器->客户端通道将从服务器打开，这使得 NAT 不可穿越。
轮询是不可接受的 - 我们在这里谈论时间敏感的信息。
那么，我现在有什么选择呢？
...what options are there now with .NET 4.0, in a way that does support NAT for the client side (i.e. client behind NAT).
I would prefer to use something HTTP based, but that is a weak condition - I think mid term I will have some non http communication outside WCF anyway, so proxy traversal is something I could delay.
Pre .NET 4.0 there was the issue that basically the server->client channel would be opened from the server, which made NAT something non-traversable.
Polling is not acceptable - we talk time sensitive information here.
So, what are my options now?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以从客户端打开连接并保持打开状态。
或者将 NAT 上的端口转发到客户端，因此连接到 NAT:34823 将转到 192.168.xxx.xxx:80。
或者付微软一些钱来使用他们的服务总线，但它还没有完全完成，未来也不确定。
或者进行一些巧妙的修改，在客户端和服务器上安装 Skype，通过 API 发送消息。
You can open a connection from the client and just keep it open.
Or forward ports on NAT to clients, so connecting to NAT:34823 will go to 192.168.xxx.xxx:80.
Or pay Microsoft some money to use their Service Bus, which is not exactly finished and with uncertain future.
Or do some clever hack, install Skype on both clients and servers, send your messages trough the API.
这并非特定于 .net 4.0，但您可以使用 Windows Azure 服务总线。
http://vasters.com/clemensv/PermaLink, guid,92d78bee-2cfd-4a29-95ab-c5abb9b905e7.aspx
This is not specific to .net 4.0, but you could use Windows Azure Service Bus.
http://vasters.com/clemensv/PermaLink,guid,92d78bee-2cfd-4a29-95ab-c5abb9b905e7.aspx