要約

  • RFC 3342ではreportAfterが尽きると一時的な時間報告を生成したが、配送には影響を与えず、元データを次の中継へ送った。
  • noLaterThanは配送を止め得る上限であり、returnTripは最終報告の帰路を別に制限したため、警告、停止、報告受領、アプリ結果は独立した証拠だった。

APEXの基本動作は、即時かつベストエフォートのアプリケーション層データグラムである。処理オプションがなければ、利用できない中継によってデータが黙って捨てられる場合があった。RFC 3342は待機と報告を追加したが、「遅い」と「終わった」を同じ状態にはしなかった。

運用画面は一つの色を好む。アラートが上がれば失敗とし、再試行を起動し、元の作業は消えたものとして扱いたくなる。しかし、この仕様ではアラートの後にも作業が続く。観測が正しいことと、その観測に停止権限があることは別だった。

報告のための予算

dataTimingは各ホップで処理される。そのため送信元はtargetHop="all"とmustUnderstand="true"を設定しなければならない。中継は次の中継へ送る直前に、経路決定、bind、送信準備に要したローカル処理時間をreportAfterから差し引いた。

残量がゼロ以下になると、その値をゼロにし、報告サービスを呼び出す。それでもデータ要素は次へ送られる。最終ホップでも、指定時間内に受信エンドポイントからokが返らなければ一時的な時間報告が生成された。

報告は元のオプションのトランザクション識別子を参照し、対象受信者に350の一時的成功を記録する。これは破棄通知ではない。報告しきい値を越えたという事実である。後に配送が成功しても、しきい値超過は消えない。逆に、報告だけを見ても最終的な失敗や利用者への影響は証明できない。

配送上限は転送を変えた

noLaterThanもローカル処理時間によって減少する。ただし、次の中継へ送る前にゼロ以下になった場合、データは送られない。reportErrorsが真なら時間エラー報告も生成される。最終エンドポイントでは、残り時間内にokを受け取れないことが時間エラーとなった。

したがって、reportAfterは「知らせて続ける」、noLaterThanは「ここから先へ進めない」という制御である。どちらもタイムアウトという名前で保存すると、元メッセージが存続しているか否かを後から判定できなくなる。

硬い上限が尽きても、原因は一つに決まらない。中継内部の処理、遅い接続、利用不能な相手、混雑、未接続のエンドポイントが時間を消費し得る。証明されたのは、ある地点で残り予算内に処理できなかったことだけである。エンドポイントのokも、そのプロトコル処理より後の業務結果まで保証しない。

報告の帰路も失敗し得た

受信者へ正常に送信され、returnTripがゼロでなければ、最終ホップ報告が作られる。ところが、その報告は送信元の台帳へ直接書き込まれるわけではない。別のAPEXデータ操作として返送され、新しいdataTiming.noLaterThanには元のreturnTripが入る。

元データと、その到着を知らせる報告は別々の配送だった。元データが届き、報告が生成されても、報告だけが帰路で失われる場合がある。期限後、送信元は報告が失われたと推定できるが、元データまで失敗したと遡って断定することはできない。

監査記録には、入口での受理、残り報告予算、一時報告生成、報告後の転送、残り配送上限、停止地点またはエンドポイント確認、最終報告生成、帰路予算、報告受領、アプリケーション結果を分けて残す必要がある。一つの最終ステータスは、この順序を保存できない。

待機とホップ数は別の制約

hold4Endpointは受信エンドポイントが接続していない間、データをキューに保持できた。配送上限がなければ無期限に残る。RFC 3342はサービス拒否への悪用を警告し、短いnoLaterThanを必須にするなどの管理制限を示した。保存されていることは配送の約束ではない。

dataHoppingはIPのTTLに似たホップ数制限でループを検出した。時間ではなく中継数を減らす。少ないホップで時間を使い切ることも、短時間でホップ数を使い切ることもある。二つの予算は同じ失敗を説明しない。

attachOverrideは同じエンドポイントの旧アプリを新しい接続で置き換えられた。遅い返信の所有権はRFC 3340の固有の境界であり、別記事が扱う。ここで重要なのは、時間報告だけでは現在のアプリが古い処理を実行する資格を証明しない点である。

Historicという記録の範囲

RFC 3342は2002年7月に標準化過程の文書として発行された。現在はHistoricで、RFC Editorの検索には該当する正誤情報がない。2012年7月29日のIETF履歴は、IETFが知る限りRFC 3340から3343の実装は配備されず、対応する機能は広く配備されたXMPP、すなわちRFC 6120とRFC 6121によって提供されていたと記す。

これは限定付きの歴史記録であり、時間設計が不採用の原因だったとは述べていない。実装事故、性能測定、脆弱性も証明しない。また仕様はdataTimingが私設網のトポロジーを露出し得るため、管理領域の入口と出口だけで使う選択肢を示した。観測を増やすことには情報コストがあった。

現在のシステムでも確認すべき順序は同じである。どの時計が知らせるだけか、どの時計が動作を変えるか、どの時計が証拠の帰還を制限するか。警告を結果に昇格させなければ、遅延を正しく見ながら、まだ続いている仕事を壊さずに済む。

出典