要約

  • ONC RPCでは、32ビットのXIDがCALLの先頭に置かれ、REPLYにも同じ値が入る。要求側は応答を正しい呼び出しへ戻せるが、応答側はXIDを順序番号として読めず、この値だけで実行回数を証明できない。
  • NFSは不足していた記憶を具体化した。NFSv3の重複要求キャッシュは短い故障窓を覆ったものの、消去や再起動に弱かった。NFSv4.1はセッションのslot、slotごとのsequence ID、保存済み応答によって、強い実行保証の費用を有限にした。

タイムアウトは事実ではなく観測だった

クライアントがファイル名の削除を要求する。サーバーは削除を終えたが、成功応答だけが失われたかもしれない。あるいは要求そのものが到着しなかったのかもしれない。クライアントに見えるのは、どちらも同じタイムアウトである。

そこで再送すると通信は前へ進める。しかし二通目のCALLには、一通目が実行済みかどうかを書いた履歴がない。再実行すれば副作用を重ねる恐れがあり、単に似ているという理由で拒めば、新しい正当な操作を失う恐れがある。

1988年4月のRFC 1050は、RPCのメッセージ規則が信頼性を実装するものではないとした。6月にこれを置き換えたRFC 1057は、UDPで再送しても応答がなければ手続きが何回実行されたか分からず、応答があれば少なくとも一回実行されたとだけ推論できる、と整理した。

待ち時間を延ばしても、この分岐は閉じない。ネットワークは実行前の要求も、実行後の応答も失える。クライアントの沈黙とサーバーの履歴は別の証拠である。

XIDは待ち受け先を見つけるための値だった

RPC version 2のすべてのメッセージは、符号なし32ビットのXIDで始まる。REPLYは、それを発生させたCALLのXIDを返す。複数の呼び出しを並行させたクライアントは、戻った結果を正しい待機処理へ渡せる。

RFC 5531は、サービス側の権限を狭く定める。再送検出のために過去のXIDとの等値比較はできるが、XIDをsequence numberとして扱ってはならない。大小関係から時間や因果を読んではいけない。

基本仕様で再送時の再利用は強制ではない。クライアントは以前のXIDを使い直してよい。サーバーも実行後にその値を覚え、同じ値の呼び出しを再実行しないようにしてよい。その両方が成立し、記録が残っている範囲で、ある程度のexecute-at-most-onceが得られる。

つまり意味は番号の中ではなく、運用状態の中にある。再送が新しいXIDを選べば同じ仕事を結べない。サーバーが記録を失えば同じ値でも古さを判定できない。長い時間の後に値が再利用されれば、要求者、program、version、procedure、epochを含まない等値比較は誤検出にもなる。

信頼できる接続にも「応答なし」の外側があった

RFC 1831は初期の意味論を引き継ぎ、RFC 5531は現行のStandards Track仕様としてまとめ直した。信頼できるtransportから応答を受け取った場合、その交換について一度だけ実行されたと推論できる、と両者は説明する。一方、応答がなければ、処理されなかったとは言えない。

TCPは一つの接続におけるバイト列を守る。クラッシュしたアプリケーションの決定履歴まで保存するわけではない。切断後に再接続したクライアントは、古い処理が切断直前に状態を変更したかどうかを依然として知らない。

XIDは認証情報でもない。RPCにはcredentialとverifierの別フィールドがある。同じXIDのREPLYは対応付けの材料であり、主体、完全性、永続化、承認済みcommitの証明ではない。

NFSのstateless設計が再送の負債を見せた

初期NFSはサーバーを可能な限りstatelessにしようとした。RFC 1094が示した利点は復旧の単純さである。サーバーや経路が戻れば、クライアントは会話状態を再構築せず要求を繰り返せる。

そのため各操作は、できる限りidempotentに設計された。同じ範囲への同じWRITEやREADは、繰り返しても等価な結果を目指せる。しかしREMOVE、RENAME、LINK、MKDIRなどは「possibly non-idempotent」と記録された。一度目の成功で名前空間が変われば、二度目は同じ意味にならない。

RFC 1813はNFSv3で危険を明文化した。非idempotentな要求の重複実行は破壊的になり得る。二度目のtruncateが、一度目の後に行われた書き込みまで失わせる場合がある。接続指向transportでも、切断と自動再接続の後には結果不明の要求を再送する必要が生じる。

