要約

  • RFC 2188のESROでは、遠隔操作の結果は全参加者に共有される一つの状態ではなく、invokerとperformerがそれぞれ保持する局所的な証拠の集合として現れる。特にacknowledged-resultでは、invokerが結果を受け取っていてもperformerがFAILURE.indicationを見る場合がある。
  • non-acknowledged-resultは交換を短くできる一方、performerのRESULT.confirmやERROR.confirmは相手から得た新しい証拠ではない。プロトコル上の完了、アプリケーション実行、永続的な業務commit、後日の照合は別の層として扱わなければならない。

RFC 2188は1997年9月にInformational RFCとして公開された文書であり、Internet Standardではない。IETFワーキンググループのレビューを経ておらず、IESGは文書にスケーラビリティ上の注意を付している。その位置づけは重要だ。ESROを、後世のRPC全般を代表する標準モデルとして読むのではなく、当時の特定の設計目標に対して組み立てられたプロトコルとして読む必要がある。

その目標は、信頼性のないコネクションレス型トランスポート上で、短い遠隔操作を低いオーバーヘッドで実行することだった。ESROはUDPなどを下位に想定し、CDPDのような無線リンクを明示的な背景としている。UDP利用時にはポート259を使用し、分割と再構成、複数情報の連結と分離、アプリケーション多重化を備える。ここでいう「効率」は、単にパケット長の話ではない。接続確立を前提とせず、短い操作のために必要な交換そのものを小さくする設計である。

ESROには、操作を起こすinvokerと、それを処理するperformerという二つの役割がある。操作結果の扱いには、acknowledged-resultを使う3-wayの交換と、non-acknowledged-resultを使う2-wayの交換がある。この一往復分の違いが、両端が持つ証拠の強さを変える。

acknowledged-resultでは、performerがresultまたはerrorを送り、invokerがそれを受け取るとACKを返す。performer側のRESULT.confirmまたはERROR.confirmは、そのACKを受けてから生成される。したがってperformerにとってconfirmは、少なくとも相手側から戻ってきたメッセージに基づくイベントである。

しかし、この仕組みでも両端の知識が一つに統合されるわけではない。resultまたはerrorを運ぶPDUそのものが失われることがある。逆に、そのPDUはinvokerへ届き、invokerが結果を受領してACKを送ったにもかかわらず、そのACKだけが失われることもある。さらにperformer側のローカルprovider障害もあり得る。RFC 2188では、これらがperformer側のFAILURE.indicationへ到達し得る。

このため、performerで観測されたfailureを「invokerは成功結果を受け取っていない」という証明として扱うことはできない。ACKが失われたケースでは、invokerはすでに成功結果を受け取っているかもしれないからだ。この「成功した可能性」は、performerから見てinvokerの受領を否定する決定的証拠がない、という限定された意味でしかない。アプリケーションの永続的な業務commitが完了したことを示すものではない。

ここで分けるべき出来事は多い。少なくとも、invokerが呼出しを発行したこと、invoke PDUがネットワークを通ってperformerへ届いたこと、performerが操作を実行または拒否したこと、resultまたはerrorを構築したこと、その応答が配送されたこと、invokerへresult/error indicationが上がったこと、invokerがACKを出したこと、ACKがperformerへ届いたこと、各端でconfirmまたはfailureが生成されたことは独立した層である。

さらに、その外側には認証と認可がある。RFC 2188自身は認証機構を提供しない。あるinvokeを受信できたという事実は、相手の身元を認証したことでも、その操作を認可したことでもない。認証失敗や認可拒否をアプリケーションがどう表現するかと、単なるPDU喪失をどう区別するかも別問題になる。

Invoke IDも、この境界を越える魔法の識別子ではない。Invoke IDは対応する操作や応答を相関させるための材料だが、それ自体で送信者を認証するわけではなく、処理の冪等性を保証するわけでも、業務処理が一度だけcommitされたことを示すわけでもない。再送されたinvokeが同じ業務処理として認識されるか、それとも二度目の操作として実行されるかは、プロトコル相関だけで決まらない。

同じ理由で、重複処理は通信層と業務層を分けて考える必要がある。ネットワークが不安定なら、invokerは応答を得られず再送するかもしれない。performerが最初のinvokeをすでに実行していて、応答だけが失われていた場合、再送されたinvokeは実質的に同じ業務要求の二回目である。プロトコル実装が重複invokeを認識したとしても、永続ストレージ上の業務commitまで安全に一度だけ実行されたことを自動的に意味しない。

