要約

  • STRU Pは不連続なファイルを独立した索引付きページとして表し、Page Indexは伝送順ではなくファイル内の論理位置を示した。
  • ページ表の空きは送信されず、値がゼロの実在ページとは区別された。RFC 959は穴とゼロのページが同じではないと明記している。
  • ページ構造は主にTOPS-20とNLSのために生まれた。RFC 1123は一般実装を推奨しなかった一方、穴あき・ランダムアクセスファイルが必要なら私的形式ではなく標準形式を使うよう求めた。

到着しなかったことをどう記録するか

RFC 959のページ構造では、各ページにPage Indexが付く。これはファイルの論理ページ番号であって、接続を何番目に通過したかを示す連番ではない。

したがって、受信順では隣り合うページが、完成したページ表では離れた位置に置かれることがある。その間は欠損したパケットとは限らない。送信元の表にページがなかったのかもしれない。

TOPS-20の付録は、空のページすなわち穴は単に送られず、穴はゼロのページと同じではないと強調する。ゼロのページは存在するページである。穴はその位置にページが割り当てられていないという事実だ。

あるOSで両方を読むと同じゼロ列に見える場合でも、保存量、割当て、属性、後の書込み動作まで同じとは限らない。穴をゼロで埋める操作は、中立な復元ではなく構造の変更になり得る。

一つのファイルに三つの見方

FTPはファイルの表現を三つの軸に分けた。TYPEは論理表現、STRUは内部構造、MODEはデータ接続上の伝送方法を指定する。相互作用はあるが、同じ状態ではない。

既定のFile構造は連続するデータバイトとして扱う。Record構造は順番に並ぶレコードとして扱う。Page構造は独立して索引できるページとして扱う。

背景には異種ホストがあった。RFC 959は、ソースファイルを固定長レコードで持つIBMメインフレームと、文字列を行へ区切って見せるTOPS-20を対比する。構造を知らせなければ、受信側はファイル固有の境界とローカル変換を区別できない。

変換は許されたが、可能な限り往復できなければならなかった。レコードをローカルなストリームへ変えたなら、同じ構造で取り出すときに元へ戻せる必要がある。RFC 1123も、対象ホストで有用である範囲でRecordとFileの変換を可逆にするよう求めた。

転送内容を証明するには、データだけでなく、その時の三つのパラメーターが必要になる。

長さゼロにも種類があった

ページの最小ヘッダーにはHeader Length、Page Index、Data Length、Page Typeが入る。それぞれはTYPEで幅を決めた論理バイトである。

Page Typeによって、同じData Lengthゼロにも文脈が生まれる。Last Pageはデータを持たない最小ヘッダーでページ転送の終端を示す。Simple Pageは通常のページである。Descriptor Pageはファイル全体の情報を運べる。Access Controlled Pageはページに付随する制御フィールドを増やす。

つまり、索引が現れない穴、データなしで現れる終端ヘッダー、全体を説明するページは別の状態だ。長さだけを読む実装は、その差を失う。

さらに到着順と配置順も別である。すべてのページを受信しても、Page Indexではなく受信時刻で並べれば異なるファイル表になる。

TOPS-20のページ表

RFC 765とRFC 959は、ページ構造が主にTOPS-20間の効率的な転送、特にNLSファイルのために必要だったと説明する。

TOPS-20のディスクファイルは、パス名、ページ表、空でもよいページ集合、属性から成る。ページ表の項目はEMPTYでもページへの参照でもよく、存在するページには固有のアクセスビットを付けられた。属性には各種時刻、バイト幅、EOFポインター、読み書き回数、バックアップ情報などが含まれた。

表は詰まっている必要がない。存在するページの間に空項目を置ける。EOFポインターも最後のデータを指す義務はない。NLSファイルでは、穴と非末尾EOFの両方が実際に使われた。

文書化された転送条件はTYPE L 36, STRU P, MODE Sだった。36ビットの論理バイトがTOPS-20のワードになる。Page Indexは表の位置を示し、Descriptor Pageは全体属性を運び、データページにはアクセス制御を添えられた。

これは他のホストにTOPS-20の保存方式を強制する設計ではない。理解できる二者が、意味のある差を私的な約束なしに交換するための形式だった。

送らない三つの理由

付録には、存在するページの末尾ゼロを捨ててData Lengthを通常の512ワードより短くできる規則もある。これで、ネットワーク上のデータが少ない状態は少なくとも三つになる。

穴ではページ自体がない。ゼロページではページが存在し、値がゼロである。短縮ページではページが存在し、規則に従って末尾のゼロだけが省略される。

ペイロードを連結したハッシュだけでは、三つの構造を区別できないことがある。索引、種類、ヘッダー長、データ長、記述・制御フィールド、終端、変換方針を一緒に残さなければならない。

規格の限界も明確だ。すべての保存先が穴を同じように実装するとも、穴を常にゼロとして読めるとも、ページ単位の制御を別システムで執行できるとも書かれていない。伝送表現とローカルな実現は別の証拠を要する。

推奨しないが、勝手に作り直さない

RFC 1123はページ構造の一般的な実装を推奨しなかった。多くのホストにとって専用機能であり、共通部分を小さくする判断だった。

しかし、ランダムアクセスまたは穴あきファイルをFTPで扱う必要があるなら、定義済みのページ形式を使い、私的なFTP形式を作ってはならないとも定めた。

実装しない自由と、互換性のない意味を同じ場所へ持ち込む自由は異なる。File構造は必須、Record構造は対応するファイルシステムを持つホストで必須、Page構造は任意だった。STRU命令が必須語彙でも、すべての引数が実装済みという意味ではない。

登録は稼働証明ではない

RFC 5797はSTRUを必須のbase命令に含めた。IANA FTP Commands and ExtensionsもFile Structure、パラメーター設定、RFC 959参照として登録している。

登録が示すのは共通名と役割である。特定サーバーがPを受理すること、クライアントがTOPS-20の表を復元すること、属性が保存されること、現代の配備を示すものではない。

登録簿に命令が存在することと、サーバーに能力が存在することは違う。送信にページが存在しないことと、ファイルにゼロのページが存在することも違う。

空きを埋めないための形式

現代のデータ交換でも、欠落、ゼロ、不明、秘匿、非該当を一つのnullへ押し込む設計は多い。処理は簡単になり、由来の意味は戻せなくなる。

STRU Pから残る規律は、欠如を明示し、論理位置を到着順から分け、復元に必要なメタデータを運び、変換の可逆性を試すことだ。

欠けたページは修復待ちではなかった。空いていることがファイルの一部だった。

出典