Während das Web in den meisten Fällen mit dem klassischen Request-Response Modell funktioniert, benötigen heutzutage immer mehr Applikationen (spätestens wenn es um Kollaboration geht) die Möglichkeit, vom Server unaufgefordert Informationen zu bekommen. Mittlerweile gibt es dafür einen Wulst voller Bibliotheken und Schnittstellen.
Mein heutiger Blogpost soll gar nicht genau auf eine (oder alle) der Technologien vorstellen, sondern nur eine kurze Übersicht und Anregung geben, wenn man mal auf der Suche ist:
- HTTP Polling oder lange blockierende HTTP Requests (Comet): Diese gehen immer und brauchen auch keine spezielle Bibliothek. Man stellt entweder sehr oft Anfragen und der Server sagt dann schon wenn etwas passiert, ansonsten nichts (Polling eben) oder der Server blockiert bis etwas passiert und sendet in diesem Falle die Antwort für den Request. Blockiert allerdings in älteren Browsern immer eine der häufig benötigten Verbindungen und ist (egal in welcher Variant) nur noch als Fallback für ältere Browser geeignet (Comet). Davon gibt es viele Varianten, im IFrame oder um Streaming zu ermöglichen, letzten Endes ists aber immer eine Krücke. Da das keine ‘offizielle Technik’, sondern eher ein Hack ist gibts als weiterführende Literatur nur die Wikipedia Seite.
- Websockets: Ein eigenes Protokol das eigens für persistente bidirectionale Kommunikation mit dem Server gedacht ist. Läuft auch auf vielen Mobilgeräten und kann für ältere Browser (wenn man den Technologiebruch verkraften kann) über ein Flash Fallback wie websocket-as nachgerüstet werden. Bei Websockets läuft die Kommunikation über einen anderen Port als 80, daher kann eine restriktive Firewall hier den Spaß verderben. Die exzellente Mozilla Developer Network Seite weist den Weg, ein Blick in den Standard kann aber auch nicht schaden. Größter Nachteil: Der mangelnde Browsersupport und die z.T. auf Drafts aufbauende Implementierung in älteren Browsern.
- Server-Sent Events: Eine W3C Recommendation, die es einem Server erlaubt, Events über einen offenen Kanal an Clients (!= Internet Explorer) zu senden. Das Protokoll ist extrem einfach und kommt mit HTTP Bordmitteln aus, im Gegensatz zu Websockets kann der Server aber über den gleichen Kanal keine Events empfangen (dafür muss man dann wieder neue Requests senden). Einen Vorteil gegenüber Websockets sehe ich darin, dass die Kommunikation über den HTTP Port geschieht, ich würde im Zweifel jedoch eher auf Websockets setzen. Die sind mittlerweile ein Standard und haben heute schon besseren Browsersupport. Die W3C Recommendation fängt mit guten Beispielen an, und Mozilla hat ein Beispiel in PHP.
Es gibt hiervon noch einige Varianten, bei der Auswahl einer Technologie muss man sich aber für Performance vs. Kompatibilität entscheiden. Meine klare Empfehlung ist daher, eine Bibliothek wie SockJS zu verwenden. Diese wählt für die aktuelle Platform das effizienteste Protokoll heraus und abstrahiert dessen Verwendung für den Nutzer. Durch die große Auswahl an Adaptern für verschiedene serverseitige Technologien ist es damit kinderleicht, asynchrone Nachrichten zwischen Browser und Server auszutauschen.
Ich hoffe zwar in Zukunft direkt mit Websockets arbeiten zu können, allerdings wird es wohl noch eine Weile dauern bis der Internet Explorer 10 in jeder Firma angekommen ist.
