要約

  • RFC 3082は、ユーザーエージェントがサービス変更を購読し、問い合わせを繰り返さずに済む方法を定める。Directory Agentの有無で通知経路は異なる。
  • DAが消えても、既に通知先を知らされたサービスエージェントは送信を続けられる。一方、新しいエージェントは購読を知らない可能性がある。古い通知の継続は、新サービスも漏れなくカバーする証拠ではない。

問い合わせはイベント配信ではない

Service Location Protocolの基本はオンデマンド型だった。サービスエージェント（SA）がサービスを広告し、ユーザーエージェント（UA）が必要になった時点で問い合わせる。サービスの出現や消失をすぐに画面へ反映したいアプリは、ネットワークを定期的にポーリングする必要があった。2001年3月にExperimental Protocolとして発行されたRFC 3082は、変化を通知する仕組みでこの反復を減らそうとした。ただし、Internet Standardを定めた文書ではない。

問い合わせから購読へ移るだけなら単純に見える。だが、後から来たSAに「誰かが待っている」と伝えるのは誰なのか。RFC 3082はDirectory Agent（DA）のない小規模ネットワークと、DAのある大規模ネットワークを別々に扱う。購読状態が置かれる場所も同じではない。

二つの構成、異なる代償

DAがないネットワークでは、SAが登録・登録解除をIPマルチキャストで広く知らせる。マルチキャストが使えなければIPv4ブロードキャストを用いる。UAはサービス種別やスコープで受信後に選別する。新しいSAに購読者を伝える中央役は不要になるが、UAは無関係な通知も処理し、配信範囲の管理が重要になる。

DAを使うネットワークでは、UAがサービス要求にSubscribe拡張を付ける。DAは対象のサービス種別とスコープに対応するマルチキャストグループをNotifyAtとして返す。既存SAにはDAAdvertで通知でき、条件に合う新しいSAの登録応答SrvAckにもNotifyAtを含められる。広告が正常な登録解除なしに期限切れになった場合は、DA自身が登録解除通知を送る。イベント通知の主な送信者はSAであり、DAが全イベントの中央リレーになるわけではない。

処理は分散するが、状態も分散する。DAは購読を記録し、既存SAはグループアドレスを覚え、UAはグループに参加する。マルチキャストアドレスの割り当てとリースも別の状態だ。重複したNotifyAt通知を抑えるため、DAは0〜3秒の一様なランダム遅延を待ち、その間に他のDAから一致する通知が届かないか監視する。これは重複抑制であって、購読テーブルの複製や合意形成ではない。

消える状態と続く通知

第10節は部分障害を明確に記す。DAが予期せず消えると、そこにあったUAの購読情報は失われる。それでもUAは既存SAから通知を受け続ける。既存SAはすでにNotifyAtを受け取っているからだ。しかし、別のDAにも同じ購読情報がない限り、新しいSAには購読が伝わらない。

UAが代替DAを見つけるのは、能動的な要求を出してからかもしれない。旧DAの消失後、新しいDAの発見と購読の更新より先にサービスが登録されれば、その新サービスは通知経路に入らない。古いサービスの通知が続くため配信は動いているように見えるが、新顔は一度も現れない可能性がある。

既に購読を知っているSAには復旧手順がある。期限までは通知を続け、ほかのDAが見つからない場合は期限を無視して新しいDAの発見まで継続する。そこで再登録した後、SrvAckによりUAが購読を更新したか分かる。ただしRFC自身が残余の時間窓を認める。再起動したDAが利用可能になってからUAが購読を更新するまでに起動したSAは、なお通知を知らされない。あらゆる新サービスの通知が必要なUAは、対応スコープを持つ新たなDAすべてに購読を出すべきだ。DAの台数だけでは購読状態は冗長にならない。

通知の受信はサービス完了の証拠ではない

ほかの仕様要素も証拠の境界を示す。マルチキャスト通知は指数バックオフで15秒にわたり再送される。RFCが述べるのはメッセージが届く確率を高めることまでで、到達保証や永続イベントログではない。属性一覧がUDPのMTUを超えればオーバーフロービットが立ち、足りない属性は後からSAまたはDAへ問い合わせられる。RFCはUAによる認証ブロックの検証も定めるが、メッセージの認証は全リスナーの受信、現在の到達可能性、アプリ処理の完了を証明しない。

UAの購読、DAに保存された種別とスコープ、SAへ届くNotifyAt、マルチキャストグループへの参加、イベントの送信、実際の受信、属性不足時の照会、そしてサービス利用の結果を分けて記録する必要がある。RFC 3082は一部の遷移を規定するが、一連の完了を示す単一の受領証にはまとめていない。

タイトルの二つの事実は両立する。RFC 3082は、DA一台の障害で全通知が止まるとは述べていない。既存SAは継続でき、別のDAが範囲を保てることもある。より限定された要点は、すでに知られた送信者が動き続けても、後から来る送信者の発見まで保証されるわけではない、ということだ。ポーリングを通知に置き換えると、「誰が聞いているか」を覚える場所と、復旧時に戻すべき状態が変わる。

出典

仕様と履歴：RFC 3082、RFC Editorの記録、Datatracker履歴、RFC 2608：SLPv2、RFC 2119、RFC 2373、RFC 2730、RFC 2908。編集上の観点であり、SLP動作の証拠ではない資料：Lu HengのRunning-Code PrimacyとOn Reality Layers。