逆方向にも重複は存在する。performerがresultまたはerrorを再送し、invoker側が同じ結果を再び受け取る可能性がある。ACKが失われれば、performerはinvokerの受領を確認できず、結果側の再送が継続し得る。つまり「重複したinvoke」と「重複したresult」は異なる方向の問題であり、同じ対策で片付くとは限らない。

RFC 2188が示す補償策の一つが、別の操作による検証である。performerが、自分のfailureを根拠に「相手は結果を知らない」と断定できないなら、後続のverification operationを設け、状態を改めて確認するという考え方だ。重要なのは、verificationが元の交換を後から完全なものへ変えるのではなく、新しい通信によって新しい証拠を獲得する点にある。

この構図を理解するには、プロトコルの「完了」とアプリケーションの「完了」を切り離す必要がある。performerが処理を実行したとしても、それが永続的な業務commitの完了と一致するとは限らない。resultが構築されたことと、そのresultがネットワークに送出されたことも同一ではない。invokerがresult indicationを受け取ったことと、後続の業務処理が正常に永続化されたことも別である。

non-acknowledged-resultでは、この証拠境界がさらに明確になる。2-way交換では、performerがresultまたはerrorを返したあと、invokerからACKは返らない。したがってperformer側のRESULT.confirmやERROR.confirmは、peerから新しい情報を得て成立するイベントではない。それはローカル側で操作が終わったこと以上の知識を与えない。

このモードでは、RFC 2188は通常の意味でperformer側FAILURE.indicationを生成しない。例外となるのはローカルprovider障害である。つまり、performerに「相手へ届かなかった」と知らせる通信上の失敗通知を省くこと自体が、2-way化によるメッセージ削減の一部になっている。

ただし、失敗通知がないから成功が確認されたわけではない。performerがresultを送ったあとconfirmを得ても、invokerがそれを受け取ったことは分からない。逆にinvoker側でFAILUREが起きても、そのことからperformerがアプリケーション処理を実行していないとは言えない。invokeはperformerまで届き、実行されたが、応答だけが失われた可能性が残るからだ。

したがってESROのイベントを読むときは、「どの端点で観測されたか」が意味の一部になる。RESULT.confirmという名前だけを見て、システム全体の成功を表す共通状態だと扱うことはできない。同様にFAILURE.indicationも、失敗したものが何なのか、どの端で観測されたのか、その観測から他端について何を推論できるのかを分けなければならない。

これはtimerについても同じである。RFC 2188は再送間隔、最大再送回数、inactivity time、reference-number lifetimeなどを、配置するネットワークの性質に合わせて設定する設計を取る。これらは実測遅延や損失特性に関係する運用値であり、timeoutそのものが遠隔業務状態を直接観測しているわけではない。

あるtimerが切れたという事実は、予定した時間内に期待した通信イベントを観測できなかったことを示す。それだけで、相手がinvokeを受信しなかった、処理を開始しなかった、処理をcommitしなかった、resultを生成しなかった、と順番に結論づけることはできない。通信上の沈黙から業務状態へ飛躍すると、証拠の層を取り違える。

reference-number lifetimeも同様に、識別子をどの期間有効な相関材料として扱うかという設計上の境界である。識別子が再利用可能になる時点と、業務上の重複検出記録を保持すべき期間が必ず一致するとは限らない。プロトコルの番号空間に寿命があることは、アプリケーションの監査履歴や冪等性記録にも同じ寿命を設定してよいという根拠にはならない。

パラメータの符号化意味論も、ここでは別の層に置くべきである。ESROが操作とパラメータを運ぶことと、そのパラメータが特定の業務意味をどう表現するかは同じ問題ではない。通信プロトコルが配送構造を与えても、アプリケーション語彙の正当性や意味的一貫性まで自動的に保証するわけではない。

RFC 2524は、ESRO上に効率的なメール提出・配送を構成することを意図した利用例を示している。これはESROが抽象的な実験だけではなく、具体的な上位用途を想定して設計・利用されたことを知る手掛かりにはなる。しかし、それを現在までの普遍的普及、商用成功、性能上の優位、安全性、コンプライアンス適合、あるいは特定導入の成功へ拡張して読む根拠にはならない。

またRFC 1831との比較も、隣接する設計を理解する程度に留めるのが妥当である。RPCという語が共通していても、そこから一般的なRPC史全体へESROの性質を投影するべきではない。RFC 2188が示す価値は、むしろ一つの具体的なプロトコルで、交換手順と端点別知識の関係を精密に観察できるところにある。