Zusammenfassung

  • Nach RFC 3528 darf ein annehmender mesh-enhanced Directory Agent dem Service Agent mit SrvAck antworten, bevor er die Registrierung asynchron an Peer-DAs weiterleitet. Der Beleg gilt für lokale Annahme, nicht für die verteilte Sicht.
  • Summary Vectors belegen Empfangsfronten je Accept-DA. Sie zertifizieren weder vollständige Abfrageergebnisse noch Gültigkeit, Erreichbarkeit oder Gesundheit des beschriebenen Dienstes. Autorität, Übertragung, Abfrage und Wirkung brauchen eigene Belege.

Ein grüner Vektor ist verführerisch. Mehrere Zahlen stehen auf dem neuesten bekannten Stand; kein Rückstand ist sichtbar. Daraus wird leicht die Aussage, die Verzeichnisse seien gesund und die Dienste verfügbar.

Der Vektor hat diese Autorität nicht. RFC 3528 erschien im April 2003 als Experimental Protocol. Es ergänzt SLPv2 um ein vollständiges Mesh pro Scope, direkte Weiterleitung und Anti-Entropie. Es ordnet den Austausch von Registrierungszustand, nicht die Wirklichkeit hinter dem Zustand.

Das erste Ack endet nur den lokalen Schreibvorgang

Ein Service Agent übergibt seine Registrierung einem Directory Agent. Der DA, der die Aktualisierung annimmt, ist der Accept-DA. Als MDA kann er den Zustand anschließend an Peers mit passenden Scopes senden.

Direkte Weiterleitung ist asynchron. Der Accept-MDA kann dem MSA SrvAck schicken, bevor er das Srv(De)Reg an einen anderen MDA weiterleitet.

Das Ack ist damit ein echter, aber begrenzter Beleg. Es sagt, dass ein bestimmter Agent eine bestimmte Last unter seiner lokalen Entscheidung angenommen hat. Es sagt nicht, dass alle Peers die Last erhielten oder dass ein späterer User Agent sie finden wird.

Diese Trennung schützt den Schreibpfad. Müsste der Sender auf jeden Peer warten, würde ein langsamer Replikationspfad jede Registrierung blockieren. Die Architektur entkoppelt die Vorgänge; die Statussprache muss dasselbe tun.

Der Annahmebeleg bindet Accept-DA, authentisierten MSA, Scopes, Payload-Hash, Version Timestamp, Accept ID, Policy und Entscheidung. Eine pauschale Meldung „im Mesh registriert“ erweitert die Beobachtung ohne Quelle.

Geordneter Transport ist keine sofortige Replikation

Peer-DAs halten eine persistente, zuverlässige, geordnete Verbindung für alle gemeinsam bedienten Scopes. Sie sorgt dafür, dass ein laufender Herkunftsstrom seine Reihenfolge behält.

Zuverlässigkeit macht einen noch nicht ausgeführten Sendeschritt aber nicht rückwirkend fertig. Eine Verbindung kann ausfallen, ein Rückstand kann entstehen, und Anti-Entropie kann später Zustände nachliefern.

Nach der anfänglichen Synchronisierung sendet der Accept-DA neue Updates direkt an seine relevanten Peers. Es ist eine Weiterleitung über einen Hop; Empfänger fluten denselben Zustand nicht unkontrolliert weiter.

Für jedes von einem Peer empfangene Update ist wegen der Transportgarantie kein eigenes SrvAck nötig. Gerade deshalb darf das Ack an den MSA nicht als versteckte Quittung aller Peers gelten.

Ein belastbarer Transferbeleg nennt den erwarteten Peer, seine authentisierte Identität, gemeinsame Scopes, Verbindung, Sendeposition, Ergebnis und spätere Empfangsfront. „TCP verbunden“ beantwortet keine dieser registrierungsspezifischen Fragen vollständig.

Accept IDs ordnen Quellen, nicht das ganze Mesh

Eine Accept ID kombiniert die URL des Accept-DA mit einem dort monoton steigenden Zeitstempel. Updates desselben Accept-DA müssen in dieser Reihenfolge verbreitet werden.

