......現在.NET 4.0有什麼選擇，它支持客戶端（即NAT後面的客戶端）的NAT。WCF，4.0，雙向
我寧願使用基於HTTP的東西，但這是一個弱條件 - 我認爲中期我會在WCF之外有一些非HTTP通信，所以代理遍歷是我可以延遲的事情。
Pre .NET 4.0出現了這樣的問題，基本上服務器 - >客戶端通道將從服務器打開，這使得NAT不可穿透。
輪詢是不可接受的 - 我們在此討論時間敏感信息。
那麼，我現在有哪些選擇？
您可以打開來自客戶端的連接，只要保持開放。 或將NAT上的端口轉發給客戶端，因此連接到NAT：34823將轉到192.168.xxx.xxx:80。 或者向微軟支付一些錢來使用他們的服務總線，這些服務總線並不完全完成並且前景不明朗。 或者做一些聰明的黑客攻擊，在客戶端和服務器上安裝Skype，通過API發送消息。
這不是特定於.net 4.0，但可以使用Windows Azure Service Bus。
如果你的應用需要 雙向連接，你 有效有兩個選擇：要麼 你賭上可用的解決方法 並承擔後果（如 BitTorrent的那樣），或者你建立和 操作某種形式中繼服務 您的應用程序。中繼服務 接受並保持來自 防火牆和/或NAT-ed客戶端的連接，並且 在它們之間路由消息。 實際上所有聊天，即時消息，視頻會議，VoIP， 和多人遊戲應用程序 和許多其他流行的互聯網 應用程序依賴於某種形式的 中繼服務。
與中繼服務所面臨的挑戰是 ，他們非常努力，建立 的方式，他們可以提供 互聯網的規模，他們需要數千甚至 數以百萬計的連接之間 路線爲一體的大型 即時消息網絡做。一旦你有一個繼電器，可以支持 這樣的規模，它是令人難以置信的昂貴 進行操作。實際上這麼貴，所需的投資和 造成的運營成本都是 ，對於大多數軟件公司來說是完全遙不可及的。 連接性挑戰是一個真實的 創新阻斷程序，並代表一個重要的入門障礙。
好消息是，微軟.NET 服務總線提供了一系列的 雙向，對等網絡 連接選項，包括中繼 通信。您不必自己製造 或自己運行;您可以使用此Building Block代替 。 .NET 服務總線涵蓋四個邏輯 功能區域：命名，註冊表， 連接和事件。
http://vasters.com/clemensv/PermaLink,guid,92d78bee-2cfd-4a29-95ab-c5abb9b905e7.aspx