BitTorrent uTorrent トランスポート プロトコル(UDP データグラム上に構築された、バッファーに敏感な信頼性の高いストリーム プロトコル)の Boost バージョンを作成しています。私の目標は、データグラムを送受信し、多くの uTP 接続のすべての輻輳とエラー制御を管理する UDP ソケット マネージャーを持つことです。クライアントスレッドは、言うことによって新しいuTP接続を作成するutp_manager.async_connect( endpoint )
か、または言うことによってインバウンド接続を受け入れることができますutp_manager.async_accept( handler )
uTP の仕様は少し薄く、次のような場合に ACK 番号を処理する方法がわかりません。
DATA (seq=1) ----------------> received OK
X-------- ACK=1 (not received)
DATA (seq=2) ----------------> received OK
<---------------- ACK=2 (received OK)
ACK=2 を受信したため、送信者は DATA-1 を ACK として処理しますか? それともDATA-1を再送しますか?その場合、受信者は既に ACK 2 を送信しているにもかかわらず、ACK=1 を送信しますか?
ルールは次のようにする必要があると思います。
- 受信者は常に、受信した最大連続SEQ_NRに対して ACK を送信します(仕様に記載されているように、最後に受信したパケットの SEQ_NR ではありません)。
- 送信者は、1 つの ACK が受信されなくても (上記の例のように) ACK_NR までのすべてのパケットが受信されたと見なすことができます (および選択的 ACK パケット)。
- 受信側にギャップがある場合、最初の欠落パケットの前に受信した最後のパケットの SEQ_NR に ACK を送信し続けます (さらに、それが行う選択的 ACK を加えます)。
- 送信者は、3 つの重複 ACK を受信した場合、または ACK_NR の後の 3 つのパケットが選択的 ACK で ACK された場合に、ACK_NR + 1 でパケットを再送信します)。
これらのシナリオを設定して既存の実装に対して実行できることはわかっていますが、正しいことが保証されている参照実装はないと思います。設定するのは面倒です。プロトコルを研究または実装した誰かが、私がそれを正しく理解したかどうか、または何が欠けているかを言うことができることを願っています.