Ein anderer Accept-DA besitzt eine andere Folge. Updates aus verschiedenen Ursprüngen dürfen in beliebiger relativer Reihenfolge eintreffen. Die Zahlen bilden keine gemeinsame logische Uhr.

Zusätzlich vergibt der MSA einen Version Timestamp. Er entscheidet, welche Fassung derselben Registrierung neuer ist. Die Ankunftszeit beim Peer taugt nicht, weil eine ältere Fassung verspätet nach der neueren ankommen kann.

Version, Annahmeordnung und Abfragezeit beantworten verschiedene Fragen. Ein einziges updated_at verschluckt genau die Trennung, die eine spätere Abweichung erklärt.

Das Protokoll nimmt einen schreibenden SA pro Registrierung an. Mehrere Autoren erfordern eine zusätzliche Autoritäts- und Konfliktregel; RFC 3528 stellt sie nicht bereit.

Empfangsfronten sind keine Gesundheitszertifikate

Der Summary Vector enthält für jeden bekannten Accept-DA den neuesten empfangenen Accept Timestamp. Er verdichtet mehrere geordnete Herkunftsströme zu mehreren Fronten.

Ein Peer fordert Zustände hinter diesen Fronten an. Eine vollständige Anfrage umfasst auch Accept-DAs, die im Anfragevektor fehlen. Eine selektive Anfrage bezieht sich nur auf die aufgeführten Accept IDs.

Diese Auswahl gehört in den Erfolgsbeleg. Selektive Anti-Entropie kann fehlerfrei enden und einen ausgelassenen Ursprung überhaupt nicht prüfen. „Synchronisiert“ ohne Modus und Menge ist unbestimmt.

Die angeforderten Zustände werden in Accept-ID-Reihenfolge übertragen; danach bestätigt ein SrvAck die Verarbeitung der Anti-Entropie-Anfrage. Dieses Ack hat ein anderes Objekt als die frühere Registrierungsbestätigung.

Auch ein lückenloser Vector beweist nur Zustandsübernahme. Die Registrierung kann abgelaufen, sachlich falsch, im falschen Scope oder auf einen toten Endpoint gerichtet sein. Replikationskonsistenz und Dienstgesundheit liegen auf verschiedenen Ebenen.

Eine Löschung bleibt zunächst sichtbar

Bei der Wiederherstellung wird eine Registrierung mit ihrer verbleibenden Lebensdauer übertragen, nicht mit einer neuen vollen Frist. Sonst könnte jeder Abgleich veraltete Anzeigen verlängern.

Eine Abmeldung bleibt als Deleted Registration erhalten. Der Tombstone verhindert, dass eine ältere, verspätete Registrierung den gelöschten Zustand wiederbelebt. Nach Ablauf der ursprünglichen Registrierung kann er bereinigt werden.

Lokale Annahme der Abmeldung, Empfang des Tombstones, Verschwinden aus einer Abfrage und physische Bereinigung sind getrennte Ereignisse. Kein einzelnes davon bedeutet gleichzeitiges Verschwinden bei allen Beobachtern.

Registrierungs-ID, Version, Accept ID, Löschflag, Restlebensdauer, Abgleichspfad und Abfragebeobachtungen machen die Entscheidung später rekonstruierbar.

Der Scope begrenzt das Publikum

Alle MDAs, die denselben Scope bedienen, bilden dafür ein vollständiges Mesh. Eine Peer-Verbindung kann mehrere gemeinsame Scopes tragen. Ein MSA muss nur bei so vielen MDAs registrieren, dass deren vereinigte Scopes seine eigenen abdecken; die Weiterleitung soll die anderen erreichen.

Eine Annahme in einem Scope spricht daher nicht für DAs außerhalb dieses Scopes. Ein User Agent kann einen anderen DA oder Scope wählen und eine andere Antwort erhalten, ohne den lokalen Annahmebeleg zu widerlegen.

Das vollständige Mesh wurde für Einfachheit und Zuverlässigkeit gewählt. Der RFC nennt im Allgemeinen Größenordnungen von einigen zehn MDAs oder weniger, nicht unbegrenzte Skalierung. Das ist Entwurfsrahmen, keine Messung einer heutigen Installation.

Wird ein Eltern-Scope in zwei Kinder geteilt, kann eine vormals einmalige Registrierung in beiden Kindern nötig werden. Scope-Verwaltung verändert also die Discovery-Pflicht.

