Zusammenfassung

  • Erschöpfte reportAfter bei RFC 3342, entstand ein vorläufiger Zeitbericht; die Daten wurden dennoch an das nächste Relais gesendet.
  • noLaterThan konnte die Zustellung stoppen, während returnTrip den Rückweg des Abschlussberichts begrenzte: Warnung, Eingriff, Berichtsempfang und Ergebnis waren getrennt.

APEX bot im Kern einen sofortigen Best-Effort-Datagrammdienst auf Anwendungsebene. Ohne Optionen konnte ein nicht verfügbares Relais Daten still verwerfen. RFC 3342 ergänzte Warten, Berichte und Grenzen, gab diesen Mechanismen aber nicht dieselbe Bedeutung.

Gerade diese Differenz verhindert, dass eine Überwachung sich selbst zur Ausführungsschicht erklärt. Ein Alarm kann korrekt sein, während die gemeldete Arbeit weiterläuft. Wer den Alarm automatisch als endgültigen Fehler speichert, erzeugt einen Zustand, den das Protokoll nie behauptet hat.

Melden und weiterleiten

dataTiming wurde an jedem Hop verarbeitet. Der Ursprung musste deshalb targetHop="all" und mustUnderstand="true" setzen. Vor der Weitergabe zog jedes Relais seine lokale Bearbeitungszeit von reportAfter ab: Auswahl des nächsten Relais, erfolgreiche Bindung und Vorbereitung des Sendens.

Bei null oder weniger setzte das Relais den Wert auf null und rief den Berichtsdienst auf. Unabhängig davon wurden die Daten weitergeleitet. Am Endpunkt entstand ebenfalls ein vorläufiger Bericht, wenn dessen ok nicht innerhalb des verbleibenden Intervalls eintraf.

Der statusResponse bezog sich auf die Transaktionskennung der Option und verwendete für den Empfänger den Code 350, einen vorläufigen Erfolg. Er sagte: Die Meldeschwelle ist überschritten. Er sagte nicht: Die Daten sind verworfen. Spätere Zustellung widerlegte die Warnung nicht; die Warnung bewies den Ausgang nicht.

Die harte Grenze griff ein

Auch noLaterThan wurde um lokale Bearbeitungszeit reduziert. Fiel der Wert jedoch vor dem nächsten Hop auf null oder darunter, sendete das Relais die Daten nicht weiter. Mit reportErrors entstand zusätzlich ein Zeitfehlerbericht. Am letzten Hop begrenzte der Restwert die Wartezeit auf das ok des Endpunkts.

Die weiche Schwelle beobachtete, die harte Schwelle veränderte die Ausführung. Beide lediglich als Timeout zu speichern, löscht die Antwort auf die wichtigste Betriebsfrage: Ist der erste Versuch noch unterwegs?

Selbst der harte Abbruch belegte nur seinen Ort und sein Budget. Lokale Verarbeitung, langsame Verbindung, fehlendes Relais, Überlast oder nicht angebundener Endpunkt konnten die Zeit verbrauchen. Daraus folgte weder eine universelle Fehlerursache noch ein bestimmtes Nutzerergebnis.

Der Bericht hatte eine eigene Frist

Nach erfolgreicher Übertragung an den Empfänger löste ein von null verschiedener returnTrip einen Abschlussbericht aus. Der Bericht war wiederum eine APEX-Datenoperation. Sein neues dataTiming.noLaterThan entsprach dem ursprünglichen returnTrip.

Nutzdaten und Nachweis reisten somit getrennt. Die Daten konnten ankommen, der Bericht konnte erzeugt werden und nur der Bericht konnte auf dem Rückweg verloren gehen. Nach Fristablauf durfte der Sender den Bericht als verloren vermuten, nicht rückwirkend die Nutzdaten.

Ein belastbares Journal trennt Eingang, verbleibende Meldeschwelle, vorläufige Berichtserzeugung, Weiterleitung danach, harte Restfrist, Stopp oder Endpunktquittung, Abschlussbericht, Rückwegfrist, Berichtsempfang und Anwendungsergebnis.

Warteschlange und Hopzahl

hold4Endpoint erlaubte das Zwischenspeichern, solange der Empfänger nicht angebunden war. Ohne Obergrenze konnte die Warteschlange unbegrenzt bestehen. RFC 3342 warnte vor Denial-of-Service und schlug administrative Grenzen wie ein kurzes noLaterThan vor. Speicherung war kein Zustellnachweis.

dataHopping begrenzte dagegen ähnlich dem IP-TTL die Zahl der Relais, um Schleifen zu erkennen. Hopbudget und Zeitbudget konnten unabhängig voneinander auslaufen. Ein gemeinsames Fehlerfeld würde auch hier zwei Ursachen verwechseln.

attachOverride konnte eine bestehende Anwendung am selben Endpunkt ersetzen. Die Eigentumsfrage später Daten gehört zu RFC 3340 und eigener Berichterstattung. Ein Zeitbericht löste diese Nachfolge nicht.

Die historische Aussage blieb schmal

RFC 3342 erschien im Juli 2002 als Standards-Track-Dokument. Heute ist es Historic; die RFC-Editor-Suche zeigt keine passenden Errata. Der IETF-Verlauf vom 29. Juli 2012 hält fest, dass nach Kenntnis der IETF keine Implementierungen der RFCs 3340–3343 eingesetzt waren und die Funktionalität durch das weit verbreitete XMPP nach RFC 6120 und RFC 6121 bereitgestellt wurde.

Das ist keine Ursache für die fehlende Einführung und kein Implementierungsurteil. Der Text warnte zudem, dataTiming könne private Netztopologie offenlegen; Administratoren konnten es auf Ein- und Ausgangspunkte einer Domäne beschränken. Beobachtung hatte Nutzen und Kosten, aber keine unbegrenzte Autorität.

Die bleibende Regel lautet: Benenne den Timer, der nur meldet, den Timer, der handelt, und den Timer, der den Nachweis zurückbringt. Erst dann kann ein Alarm informieren, ohne einen noch lebenden Vorgang fälschlich zu beenden.

Quellen