要約

  • RFC 1055 の SLIP は IP データグラムをシリアル線上で区切るための小さな約束であり、END は終端、ESC は予約された二つの値をデータとして通すために使われる。
  • パケットの先頭にも END を送る案は、平常時には空フレームを一つ生む代わりに、雑音の残りを次のフレームへ持ち込ませない。
  • 区切りを見つけること、内容が壊れていないこと、過去を参照する復号状態が揃っていることは別の事実である。RFC 1144 と RFC 1662 はその境界を見失わないための比較になる。

小ささを隠さなかった形式

RFC 1055 を読むと、SLIP の魅力は機能の多さではない。1988 年の文書は、これを point-to-point のシリアル TCP/IP で広く使われる事実上の方式と呼ぶ一方、Internet Standard ではないと明記する。さらに、SLIP は packet framing protocol にすぎず、IP パケットを囲む文字列を定めるだけだ、と述べる。

これは未完成の告白ではなく、実装の責務表である。SLIP にはアドレス通知がない。パケット種別を示す欄がない。誤り検出・訂正も圧縮もない。両端は別の方法で IP アドレスを知る必要があり、同じ回線に TCP/IP と別のネットワークプロトコルを載せても、SLIP 自体にはそれらを振り分ける型がない。END を見たというだけでは、区切られたバイト列が無傷だとも言えない。

後から PPP と並べて、SLIP を「足りない PPP」と呼ぶのは簡単である。しかしそれでは、どの仕事を最小の共通規則として引き受けたのかが消える。SLIP の仕事は、連続して来るバイト列の中で、IP データグラムがどこで終わったかを双方が同じように読めるようにすることだった。データ内の値がその終端に見えてしまう衝突だけは、局所的な逆変換で防ぐ。そこから先の権限は主張しない。

RFC 1055 は END を 8 進数 0300、10 進数 192、ESC を 8 進数 0333、10 進数 219 とする。データ中の END は ESC と 8 進数 0334 の二つに、データ中の ESC は ESC と 0335 の二つに置き換える。ペイロードを送り終えたら END を送る。受信側は、フレームを読んでいるその文法の中でだけ、二つの置換を元へ戻す。

ここで END は、どこにあっても命令になる魔法の値ではない。SLIP フレームを組み立てる受信器にとってだけ構造を意味する。ESC も二つの予約値を守るための合図に限られる。送信側が一時的な痕跡を残し、同じ層の受信側がそれを取り除く。データを外側の制御と誤認しないための仕組みであって、データを正しいと認定する審査ではない。

次を始める前に、もう一度終える

Phil Karn の提案は、この小さな文法に回復の輪郭を与える。RFC 1055 は、パケットを END で終えるだけでなく、END で始めることを勧める。目的は、回線雑音のために受信側に蓄積したかもしれない誤ったデータを flush することだ。

平常時には、前フレームを閉じた END と次フレームの先頭 END が並ぶ。余計な一バイトに見えるが、仕様はその副作用を隠さない。空または不正な IP パケットが生じ、IP 実装が捨てる。例示された受信ルーチンなら、まだデータを一つも受けていないときの END を無視する。空フレームは偶発的な失敗ではなく、境界を取り戻すために支払う可視の代価である。

雑音があった場合、同じ先頭 END は別の役割を果たす。バッファにあるバイトは、古いパケットの残りかもしれず、新しいパケットの冒頭として読む理由もない。END はその不確かな蓄積を終わらせる。雑音の断片は次のデータグラムに接続される前に捨てられ、受信器は境界の後で改めてデータを待つ。

したがって、END が「パケットを復旧した」と表現するのは強すぎる。復旧したのは読み始めの位置である。捨てられたバイトを修理しないし、次のフレームにビット誤りがないことも示さない。また、上位に前回のヘッダを覚える復号器が、送信側と同じ記憶を持つことも保証しない。先行する不確実さが、次の解釈の最初の一部になるのを止めるだけである。

RFC の受信コードも、そこまでしかしない。END が来た時点で一つ以上のデータを持つときだけパケットを返し、連続 END が作る空のケースは通過させる。ESC の次が二つの期待値のどちらかなら END または ESC を戻し、それ以外なら protocol violation としてバイトをそのまま保存する。ここには完全性を判定する広い検証器ではなく、二つの構造値と境界を扱う小さな読み手がある。

フレームと記憶を同じものにしない

RFC 1144 の低速シリアル回線向け TCP/IP ヘッダ圧縮は、この区別を実務的にする。処理図では、IP パケットはまず compressor を通り、その後 framer に渡る。圧縮器はシリアルリンク上の接続ごとに過去のヘッダを保存し、圧縮パケットはその過去との差分を表せる。

そのため、END で一つのバイト列を切り出せたことと、その列を正しく解釈できることは同じではない。フレームが壊れていない証拠がないこともある。壊れていなくても、解凍側の先行状態が送信側の仮定とずれていることがある。RFC 1144 は誤り検出を framing level の問題として置き、誤ったパケットを捨てて状態誤差を伝播させないために、decompressor が誤りの通知を受ける必要があると説明する。SLIP の先頭 END はその通知ではない。

少なくとも三つの問いを分ける必要がある。境界はどこか。境界内のオクテットは無傷か。履歴を用いる消費者は必要な状態を共有しているか。END は最初の問いにだけ答える。チェックサムや FCS のような仕組みは二つ目を扱いうる。状態の再設定や同期は三つ目の仕事になる。

RFC 1662 は後年の PPP を、この点だけで比較させてくれる。HDLC-like framing は開始または終了を示す Flag Sequence、オクテット stuffing、FCS、無効フレームの扱いを規定する。そして、終端 flag を次の開始 flag と兼用して一オクテットを節約すると、空閑後には信頼性が下がると警告する。新しい開始 flag がなければ、雑音が次フレームの一部として読まれるからだ。PPP を SLIP の勝者に仕立てる必要はない。境界、完全性、棄却の責務を別々に明文化した契約として読むだけでよい。

印の効力をそこで終わらせる

Heng Lu の Note 64 と Note 65 の姿勢を借りれば、実行中のコードが局所的に検証できる最小機能をまず確認し、それを包括的な権威へ膨らませないことが重要になる。SLIP の END は、古い蓄積を放棄して次のフレームを読む境界を作るまで有効である。ESC は二つの値の保護にだけ有効である。その先にある完全性、信頼、状態の一致を証明する力はない。

流れの再開始を記録するなら、マーカー前の生バイト、観測した END、その後に組み立てたフレーム、独立した完全性判定、状態依存のデコーダが前後で使った状態を分けて残すべきだ。「パケットを回復した」という一文では、別々に正否を問える判断を一つに潰してしまう。

情報源と証拠の限界

この文章の閉じた証拠集合は RFC 1055、RFC 1144、RFC 1662 である。END/ESC の文法、先頭 END の根拠、SLIP が提供しない機能、圧縮器と framing の分担、PPP との限定比較を裏付ける。SLIP の普遍的利用、現代機器の挙動、雑音率、安全性、すべての SLIP 回線に RFC 1144 が使われたことは示さない。