Zusammenfassung

  • RFC 2188 trennt die Beobachtungen von invoker und performer so deutlich, dass ein erfolgreicher Eindruck an einem Endpunkt mit einem Fehlerzustand am anderen vereinbar sein kann.
  • Daraus folgt eine zentrale Evidenzgrenze verteilter Systeme: Transportzustand, Remote-Operation-Protokollzustand und tatsächlicher Anwendungs- oder Geschäftszustand dürfen nicht als dieselbe Wahrheit behandelt werden.
  • Invoke IDs, Timer, Retries und lokale Bestätigungen liefern jeweils begrenzte Belege. Sie beantworten nicht automatisch, ob eine Wirkung dauerhaft eingetreten ist.
  • Betreiber müssen deshalb festlegen, welche Beobachtung als Erfolg gilt und wann zusätzliche Verifikation erforderlich ist; diese Entscheidung prägt Monitoring, Wiederholungen und spätere Betriebsrisiken.

Ein Protokoll für kurze Remote-Operationen

RFC 2188 erschien im September 1997 als Informational-Dokument und nicht als Internet Standard. Es wurde nicht in einer IETF-Arbeitsgruppe geprüft; die IESG-Notiz weist zudem auf Grenzen der Skalierbarkeit hin. Sein Gegenstand ist ESRO, „Efficient Short Remote Operations“: ein Mechanismus für zuverlässige, verbindungslose Remote-Operationen über UDP oder einen anderen unzuverlässigen Transportdienst. Der Entwurf berücksichtigt ausdrücklich Umgebungen wie CDPD.

ESRO umfasst mehr als den bloßen Austausch einer einzelnen Anfrage und Antwort. RFC 2188 beschreibt Segmentierung und Wiederzusammensetzung, Verkettung und Trennung sowie Multiplexing mehrerer Anwendungen. Für UDP nennt das Dokument Port 259. Die Rollen sind klar getrennt: Der initiierende Endpunkt ist der invoker, die ausführende Seite der performer.

Diese Rollenbezeichnung ist für die Ergebnisinterpretation wesentlich. Sie verhindert bereits sprachlich die Annahme, beide Endpunkte hätten automatisch dieselbe Sicht auf den Vorgang. Was der invoker weiß, hängt von den Ereignissen ab, die ihn erreichen. Was der performer weiß, hängt von einer anderen Folge lokaler und empfangener Ereignisse ab.

Drei Wege schaffen mehr Bestätigung, aber keine gemeinsame Allwissenheit

Im acknowledged-Modus verwendet ESRO einen Drei-Wege-Ablauf. Der performer sendet nach der Ausführung ein RESULT oder ERROR und wartet anschließend auf die Bestätigung des invoker. Erst nach Empfang dieser Bestätigung kann die performer-Seite den entsprechenden RESULT.confirm oder ERROR.confirm erhalten.

Gerade diese zusätzliche Bestätigung zeigt jedoch, weshalb verteilte Ergebniskenntnis relativ zum Endpunkt bleibt. Ein performer-seitiges FAILURE kann mehrere Ursachen haben: Das RESULT- oder ERROR-PDU kann verloren gegangen sein, die Bestätigung des invoker kann verloren gegangen sein, oder ein lokaler Dienstanbieter kann einen Fehler melden.

Damit entsteht eine wichtige Konstellation: Der invoker kann ein erfolgreiches Ergebnis empfangen haben, während der performer trotzdem FAILURE registriert. Das performer-seitige FAILURE beweist in diesem Fall nicht, dass der invoker das Ergebnis niemals erhalten hat. Es bezeichnet die Evidenzlage am performer, nicht eine universelle Wahrheit über alle Beobachter.

RFC 2188 beschreibt zugleich eine begrenzte Asymmetrie in die andere Richtung: Ein Fehler beim invoker impliziert im acknowledged-Modell auch einen Fehler beim performer. Daraus darf aber keine allgemeine Regel symmetrischer Zustände abgeleitet werden. Die Protokollmechanik erlaubt gerade den Fall, dass beide Seiten denselben Vorgang unterschiedlich klassifizieren.

Zwei Wege begrenzen das Wissen noch stärker

Der non-acknowledged-Modus reduziert den Austausch auf zwei Wege. Hier liefert die performer-seitige Bestätigung keine neue Information über den Peer. Sie bestätigt lediglich ein lokales Ende des Vorgangs aus Sicht des performer.

Auch FAILURE hat dort eine enger definierte Bedeutung. Auf performer-Seite stammt es vom lokalen Dienstanbieter. Daraus lässt sich keine zusätzliche Aussage darüber ableiten, was der invoker gesehen hat.

Umgekehrt beweist auch ein Fehler beim invoker weder, ob die entfernte Operation ausgeführt wurde, noch ob ein daraus folgender Anwendungszustand eingetreten ist. Er kann eine fehlende Rückkehr oder ein lokales Problem anzeigen. Das Fehlen eines beobachtbaren Erfolgs ist damit nicht dasselbe wie der Nachweis einer nicht erfolgten Ausführung.

Drei Wirklichkeitsschichten dürfen nicht zusammenfallen

Aus diesen Abläufen ergibt sich eine notwendige Trennung zwischen drei Ebenen. Erstens gibt es die Transportrealität: Daten können übertragen werden, verloren gehen oder lokal als fehlerhaft behandelt werden. Zweitens gibt es die Realität des Remote-Operation-Protokolls: invoker und performer erzeugen aus diesen Transportereignissen definierte Indikationen und Bestätigungen. Drittens gibt es den Anwendungs- oder Geschäftszustand: die Frage, ob die beabsichtigte Wirkung tatsächlich und in der gewünschten Form eingetreten ist.

RFC 2188 verbindet die ersten beiden Ebenen, macht die dritte aber nicht automatisch beweisbar. Selbst ein protokollseitig erfolgreiches Ergebnis ist kein eigenständiger Beleg für einen endgültigen Anwendungs-Commit. Wo dieser Zustand entscheidend ist, braucht die Anwendung eine separate Verifikation.

Die Invoke ID hilft dabei, eine Operation und ihr Ergebnis miteinander zu korrelieren. Sie ist aber kein Nachweis des Geschäftserfolgs. Ebenso liegt die Kodierung außerhalb des Umfangs von RFC 2188, und das Protokoll fügt keine Authentisierung hinzu. Ein korrekt korreliertes Ergebnis beantwortet daher nur bestimmte Fragen; es verwandelt die gesamte Operation nicht in eine durchgehend verifizierte Transaktion.

Timer und Retries gehören zur Beweisgrenze

RFC 2188 überlässt Timer und Retry-Richtlinien dem Betreiber. Damit sind sie nicht bloß lokale Feinabstimmungen. Sie beeinflussen, welche Ereignisse überhaupt beobachtet und wie sie interpretiert werden.

Ein Timeout sagt beispielsweise zunächst nur, dass innerhalb der gewählten Frist nicht die erwartete Protokollentwicklung beobachtet wurde. Ein Retry fügt einen neuen Versuch hinzu, aber keinen rückwirkenden Beweis über den Zustand des vorherigen Versuchs. Sobald Wiederholungen eingesetzt werden, muss die Auswertung deshalb zwischen der Identität einzelner Aufrufe, deren beobachteten Ergebnissen und der separaten Prüfung der beabsichtigten Wirkung unterscheiden.