要約

  • RFC 1235は、実験的なパケット無線網で複数のディスクレス端末を同時起動する課題から、同一ファイルを一斉送信するCFDPを提案した。
  • 端末は進行中の配信をまず聴き、なければ全体を要求する。受信後に不足があれば、その端末固有のブロック番号を指定して再送を求める。

ファイルが一つなら、送信も一回で済ませたい。John IoannidisとGerald Maguire Jr.が1991年6月に出したRFC 1235は、その素朴な節約を端末の現実にぶつけた。ディスクを持たないワークステーションが同時に起動する。各台へ個別に同じデータを流せば、サーバーは台数分の送信を繰り返す。放送できる媒体なら、共通のファイルを一度に渡せる。

出発点は実験的なパケット無線網だった。論文は複数台へのソフト更新や、電子教室で同じ画像などを全員に送る場面も挙げる。少数の送り手と多数の受け手が同じ内容を求める。CFDPはその重複を狙った。将来IPマルチキャストが普及すれば、関係のない端末まで放送を受ける負担も減らせると著者らは見ていた。

受信するには、まずファイル名に対応する32ビットのチケット、ファイル長、ブロック長を得る。BOOTPやTFTPを改造した受付窓口でもよく、名前からチケットへの変換は転送本体の外にある。端末はチケットを持つと、同じ番号の配信が既に流れていないか聴く。途中から合流できれば、その時点以降のブロックを拾う。一定時間何も来なければ、FULREQで全体の送信を求める。

サーバーは番号付きのUDPブロックを放送する。端末は各パケットを検査し、番号が示す場所へデータを置く。早く来た端末、遅く来た端末、途中で一包失った端末では、空白の位置が異なる。データが止まってもファイルがそろわなければ、各端末はPARREQで不足番号だけを知らせる。RFCの三台を使った時系列例は、共有送信と個別の未完了状態を一枚に収めている。

再送依頼は送ればすぐ受理されるわけではない。同じファイルの配信中に届いた新たな要求はサーバーが無視し、端末は待って再試行する。著者らは受信者ごとの流量制御を避け、送信パケットの間隔を調整した。目安はインターフェースが一包を送る時間の約二倍。実験環境では、その時間の六～八倍を待ち時間とする設定がよかったと記す。一つの流れの速さを決める際、遅い端末の受信能力を無視できない。

512バイトのブロックなら、RFCが挙げるIPの最小MTUである576バイトよりパケット全体を小さくできる。16ビットのブロック番号では論理ファイルは32MBまで。1024バイトのブロックなら64MBまでで、それ以上は分割する。節約のための形式にも、扱える大きさと再送の細かさという値札が付く。

RFC Editorの記録でCFDPはExperimentalとされる。仕様は参考実装について述べるが、普及台数や起動成功率を記録していない。ここに残る発見は、サーバーの送信終了と端末の受信完了を別々に数える設計だ。共通の仕事をまとめても、最後の欠けた一片は各端末が取り戻す。

出典