送信ベース()と送信する次のパケット()を追跡するための2つのポインタがあります。送信者は最初のフレームを送信することから始めます。送信するパケットが多く、は;よりも小さいですが。送信者は、ポインタが指すパケットを送信してから、をインクリメントします。受信者から確認応答パケットを受信した後にインクリメントされます。重複したACKメッセージを受信しても、メカニズムはトリガーされません。送信ウィンドウ全体に単一のタイマーがあり、でパケットのタイムアウトを測定します。したがって、タイムアウトが発生した場合、送信者はタイマーを再起動し、から始まる送信ウィンドウですべてのパケットを再送信します。要約すると、送信者のアルゴリズムを次の擬似コードで表すことができます。受信機Go-Back-Nのレシーバーの実装は、可能な限り単純です。受信者は、次に受信する予定のシーケンス番号のみを追跡します。レシーバーバッファはありません。故障したパケットは単に破棄されます。同様に、破損したパケットもサイレントに破棄されます。新しいパケットの受信時に(成功または失敗して)受信された最後の順序どおりのパケットの確認応答を常に送信します。その結果、問題が発生した場合に重複した確認メッセージが生成されます。要約すると、受信者のアルゴリズムの擬似コードは次のとおりです。全体として、これでACKベースのNAKフリーのGo-Back-Nプロトコルの説明は終わりです。チェックサム、およびタイムアウト/再送信を使用した信頼性の高いデータ転送に関連する問題をカバーしています。累積的な謝辞とシーケンス番号Go-Back-Nプロトコルは、累積確認応答の使用を採用しています。フレームの確認応答を受信するということは、フレーム、、なども確認応答されることを意味します。このような確認応答をACKと表記します。フレームをマークするために使用する可能な最大シーケンス番号を示しましょう。ここでも、ウィンドウサイズが。ここで、簡単なシナリオを想像してみましょう。送信者はウィンドウ内のフレームを送信し、0から応答として、ACK、マーキングフレーム、などを受信します。場合、送信者が実際の結果を知る方法はありません。使用率とウィンドウサイズ前に述べたように、パイプラインプロトコルはストップアンドウェイトプロトコルよりも改善されています。良いネットワーク使用率を達成するために、特定の時間に送信者と受信者の間に複数のフレームが「飛行中」にあります。Go-Back-Nのウィンドウサイズを示します。これは、送信者が確認応答を受信する前に送信できるウィンドウサイズです。基本的に、の場合、ストップアンドウェイトの実装があります。オーバーヘッドを無視した、可能な最大のリンク使用率の式は次のとおりです。式では、は帯域幅遅延積であり、特定の時間にリンクを介して伝送できるデータの量を表します。これは、データリンクの容量にラウンドトリップ遅延時間を掛けたものとして計算されます。理論的には、上記の方程式を解くことにより、可能な最大値を見つけます。実際には、さらに小さい値を使用する必要があります。これには2つの主な理由があります。受信者が到着したパケットを処理できる速度と、ネットワーク使用率が高いことを考慮する必要があります。受信者がパケットの処理に対応できない場合、パケットをドロップします。この場合、送信者は同じパケットを何度も再送信し、正常に送信されたパッケージレートは不十分に低くなります。したがって、高い使用率を達成することは無意味です。高速の送信者が低速の受信者をデータに溺れさせないようにするという概念は、フロー制御と呼ばれます。フロー制御は、レシーバーの処理速度に関して、より小さなウィンドウサイズを強制します。次に、ウィンドウサイズを制限することも同様に重要ですが、輻輳制御です。ネットワーク(の一部)に存在するパケットが多すぎると、パケット遅延とパケット損失が発生し、パフォーマンスが低下します。実際、送信者は、ネットワーク全体のパフォーマンスが利用されるように、ネットワーク内の各要素を尊重する必要があります。要約すると、Go-Back-Nプロトコルは送信側と受信側の両方で機能し、信頼性の高いデータ転送を保証します。累積確認応答がどのようにより大きい値を使用するように強制しているか、およびより良い使用率を達成するために適切なウィンドウサイズを選択する方法についても説明しました。Joseモバイルバージョンに。