RDPは信頼できる配送と順序配送をどう分けたか

要約

100、101、102、103の順でセグメントを送る。101だけが失われ、102と103は正しいチェックサムで到着したとする。累積ACKだけを見れば、受信の連続境界は100のままだ。だが受信側が102と103を持っている事実まで消えるわけではない。

RFC 908のEACKは、その事実を可変長フィールドに記した。通常のACKは最後に順序どおり受け取った番号を保ち、EACKは順序外で正しく受け取った番号を列挙する。送信側は101を再送し、102と103を無駄に送り直さずに済む。

それでも受信窓の左端は101の欠落に拘束される。後続セグメントがEACKされ続けても、固定された右端へ達すれば新規送信は止まる。選択的な確認は損失を隠す仕組みではない。すでに存在するデータと未解決の穴を同時に表す仕組みである。

RDPの想定用途は、遠隔ロード、メモリダンプ、デバッグだった。どれも欠けたメッセージを放置できないため、正の確認と再送が必要になる。しかし、受け取った順序をそのままアプリに強制する必要は用途ごとに違う。

宛先が明確なメモリブロックは、先に到着したものから配置できる。一方、状態を変えるデバッグ命令は、前後が入れ替われば意味が壊れる。RDPはこの差を一つの「信頼性」に押し込めなかった。

Open要求には、sequenced deliveryかnon-sequenced deliveryかが含まれた。非順序モードなら、受信側は102をEACKすると同時にユーザーバッファへ渡せる。順序モードなら、EACKによって通信上の受領を示しながら、101が届くまでアプリへの配送を待つ。

つまりEACKは、アプリがデータを見たという印ではない。同じEACKでも、接続開始時のモードによって上位への意味が変わる。

配送モードはメッセージごとの気分では変えられない。Openで選択され、接続の寿命を通じて続く。SYNは初期シーケンス番号、未確認セグメントの最大数、最大セグメントサイズ、順序配送モードを含むオプションを交換した。

このため、接続途中から始まった観測には限界がある。ACKとEACKを完全に見ても、SYNを失えば、順序外データが直ちにアプリへ渡されたのか、受信側内部に留められたのかを確定できない。接続確立は単なる前置きではなく、後の証拠を解釈する基準である。

バッファ上限も各側が自分の能力として提示した。共通規則は相手の上限を守らせるが、全実装に同じ容量を要求しない。相互運用に必要な境界だけを共有し、設備判断はその設備を持つ側に残していた。

RDPにはCLOSED、LISTEN、SYN-SENT、SYN-RCVD、OPEN、CLOSE-WAITがある。二つのSYNが交差する同時Openも扱い、初期番号とSYNへの確認を同じ接続状態にまとめる。

半開き接続を調べるため、次のシーケンス番号を使うNULも送れた。NULへのACKは、相手のRDPがその接続をなお認識している証拠になる。しかし、デバッガのプロセスが応答可能だとか、ロードしたコードが実行可能だという証拠にはならない。

終了も同様である。Close要求はRSTを送り、CLOSE-WAITを経て接続記録を捨てる。RFC 908は、Closeを求める前に必要なデータが信頼できる形で届けられたかをユーザーが判断するよう求めた。通信の終了操作からアプリの完了証明を作らなかった。

チェックサム、ACK、EACK、ユーザーバッファ、アプリ効果は階段になっている。下の段を確認しても上の段に自動で上がることはない。

1990年のRFC 1151は、1986年と1987年の実験で見つかった問題を記録した。v1の32ビット非線形チェックサムは、ホストのデータ表現によって計算コストが大きく変わった。同程度のハードウェアで最適化しても五倍の差が生じたため、v2は16ビットTCPチェックサムへ変更した。

8ビットだったRDP内部ポートも16ビットへ広げられた。ヘッダーが変わるため、バージョン番号も2になった。さらに、最古の未確認番号を表すSND.UNAは、SEG.ACKを受けた後にSEG.ACK + 1へ進めるよう擬似コードが修正された。

ここで文書の発行と採用を分ける必要がある。RFC 1151は、実装需要が限られていたため全面改稿を正当化できなかったと説明する。試験による修正は確認できるが、誰がv2を運用したかはこの証拠から分からない。

IANA Protocol Numbersは番号27をRDPとして保持している。番号の一意な意味を維持する登録であり、現在のトラフィック、実装、バージョン、EACK対応を保証する台帳ではない。

RDPは、すべてのメッセージを最終的に揃えること、順序外の受信を記録すること、アプリに見せる順序、アプリが仕事を終えたことを別々にした。この分解があるから、用途の異なるプログラムが同じ回復機構を共有できた。

順序が不要だと言ったのではない。順序が必要かを知る場所を間違えなかったのである。