要約

  • XMODEMが共通化したのは、128バイトのデータ、ブロック番号とその反転値、簡単なチェックサム、受信側主導のACK/NAK、終了を示すEOTだった。接続、ファイル名、保存、操作画面は規格の外に置かれた。
  • 小さな共通層は別々の作者による実装と相互試験を容易にした。同時に、弱い誤り検出、待ち時間に弱いストップ・アンド・ウェイト、メタデータ不足という限界を隠さず、後続の方式に改良の余地を残した。

受信側が最初の一文字を送る

XMODEMの通信を眺めると、主役が少し意外である。最初に動くのはファイルを送りたい側ではない。受信プログラムがタイムアウトし、NAKを返す。それが準備完了の合図になり、送信側はSOH、ブロック番号、番号の1の補数、128バイトのデータ、チェックサムを順に送る。

受信側は同じ計算を行い、受け入れられればACK、やり直しが必要ならNAKを返す。次のブロックも同じ手順で進む。データが尽きると、送信側はEOTを送り、最後のACKを待つ。

この往復に中央の調停者はいない。二つのプログラムが、回線上の数種類のバイトと状態遷移について同じ理解を持てばよい。ブロック番号は一から増え、反転値はヘッダーの破損を見つける助けになる。データ部分の合計からあふれを捨てた一バイトが、最低限の検査になる。

Christensenが1982年にまとめた説明には、実装者らしい故障の扱いがある。受信した番号が期待していた次のブロックではなく、直前の番号だった場合、すぐに異常終了してはならない。前のデータは正しく届いたが、戻りのACKが壊れ、送信側が再送した可能性があるからだ。受信側は再びACKを返す一方、同じデータを二重に保存しない。

巨大なログ基盤に真実を問い合わせるのではなく、直前の状態だけで曖昧さを解く。ただし、どんな番号でも許すわけではない。説明のつかない番号は同期喪失を示し、終了が必要になる。XMODEMの信頼性とは、すべての障害を消すことではなく、限られた障害に同じ答えを出せることである。

128という数字が示す設計範囲

128バイトは普遍的な最適値ではない。Christensenが作業していたCP/Mのディスクセクターという具体的な環境につながっていた。固定長なら、小さなメモリーでバッファーを扱いやすく、コードも単純になる。その代わり、短い最終ブロックには埋め合わせが必要で、正確なファイル長は別の方法で扱わなければならない。

元のブロックにはファイル名も時刻もない。モデムのダイヤル、利用者認証、課金、保存場所、画面表示、複数ファイルの束ね方も定めない。今日の製品仕様として読めば欠落だらけに見える。しかし、相互運用の境界として読めば、その空白には意味がある。全端点が同じでなければならない部分だけを回線上の契約にし、それ以外はローカルな選択として残したのだ。

Christensenは後年、1977年の仕事を個人的な必要から生まれた即席のものと振り返り、早く作り、すぐパブリックドメインにしたことが標準化につながったと述べた。これは本人の回想であり、普及原因を一つに絞る実験ではない。それでも実装コストの差は理解できる。短いプログラムなら複写し、読み、別の機械へ移し、相手の実装と試せる。ネットワークの所有者に参加許可を求める必要もない。

RFCが「既に使われていたもの」を記録した

XMODEMをIETFが制定した標準と呼ぶのは正確ではない。1984年のRFC 916は、別の信頼性ある非同期転送プロトコルを提案する中で、MODEM/XMODEMを当時一般に使われていた比較対象として付録に記した。実装の集積が先にあり、RFCによる観察が後に来た。

その付録は弱点もはっきり書いている。データは一方向に流れ、パケットは128オクテットで固定される。中間装置によっては、そのまとまりさえ負担になり得た。一ブロックごとに返事を待つ方式は、往復遅延が大きいほど回線を遊ばせる。単純な加算チェックサムは、すべての破損を発見できない。

小さいことは、正しいことと同義ではない。ただし問題の位置は見える。再送回数、完了時間、見逃した誤り、最終ブロックの扱いを端点で観察し、次の方式を選べる。身元、保管、検索、転送を一つのサービス内部に閉じ込めた場合よりも、交換すべき部品を特定しやすい。

改良は名前ではなく相互運用で決まる

後続の実装ではCRC-16、1Kバイトのブロック、ファイル名やサイズを運ぶブロック0などが加わった。Chuck Forsbergの公開プログラムは、YMODEMと呼ばれる慣行の普及を支えた。元の共通部分を認識できたからこそ、追加機能を段階的に導入できた。

ChristensenはXMODEM自体を全二重にし、複数ブロックを未確認のまま送り、複数の宛先を扱う案に慎重だった。高度な転送が不要だという主張ではない。多数の機械とプログラムで生き残れた理由を、極端な単純さに見ていた。旧来の端点を一斉に不適合とする変更は、機能だけでなく、共有基準を動かす権限も変える。

一方、自発的採用は混乱を防がない。歴史資料は、同じYMODEMという名称の製品が違う動作をした問題も記録する。製品名や準拠宣言だけでは足りない。提案を実装し、既存相手と交換し、エラーを注入し、限定運用を観察し、対応能力を明示する。その循環を通ったものだけが、実用上の拡張になる。

CBBSとXMODEMを一つにしない

1978年のシカゴ大雪の後、ChristensenはRandy SuessとCBBSを作った。Suessがハードウェア、Christensenがソフトウェアを担当し、電話を受け、メッセージを蓄え、人が戻ってくる場所を形にした。これは重要な周辺史だが、XMODEMのブロック定義ではない。

BBSはサービスであり、XMODEMはファイルを渡すための線上の約束だった。この区別があったため、異なる掲示板や端末ソフトが、それぞれの利用者体験を保ちながら転送機能を実装できた。共通層は一つでも、製品が一つになる必要はなかった。

128バイトをそのまま現代へ持ち込む必要はない。残すべき問いは、どの事実が本当に全参加者に共通でなければならないか、である。XMODEMは、順序、再試行、終了には厳密さを置き、それ以外の多くを端点へ返した。自由とは無規則であることではなく、共有しなくてよい判断まで中央に差し出さないことだった。

情報源