3

システムはUDPを使用し、前方誤り訂正を使用して、いくつかのパケットが失われた場合でも、再送信せずにメッセージ全体を送信できます。これは実際にうまく機能するのでしょうか、それとも余分なオーバーヘッドが無駄になりすぎるのでしょうか。

4

5 に答える 5

5

音声 (VoIP) など、エラーを回避したいアプリケーションや、停止(NAK されたパケットを再送信する) や待機 (再送信されるまで) が不要なアプリケーションに役立つと思います。

そのため、UDP のリアルタイム トランスポート プロトコルフレーバーの上に実装される可能性があります。

レイテンシがひどいのではないでしょうか?

前方誤り訂正がエンドツーエンドの遅延を増加させるかどうかを尋ねていますか? もしそうなら、答えは「いいえ」だと思いますが、必要な帯域幅は増加します。

ジッターを避けるために、常にある程度のレイテンシーが必要だと思います。たとえば、「音声チャネル全体を 200 ミリ秒遅らせて、すべてのパケットがインターネットを通過するのに 0 から 200 ミリ秒かかるようにしましょう。違った終わり方。"

これらの数値を考えると、前方誤り訂正がないということは、200 ミリ秒ごとに、それぞれ 20 ミリ秒のデータを含む 10 個のパケットを送信することを意味する可能性があります...そして、1 つが失われた場合、それはもう 1 つのギャップ (グリッチ) です。終わり。

一方、前方誤り訂正があるということは、200 ミリ秒ごとに 10 パケットを送信することを意味する可能性があります...各パケットには 20 ミリ秒のデータと、別のパケットで既に送信された 10 ミリ秒のデータが含まれます (または、おそらくあなた20 ではなく 30 パケットを送信します)。次に、単一のパケットが失われた場合、それが運んだデータは冗長に配信され（他の2つのパケットのそれぞれで半分ずつ）、デコードされた出力のグリッチを回避します.

于 2009-02-12T20:48:40.490 に答える
1

また、ハードドライブや光ディスクなど、破損していないデータを取得するためにソースに戻ることができないストレージメディアにも適しています。実際、ハードドライブと光ディスクはどちらも前方誤り訂正を非常に広範囲に使用しています。

前方誤り訂正は、エラーが一度に数ビットだけノックアウトする傾向がある無線通信でも広く使用されています。パケット全体を単一のビットエラーで失うのではなく、前方誤り訂正を使用して、破損したビットを修正します。

于 2009-05-08T23:08:46.323 に答える
0

アプリケーションによって異なります。

ゲームなどのアプリケーションでは、データが少し失われても大きな違いにはならないため、エラー修正は常に必要です。

ただし、アプリケーションが特定の順序どおりのデータを必要とする場合は、何らかのエラー修正が必要です。

「オーバーヘッド」の問題ではなく、「アプリケーション」の問題です。

于 2009-02-12T20:48:09.523 に答える
0

再送信の「価格」が、あなたが支払おうとしているものよりも高い場合。
たとえば、サテライトの伝播時間は非常に長いため、パケットを再度送信するよりも数バイト多く送信することをお勧めします。

于 2013-05-30T16:39:48.030 に答える
0

簡単な答えは、高帯域幅の高遅延 (「長距離」を意味する) リンクを送信している場合は、前方誤り訂正が理にかなっているということです。そうでなければ、おそらくそうではありません。

于 2009-05-08T22:44:28.207 に答える