私は現在、かなり基本的なネットワークを研究しており、現在、信頼性の高い伝送をテーマにしています。私はKurrose＆Rossの著書Computer Networkingを使用していますが、レビューの質問のうち2つは次のとおりです。
selection-repeat / go-back-nプロトコルを使用すると、送信者は現在のウィンドウの外にあるパケットのACKを受信することができますか？
SRバージョンの場合、質問に対する私の答えは次のとおりです。
はい、ウィンドウサイズがシーケンス番号スペースに対して大きすぎる場合。たとえば、受信者はシーケンス番号のスペースに等しい数のパケットを取得します。したがって、その受信ウィンドウは、最後のパケットと同じシーケンス番号を持つ新しいパケットのセットを期待するように移動しました。受信者はパケットごとにACKを送信しますが、途中ですべてが失われます。これにより、送信者は前のパケットセットごとにタイムアウトになり、それぞれを再送信します。受信者は、この重複したパケットセットが実際に予期している新しいパケットであると考え、送信者に正常に到達した各パケットにACKを送信します。送信者は、同様の種類の混乱を経験します。この場合、ACKは、古いパケットがそれぞれ受信されたことの確認であると考えられます。
この種のシナリオは、ウィンドウサイズがシーケンス番号スペースの半分以下のサイズである必要がある理由の古典的な正当化のように思われるため、これは正しいと確信しています（そうでない場合は、教えてください！）。 SRプロトコルに、しかしGBNはどうですか？
同じ種類のラップアラウンドの問題が発生して、答えがほぼ同じになる可能性はありますか？そうでない場合、一般的なGBN送信者がウィンドウの外でACKを受信する原因となる可能性のある他のケースはありますか？
後者に関して、私が考えることができる唯一の例は次のとおりです。
GBN送信者は、パケットAとBを順番に送信します。受信者は両方を順番に受信し、Aまでのすべてのパケットをカバーする1つの累積ACKを送信し、次にB（Aを含む）までのすべてのパケットをカバーする別のACKを送信します。最初のものは非常に遅れているため、2番目のものが最初に送信者に到着し、ウィンドウがAとBを超えてスライドします。最初のものが最終的に到着したとき、Aがすでに送信者のウィンドウの外にあります。
この例は、前の例とは対照的に、かなり無害でありそうもないように思われるので、正しいとは思えません（ただし、間違っている場合は訂正してください！）。