UDPホールパンチングが3Gで実行されない
ソフトウェアに穴あけ機能を実装しようとしています。重要なのは、ユーザーと通信するために、すでに作成されたTCPサーバーを使用してこれを実装しているということです。
ここに私がこれまで持っているものがあります：
- 「A」は、UDPサーバー「US」（ポート9333）にメッセージを送信します。
- 「US」は、接続したポートを「A」に送り返します（ポート31000-ローカルポート31005）
- 「A」はTCPサーバー「TS」にメッセージを送信し、Bに接続したい（そしてポート31000を指定したい）ことを伝えます。
- 「TS」は「B」にメッセージを送信し、「A」のポート（31000）とIPを通知します。
- 「B」は「US」にメッセージを送信します（ポート9333）
- 「US」は「B」にメッセージを送信して、ポート45000（ローカルポート45005）を通知します。
- 「B」は「TS」にメッセージを送信し、udpポート（45000）を提供します。
- 「TS」はメッセージを「A」に送信し、Bのudpポート（45000）とip
- 「A」は、ポート45000でBのIPにudpメッセージの送信を開始し、ローカルポート31005でリッスンします。
- 「B」は、ポート31000でAのIPにudpメッセージの送信を開始し、ローカルポート45005でリッスンします。
もちろん、ポート31000、31005、45000、45005はここにあります。たとえば、新しい接続ごとにポートが変更され、9333のみが静的です。
私は、実際にあるべき以上に、何度も行き来していることを知っています。事実、私はTCPサーバーを使用して両方のユーザーと通信する必要があります。udpサーバーは、ユーザーのポートを自分に返すためにここにあるので、TCPに送信できます。サーバ。
しかし、ユーザー間のメッセージは誰にも届きません...なぜだれかが知っているでしょうか？
EDIT：
http://nattest.net.in.tum.de/test.php でルーターをテストしましたが、UDPホールパンチングは正常に機能するため、問題はルーターからではなく、ルーターから発生しています。プロトコル...
ユーザーが同じNATの背後にいる場合、すべてが正常に機能します。もちろん、privates ipを使用しますが、コードも機能していることを意味するため、プロトコルの問題が発生します...
EDIT 2：
実際、私はそれを半分動作させました（そして問題は実際にはプロトコルではなくコードから来ていました...私は2人のユーザーを3GでiPhoneに接続し、1人はWifiのNATの後ろに接続しました。
面白いことに（それほど多くはありませんが）、両方のユーザー間でデータを送受信できたのは1つのソケットだけでした。 （iphoneによって開始されたソケット）プロトコルによれば、2つの適切に接続されたソケットが必要ですが、間違っていますか？
したがって、私は自分のNATに穴を開けることができましたが、実際にはセルラーNATには穴がありませんでした。
もちろん、3Gで接続された2台のiphoneをすぐにテストしました。そして、誰も他からのメッセージを受け取りません。
携帯電話について何か見落としましたNAT？
P.S. ：私の質問をたくさん更新して申し訳ありませんが、答えが得られなかったので、自分で見つけようとしています...
P.S. 2：NATに穴を開けることができたので、タイトルを「on 3G」に変更しました。
編集3： http://nattest.net.in.tum.de/test.php テストを再度実行しました私のコンピュータを私のiphoneの3G接続を介してインターネットに接続しました。
結果は次のとおりです。 
どうやらすべてのudp穴あけテストは9番目のテストで成功しました。
さらにそれはそうです：
UDPバインディングテスト（？）：エンドポイントに依存しないバインディング、ポート予測は簡単
したがって、3G接続を介して2つのピアを接続するのに問題はないはずです（「ホーム」NATの後ろほどではありません）...私は正しいですか？
EDIT 4：
念のため、2つの異なるUDPサーバーにメッセージを送信して、ポートとローカルポートが3Gで同じかどうかを確認します。
簡単に言うと、両方のサーバーで接続する場合、ポート（ローカルとパブリック）は同じです。 EDIT 2で行われたテストは正しかった、udpはエンドポイントに依存しないので、穴あけを実行する際に問題はないはずです...（少なくとも私のISPでは）
残念ながら、UDPでNATホールパンチングを実行するための100％信頼できる方法はありません。せいぜい、NATとファイアウォールがおそらくほとんどの場合どのように動作するかについて、ある程度推測することができます。しかし、常に例外であり、まれではない場合があります。
この場合、中央サーバーを使用して、2つのピアが互いの外部ポートを把握し、相互にデータの送信を開始しているようです。これはかなり良いアルゴリズムです。問題は、外部ポートのルーティングが宛先によって異なる可能性があることです。つまり、AからBの外部ポートが5000の場合、AからCも5000から来るという保証はありません。したがって、中央サーバーが認識したポートを記録しても、他の人との接続に役立たない場合があります。
ここにいくつかの関連する質問といくつかの詳細があります。
NAT遅れているのは対称であるか、宛先に応じて発信ポート番号を変更します。対称NATを介した穴あけには、別の方法が必要です（いずれかのTURNまたはUDPマルチホールパンチングです。次のようにしてみてください： https://drive.google.com/file/d/0B1IimJ20gG0SY2NvaE4wRVVMbG8/view?usp=sharing