XMODEM

電話回線は、ファイルを運ぶために作られていない

モデムは、コンピュータのビットを音へ変え、電話回線へ流した。

しかし電話回線には、雑音、瞬断、文字化け、速度差がある。

画面上の一文字なら、多少壊れても人間が推測できる。

プログラムや圧縮ファイルでは、一ビットの違いでも動かなくなる。

そこで必要になったのが、送る側と受け取る側が、

どこまで受け取ったか
壊れていないか
送り直すべきか
終了したか

を確認する作法だった。

XMODEMは、その作法を小さな状態機械としてまとめた。

128バイトずつ渡す

原型のXMODEMは、ファイルを128バイトのデータブロックに分ける。

各ブロックには、開始記号、ブロック番号、その補数、データ、チェックサムが付く。

SOH
block number
block numberの1の補数
128 bytes data
checksum

受信側は、受け取ったデータから自分でもチェックサムを計算する。

一致すればACKを返す。

一致しなければNAKを返す。

送信側                     受信側
  |---- block 1 ----------->|
  |<--------- ACK ----------|
  |---- block 2 ----------->|
  |<--------- NAK ----------|
  |---- block 2 再送 ------>|
  |<--------- ACK ----------|

XMODEMは、回線が壊れないと信じなかった。壊れたときに、どこからやり直すかを決めた。

一度に一つだけ進む

XMODEMは、ブロックを送ったら返事を待つ。

ACKが来るまで次へ進まない。

これはstop-and-wait型の単純な方式である。

高速な回線では待ち時間が効率を下げる。

しかし、低速なモデム、性能の異なるマイクロコンピュータ、短いプログラムで実装する環境では、この単純さが強みになった。

送信側は現在の一ブロックを保持すればよい
受信側は順番とチェックサムを確認すればよい
問題があれば同じブロックを要求できる
複雑なウィンドウ制御を実装しなくてよい

巨大で完全な通信基盤を待たず、小さなコンピュータ同士で信頼できる転送を始められた。

受信側が会話を始める

XMODEMでは、受信側が転送開始を要求する。

原型ではNAKを送り、送信側に最初のブロックを要求した。

ファイルの最後では、送信側がEOTを送り、受信側がACKを返す。

receiver: NAK
sender:   first block
receiver: ACK
...
sender:   EOT
receiver: ACK

転送は、送る側が一方的にデータを流すことではない。

一ブロックごとに、受信側が「届いた」「壊れた」「終わった」を返す対話だった。

XMODEMでは、確認応答もファイルの一部ではないが、ファイルを完全なものとして成立させるために不可欠だった。

仕様書が後から書かれた

Ward Christensenは、1970年代後半にマイクロコンピュータ間のファイル転送手順を実装した。

1982年1月1日付の仕様書では、自分のmodem protocolを初めてまとまった形で記述した理由を説明している。

その文書は、定義、伝送媒体、メッセージブロック、ファイル、エラー回復、実装上の注意から構成されていた。

ここで面白いのは、中央の標準化機関が先に完全な規格を制定したのではないことだ。

必要が生まれる
      ↓
動くプログラムを作る
      ↓
ほかの人が実装する
      ↓
互換性のために文書化する
      ↓
派生方式が増える

XMODEMは、実践から生まれ、コピーされ、修正され、後から仕様として固定された。

BBSとPDSの文化に合った発展だった。

名前や時刻は運ばない

原型XMODEMが主に扱ったのは、データ列そのものだった。

ファイル名、作成日時、長さなどの豊富なメタデータは、プロトコルの外側で合意する必要があった。

128バイト単位に満たない最後の部分は、CP/M文化に由来する終端文字などで埋められることもあった。

つまり、

何という名前のファイルか
何バイトが本当の末尾か
誰が作ったか

と、

送ったデータブロックが壊れていないか

は別問題だった。

XMODEMは後者へ集中した。

狭く定義された問題を、小さく確実に解く設計である。

checksumからCRCへ

原型は、一バイトの算術チェックサムを使った。

単純で実装しやすいが、異なる誤りが同じ合計値になる場合がある。

後にCRCを使う派生方式が普及し、さらに1024バイトブロックを使うXMODEM-1K、連続送信を改善する方式などが生まれた。

XMODEMという名前は、一つの不変な実装だけでなく、単純な原型から枝分かれした互換文化を指すようになった。

プロトコルは完成品ではない。実装者が同じ回線で困った結果が、派生名として積み重なった。

BBSとパソコン通信の物流

草の根BBSやパソコン通信では、掲示板の文章だけでなく、プログラム、画像、ドライバ、MIDIデータ、文書がファイルライブラリを通じて流通した。

通信ソフトがXMODEMに対応していれば、異なる機種やBBS間でも、同じ転送作法を使える。

作者のパソコン
      ↓ XMODEM
BBSのファイルライブラリ
      ↓ XMODEM
別の利用者のパソコン

ファイルの内容だけでなく、それを壊さず渡すプロトコルが、PDS、フリーソフト、シェアウェア文化の基盤になった。

XMODEMは、目立つコミュニティ機能ではない。

だが、ネットワーク上の共同体へ「物」を持ち込むための荷役設備だった。

雑音を消すのではなく、雑音と交渉する

完璧な回線を用意できれば、再送は不要に見える。

しかしXMODEMは、安価で不完全な回線を前提にした。

ブロックを小さくする
番号を付ける
誤りを検査する
受信側が結果を返す
失敗した部分だけ繰り返す
応答がなければ時間切れにする

これは雑音を完全に除去する設計ではない。

雑音が存在する世界で、双方が同じ手順に従うことで、完全なファイルを徐々に組み立てる設計である。

信頼できない媒体の上に信頼を作るとは、失敗をなくすことではなく、失敗を検出し、合意してやり直せるようにすることだった。

この標本が示す境界

データの完全性と、通信路の完全性は別である
ACKは成功、NAKは失敗という最小の会話が信頼性を作る
単純な方式は低速でも、多くの機種へ移植できる
仕様書は実装より先に存在するとは限らない
メタデータを運ぶことと、内容を壊さず運ぶことは別問題である
再送は失敗の証拠ではなく、失敗を前提にした正常動作である

XMODEMは、電話回線を信頼できる媒体へ変えたのではない。信頼できない媒体の上で、送り手と受け手が一ブロックずつ合意する方法を与えた。