要約

  • 初期FTPの再開マーカーはブロックまたは圧縮モードのフレームに入り、110 MARK が送信側の位置と受信側の永続化済み状態を結び付けた。
  • マーカーは単なる数ではなく、表現変換の途中状態も持ち得た。RFC 1123は、CRを処理済みでLFをまだ出力していない状態まで例示している。
  • RFC 3659のREST STREAMは直後の転送で省くオクテット数へ単純化したが、その数は版の識別、部分コピーの正しさ、完成物の完全性を証明しない。

進捗と復旧可能性は同じではない

FTPでは命令と数値応答が制御接続を通り、ファイル本体は別のデータ接続を通る。この二重構造により、受信側はファイルを受け続けながら、制御側へ復旧点を報告できた。

RFC 1123 が訂正した110応答では、ssss はデータ流に現れた文字列で、送信側ファイルシステムの位置を符号化する。rrrr はそれに対応する受信側の位置である。どちらも生成したシステム自身が後で解釈する。

等号は数値の一致を主張しない。ある送信状態とある受信状態が同じ転送境界で対応したことを示すだけだ。利用者側のFTPは、その関係を保存すればよく、相手の内部形式を理解する必要はない。

送信側は110を待って止まってもならなかった。応答はデータと同期するとは限らず、転送は先へ進む。画面のカウンターが示す最大地点より、最後に保存された対応表のほうが手前でも不思議ではない。前者は動いた量、後者は障害後に再現できる地点を表す。

マーカーを置ける転送モードが必要だった

RFC 959 は、表現形式、ファイル構造、転送モードを別々に扱う。STREAMモードは連続データを送り、通常はデータ接続の終了でEOFを表す。しかし接続が閉じた事実だけでは、正常な終端か途中切断かを見分けられないと文書は指摘する。

ブロックモードにはFTP自身の区切りがある。各ブロックは、8ビットの記述子と16ビットの長さからなる3オクテットのヘッダーを持つ。記述子の値16は再開マーカーを意味し、その後に空白を含まない印字可能文字列が入る。

これはTCPシーケンス番号の読み替えでも、ファイル中の特殊文字でもない。転送表現に属する制御用の目印である。ブロックと圧縮モードは接続を閉じずにEOFも示せるため、初期の再開機構を運ぶことができた。

ネットワーク上の到達記録だけでは、送信プログラムが同じ表現をどこから作り直せるか、受信プログラムがローカル保存をどこまで確定したかは分からない。復旧状態はエンドポイントが所有していた。

受信側は返答の前に書き切る

RFC 1123は、受信側がマーカーを見たら、それ以前のデータを安定記憶へ強制的に書き出してからrrrrを作るよう求める。この順番により、トークンは単なる「ソケットで読んだ位置」ではなく、受信側が後で責任を持って戻れる位置になる。

安定とは永久保存や遠隔複製を意味しない。標準はストレージ製品の耐久性を保証していない。受信側が自分で生成した値を、自分の障害モデルの範囲で後に正しく再解釈できることを要求している。

利用者側も対応表を残す。RFC 1123は転送開始時に空の再開制御ファイルを作り、110が届くたびに組を追記し、成功時に削除する方法を勧める。障害時には最後の完全な組を使う。

成功後の削除は重要である。古いトークンが残れば、同じ名前の次のファイルに誤って適用されかねない。チェックポイントの意味は、生成、利用、無効化という寿命を含む。

改行の途中は一つの数にできない

RFC 1123の具体例は、ASCII転送の改行変換である。ネットワーク上ではCRLFだが、受信ホストは一つのLFとして保存することがある。マーカーがCRとLFの間に来れば、受信側はCRをすでに見て捨てたものの、改行変換をまだ完了していない。

その場合、rrrrにはファイル位置だけでなく「CR処理済み」という状態も必要になる。ディスクの数値位置だけへ戻れば、改行を重複させたり欠落させたりする可能性がある。

FTPが想定した機械は、文字コード、ワード長、論理バイト、保存形式が異なっていた。共通のネットワーク表現は相互運用を可能にしたが、内部表現を同一にはしなかった。だからローカルにのみ解釈可能なトークンが正確だった。

不透明さは曖昧さではない。送信側の値を送信側だけが解釈し、受信側の値を受信側だけが解釈するという権限境界を明確にする設計だった。

転送方向によって組の使い方が反転する

利用者からサーバーへ送る場合、利用者側がssssを流し、サーバーが既受信部分を保存してrrrrを返す。再開時、利用者は自分のssssでローカル状態を戻し、サーバーにはREST rrrrを送る。

サーバーから取得する場合は、サーバーが流れにマーカーを入れる。クライアントが部分ファイルを保存し、ローカル位置を記録する。再開時には自分の状態を戻し、サーバーが作った値をサーバーへ返す。

さらにFTPは、利用者プロセスが二台のサーバー間転送を制御する場合を扱った。制御者はどちらのファイルシステムも理解せず、二つの値の対応だけを保管する。そして各値を生成元へ戻す。

