要約

  • RFC 916のSOフラグは、データが正確に1オクテットであることを示した。不要になったLENGTH欄にその文字を入れ、ヘッダーチェックサムで保護したため、独立したデータ部を送らずに済んだ。
  • 同じ欄は、SYNでは受信側のMaximum Data Length、通常パケットでは後続データ数、SOパケットではデータ自体だった。意味を決めるのは欄の位置ではなく、検証済みのフラグと接続状態である。
  • シーケンス番号と確認番号が各1ビットで足りたのは、各方向に応答待ちのパケットが最大1個しか存在しなかったからだ。小さな表現と小さなウィンドウは一つの選択だった。

RFC 916は1984年10月、Reliable Asynchronous Transfer Protocol（RATP）を提案した。想定したのは全二重のポイント・ツー・ポイント回線で、多くの場合、小型コンピューターやモデム、コマンドを受け取る装置を結ぶ非同期RS-232だった。RFC Editorの現在の記録ではHistoricに分類される。これは現在の文書上の地位であって、当時の普及率を示す統計ではない。

設計の優先順位は明記されていた。信頼性を最優先し、その次に実装の単純さを選ぶ。動的ウィンドウ管理や複数の未確認パケットは外された。相手が接続を閉じた時点で送信待ちだったデータは捨てられ、文書によれば、それによって二つの状態を削除できた。TCPの全機能を小型化するのではなく、対象を狭くして状態機械を小さくしたのである。

1文字に7オクテットかかる問題

通常のRATPヘッダーは4オクテットだった。16進数01の同期リーダー、制御、データ長、ヘッダーチェックサムである。通常データはその後に続き、さらに16ビットのデータチェックサムが付いた。

対話的な端末では、キー入力をまとめるまで待つと遅延が見える。ところが1文字を通常形式ですぐ送ると、ヘッダー4、データ1、データチェックサム2の計7オクテットが必要だった。

SO、すなわちSingle Octetフラグは、この一点だけを最適化した。SOが立ち、SYN、RST、FINが立っていなければ、受信側はデータ長が必ず1だと知る。LENGTH欄にもう一度1を書く必要はない。そこでRFC 916は、その欄に文字そのものを置き、データ部とそのチェックサムを省いた。埋め込まれた文字はヘッダーチェックサムの対象になる。文書は7オクテットから4オクテットへの削減を40パーセントの効率改善と表現した。

任意のデータを圧縮したわけではない。フラグが長さを、固定位置がデータを、ヘッダーチェックサムが限定的な誤り検出を既に提供したため、重複する3オクテットを送らなかっただけである。2文字には適用できず、確認応答も接続状態も消えない。

3番目の欄は自分の意味を名乗らない

SYNパケットでは、同じ位置はMaximum Data Length（MDL）だった。そのSYNを送る側が、1パケットで受信できる最大データ量を相手へ知らせる。三者間ハンドシェイクの間に、両端がそれぞれ自分の受信限界を表明した。

接続成立後、SYN、RST、FINのないパケットでは、この位置をLENGTHと呼ぶ。SOがなければ、後に続くデータ数を0から相手のMDLまでの範囲で示す。SOがあれば、数ではなく唯一のデータオクテットになる。

したがって、値が65であるという事実だけでは意味を決められない。受信上限65、後続65オクテット、あるいは1文字の値かもしれない。同期を認識し、制御・当該欄・チェックサムを検証し、現在の状態でフラグの組合せが受理可能だと確認して、初めて解釈が成立する。

MDLは目安でもなかった。ヘッダー検証を通った通常パケットが受信側MDLを超える長さを宣言した場合、RFC 916はプロトコル違反、または低確率の未検出誤りとして接続をリセットした。受信資源を負担する側が境界を決め、共通規則がそれを実行する。

データを受け取りたくない側はMDLを0にでき、一方向の利用も表せた。ただしデータを流すなら両端が同時に0では成立しない。共通層は表示形式と違反時の処理だけを決め、端末の能力値そのものはローカルな判断に残した。

1ビットで足りたのは、二つ目がなかったから