statelessであることは、実行世界が状態を持たないことではない。ファイルとディレクトリは変化する。プロトコル会話を薄くした分だけ、操作の性質と重複判定の責任が重要になった。

重複要求キャッシュは有限の証言だった

多くのNFSv3サーバーは、最近の要求と完了結果をキャッシュした。同じ要求を認識したとき、操作をもう一度行う代わりに最初のstatusを返す。これにより、判断はタイムアウトしたクライアントの推測ではなく、実行境界に残った記録に基づく。

ただしRFC 1813は、その記録を保証と呼んではいない。典型的なキャッシュはRAMにあり、再起動で消える。容量が有限なら古いentryは追い出される。長いpartitionの間に元の応答が届かず、記録だけがevictされれば、後の再送は新しい要求として処理され得る。

このとき壊れたのはXIDの比較機能ではない。比較に結果を与える履歴が失われた。XIDをそのまま「idempotency key」と呼ぶと、scope、保持期間、引数照合、failover共有、server epochという支配条件が隠れる。

NFSv3のexclusive CREATEは、通常のvolatile cacheに全面依存せず、作成対象に結び付くverifierを利用した。必要な強度が高い操作では、証拠を副作用の近くへ置く必要があることを示している。

slotは記憶の上限と解放条件を同時に決めた

NFSv4.1はXIDの全履歴を保存しようとはしなかった。RFC 5661がsessionを導入し、現在のRFC 8881は、有限個のslotと、slotごとのsequence IDおよびcached replyを定義する。

要求側は空いているslotを選ぶ。新しい要求ではそのslotのsequenceを一つ進め、現在の要求を再送するときは同じ値を用いる。応答側は、次の新規要求、現在要求のretry、順序外の値を区別できる。最初の実行が完了していれば、同一sequenceには保存済みの応答を返す。

sequenceだけでなくslotの有限性が要点である。交渉されたslot数は同時に未解決となる要求数を制限し、サーバーが保持すべき応答数も制限する。次のsequenceが届けば、クライアントが前の結果を越えたため古いentryを更新できる。

RFC 8881は、opaqueなXIDだけではこの解放条件を作りにくいと説明する。RPC要求は任意の順で実行され、未完了数に自然な上限がない。32ビット空間の全応答を保存することは現実的ではない。slot tableは無限に見える履歴を、合意された現在の保管責任へ縮めた。

exactly onceは永続化の範囲を超えられなかった

slotとsequenceが正しくても、その状態がサーバー障害で消えれば、失った結果について証言できない。RFC 8881は、再起動をまたぐ完全なEOSにはreply cacheと回復状態の永続化が必要だとする。volatileな実装は通常のretryを改善するが、保持していない過去まで保証しない。

NFSv4.1もRPCのXIDを残した。CALLとREPLYの対応付けには依然必要であり、通常のSEQUENCE経路を使わない操作でも役割がある。session ID、slot ID、sequence IDは、より強い問いのための追加文脈である。

歴史的な変更は、万能な番号の発明ではなかった。XIDが応答を結ぶ。cacheがその等値に一時的な結果を与える。slotが保持量を制限する。永続化が、どの障害まで「一度」を主張できるかを決める。

同じ値から読み取ってはいけないこと

同じXIDでも、引数、認証主体、server instance、boot epochが同じとは限らない。cache missは新規性を証明せず、cache hitは結果のstable commitを証明しない。idempotentという分類も順序問題を消さない。RFC 8881は、遅れて残った古いWRITEが後のWRITEを上書きする例を挙げ、変更を伴うidempotent操作にもEOSが必要だと説明する。

安全な主張はもっと狭い。番号は比較点を提供する。一回実行という性質は、実行者が番号、仕事、結果、scope、回復epochの関係を、クライアントの不確実性が終わるまで保存して初めて生まれる。

出典と証拠の限界

RPCの系譜はRFC 1050、1057、1831、5531で確認できる。NFSのstateless方針はRFC 1094、NFSv3の重複要求キャッシュと限界はRFC 1813にある。NFSv4.1 sessionはRFC 5661で導入され、現行仕様はRFC 8881である。これらは規則と記録された故障モデルを示すが、現在の製品別キャッシュ容量、永続化、普及率、適合性は測定していない。