Zusammenfassung
- Das Ereignis
Sentbeendet die Verantwortung der Transport-API für abgeleitete Nachrichtendaten; es beendet nicht die Beweiskette für eine Zustellung. - Ob die Daten bereits gesendet wurden oder noch in einem Kernel- oder Schnittstellenpuffer liegen, bleibt laut RFC 9622 implementationsspezifisch.
„Gesendet“ wirkt wie ein Abschlusswort. In einer Betriebsansicht kann es eine Eskalation schließen, einen Retry unterdrücken oder eine externe Zusage stützen. Gerade deshalb muss klar sein, welcher Akteur es ausgesprochen hat. Ein Label des lokalen API-Lebenszyklus darf nicht unbemerkt zu einer Aussage über den Zustand eines anderen Systems werden.
Die Transport-Services-API in RFC 9622 ist in dieser Hinsicht vorbildlich zurückhaltend. Colin Perkins steht neben sieben weiteren Autoren auf dem Standards-Track-Dokument von 2025. Nach einem Send tritt Sent ein, wenn die aus der Nachricht abgeleiteten Daten nach unten oder durch den zugrunde liegenden Protokoll-Stack gelangt sind und nicht mehr in der Verantwortung der API liegen. Der RFC bestimmt nicht, ob dies eine tatsächliche Übertragung, einen Netzwerkschnittstellenpuffer, einen Kernelpuffer oder einen anderen Zustand bedeutet.
Das ist eine Zuordnung von Verantwortung, keine Lücke in der Spezifikation. RFC 9621 trennt Auswahl-, Verbindungs- und Nachrichteneigenschaften. Eine Anwendung kann Anforderungen, Verbote und Präferenzen äußern; das Transport-System wählt Kandidaten jedoch auch nach lokaler Politik und Heuristik. Eine Priorität kann ausschließlich den Senderplaner berühren, und RFC 9622 gibt keine Garantie, wie eine solche Prioritätsäußerung verwirklicht wird.
Auch die Fehlerpfade sind absichtlich lokal lesbar. Expired bedeutet, dass eine Nachricht vor Ablauf ihrer Lifetime nicht gesendet wurde. SendError benennt etwa zu große Daten, einen Fehler des Unterbaus oder widersprüchliche Eigenschaften. Die Lifetime selbst ist nur ein Hinweis; sie garantiert nicht, dass nach Ablauf keine Sendung mehr stattfindet. Keines dieser Ereignisse belegt eine Verarbeitung beim entfernten Dienst.
Für einen belastbaren Abschluss müssen die Nachweise weiterwandern: lokaler API-Aufruf, Übergabe, Ausgabebeobachtung, Transport beim Peer, Anwendungsvorgang, fachliche Wirkung. Ein Sent-Ereignis ist ein guter Beleg für genau eine Stufe. Seine Genauigkeit geht verloren, sobald es für die übrigen Stufen sprechen soll.
Sources
- RFC 9622 — Abstrakte API für Transportdienste
- RFC 9621 — Architektur und Anforderungen für Transportdienste
- RFC 8922 — Sicherheitsprotokolle und Transportdienste
- RFC 8085 — UDP-Nutzungsrichtlinien
- IETF Datatracker — Colin Perkins
- IETF — öffentliches Porträt von Colin Perkins
- Heng Lu — Minimale Anfangsspezifikation
- Heng Lu — Vorrang des laufenden Codes
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
