2 つのピア間に信頼性の低い損失の多いチャネルが既にあるとします。パフォーマンスを低下させずにデータを確実に転送するには、どの方法を提案できますか? また、基礎となるプロトコルは TCP ではありません (これはすでに信頼性があります)。(質問を一般化するために損失のあるチャネルを使用しました。)
(私の知る限り、RDT(rfc-908)、Go Back-Nなどのいくつかの方法が存在します。)
2 つのピア間に信頼性の低い損失の多いチャネルが既にあるとします。パフォーマンスを低下させずにデータを確実に転送するには、どの方法を提案できますか? また、基礎となるプロトコルは TCP ではありません (これはすでに信頼性があります)。(質問を一般化するために損失のあるチャネルを使用しました。)
(私の知る限り、RDT(rfc-908)、Go Back-Nなどのいくつかの方法が存在します。)
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Reliable_transmission
誰かがすでに問題を解決していて、存在するすべての言語でそれを行うライブラリ(TCP / IP)または10が存在するためです。
これは哲学の質問ですか?
Steve-oが言ったように、FECとKdanskyが再送信を提案したように、良い出発点です。再送信の主なボトルネックはラウンドトリップ時間であり、これが失われたパケットの受信に遅延を引き起こします。ただし、FECはまったく別の主題であり、パケットレベルで適用できます。Steve-oが再び言ったように、ボトルネックは、冗長ストリームを生成することによって発生する帯域幅のオーバーヘッドになります。非常に単純に見えますが、Parity FEC、Reed-Solomon、Turbo code、Raptor QなどのさまざまなFECスキームは、パラメータに応じて遅延、帯域幅オーバーヘッドなどにさまざまな影響を及ぼします。(主に、冗長ストリームを生成するために使用するエンコードレートに基づいています)
パフォーマンスの損失がないということは、通常、ACK を送信する受信者から送信者へのバック チャネルへの依存を減らすことを意味します。これは通常、データグラムを使用し、何らかの形式の前方誤り訂正 (FEC) を使用するカスタム プロトコルを意味します。FEC はスライディング スケールであり、多くの場合、重大なパフォーマンス ペナルティになる可能性があることに注意してください。これは、定義上、追加の冗長データをプリエンプティブに送信して、受信者がそれを要求する必要がないようにするためです。
http://en.wikipedia.org/wiki/Forward_error_correction http://udt.sourceforge.net/