0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ピギーバック

Posted at

全二重データ転送を実現する一つの方法は、これまでのプロトコルのいずれの二つのインスタンスをそれぞれ別々の回線を用いて(、反対方向の)単方向データ・トラフィックに動作させる方法でる。

データフレームと確認フレームが混ざっている

このモデルでは、AからBへのデータ・フレームはAからBへの確認フレームと混合されている。入力フレームのkindフィールドを見ることで、受信者はフレームがデータであるか確認通知であるか知ることができる。

出力データフレームと一緒に制御フレームを送る

データ・フレームが到着すると、直ちに個別の制御フレームを送信するのではなく、受信者はネットワーク層が次のパケットを渡してくれるまで待つ。確認通知は出力データ・フレームに付加される(フレーム・ヘッダーのackフィールドを用いて)。事実上、確認通知は次の出力データ・フレームにただ乗りする。出力確認通知を一時的に遅延させて次の出力データ・フレームに引っ掛ける技法は、ピギーバック(piggybacking)として知られる。

独立した制御フレームよりもピギーバック・フィールドを使う方が負荷が軽い

チャネル帯域をより有効に利用できることである。フレーム・ヘッダーのackフィールドはほんの数ビット出るが、独立したフレームでは、ヘッダー、確認通知、チェックサムが必要となる。さらに、送られるフレームが少ないことは、受信側の処理負荷が軽いことを通常意味する。次に見るプロトコルでは、ピギーバック・フィールドはフレーム・ヘッダー中の1ビットしか必要としない。数ビットより多く必要であることはほとんどない。

届くのが遅すぎるとピギーバックされない

新しいパケットがすぐに到着すれば、確認通知はそれにピギーバックされる。そうでなく、一定の時間の終わりまでに新しいパケットが到着しなければ、データ・リンク層は単に独立した確認通知フレームを送出する

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?