SNとANは各1ビットだった。2値で一般的な信頼性を実現できるからではない。ある方向で送信・確認中になれる応答要求パケットが最大1個という不変条件があったからである。

受信側は、次に期待する値をモジュロ2で管理した。別の値が来れば、既に受理して確認したパケットの重複だと判断できる。前の確認が失われて再送された可能性があるため、重複データを捨て、必要な確認を返す。送信側はANから唯一の未確認パケットが届いたと判断し、再送キューから削除してビットを反転した。

双方向は独立して進めた。自方向の最後のパケットが確認済みなら、相手が送るデータを待たずに次を送れる。相手への確認と自分のデータ送信が重なれば一つのパケットにまとめる。確認だけのパケットは確認を要求しないため、受領通知が無限に続くこともない。

同じ不変条件が性能の上限にもなった。往復を待つ間に複数パケットを流せないので、帯域遅延積の大きい回線では利用率が下がる。一方、低速の対話回線と小さな装置なら、バッファー、状態、重複判定を簡潔にできる。1ビットだけを後世へ持ち出し、その前提を捨てることはできない。

受信可能量は受信側が決めた

MDLの上限は255だった。同期、残りのヘッダー、2オクテットのデータチェックサム、最大255オクテットのデータを合計すると、通常パケットの最大は261オクテットになる。仕様はこの上限から、受信1パケットのためにそれ以上の記憶領域を確保する必要はないとした。

実際のMDLは、OS、ドライバー、メモリー、通信速度、外部フロー制御の挙動で決まる。長いバーストが制御文字の挿入を招きやすいなら、最大値を下げて、一部のパケットが妨害されずに届くようにすべきだとも説明した。

ここで共通なのは値ではなく、値を伝えて守る方法である。各参加者が自分の容量を決め、相手が検証可能な形で受け入れる。中央の組織が装置の適正値を認定する必要はない。

パケット完了と上位レコード完了を分ける

RATPは01で開始候補を示したが、終端用の同等なデリミターは使わなかった。任意のビット列がデータ内に現れ得るため、検証済みヘッダーの長さから終端を計算した。

上位層の単位がMDLを超える場合は分割が必要になる。EORフラグは、このRATPパケットで上位レコードが終了すると示した。設定責任は上位層にある。リンク上で完全に受信され確認されたパケットでも、上位の対象としては途中の断片かもしれない。

証拠の効力は層を越えない。ヘッダーチェックサムは候補ヘッダーの限定的な整合性を、確認応答はRATP状態での受理を、EORは上位境界の手掛かりを与える。アプリケーションが理解したか、コマンドを実行する権限があったか、結果が生じたかは別の証明である。

回線ノイズへの再同期は別の設計だった

RS-232が区切るのは個々の文字で、RATPパケットではない。受信側は01を探し、その後の3オクテットを検査した。ヘッダーチェックサムに失敗すると、その3オクテットを新しい入力として同期探索へ戻した。偽の開始候補を見ただけで、未知の長さを読み飛ばさないためである。

後のRFC 1055が記録したSLIPは、IPデータグラムのデリミターとエスケープを持つ一方、型フィールド、基本仕様上の統一最大長、リンク層の誤り訂正を持たない別の取引だった。RFC 1661とRFC 1662のPPPは、プロトコル多重化、LCP、可変制限、フラグ、透過化、FCSを定めた。いずれも比較資料であり、RATPからの直接の系譜を証明しない。

RFC 916自身が動的ウィンドウとの比較で参照した同時代資料がRFC 793のTCPである。TCPは相互接続されたネットワーク上の広いストリーム契約を扱い、RATPは1本のポイント・ツー・ポイント回線でパケットと信頼接続の役割をまとめた。同じ用語が同じ運用証拠を意味するわけではない。

これらの一次資料はRATPの普及数も、現代製品の動作も示さない。チェックサムは署名ではなく、暗号化も認証も権限付与もしない。歴史的な要点は、4オクテットが成立した境界にある。両端が容量、接続状態、唯一の未決パケットについて厳密に同意していたからこそ、省略が推測にならなかった。