Zusammenfassung

  • RFC 3082 lässt einen User Agent Dienständerungen abonnieren, statt das Netz fortwährend abzufragen. Ob Directory Agents vorhanden sind, bestimmt den Benachrichtigungspfad.
  • Fällt ein DA weg, können bereits informierte Service Agents weiter melden; ein neuer Agent erfährt möglicherweise nichts vom Abonnement. Dass alte Meldungen weiterlaufen, belegt keine vollständige Abdeckung neuer Dienste.

Eine Abfrage ist kein Ereignisstrom

Das Service Location Protocol war auf Bedarf ausgelegt: Service Agents (SAs) kündigten Dienste an, User Agents (UAs) fragten sie bei Bedarf ab. Eine Anwendung, die jede Dienstaufnahme oder -beendigung zeitnah in ihrer lokalen Sicht sehen wollte, musste das Netz regelmäßig abfragen. RFC 3082 erschien im März 2001 als Experimental Protocol und sollte solche Wiederholungsabfragen durch Änderungsbenachrichtigungen vermeiden. Es ist kein Internet Standard.

Der Wechsel vom Fragen zum Zuhören wirkt einfach – bis der nächste SA hinzukommt: Wer teilt ihm mit, dass ein UA lauscht? RFC 3082 beantwortet das je nach Netz ohne oder mit Directory Agent (DA) unterschiedlich. Der Zustand liegt in diesen beiden Topologien nicht am selben Ort.

Zwei Topologien, zwei Kosten

In kleinen Netzen ohne DA senden SAs Registrierungen und Abmeldungen breit per IP-Multicast, ersatzweise per IPv4-Broadcast. UAs empfangen Meldungen über verschiedene Diensttypen und Scopes und filtern selbst. Ein zentraler Vermittler muss neue SAs nicht über jedes Abonnement informieren; dafür müssen Empfänger irrelevante Meldungen aussortieren, und die Multicast-Reichweite wird wichtig.

In größeren DA-Netzen hängt der UA die Erweiterung Subscribe an eine Dienstanfrage. Der DA antwortet mit NotifyAt-Multicastgruppen für Diensttyp und Scopes. Bestehende SAs können eine DAAdvert mit der neuen Information erhalten; im SrvAck eines passenden neuen SA kann dieselbe Anweisung stehen. Läuft ein Dienstangebot ohne geordnetes Abmelden aus, meldet auch der DA eine Abmeldung. Die SAs erzeugen weiterhin den Hauptteil der Ereignismeldungen; der DA ist kein zentraler Relaisdienst für jeden einzelnen Vorgang.

Die Arbeit verteilt sich, aber auch der Zustand: Der DA hält Abonnements, informierte SAs merken sich Gruppenadressen, der UA tritt den Gruppen bei, und Vergabe sowie Laufzeit der Multicast-Adresse bilden nochmals eigenen Zustand. Um doppelte NotifyAt-Ankündigungen zu vermeiden, wartet ein DA eine gleichverteilte Zufallszeit von null bis drei Sekunden und lauscht auf passende Ankündigungen anderer DAs. Das unterdrückt Duplikate. Es repliziert keine Abonnementtabelle und schafft keine dauerhafte gemeinsame Zustandsbasis.

Was verschwindet – und was weiterläuft

Abschnitt 10 beschreibt einen Teilausfall ausdrücklich. Verschwindet ein DA unerwartet, geht die dort gespeicherte Abonnementinformation der UAs verloren. Trotzdem erhalten die UAs weiterhin Meldungen bereits bestehender SAs, denn diese haben NotifyAt schon erhalten. Ein neuer SA erfährt dagegen nichts vom Abonnement, sofern ein anderer DA die Information nicht ebenfalls besitzt.

Der UA entdeckt einen Ersatz-DA womöglich erst bei einer aktiven Anfrage. Ein Dienst kann sich also registrieren, nachdem der bisherige DA ausgefallen ist, aber bevor der UA einen Ersatz entdeckt und dort sein Abonnement erneuert hat. Der Meldestrom wirkt intakt, weil alte Dienste weiter auftauchen; der neue kann ganz fehlen.

Der Wiederanlauf schützt zunächst die bereits informierten Sender. Sie melden bis zum Ablauf des Abonnements weiter; steht kein anderer DA zur Verfügung, ignorieren sie den Ablauf und fahren bis zur Entdeckung eines neuen DA fort. Nach der Registrierung dort zeigt das SrvAck, ob der UA erneuert hat. RFC 3082 benennt jedoch selbst eine Restlücke: SAs, die zwischen dem Neustart des DA und der Erneuerung durch den UA starten, werden weiterhin nicht informiert. Soll jeder neu auftauchende Dienst gemeldet werden, sollte der UA jedes neu entdeckte DA abonnieren, das seine Scopes unterstützt. Mehrere Geräte allein replizieren keinen Abonnementzustand.

Eine Meldung ist kein abgeschlossener Dienstvorgang

Auch die übrigen Regeln verlangen getrennte Nachweise. Multicastmeldungen werden über 15 Sekunden mit exponentiellem Backoff wiederholt. RFC 3082 sagt, das erhöhe die Wahrscheinlichkeit, dass eine Nachricht ankommt – nicht, dass sie garantiert zugestellt oder in einem dauerhaften, erneut abspielbaren Ereignisprotokoll gespeichert wird. Eine Attributliste kann das UDP-MTU überschreiten; das Overflow-Bit weist den UA darauf hin, fehlende Attribute später beim SA oder DA abzufragen. Die RFC beschreibt außerdem überprüfbare Authentifizierungsblöcke.

Eine authentifizierte Nachricht beweist aber weder den Empfang bei allen Hörern noch die aktuelle Erreichbarkeit des Endpunkts oder den Abschluss eines Anwendungsvorgangs.

Zu trennen sind deshalb: das UA-Abonnement, der beim DA gespeicherte Typ- und Scope-Zustand, ein beim SA angekommenes NotifyAt, die Mitgliedschaft in der Multicastgruppe, das ausgesendete Ereignis, sein tatsächlicher Empfang, eine spätere Ergänzungsabfrage und der Dienstvorgang selbst. RFC 3082 regelt manche Übergänge; sie werden dadurch nicht zu einem einzigen Ende-zu-Ende-Beleg.

Die beiden Aussagen im Titel widersprechen einander nicht. RFC 3082 sagt nicht, dass der Ausfall eines DA alle Meldungen stoppt: Bestehende SAs können weitersenden, andere DAs können Abdeckung erhalten. Der engere und nützlichere Befund lautet, dass die Kontinuität bereits informierter Sender nicht automatisch jene Sender erfasst, die später hinzukommen. Wer Polling durch Meldungen ersetzt, verlagert den Ort, an dem das Netz sich merkt, wer zuhört – und den Zustand, den eine Wiederherstellung zurückbringen muss.

Quellen

Spezifikation und Historie: RFC 3082, RFC-Editor-Eintrag, Datatracker-Verlauf, RFC 2608: SLPv2, RFC 2119, RFC 2373, RFC 2730 und RFC 2908. Nur redaktionelle Denkanstöße, keine Belege für SLP-Verhalten: Lu Heng, Running-Code Primacy und On Reality Layers.