Seite wählen

NETWAYS Blog

Der kleine Ping erkundet die Welt

Als der kleine Ping vor bald 34 Jahren geboren wurde, war die Welt noch übersichtlich und in Ordnung. Jeder kannte jeden und man lernte schnell neue Freunde kennen. Diese Freunde bleiben einem dann häufig auch lange treu. Ein offenherziger Kerl wie der kleine Ping lernte damals sehr schnell sehr viele Freunde kennen.
Gut erzogen und treu wie er war, besuchte er die meisten davon immer wieder und wieder. War jemand krank, dann war Ping schon mal länger unterwegs oder kam gar nicht mehr zurück. Aber langsam von vorn.
Seinen Namen bekam der kleine Ping vermutlich, weil sein Vater Mike zu viele Kriegsfilme im Fernsehen schaute. Oder weil seine Arbeit bei der US Army ihn so faszinierte. Ping, so hört sich nämlich der Sonar ein einem U-Boot an. Wie ein Klopfen. Irgendwie fanden seine Eltern das wohl sehr spannend. Also die Tatsache dass da Schallsignale gesendet und wieder zurück reflektiert wurden.
Das wäre doch auch ein schöner Job für unseren Ping, dachten sie. Also wurde der kleine Ping schon sehr früh losgeschickt, um unsere Welt zu erkunden. Da war er noch ganz klein, gerade mal 1000 Zeilen hoch. Dennoch fühlte er sich wie ein ganz Großer. Ständig auf Reisen kannte er sehr bald jede Straße, jede Autobahn und jeden Weg wie seine Westentasche. Das fand er unglaublich spannend.
Sein Vater war aber sehr streng. Jedesmal wenn Ping das Haus verließ notierte er auf die Millisekunde genau, wie spät es war. Und als der Ping dann wieder zurückkam, wurde auch das notiert. Aus Start- und Endzeit errechnete sein Vater dann, wie lange der kleine Ping unterwegs war.
Als der kleine Ping älter wurde, machte er sein Hobby zum Beruf. Wenn jemand wissen wollte, wie lang man auf einer Strecke unterwegs war, dann ging er zum kleinen Ping. Wollte ein LKW-Fahrer wissen, ob sein fetter Brummi unter einer Brücke Platz hätte – unser Ping konnte das klären.
Manchmal war es freilich ein wenig langweilig. Als Berufspendler war er hauptsächlich auf immer denselben Strecken unterwegs. Zu den Stoßzeiten im Stau zu sein war auch kein Vergnügen. Ping nahm sich dann ab und an andere Texte zum Lesen mit, das sorgte für gute Unterhaltung. Sein Vater prüfte übrigens immer, ob er auch wirklich mit denselben Texten wieder nach Hause kam. Fehlten Buchstaben oder waren falsche dabei, dann ließ er ihn unter Umständen gar nicht mehr ins Haus. Ping musste dann auf der Straße übernachten.
Ab und an erlaubte Ping sich einen Spaß. Da packte er ein Vielfaches an Ladung drauf um zu sehen, ob auch wirklich alle Tunnel-Decken und Brücken hoch genug waren. Er war halt so ein richtig nerviger Besserwisser. Und ab und an krachte es dabei natürlich ganz heftig. Ping bekam dann aber nicht etwa Stress. Das lief dann einfach als „Prüfung des Maximalen Tunnel Umfangs“, kurz MTU-Test. Ping hatte seinen Spaß – und die Polizei war froh, dass sie von jemandem auf Verletzungen der Bauvorschriften hingewiesen wurden.
Die richtig wichtigen Jobs bekamen andere. Einige seiner Brüder arbeiteten bei der Polizei, das hätte dem kleinen Ping gefallen. Bei welcher Einheit wäre ihm egal gewesen, zur Not auch bei den lahmen Kerlen von der „Ruhigen Inneren Polizei“, dem RIP. Das sind die Verkehrspolizisten in den kleinen Käffern auf dem Land.
Im Grunde machten die nicht viel mehr als die Leute nach links und rechts zu dirigieren. Aber dennoch. Betrachtete man das Geschehen vom Kirchturm aus, dann sah das schon beeindruckend aus. Alles floss schön links und rechts an den Polizisten vorbei – genau wie die sich das gerade so vorstellten. Ganz großes Kino!
Die richtig coolen Jungs hingegen arbeiteten bei der „Beindruckend Großen Polizei“, dem BGP. Das ist die Autobahnpolizei, irre was bei denen abging. Schon bei der Aufnahmeprüfung musste jeder von denen ein paar hunderttausend Routen im Kopf haben. Das klang irre anspruchsvoll und stressig. So weit wollte der kleine Ping dann doch nicht hinaus. Aber ab und an davon zu träumen, das war schon schön.
Der kleine Ping war zufrieden mit seinem Job. Er war es, der dieses Berufsbild erfunden und geformt hatte. Tausende hatten es ihm im Laufe der Jahre nachgemacht. Und heute ist er nicht zuletzt wichtiger Bestandteil einer jeden Monitoring-Umgebung. Auch wir haben kaum irgendwo eine Icinga-Umgebung am Laufen, in welchem er nicht zuverlässig seinen Dienst verrichten würden. Darum sei ihm an dieser Stelle mal ein Lob ausgesprochen: er macht seinen Job ausgezeichnet, ist zuverlässig und unauffällig.
Weiter so, lieber kleiner Ping!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

JSON-Streams über HTTP

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.