要約

  • Sun MicrosystemsのRFC 1014は、符号化する項目を四バイトの倍数にそろえた。可変長文字列では先に四バイトの長さを書き、文字列本体の後ろをゼロで埋める。
  • RFCの例にあるファイル名sillyprogは九バイトの文字に三バイトの詰め物を続ける。次のファイル種別はオフセット16から始まる。長さが内容を数え、詰め物が次の項目の位置を決める。

RFCの終盤には、johnという利用者がLispのプログラムsillyprogを保存する例がある。名前だけなら九バイト。XDRは最初の四バイトに長さ9を置き、続いて九文字を書き、最後にゼロを三つ足す。次のファイル種別はオフセット16に現れる。三つのゼロは名前の一部ではない。後続の値に「ここからどうぞ」と床に線を引く役目を持つ。

1987年の計算機は一枚岩ではなかった。RFCはSunのワークステーション、VAX、IBM PC、Crayを挙げる。内部で数値や構造をどう置くかが違う機械の間で、同じデータを同じ意味で読ませる必要があった。XDR、外部データ表現はそのための記述言語と符号化規則だった。Sun RPCやNFSでもデータ形式の記述に使われた。八ビットのバイトを共通の運び手とし、その上で四バイト刻みの道筋を作った。

32ビット整数は最初から一組に収まる。九文字の名前は二組と少しを使う。そこで残った三バイトをゼロで埋め、三組目を閉じる。先頭に書いた長さは9のままだ。受信側は九バイトだけを名前として読み、その後の三バイトを飛ばして次の項目へ進む。送信側にとっては余分な三バイトだが、受信側には次の位置を暗算できる利点がある。

RFCの16進数の表を追うと、仕組みは曖昧さを残さない。オフセット0から3に長さ9。4から12に九つの文字。13から15にゼロ。16からはファイル種別EXECを表す値2が始まる。ゼロを名前に含めれば名前が変わる。ゼロを飛ばさず次の値を読めば位置がずれる。紙の上でたった三つの空欄が、異なる機械の読み手を同じ行にそろえている。

ファイルの残りも具体的だ。EXECという種別は判別付き共用体の分岐を選び、インタープリター名lispを後ろに置く。四バイトの長さ4に続いて四文字が並ぶ。所有者johnも同じ形だ。内容の(quit)は六バイトなので、先に長さ6を書き、後ろにゼロを二つ付ける。各項目の自然な長さは違っても、「長さ、内容、四バイト境界」という手順は続く。

文字列とopaqueデータの扱いも分かれている。このRFCの文字列はASCIIのバイト列だ。opaqueはバイトをそのまま運び、XDR自身はその中身を解釈しない。可変長の型には上限を宣言でき、長すぎる値の符号化は誤りになる。長さの欄は内容の終点を示し、上限の確認にも使える。末尾のゼロは別の仕事、次の項目の始点を整える仕事をする。一つの数字に全部を任せず、役割を分けた。

受信側が頼るのは送信側のメモリー配置ではなく、共有されたデータの記述だ。プログラムのポインターをそのまま別の機械に渡しても、相手のメモリーには対応する場所がない。XDRの型は値の順序を示し、符号化はバイト列を示す。ファイル種別がEXECなら次はインタープリターを読む。四バイト刻みの境界が、その判断を行う位置を固定する。

ゼロには費用がかかる。九文字の後に三バイト、六バイトの内容の後に二バイト。RFCはその請求書を隠さず、表のオフセットに並べている。引き換えに、次の値の入口が読み手ごとに動かなくなる。ふざけた名前のsillyprogでも、到着番線だけは厳密だった。