...クライアント側（つまり、NATの背後にあるクライアント）のNATをサポートする方法で、.NET4.0には現在どのようなオプションがありますか。
HTTPベースのものを使用したいのですが、それは弱い条件です。中期的には、WCFの外部でhttp以外の通信が行われると思います。そのため、プロキシトラバーサルは遅延する可能性があります。
.NET 4.0より前では、基本的にサーバー->クライアントチャネルがサーバーから開かれ、NATを通過できないものにするという問題がありました。
ポーリングは受け入れられません-ここでは時間に敏感な情報について話します。
だから、今私のオプションは何ですか？
クライアントから接続を開いて、開いたままにしておくことができます。または、NATのポートをクライアントに転送するため、NAT：34823に接続すると192.168.xxx.xxx:80になります。または、Microsoftにサービスバスを使用するためにいくらかのお金を払ってください。これは正確には終了しておらず、将来は不透明です。または、巧妙なハッキングを行い、クライアントとサーバーの両方にSkypeをインストールし、APIを介してメッセージを送信します。
これは.net4.0に固有のものではありませんが、WindowsAzureサービスバスを使用できます。
アプリケーションで双方向接続が必要な場合は、事実上2つの選択肢があります。利用可能な回避策に賭けて結果に対応するか（BitTorrentのように）、アプリケーション用に何らかの形式のリレーサービスを構築して運用します。リレーサービスは、ファイアウォールやNATを使用したクライアントからの接続を受け入れて維持し、それらの間でメッセージをルーティングします。事実上、すべてのチャット、インスタントメッセージング、ビデオ会議、VoIP、マルチプレーヤーゲームアプリケーション、およびその他の多くの一般的なインターネットアプリケーションは、何らかの形式のリレーサービスに依存しています。
リレーサービスの課題は、大規模なインスタントメッセージングネットワークのように、数千または数百万もの接続間をルーティングする必要があるインターネット規模を提供できるように構築するのが非常に難しいことです。そして、そのような規模をサポートできるリレーができたら、操作するのに非常に費用がかかります。実際、非常に高額であるため、必要な投資とそれに伴う運用コストは、大多数のソフトウェア会社にとって完全に手の届かないものです。接続の課題は真のイノベーションブロッカーであり、重要な参入障壁を表しています。
幸いなことに、Microsoft .NET Service Busは、リレー通信を含むさまざまな双方向のピアツーピア接続オプションを提供します。自分で作成したり、自分で実行したりする必要はありません。代わりに、このビルディングブロックを使用できます。.NET Service Busは、ネーミング、レジストリ、接続、およびイベントの4つの論理機能領域をカバーしています。
http://vasters.com/clemensv/PermaLink,guid,92d78bee-2cfd-4a29-95ab-c5abb9b905e7.aspx