要約

  • David Cheritonの1988年2月のRFC 1045は、遠隔手続き呼び出しのような要求・応答を扱うVMTPを記述した。Client、32ビットのTransaction番号、転送回数が取引を特定し、サーバー側の状態記録が重複要求を見分ける。
  • 応答を冪等として扱う場合、失われた返事を保存せず、Clientが要求を再送して処理をやり直す。元の結果を守る場合は応答の複製を残すか、確認までサーバーを待たせる。時刻を尋ね直せば、古い控えより新しい答えが得られる。

再試行ボタンの裏には、見えない受付がある。最初の要求は届いたのか。処理は済んだのか。返事だけが途中でなくなったのか。RFC 1045のVersatile Message Transaction Protocolは、失われ得るデータグラムの上で要求と応答を扱うために設計された。遠隔手続き呼び出しが想定された仕事の一つだ。クライアントがもう一度訪ねてきた時、受付は同じ用件か新しい用件かを先に確かめる。

受付票には三つの座標があった。あるエンティティ領域内ではClient識別子、Transaction番号、ForwardCountを組み合わせる。32ビットの番号はClientの生成時に乱数から始まり、通常は取引が終わるごとに進む。4ビットのForwardCountは要求を別のサーバーへ転送した場合に使う。サーバーはClientごとの状態を持ち、同じ座標の要求を重複として扱う。番号を付けた目的は、単に表をきれいにすることではない。二度目の訪問で同じ作業をもう一度始めるかが懸かっている。

状態記録は応答後もしばらく残す。遅れて到着した要求の複製がアプリケーションを起こさないようにするためだ。記録がなければ、Clientの管理モジュールにProbeで現在の番号を尋ねる方法がある。パケットの最大寿命と再送期間を覆うだけ記録を保ち、その間再起動していなければ新規と判断する道もある。安全に繰り返せる処理なら、そのままやり直す選択もある。気軽な「もう一回」の前に、古いパケットがどれだけ長居するかまで計算していた。

ここで時計が登場する。応答に冪等の指定があると、VMTPは古い返事を保存して再送する代わりに、ClientにRequestを再送させる。サーバーは最新取引の要求をアプリケーションへ渡し、処理をもう一度行って新しい応答を作る。さらに古い遅延要求は捨てる。Cheritonの例は現在時刻の問い合わせだ。さっきの時刻を書いた紙を探すより、時計を見直したほうが正確な場合がある。書類整理の名人が、時間には負ける。

結果を一つに保ちたい仕事には、別の会計がある。応答を冪等として扱えない場合、VMTPはその複製を残す。実際に写しても、コピーオンライトでもよい。あるいは応答の確認までサーバーを先へ進ませない。支払うのは記憶領域か待ち時間だ。時刻を読む仕事は繰り返せるが、台帳を書き換える仕事は二度実行すると台帳も二度変わる。どちらの窓口へ案内するかは、アプリケーションの意味が決める。

通信量にも節約策があった。損失の少ない環境なら、再送では本文全部の代わりに制御ブロックだけを送り、不足したデータ片を相手が選んで要求できる。後の要求が前の応答をプロトコル上で片付ける場合もある。つまりVMTPは、保存する空間、再送するバイト、再実行する時間を一枚の帳簿で扱った。どれか一つを無料にすると、別の欄に請求が来る。

時刻を尋ね直す話は少し笑える。しかし、答えをなくした後で繰り返す処理の種類を取り違えると、冗談では済まない。VMTPの識別子と状態記録は古い要求の混入を防ぎ、アプリケーションはやり直してよい仕事を見極める。このRFCが残したのは、再試行を「同じものをもう一度送る」だけで片付けない、実に人間くさい勘定感覚だ。