Seite 2: BEEP

Inhaltsverzeichnis

Noch ein Standard

Internetstandards sollen die Interoperabilität von Anwendungen im Netz gewährleisten. HTTP als einer der erfolgreichsten Vertreter zeigt die Richtigkeit eines derartigen Vorgehens. Die Aufgabe, für die HTTP entwickelt wurde, ist klar umrissen und hat sich seit der ersten Version kaum verändert. Erst die Diskussion um HTTP/2, das außer dem Namen nur noch wenig mit HTTP/1.1 gemeinsam hat, zeigte die Schwierigkeiten, eine neue Version eines bestehenden Standards zu definieren, die den Anwendungsbereich eines anderen erweitert. Automatisch kommt in dem Szenario schnell die Frage nach der Abwärtskompatibilität auf. Die Folge sind Kompromisse beim Design, die sich negativ auf die Akzeptanz der neuen Version auswirken können.

Oft verzichten die zuständigen Organe daher auf eine neue Version und streben direkt einen komplett neuen Standard an, der sich wiederum häufig nur langsam, wenn überhaupt, durchsetzt. Ein möglicher Grund dafür sind die sogenannten Well-known Ports. Ein neues Protokoll muss einen neuen Port verwenden. Damit ein Server mit dem Protokoll erreichbar ist, sind in vielen Fällen Firewall-Regeln anzupassen. Iterative Verbesserungen sind so kaum durchsetzbar. Es stellt sich die Frage, ob die seit Jahrzehnten bekannten und bewährten Methoden der Standardisierung von Protokollen ungeeignet für die aktuellen Anforderungen sind. Jon Postel hat 1977 auf das Prinzip der Schichten verwiesen (siehe Teil 1). Das monolithische Transmission Control Program wurde daraufhin in TCP und IP aufgeteilt. Dabei fassten die Entwickler grundlegende Funktionen zusammen, um sie modular verwenden zu können. Wollte man die Vorgehensweise auf Nachrichtenprotokolle anwenden, wäre zunächst zu überlegen, welche Funktionen letztlich vorhanden sein sollten.

Profile statt Protokolle

Elementare Funktionen wie Flusskontrolle, Kanäle und Multiplexing bilden mit vielen anderen die Infrastruktur für einen reibungslosen Nachrichtenaustausch im Netz. Der Inhalt der Nachrichten spielt dabei keine Rolle. Auch Kommunikationsmuster wie Client/Server oder Publish/Subscribe legt erst die Anwendung fest. Von den in Teil 2 vorgestellten Protokollen bietet das Blocks Extensible Exchange Protocol (BEEP) als einziges die Option, mit Profilen die Syntax und Semantik von Nachrichten sowie das Kommunikationsmuster zu definieren.

Abbildung 1 zeigt, wie sich BEEP-Profile wie eine neue Schicht in den Protokollstapel einfügen. Sie übernehmen die Rolle der Schnittstelle zur Anwendung. Andere Nachrichtenprotokolle wie HTTP, SOAP, RPC, aber auch MQTT lassen sich mit Profilen nachbilden. Eine Reihe von BEEP-Profilen stehen als IANA-Standard zur Verfügung. Ob Standard oder proprietär, die Profile übernehmen die Rolle des TCP/IP-Anwendungsprotokolls und nutzen die Möglichkeiten asynchroner, skalierbarer Kommunikation über eine einzige Transportverbindung.

Kanäle statt Ports

BEEP und der neue HTTP/2-Standard verwenden Kanäle für asynchrone Kommunikation. Ein einzelner Kanal verhält sich wie ein Vollduplex-Stream, man kann also lesend und schreibend auf ihn zugreifen. Entsprechende Systeme übertragen Nachrichten nacheinander. Die Kanäle sind jedoch unabhängig und erlauben eine asynchrone Kommunikation über eine einzige TCP-Verbindung. Nachrichten werden in Pakete (Frames) zerlegt und über eine gemeinsam genutzte TCP-Verbindung versendet (Multiplexing). JederKanal verfügt über einen eigenen Puffer, der wiederum eine Flusskontrolle erfordert, damit es nicht zu Übertragungsfehlern durch zu schnelles Senden von Daten kommt. Framing und Multiplexing erlauben einer Anwendung, die Übertragung einer großen Nachricht zu unterbrechen, wenn eine Änderung des Systemzustands es erfordert.

Die Idee von Framing und Flusskontrolle in einem Anwendungsprotokoll erscheint zunächst ungewohnt. Diejenigen, die Details des TCP-Protokolls kennen, lehnen die Idee gelegentlich mit dem Argument ab, dass die entsprechenden Funktionen in der Transportschicht vorhanden sind. Wenn für asynchrone Kommunikation mehrere TCP-Verbindungen zum Einsatz kommen, reicht das folglich aus. Für asynchrone Kommunikation über eine TCP-Verbindung durch Kanäle und jeweils einen Empfangspuffer pro Kanal ist jedoch auch im Anwendungsprotokoll Framing und Flusskontrolle nötig. Quality of Service, also die Steuerung der Priorität unterschiedlicher Kanäle, ist eine wichtige Anforderung, wenn ein Dienst unterschiedliche Leistungen anbieten soll. Framing, Multiplexing und Flusskontrolle ermöglichen eine gezielte Steuerung der Bandbreite, die einer Schnittstelle zur Verfügung steht.