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.

Crossing streams

chromecastStreaming Clients sind im Moment ein gehyptes Thema. Jeder Namhafte Elektronik- oder Contentriese drück mit einer kleinen Box auf den Markt, die das Hör- und Sehvergnügen von uns Konsumenten ins unermessliche steigern soll. Ich reihe mich in die Riege der Poster ein, die fragen: Was gibts, was kommt und was bringts wirklich.
Kurz zu mir. Ich nutze gerne Angebote wie z.B. Maxdome oder Watchever. Leihe mir hier und da einen Film aus und hab keine Lust mir mit Festplatten den Keller zu füllen. Bei mir überwiegt die Musik, weshalb der eine oder andere Musik-Streaming-Dienst dauerhaft am Abend dudelt. appletv_smallsize
Starten wir mit dem Chromecast von Google. Jeder hat bestimmt schon irgendwo gelesen, dass hier ein clevere Konstruktion am werkeln ist. Goggle verbaut seine Streaming-Lösung in einem Dongle Design mit HDMI Anschluss welcher direkt in das Endgerät gesteckt wird. Versorgt man den Dongle mit externer Spannung kann man durch CEC seinen Fernseher ein- und ausschalten. Damit das Streaming funktioniert muss es die Applikation unterstützen und hier liegt im Moment der Knackpunkt: Es gibt zu wenig Apps die das können. Spotify verweigert im Moment noch die Umsetzung mit Ihrer Android Applikation. Einen Ausweg könnte die Browser Extension für Chrome schaffen. Diese kann Browser Tabs einfach auf den Fernseher spiegeln. Allerdings ist die Latenz so hoch, dass zappen durch Musik nicht wirklich spaß macht.
Der alte Hase mit seinem Apple TV liegt mittlerweile in der dritten Generation vor. Dank größerer CPU funktioniert er schnell und gut. Vor allem die Möglichkeit den Screen komplett zu streamen (Nur Mac devices oder Android AllCast) macht das Gerät besonders flexibel. Will man aber mehr als Stereo über seinen Mac streamen ist dann aber auch schon Schluss. Die vorinstallierten Apps leiten aber Dolby Digital einwandfrei durch. Ist die App seiner Wahl vorhanden, erhält man aber eine robuste und eigenständige Streaminglösung. Gerüchten zur Folge kommen bald Apps von Drittherstellern über den AppStore auf den Markt. Dann wird es nochmal eine Schippe interessanter.
Ziemlich neu kommt der Roku Stick (zumindest als Thema in Deutschland) daher. Aktuell gibt es ihn hier zulande noch nicht. Er wartet allerdings mit einem großen Angebot an roku_streaming_stick_3500RApps (Channels) auf, welche stark auf den englischen und amerikanischen Markt ausgerichtet sind. Viele sind in Deutschland nicht nutzbar, z.B netflix. Er kommt wie der Apple TV mit eigener Fernbedienung daher und verbraucht daher nicht ein eigenes Personal Device als Fernbedienung.
Für mich persönlich hat Apple das reifere Konzept und die beste Audio Qualität. Aber auch das teuerste von allen. Im Moment muss man genau überlegen für was man die Streaming-Lösung benötigt – Und das ist auch genau das Manko: Proprietät und Intransparenz. Kein Hersteller liefert vollständige Freiheit. Dienste sind beschränkt oder lokales Streaming erst gar nicht möglich. Auch bei der Qualität von Video- und Tonformaten muss man darauf achten das die eigenen Ansprüche erfüllt werden – Informationen sind spärlich zu finden und die Hersteller hüllen sich allzu gerne in Schweigen. Streaming-Dienst und Streaming-Hardware sind jung. Einige Hersteller drängen in Zukunft noch auf den Markt und da wird es wohl noch etwas rumpeln.
Wer unentschlossen ist, spart sich den Konsumstress und geht nach draußen, eine Runde wandern! Holadio.
(Bildnachweis: Herstellerseiten)

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

Open Source Monitoring Conference on Nagios 2010 – Vorträge verpasst?

Die Vorträge der Open Source Monitoring Conference on Nagios wurden auch 2010 wieder von unserem Partner dem Linux Magazin live mitgeschnitten und anschließend archiviert. Wer die Konferenz verpasst hat oder sich einen der spannenden Vorträge wie Rainer Jung | Java Monitoring und Troubleshooting, das Icinga Team | Monitoring mit Icinga, Michael Medin | NSCLient++ oder Wolfgang Barth | Netzwerkmonitoring mit Argus erneut anhören möchte kann dies nun ab sofort online auf den Seiten des Linux Magazins: http://streaming.linux-magazin.de/
Der alles im Blick-screen zeigt in hoher Auflösung den Sprecher und die zugehörigen Vortragsfolien. Der Vortrag kann je nach Wunsch pausiert oder angehalten werden, von vorne gestartet oder Beispiele erneut angesehen und erläutert werden.
Auf der Homepage sind einige Demovideos verfügbar und wer Vorträge des Archivs buchen möchte erhält mit 199 € einen absolut fairen Preis. Abonnenten des Linux Magazins erhalten sogar noch 20 % Rabatt.
Für alle Konferenzteilnehmer gilt nach wie vor: das Streaming-Archiv ist im Konferenzpaket inkludiert und Sie können sich mit Ihren Zugangsdaten, welche Sie per Mail erhalten haben, jederzeit einloggen und sich Ihre persönlichen Highlights noch einmal in Ruhe ansehen.
Abbildung unten: Übersichtliche Weboberfläche mit paralleler Darstellung der Vortragsfolien

Kostenloser Vortrag von Kristian Köhntopp im Stream der OSMC 2009

Streaming_OSMC
Wie in jedem Jahr werden auch 2009 die Vorträge des Haupttracks der “Open Source Monitoring Conference” von unserem Partner, dem Linux Magazin, live ins Internet übertragen bzw. im Nachgang beide Tracks für alle Konferenzteilnehmer im Archiv zur Verfügung gestellt. In diesem Jahr gibt es allerdings zum ersten Mal eine Neuerung.
Als kleines Highlight haben wir uns  in Zusammenarbeit mit dem Linux Magazin entschlossen, den Vortrag der Konferenz, welcher vom bekannten MySQL Profi Kristian Köhntopp zum Thema “Monitoring MySQL” gehalten wird, komplett kostenfrei für alle Interessierten live ins Internet zu übertragen.
Jeder der sich einen Eindruck von der Konferenz verschaffen will hat damit die Möglichkeit, kostenfrei einfach mal hineinzuschnuppern. Am Besten also direkt den 28.10.2009, 09.00 Uhr rot im Kalender markieren und die Seiten des Linux Magazins Livestreamings bookmarken.
Wir freuen uns über viele Zuschauer!