要約

  • RFC 1068のBFTPでは、対話型の画面がFTP操作を制御ホストのキューへ保存し、FTCデーモンが後から両サーバーへ接続した。submit が確定したのは依頼の永続性であり、データの到着ではない。
  • 複数ファイルは最初に成功した NLST で集合を固定し、成功済みの項目を保持した。全件成功だけでなく、恒久障害や再試行上限でも依頼は「完了」したため、結果はファイル別報告から読む必要があった。

RFC 1068 が扱ったのは、FTPそのものの新しい命令体系ではない。利用者が席を離れた後も仕事を忘れない仕組みである。当時の前景型FTPでは、接続が切れたり相手が停止していたりすれば、人がもう一度命令を出す。その役割を、BFTPはキューとFile Transfer Control、すなわちFTCデーモンに移した。

文書は議論を促すためのメモであり、新プロトコルを提案してはいない。既存FTPの外側に、依頼の保存、開始時刻、再試行、途中経過、通知を組み合わせた。端末セッションが終わっても意思が残るようになったことで、「依頼が存在する」と「転送が成立した」の間に、独立した管理領域が生まれた。

制御ホストが保存したのは転送の設計図だった

送信元、宛先、制御ホストは別々の機械でよい。利用者は両端のホスト名、ログイン名、パスワード、ファイル名を入力し、コピー、移動、送信元削除、宛先での新規作成・置換・追記などを選んだ。FTPのtype、mode、structureも指定でき、ワイルドカードで複数項目をまとめ、最初の実行時刻を先に延ばすこともできた。

通知先のメールボックスを添えて submit すると、画面は終了できる。この瞬間に残ったものは、将来の動作を記したレコードである。二つのホストが接続可能であることも、認証情報が受理されることも、データ接続が開くことも、宛先に完全なファイルが書かれることも、まだ確定していない。

verify は事前の不確かさを減らす手段だった。到達できる場合には両サーバーへログインし、設定や送信元ファイルの存在を確認する。停止中のホストについては確認できない項目もある。しかも検証の後には別の submit と将来の実行が待つ。検証はその時点の観測であって、将来の到達性や書込み権限を予約するものではない。

指揮する場所と、バイトが通る場所は異なった

BFTPが使ったのは、RFC 959 の第三者間FTPである。FTCは送信元と宛先にそれぞれ制御接続を持ち、一方で PASV を実行し、そのアドレスとポートを PORT で他方へ渡した。次に RETR と STOR を組み合わせる。データ接続は二つのFTPサーバー間に直接作られ、ファイルは制御ホストを通らない。

この構造では証拠も分かれる。キューは何を望んだかを示す。二本の制御会話はサーバーが何を受理し、何を拒んだかを示す。ファイル本体は別のデータ経路を流れる。RFC 959は転送中も制御接続を保ち、次の転送命令に進む前に終端応答 226 または 250 を待つよう求めた。予備応答、ソケット接続、データ路の切断のどれか一つだけでは成功を決められない。

さらに、組み合わされる実装は均一ではなかった。少なくとも一方が PASV を実装する必要がある。RFC 1068は、非標準の NLST、壊れた応答形式、通信断を一時的な 4xx ではなく恒久的な 5xx として返すサーバーを挙げている。再試行を担う機械は、相手が返す分類以上に賢くはなれない。

一回のFTPセッションを越えて失敗を扱う

FTCは一時障害を記録すると待機し、新しい制御接続でやり直した。記載された実装例では、約十分から始め、待ち時間を倍にし、約四時間で増加を止める。これは運用例であって、インターネット全体に定めた時間ではない。

ここでRFC 959の 4yz と 5yz がスケジュールを左右する。4yz は要求された動作がまだ起きていないが、依頼を変えずに再実行できることを示す。5yz は同じ要求をそのまま繰り返すべきでない状態である。切断が 5xx と誤分類されれば、回復可能な仕事から次回が奪われる。逆の誤りなら、進まない操作が何度も走る。

成功、恒久障害、または最大試行回数のいずれかで、デーモンは仕事を終えてメールを送る。通知が来たという事実は、ワークフローが終端状態に着いた証拠にすぎない。配送成功か断念かは、通知の内容を読まなければ分からない。

ワイルドカードには時間的な境界が必要だった

待っている間にディレクトリは変化する。再試行のたびに NLST を取り直せば、最初の依頼にはなかった新しいファイルが入り、逆に期待したファイルが消えるかもしれない。BFTPは最初に成功した NLST の一覧を保存し、それを仕事のメンバーとして固定した。後から作成された項目は、古い依頼の対象にならない。

固定された集合も、原子的に転送されるわけではない。五件のうち四件が成功した後で最後が失敗しても、宛先の四件を削除して初めから戻ることはしない。状態ポインターが成功済みを覚え、次の周期は未完了だけを試す。一方で、同じ依頼の内部に成功と失敗が同居する。

RFC 1068が依頼をcompleteと呼ぶのは、全項目が成功した時だけではない。恒久障害が起きた時、再試行を使い切った時も含まれる。この語は「もう予定された試行がない」という意味であり、「宛先に全ファイルがある」ではない。だから最終通知は各ファイルの状態を列挙した。

キーワードは本人性の代わりにならなかった

利用者は提出時にキーワードを付け、後から一致する仕事を探して取り消せた。著者はこれを弱い認証と明記している。二人が同じ語を選べば、他人の依頼を閲覧または取消できる。取消メールは事後記録にはなるが、事前の権限を生み出さない。

第三者接続の権限には、後に別の境界も示された。RFC 2577 は、proxy FTPの PORT を使ってFTPサーバーから別サービスへ接続させるbounce attackを説明し、防ぐ制限がproxy機能を失わせ得ると論じた。これはBFTPでの事件を証明しない。ただし、バイトを運ばない制御者にも接続先を決める力があることを示す。

この文書から言える範囲

RFC 1068が報告するのはISIで数か月使われた実装であり、広範な普及ではない。現代のジョブキューがBFTPから直接生まれたとも証明しない。RFC 959は制御とデータの分離、応答の意味を与え、RFC 2577は後年のセキュリティ境界を与える。どの文書も特定の配送成功、資格情報の安全、現在の導入状況を保証しない。

歴史的な要点はもっと限定される。意思を保存すれば再試行できるが、命令対象とは別の状態機械が一つ増える。キューが語れるのは「試すべきこと」までである。何が届いたかは、ファイルごとの証拠が語る。