制御者の責任は座標の解釈ではなく、対応関係の取り違えを防ぐことだった。別ファイルや別セッションの組を混ぜれば、不透明な文字列そのものは警告してくれない。

RESTは次の動作を準備するだけだった

RESTに対する350は転送完了ではない。サーバーが再開パラメータを保存し、次のサービス命令を待っていることを示す。データも完全性も、この時点では何も確定していない。

RFC 959の状態モデルでは、その後にRETR、STOR、場合によってAPPEが続く。RFC 1123は、位置を適用できない554と、TYPEまたはSTRUが既存ファイルに合わない555を区別した。同じ地点でも表現条件が変われば再開できない。

二命令の間でクライアントが失敗すれば、保存された意図だけが残る。後の仕様は、この残留状態が別の転送へ移る危険を一回限りの順序規則で抑えた。

STREAMでは八位組が共通座標になった

RFC 3659 は、STREAMモードのデータ中にマーカーを挿入せず再開する方法を定義した。RESTの引数は十進数になり、直後の転送で送らないオクテット数を表す。REST 0は省略を解除して最初から送る。

例ではTYPE Iを選び、サーバー側ファイルが変更されていないことを確認してから、REST 802816、350、RETRと進む。バイナリのオクテット列なら、現代の「その位置から続ける」に近い。

ただし数は古い組の情報をすべて持たない。変換途中の状態、ファイル版、クライアントの前半部分の正しさは含まれない。直後の転送で何オクテットを省くかだけを指定する。

RESTは対象転送の直前最後の命令でなければならない。続く転送命令を送れなければ、改めてRESTを送る。完全転送へ戻るならREST 0を明示する。数字として正しくても、対象ファイルが示されるまで範囲外と判断できない場合もある。

STORの再開は部分ファイルへの書き込み権限になる

RETRでは、クライアントが受け取った後半をどう組み立てるか決められる。STORでは、サーバーが既存の部分オブジェクトへ書き込む。誤った位置は遠隔ファイルを壊す可能性がある。

RFC 3659はSTORとの利用を、以前失敗した転送の完了に限定する。マーカーがサーバー上の現データ末尾でなければ結果は未定義であり、続きが元の長さまで戻せない場合も同様である。APPEを許す実装でも、単純な末尾追加ではなく指定位置のSTORと同じ動作が必要になる。

これによりRESTは任意の遠隔編集機能にはならない。しかし原子的更新も保証されない。再び失敗すれば新しい部分状態が残る。命名、可視性、権限、置換、削除はローカル運用の責任である。

位置指定を理解する能力と、対象を変更してよい権限は別の問題だ。

正しいオフセットでも違う版に入れる

RFC 3659は、最初のRETR前に変更時刻を取得し、再開前に比較することを勧める。STORでも、部分ファイルと再送しようとする送信元の時刻を比べられる。MLSTの事実は、さらに多くの変化情報を与え得る。

それでも時刻はハッシュではない。時計にはずれがあり、時刻が変わっても最終内容が同じ場合がある。内容が変わって元に戻ることもある。時刻は無効化の手掛かりであって、同一性の証明ではない。

SIZEも現在のTYPEで転送される長さを表す。同じ長さの別ファイルは存在する。期待サイズまで達したことは、前半と後半が同じ版に属する証拠にならない。

完全性が必要なら、再開後に完成物全体を別の証拠で検証する。350や226の成功はプロトコル手順の成功であり、内容の一致ではない。

FEATと登録簿が示すのは語彙の存在

RFC 3659のSTREAM再開を扱うサーバーは、FEATに正確な文字列REST STREAMを掲げる。クライアントは、数値オフセット対応とブロック/圧縮モードだけの再開を区別できる。

IANAのFTP Commands and Extensions は、基礎のRESTと、STREAM用に修正されたREST+を別々に記録する。これは標準化された文法と適合区分の記録であり、現在の普及率や実装品質の証明ではない。

能力表示は「この形式を理解すると表明しているか」に答える。部分ファイルが同じ版か、利用者に上書き権限があるか、結果が正しいかには答えない。

チェックポイントの権限は完成物より小さい

古い仕組みは、異種変換を扱うため多くのローカル状態を保存した。STREAMの仕組みは、よく使われるオクテット列へ問題を絞り、操作を単純にした。その代わり、ファイル同一性と完成後検証を周辺証拠に委ねた。

どちらの方式も、チェックポイントをファイルそのものとはみなさない。再開位置は継続の候補を示すだけで、供給者の認証、内容の意味、実行の安全性を保証しない。

再送を省くほど中間状態は長く残る。対象、表現、権限が変わったときに確実に失効できて初めて、再開は回復になる。

出典と証拠の限界

これらは標準上の機構と文書史を示すが、現在の製品対応、導入率、実転送の成功や完全性を測定しない。IANA登録やFEAT行だけから、個別の再開が安全だとは判断しない。