要約

  • RFC 3343のサービスはterminateを処理して返答した後に新しい更新を送らない一方、以前に送ったpresenceまたはwatcher更新が転送中で後から届く可能性を明記した。
  • コード250はサービス側の停止を証明しても中継網の排出は証明せず、相関、購読世代、情報の鮮度、利用者の処置は別の判断だった。

取消しを一本の境界線として扱うと、その後に届くものはすべて異常に見える。しかし分散システムでは、送信元が止まる時刻と、すでに送信されたメッセージが消費者へ到達する時刻は一致しない。RFC 3343はこの隙間を隠さなかった。

終了確認と遅い更新は同時に正しい。どちらかが偽物なのではなく、それぞれが異なる場所の状態を記録している。

継続する三種類の操作

APEXプレゼンスサービスは管理ドメイン内の既知エンドポイントapex=presenceで提供された。アプリケーションはプレゼンスエントリを公開し、あるendpointを購読し、そのendpointを購読している者をwatchできた。

subscribeは現在のエントリを直ちに返す。durationが正なら変更のたびに新しいpublishを送り、期限にterminateする。ゼロなら一回だけの取得になる。watchは最初に250を返し、現在の購読者ごとにnotifyし、その後の購読開始と終了も知らせた。

サービスはプレゼンスエントリと進行中の操作を永続保存する必要があった。サービス発のpublishとnotifyは原因となったsubscribeまたはwatchのトランザクション識別子を保持した。由来は追跡できても、到着時点の有効性までは保証しない。

250が閉じた範囲

消費者もサービスも操作を終了できた。指定した識別子がその発信者の進行中操作でなければ550、正しければ操作を終了し250を返す。

仕様はその直後に、終了後も追加のプレゼンス更新やwatcher更新を受け取り得ると注意する。サービスはterminateを処理し返答した後には更新を送らない。それでも、以前の更新が転送中の場合がある。

250は永続状態から操作が外れ、将来の送信方針が変わったことを示す。各中継のバッファ、接続、スケジューラ、消費者の入力キューが空になったとは言わない。排出障壁なら、境界以前の全メッセージが到着、廃棄、または精算済みだと証明する必要がある。ここにはその証明がない。

正しい相関でも現在形とは限らない

遅い更新には終了済み操作の識別子が残る。どの過去に属するかは分かるが、内容を現在へ適用してよいとは限らない。消費者は購読世代または終了の墓標を保存し、遅い到着の処理規則を持つ必要がある。

破棄、監査保存、隔離、新しいスナップショットとの比較などが考えられる。識別子一致だけで適用するのは誤りである。「この操作が生んだ」と「この操作が今も有効」は別の証拠だからだ。

同じ発信者が同じ対象を再購読すると、RFCは古い操作を黙って終了してから処理を続けた。見かけの関係は同じでも世代は変わる。世代を記録しなければ、旧publishが新しい流れの最初の更新に見えてしまう。

エントリの存在は接続証明ではない

各管理ドメインは、現在中継網に接続しているかどうかに関係なく、全endpointのプレゼンスエントリを維持した。エントリにはpublisher、lastUpdate、情報URI、そしてdestination、availableUntil、能力を持つtupleが入る。

したがってエントリがあることは現在の接続や到達性を証明しない。終了後に届いた更新が保存時点では正確でも、現在の判断には古い場合がある。

公開更新には別の原子性制御があった。送信したlastUpdateが保存値と意味的に一致しなければ555になる。250はサービス内の変更成功を示すが、全購読者の受信時刻を示さない。

Historic記録と位置情報

RFC 3343は2003年4月にExperimentalとして発行され、現在はHistoricである。2012年7月29日のIETF履歴は、IETFが知る限りRFC 3340から3343の実装は配備されず、機能はRFC 6120とRFC 6121の広く配備されたXMPPによって提供されていたと記す。

この限定的記録は終了競合が不採用の原因だったとは述べず、実装事故や遅延測定も提供しない。安全性の節は、タイムゾーンが位置を漏らし得るため、時刻を変換して-00:00を使う選択肢も示した。

残る設計原則は、更新作成、転送への引渡し、終了処理、送信停止、排出、受信、実行を別々に記録することだ。排出証拠がないなら作ってはいけない。取消しが終わっても、その過去はまだ近づいているかもしれない。

出典