要約

  • RFC 935は、低速の非同期回線向けにRFC 914とRFC 916が示した新しい信頼性確保の案を検討した。Robinsonは文字区切り、ビット区切り、長さ欄による方式を比べ、透過的な文字フレーム、16ビットCRC、LAPBの制御手順を組み合わせる案を出した。
  • リンクの付加情報を載せる前のThinwireフレームは13バイト。既存手順の8文字を足せば線上は21文字、RATPの6文字なら19文字になる。毎秒約120文字を送る想定で、120×13/21と120×13/19はThinwire文字で毎秒約74と82だ。Robinsonはこの差と、故障からの復帰や既存チップを利用できる価値を同じ秤に載せた。

表の外に残った請求書

1984年のThinwireとRATPは、低速回線を通じてパソコンをネットワークにつなぐ現実的な課題を扱った。回線に流す余分な文字を減らす理由は強い。Robinsonもその数字を退けてはいない。13バイトはリンクの付加情報を加える前のThinwire IIフレームだ。既存手順の8文字は13に対して約61%で、線上では21文字になる。RATPの6文字は約46%で、線上では19文字。毎秒約120文字を送る回線なら、120×13/21 ≈ 74と120×13/19 ≈ 82のThinwire文字が届く。この例で利用者の打鍵はThinwireの13文字につき1文字なので、Robinsonは毎秒約5.6と6.3文字と見積もった。これは特定の短いフレームに対する計算で、実ネットワーク全体の測定値ではない。2文字を節約する案には、それでも確かな利点がある。問題は、その利点にどこまで払えるかだ。

フレーム境界の作り方は、故障した時の振る舞いを決める。文字方式は開始・終了を特別な文字で示し、同じ文字がデータに現れれば逃がす。ビット方式はフラグとビット挿入を使い、通常は同期通信向けだ。DDCMPはヘッダーの長さ欄で後続データを数えるので、データのエスケープは要らない。しかし長さ欄が壊れると、受信側は次のヘッダーを探す必要がある。Robinsonは、エスケープの費用だけを数え、同期を失った後の費用を消す比較を嫌った。

データだけ守っても足りない

RFC 914とRFC 916は、汎用プロセッサで計算しやすい加算やXOR型の簡単な検査を提案した。Robinsonはリンクに16ビットCRCを置く方を選ぶ。制御欄の誤りは、確認の行き違いからフレームの喪失や重複を起こし得る。TCPによる後始末は遅い回線では時間を食う。CRCはTCP/IP側の加算式検査とは異なる誤りの型を捉える、と彼は説明した。表引きを使ったソフトウェア処理は1文字あたり約5〜6命令という見積もりで、回線上限は毎秒およそ120文字。ゲートウェイ側にはCRCを扱うシリアル回路も期待できた。

提示された組み合わせは、DLE STX … DLE ETX CRC CRCで文字フレームを作り、LAPBで順序と確認を管理する。逆方向の通信に確認を同乗させられ、両方向それぞれ最大7フレームを未確認のまま送れる。2点を結ぶ線では多点接続用のアドレス欄は余る。それでもRobinsonは既存手順との共通性を選び、欄を残した。付加情報は1フレーム8文字。欄を消すかRATPの長さ方式を借りれば少し縮むが、今度は独自仕様を全端末に実装させる。

既に広く使われる手順なら、チップのメーカーにも対応する理由がある。RFC 935はこの産業上の誘因を性能の話から切り離さなかった。後書きでは、提案が1976年ごろのTelenetの接続仕様に似ることに触れ、X.25/X.32が将来の接続を担うと予想した。後者は1985年時点の予測だ。本文が示すもっと確かな境界は、雑音で長さ欄が壊れた瞬間にある。節約した2文字は、受信側が次のフレームを探す費用まで支払えるだろうか。

出典