問題タブ [packet-loss]

ゲーム エンジン (Unity) から Android フォンに UDP を介して画面を共有できるようにするコードに取り組んでいます。

このプロセスは、実際にはスクリーンショットを撮り、それらを jpeg バイト配列にデコードし、それらのバイト配列を複数のパッケージに分割するだけです (必要な場合)。

プロジェクトを実行すると、実際には画像が送信されますが、受信時に歪んだり、めちゃくちゃになったりするものがあります。

そのため、バッファ サイズを少しいじってみたところ、受信 UDP クライアントのバッファ サイズを大きくすると、実際にデータの損失や破損が改善されることがわかりました。しかし、残念なことに、ユーザーが無視できない破損したデータがまだ多すぎます。

しばらくすると、ホスト (私の電話) がクラッシュします。これはパッケージのバッファサイズと関係があると思いますが、フラッディングを超えたのでしょうか?

とにかく、ここに接続を処理するコードがあります。現在、データを一方向（コンピューター -> 電話）でのみ送信していますが、電話からコンピューターに他の情報も送信するように設定されています（ただし、これは後で行うため、最初にこれを機能させる必要があります）。

現在、変数bufferSizeを に設定しており、スライスされた画像データ パッケージは、合計サイズがish20.000のシリアル化されたクラス (フレーム ID、パッケージ ID、画像データなど)です。15.200

UDP の結果はわかっていますが、できる限りレイテンシを低くする必要があります。TCP に切り替える必要がありますか? 現在の画像サイズは、青色の背景にいくつかの粒子がある立方体の画像をテストしているだけです。より複雑な画像をストリーミングすると、JPEG 圧縮ファイルも増加すると思います。

ありがとう！

私が取り組んでいる小さなプロジェクトのために、ネットワーク経由でオブジェクトをシリアル化することに取り組んでいます。私が使用しているコードはほとんど問題なく動作します。バイトが正しく読み込まれないことがありますが、UI をリロードするだけで修正されます。ただし、同じシステムで通信しているときに、別のシステムに移動するとすぐに、コードは部分的にしか機能しません。ネットワーク経由でサイズ 30 の文字列配列を送信しようとするとすぐに、サーバーは受信パックの報告を停止し、奇妙なことに一貫してエラーをスローするものは何もありません。ときどきポップアップするエラーがいくつかあります。

これは、コンソールに表示される主なエラーであり、対処方法がわかりません。私はネットワークプログラミングの経験があまりないので、どこが間違っているのか頭を悩ませています。

私の主な懸念は、何らかの理由で、クライアントが 330 バイトを超えて送信しようとすると、サーバーが受信バイトの報告を停止し、全体的なグリッチ動作を引き起こすことです。サーバーは確実に接続を受信して​​いることを示していますが、シンプルは何らかの理由ですぐにそれを強制終了します。何が起こっているのか、またはそれを修正する方法を知っている人がいれば、助けていただければ幸いです!

前もって感謝します！

クライアント：

サーバ：

HTTP 経由でリモート サーバーからビデオをストリーミングしています。クライアントで Wireshark を使用してパケットをキャプチャしました。接続のクライアントが、一時停止するたびに数秒間、パケットの送信を時々停止していることに気付きました。RTT は 170 ミリ秒から 200 ミリ秒の間で、帯域幅は 20 Mbps であり、接続のパケット損失率は 5.8% と高く、サーバーから通知されたウィンドウ サイズは 14 KB から 64 KB 近くまでスロー スタートで増加していることがわかります (ウィンドウ値)。サイズ=501、[計算されたウィンドウ サイズの値=64128]、ウィンドウ サイズの倍率=128)。

私の混乱は、接続用のサーバーの受信バッファーがまったく満たされていないときに、クライアントが時々パケットの送信を停止するのはなぜですか?

この状況 (ブラウザ ストリーミング ビデオ) でパケットが失われると、どのような影響がありますか?

私はこの可能な状況を考えています：

ブラウザは単一の接続でビデオをストリーミングします (同じ TCP 接続を再利用する HTTP を使用)。サーバーがクライアントに応答を送信している間、クライアント ACK が時間内に受信されないため、サーバーは停止し、ACK の再送信を待機し続けます。クライアントはサーバーの応答パケットを待っています。もちろん、サーバーからの ACK も待っています。しばらくすると、クライアントは ACK の再送信を開始し、すべてが再び機能し、キャプチャされたデータから、一時停止直後のパケットがクライアントからサーバーへのものであることがわかりました。

この理解は正しく、理にかなっていますか?

複数の Axis IP カメラがあり、それらの H264 出力を RTP 経由でアプリケーションにストリーミングしたいと考えています。これまでのところ、ほとんどの場合、通常は 1 台のカメラですべてが機能しています。複数のカムを接続するとすぐに、使用しているすべての jrtplib インスタンスで多くの欠落パケットが発生し、結果としてビデオの品質が低下します (アーティファクト、画像の破損など)。

そこで、サンプルから多かれ少なかれ直接取得したコードを使用して、カメラを 1 つだけ接続し、jrtplib インスタンスを 1 つだけ使用する小さなテスト セットアップを作成しました。

この単純なテストでも、欠落したパケット (欠落したシーケンス番号) が発生し、欠落したシーケンス番号が単に遅延しているだけかどうかも確認しましたが、違います。

しかし、transparams.SetRTPReceiveBuffer1048576 バイトなどのかなり高い値を追加すると、少なくともこのサンプルではパケットの欠落がなくなります。

私の実際のコードでは、受信バッファを増やしても役に立ちません。session.Poll()また、別のスレッドに移動しようとしました。

Wireshark を使用して UDP パケットをキャプチャしても、ドロップされたパケットは表示されません。誰かがこれを経験したことがありますか、それとも別のライブラリを使用するための提案さえありますか? 私はこの時点でかなり立ち往生しています...

ヒントをありがとう、多分それはほんの小さな問題で、私はそれを見ません

よろしく

ネットワーク診断のテストを目的としたプロジェクトに取り組んでいます。私が現在取り組んでいるセクションには、TCP および UDP 接続のテストが含まれます。測定ポイントの 1 つは、TCP と UDP の両方のパケット損失です。

過去に使用したもの: '/statistics/rx_dropped'(そのファイル パスの最初の部分は省略しています)、指定されたネットワーク インターフェイスで合計でドロップされたパケットの数を指していると言えば十分です。

ただし、Android Nでは、このファイルを読み取るにはルートが必要であり、このアプリが使用される電話がルート化されているとは想定できません。

ルート化を必要としない、少なくとも TCP のクライアント側でパケット損失を測定する適切な方法を誰かが持っていますか?

私はネットワーキングの専門用語をほとんど知っているので、恥ずかしがらないでください。私が尋ねる理由は、私が測定する方法がかなりエレガントでなければならないからです (既存の Java/Android ライブラリを使用するか、デバイスからパケット損失を読み取る合法的な方法を見つけるかのいずれか) ）。

アプリケーションの堅牢性をテストしたい。だから、数ナノ秒の間、いくつかのパケットをドロップするLinuxコマンドが必要です。これらのパケットをマルチキャスト IP ポートから受信しています。