NETWAYS Blog

Viele Anwendungen sind darauf angewiesen, in Echtzeit Benachrichtigungen zu bestimmten Ereignissen zu erhalten:

• Der Benutzer soll sofort über neue E-Mails benachrichtigt werden.
• Notifications von einem Monitoring-System sollen durch eine Anwendung in der Taskleiste angezeigt werden.
• Nachrichten, die per Instant Messaging versendet werden, sollten zeitnah beim Empfänger ankommen.

Zur Umsetzung solcher Anwendungen bieten sich durch die Verwendung von bekannten Standardprotokollen wie HTTP signifikante Vorteile:

Vorhandene Tools und Infrastruktur

Für HTTP gibt es in nahezu jeder Programmiersprache nativ integrierte Libraries. Hierdurch sinkt für Entwickler, die einen neuen Client für das Protokoll schreiben wollen der initiale Aufwand. Zwar unterscheiden sich die Anwendungen trotzdem noch an einigen Stellen (Wie sehen einzelne Messages aus? Welche URLs werden verwendet?), dafür werden andere Themen wie Authentifizierung bereits durch den Standard abgehandelt.
Um im Fehlerfall bzw. während der Entwicklung Probleme zu analysieren gibt es bereits etliche Tools. Diese reichen von einfachen konsolen-basierten HTTP-Clients wie curl und wget über Protokoll-Analyse-Tools wie Wireshark hin zu speziell für HTTP entwickelten Debug-Hilfsmitteln wie Fiddler.
Zusätzlich unterstützt HTTP mittels HTTP-Proxies „Routing“, da es in jeder Anfrage alle notwendigen Adressinformationen bereithält.

Streaming über HTTP

Nun ist HTTP zunächst ein Protokoll, das darauf basiert, dass für eine Anfrage jeweils genau eine Antwort übermittelt wird. Wie können wir nun also dem HTTP-Client unaufgefordert Events schicken?
Die einfache Grundlage hierfür ist eine Technologie, die als „Long Polling“ bekannt ist: Der HTTP-Client sendet hierbei zunächst einen Request und bekommt vom Server auch eine Antwort. Diese Antwort hat allerdings kein Ende: Der Server sendet über die noch bestehende Verbindung JSON-kodierte Ereignisse sobald sie vorliegen.
Der Client muss dazu die Möglichkeit haben, zwischen den einzelnen JSON-kodierten Ereignissen unterscheiden zu können. Am Beispiel von zwei JSON-Ereignissen möchte ich hier auf die unterschiedlichen Ansätze eingehen.
Beispiel:

• { „id“: 1, „message“: „Hallo Welt“ }
• { „id“: 2, „message“: „Dies ist ein Test.“ }

Inkrementeller JSON-Parser

Ein JSON-Parser, der den Datenstrom inkrementell parsen kann, hat die Möglichkeit, zu erkennen, an welcher Stelle eine JSON-Message aufhört und die nächste beginnt. Die Messages werden hierbei also einfach aneinander gehängt. Der Body der HTTP-Antwort würde dabei etwa so aussehen:

{ "id": 1, "message": "Hallo Welt" }{ "id": 2, "message": "Dies ist ein Test." }

Vorteil hierbei ist, dass die Implementation des Servers sehr einfach ist. Allerdings können nur wenige JSON-Parser inkrementell parsen, was die Entwicklung des Clients erschwert.

Eine JSON-Message pro Zeile

Hierbei werden einzelne JSON-Messages per Newline („\n“) getrennt. Beim Encoden der Messages muss darauf geachtet werden, dass diese selbst keine Newlines beinhalten.

{ "id": 1, "message": "Hallo Welt" }
{ "id": 2, "message": "Dies ist ein Test." }

Auf Clientseite ist dies im Regelfall recht einfach umzusetzen. Die Entwicklung des Servers wird minimal dadurch erschwert, dass mit Newlines innerhalb der JSON-Messages richtig umgegangen werden muss.

Längenangabe vor jeder JSON-Message

Bei dieser Möglichkeit sendet der Server vor jeder eigentlichen Message die Länge der JSON-Daten gefolgt von einem Newline:

37
{ "id": 1, "message": "Hallo Welt" }
45
{ "id": 2, "message": "Dies ist ein Test." }

(Wer nachzählt kommt möglicherweise darauf, dass die Längenangaben um ein Byte zu groß sind. Hierbei ist zu beachten, dass ich für dieses Beispiel aus Gründen der Lesbarkeit nach den JSON-Messages ein Newline eingefügt habe, das dann auch Bestandteil der Message ist und mitgezählt werden muss.)
Im Regelfall sollte es sowohl für Client als auch Server recht einfach sein, dies umzusetzen.