Zusammenfassung

  • RFC 3081 bildete eine BEEP-Sitzung auf eine TCP-Verbindung ab, hielt die verbindungsweite Flusskontrolle aber nicht für einen Fortschrittsbeleg jedes multiplexierten Kanals.
  • Jeder Kanal begann mit 4096 Oktetten Kredit. Vorrangige SEQ-Frames verschoben diese lokale Grenze; Round-robin sollte verhindern, dass ein voller Kanal alle Bedienrunden beanspruchte.

Korrekte Lieferung war noch keine faire Bedienung

Vier Kanäle teilen einen TCP-Strom. Drei Anwendungen lesen zügig. Die vierte liest langsam, während ihr Sender eine große Antwort bereithält. TCP kann Oktette ordnen, Verluste beheben und die Verbindung gesund halten. Trotzdem können die drei kleinen Arbeiten hinter der großen warten.

Nicht die Zuverlässigkeit ist defekt. Umstritten ist die Zuteilung innerhalb eines zuverlässigen Trägers.

RFC 3081 erschien im März 2001 auf dem Standards Track und definierte BEEP über TCP. Eine Sitzung benutzte eine bestehende TCP-Verbindung, BEEP-Frames wurden zu Oktetten in deren Strom. Die einfache Abbildung verdeckte nicht die Folgen des Teilens. Der Text nannte Aushungern und Deadlock als Risiken, wenn mehrere logische Kanäle allein vom einen Flusskontrollkontext TCPs abhingen.

TCP führte nur das Verbindungskonto

TCP weiß nicht, welche Oktette Sitzungssteuerung, eine kleine Anfrage oder eine Massenantwort bilden. Diese Grenzen entstehen oberhalb. Deshalb gab RFC 3081 jedem BEEP-Kanal ein eigenes Schiebefenster.

Bei seiner Erzeugung durfte ein Kanal 4096 Nutzlastoktette senden. Danach konnte der Empfänger mit einem SEQ-Frame die nächste erwartete Sequenznummer und seine akzeptierte Fenstergröße melden. Beide Werte bildeten die lokale Obergrenze. Erreichte der Sender sie, musste genau dieser Kanal anhalten, selbst wenn der TCP-Schreibpuffer noch Platz bot.

Das war keine zweite Übertragungssicherung. TCP sorgte weiter für Ordnung und Wiederholung. Das BEEP-Fenster beantwortete eine andere Frage: Wie viel zusätzliche Anwendungslast darf dieses Gespräch in die gemeinsame Ressource einführen?

Zähler laufen irgendwann über. RFC 3081 verwies auf die Seriennummernarithmetik aus RFC 1982 und begrenzte Fenster so, dass Vergleiche eindeutig blieben. Eine alte Position durfte nach dem Umlauf nicht als neue Erlaubnis erscheinen.

Die befreiende Meldung durfte nicht hinten anstehen

Kredit wirkt nur, wenn er den Sender erreicht. Wartet SEQ hinter der Nutzlast, die es gerade freigeben soll, kann die Rückkopplung einfrieren. Darum erhielt der Frame Vorrang vor normalem Verkehr.

Das war keine Rangordnung des Inhalts, sondern Schutz der Kausalität. Der Empfänger musste freien Raum melden können, bevor der Sender weitere Last einlassen durfte. Ohne Fluchtweg für die Steuerung hätte Flusskontrolle selbst einen Deadlock erzeugt.

Für Kanäle gleicher Priorität empfahl die RFC Round-robin. Sie versprach weder gleiche Latenz noch mathematische Fairness über alle Betriebssystempuffer. Sie setzte eine Untergrenze: Ein dauerhaft voller Kanal durfte nicht endlos geleert werden, während bereite Nachbarn keinen Zug bekamen.

Der langsame Leser lag noch darüber

Ankunft bei TCP, Aufnahme ins BEEP-Fenster, Übergabe an die Anwendung und äußere Wirkung waren vier Belege. RFC 1122 beschrieb TCP als zuverlässigen Bytestrom, nicht als Abschluss von Anwendungstransaktionen; RFC 9293 behält die Grenze bei.

Spätere Profile zeigen ihren Wert. RFC 3195 transportierte zuverlässiges Syslog mit BEEP, RFC 4744 NETCONF. Eine fortgeschrittene Sequenz belegte weder gespeicherte Logs noch eine wirksame Netzkonfiguration. Nur die semantisch zuständige Anwendung konnte die Wirkung prüfen.

Das Fenster war begrenzte Erlaubnis

Der Empfänger kontrollierte die angekündigte Kapazität, weil er Speicher und Zustellung trug. Der Sender wählte den nächsten kreditfähigen Kanal unter den Prioritätsregeln. TCP kontrollierte Zuverlässigkeit und Stau der Verbindung. Die Anwendung entschied über nützliche Arbeit.

Diese Befugnisse lagen nebeneinander, ersetzten sich aber nicht. Freier TCP-Raum war keine BEEP-Erlaubnis. BEEP-Empfang war kein Anwendungsabschluss. Ein gewährter Turn war keine bewiesene Wirkung.

Die bleibende Aussage von RFC 3081 reicht über BEEP hinaus. Benannte Spuren sind noch nicht unabhängig. Es braucht getrennte Budgets, Rückmeldung, die nicht unter dem von ihr geregelten Verkehr begraben wird, und sichtbare Bedienung, damit ein legitimer Nutzer nicht unbemerkt Eigentümer der gemeinsamen Infrastruktur wird.

Quellen

  1. https://www.rfc-editor.org/info/rfc3081
  2. https://www.rfc-editor.org/rfc/rfc3081.html
  3. https://datatracker.ietf.org/doc/rfc3081/
  4. https://www.rfc-editor.org/rfc/rfc3080.html
  5. https://www.rfc-editor.org/rfc/rfc1982.html
  6. https://www.rfc-editor.org/rfc/rfc1122.html
  7. https://www.rfc-editor.org/rfc/rfc9293.html
  8. https://www.rfc-editor.org/rfc/rfc3195.html
  9. https://www.rfc-editor.org/rfc/rfc4744.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/