現在、私はかなり基本的なネットワークを研究しており、現在は信頼性の高い通信の対象です。私はKurrose &ロスによってブックコンピュータネットワークを使用していて、次のように復習問題の2は以下の通りであった。SR＆GBN：ウィンドウ外のACK
を選択リピート/ゴー・バック・Nプロトコルで、それが 送信者へのために可能であり、その 現在のウィンドウの外にあるパケットのACKを受信しますか？ SRのバージョンについては
次のように、質問に対する私の答えは：
はい、ウィンドウサイズは、シーケンス番号空間の大きすぎる場合。 の例の場合、受信者は シーケンス番号のスペースに等しい数のパケットを取得します。したがって、その受信ウィンドウは、 と同じシーケンス番号を有する新しいパケットセットを待つように移動される。受信側はパケットのそれぞれに対してACKを送信しますが、 すべてが途中で失われます。これにより、最終的に、送信者 は、前回のパケットのセットごとにタイムアウトし、それぞれを で再送信します。受信者は、パケットのこの重複セット が本当に期待している新しいものだと思って、それぞれが成功裏に送信者に届く のACKを送信します。今度は送信者 は、同様の種類の混乱を経験します。ここでは、ACKが は、古いパケットのそれぞれが受信されたという確認であると考えます。 本当に新しい未送信パケットのACKの場合。
このようなシナリオは、ウィンドウのサイズがウィンドウのサイズの半分以下になる必要がある理由の古典的な正当性と思われるので、これが正しいと確信しています（他に教えてください）。それはSRプロトコルになるとシーケンス番号空間が、しかしGBNについてはどうですか？
同じ種類のラップアラウンドの問題が発生する可能性があります。答えはほとんど同じですか？そうでない場合は、通常のGBN送信者がそのウィンドウの外でACKを受信する可能性のある他のケースがありますか？後で、私は考えることができる唯一の例は以下の通りですについて
：
GBNの送信者が順番にパケット& Bを送信します。受信機は、両方を順番に受信し、Aまでのすべてのパケットをカバーする1つの累積ACKを送信し、Bまでのすべてのパケット（Aを含む）をカバーする別のパケットを送信します。最初のものが非常に遅れて2番目のものが最初に送信者に到着し、そのウィンドウがA & Bを超えて滑り落ちます。最初のものが最終的に到着したとき、Aまでのすべてが正しく受信されたことを不必要に認識します。すでに送信者のウィンドウの外側にあります。
この例は、以前の例とは対照的に、むしろ無害であると思われるので、正しいとは思えません。