8

実際には、PCに接続されたWebカメラの写真を受信するAndroidアプリをコーディングしています。より多くのfpsを取得するには、tcpの代わりにudpプロトコルを使用します。アイデアは、PCが写真を電話のIPとポートに送信するというものです。ただし、電話のプロバイダーにはさまざまなパブリックポートがあります。だから私は直接電話にかけることができません。そのため、UDPホールパンチングを使用して問題を解決しようとしましたが、うまくいきませんでした。私の電話が1つのパケットをPCに送信すると、PCは電話のパブリックIPとポートを取得します。これは、接続を開いたままにするために毎秒発生します。次に、サーバーはWebカメラフレームをこのIPとポートにできるだけ速く送信します。しかし、電話は1〜2秒で10〜15枚の写真を受信します。その後、電話はそれ以上のパケットを受信しないため、プロバイダーは後続のすべてのパケットなどをフィルタリングするように見えます。

今私の質問は：何が起こっているのか（またはプロバイダーは何をしているのか）、そしてどうすればこの問題を修正できますか？TCPプロトコルは機能しますが、オーバーヘッドとエラー修正が多すぎるため、ストリーミングには遅すぎます。

4

1 に答える 1

12

UDP に関して留意すべき問題がいくつかありますが、これらの問題はモバイル ネットワークで大きくなります。

  • おそらくご存じのとおり、UDP データグラムを送信すると、それが通過するという保証はまったくなく、通過しなかった場合に何が起こったのかを確実に知る方法はありません。

  • 約 1400 バイトを超えるペイロードは、IP フラグメントに分割される可能性があります。受信側のオペレーティング システムは、それらをパケット全体に再構築できますが、すべてのフラグメントが到着した場合に限ります。一部のルーターはフラグメントを任意にドロップし、一部のファイアウォールはフラグメントに特定のバイト パターンが含まれている場合にフラグメントをドロップし、一部のファイアウォールはフラグメントの送信速度を制限します。データグラムを常に小さく保ち、再構築と欠落部分の繰り返しを自分で処理することをお勧めします。

  • フロー制御はありません。ルーターのバッファーがいっぱいになると、それ以降はすべて破棄されます。一部のルーターは、バッファーが増加しているが、まだいっぱいになっていない場合、一定の割合のパケットをランダムにドロップし始めます。一部のファイアウォールは、任意のしきい値よりも高速になると、UDP ソースをブラックリストに登録します。

一般に、デバイスとファイアウォールのメーカーは UDP をがらくたのように扱う傾向があるため、UDP 開発者として、だまされないように特別な善良な市民になる必要があります。フローを調整し、パケットのドロップは速度が速すぎる可能性があることを覚えておいてくださいパケットが小さい。制御された環境で回避できることはたくさんありますが、アプリケーションが「実際に」デプロイされる場合は、問題を回避するために多くの注意深いプログラミングが必要になります。

于 2012-08-20T17:54:24.593 に答える