Ein falscher Eingang verteilt sich zuverlässig

mSLP nutzt die Authentisierung von SLPv2. Ein MDA sollte andere MDAs vor dem Peering und MSAs vor Annahme und Weiterleitung authentisieren; ein MSA sollte seinen MDA authentisieren.

Eine zuverlässige TCP-Verbindung beweist keine berechtigte Mitgliedschaft. Eine gültige Signatur allein beweist nicht, dass ihr Schlüssel in diesem Scope schreiben darf. Autorisierung und Semantik bleiben eigene Entscheidungen.

Wird ein MDA kompromittiert, kann die Verbreitung alle anderen betreffen. Derselbe Mechanismus, der Verfügbarkeit schafft, vervielfacht eine falsche Annahme.

SLPv2 beschreibt beim Bootstrap ohne vorbereitete Sicherheitskonfiguration einen Anteil „blind faith“. Schlüsselverteilung und Prüfpolicy sind deshalb Voraussetzungen des Betriebs, nicht automatisch im Protokollnamen enthalten.

IANA führt Mesh-enhancement als SLPv2 Extension ID 0x0006 mit RFC 3528. Der Eintrag koordiniert die Nummer; er bestätigt weder Implementierung noch Aktivierung, Authentisierung, Konvergenz oder Ergebnis.

Eine Trefferliste benutzt den Dienst noch nicht

Der SA schreibt zu einem DA; ein UA fragt später einen nach seinen Regeln ausgewählten DA ab. Sichtbarkeit wird deshalb an den relevanten Lesepunkten gemessen: DA-Identität, Scopes, Prädikat, Response-Hash, Version, Restlebensdauer und Beobachtungszeit.

Der Treffer ist weiterhin nur eine Verzeichnisbehauptung. Er öffnet keine Verbindung, prüft kein Anwendungsprotokoll, autorisiert keinen Nutzer und beendet keinen Geschäftsprozess.

Für eine Verfügbarkeitsaussage folgen Zielauflösung, Netzwerkerreichbarkeit, Handshake, dienstspezifischer Health Check und Anwendungsergebnis. Der Summary Vector kann keinen dieser Schritte übernehmen.

Eine Belegkette mit klaren Zuständigkeiten

Zuerst werden Protokollidentität und Status, Scope-Definition, MSA-Identität, Credential, Trust Policy und Autorisierung erfasst. Diese Fakten werden mit Payload-Hash, Version Timestamp, Accept-DA und Accept ID verbunden.

Das erste SrvAck bleibt unverändert lokaler Beleg. Peer-Weiterleitung, Summary Frontier und Anti-Entropie werden als spätere Ereignisse verknüpft. Wissen von später darf den früheren Beleg nicht umdeuten.

Abfrage und Diensttest schließen die Kette. Verzeichnisbetrieb verantwortet Verteilung, Security die Autorität, der Service Owner die Gesundheit und die Anwendung das Nutzerergebnis. Audit verbindet, ohne Zuständigkeiten zu erfinden.

Evidenzgrenze

Dieser Artikel benennt keine Implementierung, keinen Anbieter, Betreiber, Agenten, Dienst, Endpoint, Eintrag, Vorfall, Ausfall, Angriff und kein Kundenergebnis. Er misst keine Verbreitung, Größe, Latenz, Sichtbarkeit oder Gesundheit.

RFC 3528 wird als Experimental Protocol vom April 2003 behandelt, nicht als Internet Standard. Die Defaultwerte 200 Sekunden Keepalive und 300 Sekunden Timeout sind Dokumentwerte, keine reale Konfiguration oder Messung.

Register und Metadaten belegen Dokumentidentität und zugewiesene Werte, nicht Running Code.

Heng Lus Notizen zu Autorität und laufendem Code sind eine offengelegte redaktionelle Perspektive. Sie motivieren die Begrenzung von Belegen, beweisen aber weder IETF-Absicht noch Betriebskonformität.

Die Schlussfolgerung bleibt eng: Annahme, Empfangsfront, Abfragesicht, Erreichbarkeit und Wirkung können getrennt wahr oder falsch sein.

Quellen