Manuel Rauber Thinktecture AG

Socket.IO bietet eine sehr einfache Abstraktion des WebSocket-Protokolls, bleibt aber dennoch sehr mächtig und unterstützt uns mit sinnvollen Keep-Alive-Mechanismen mit automatischem Reconnect.

Was wäre heute eine Anwendung, ohne die bekannten In-App Notifications? Neue Chatnachricht, neuer Artikel oder im Allgemeinen eine neue Benachrichtigung – oft symbolisiert durch ein kleines Icon mit einer Zahl zur Anzeige, wie viele neue Nachrichten uns erwarten. Kaum mehr wegzudenken und ständig verfügbar, auch ohne dass man eine Seite neu laden muss. Und das Ganze natürlich in Echtzeit. Wie das geht? WebSocket für Echtzeitkommunikation lautet das Zauberwort.

In der heutigen Zeit haben wir alle sicher schon mal ein Real-Rime-Collaboration-Tool genutzt, ein Werkzeug, um in Echtzeit gemeinsamen mit anderen Personen ein Dokument zu editieren. Als Paradebeispiel sei hier Google Docs genannt, aber mittlerweile auch Office-Web-Apps wie Word Online. Je mehr Leute dabei sind, umso mehr bunte Marker springen munter in einem Dokument herum, fügen neue Texte ein oder ändern bestehende. Dass alles passiert in Echtzeit.

Prinzipiell gibt es verschiedene Möglichkeiten, das gemeinsame Editieren von Dokumenten zu ermöglichen. Die erste Möglichkeit ist ein typisches Intervallpolling, also das Senden einer Anfrage mit der Bitte um Aktualisierung zum Server in einem bestimmten Intervall. Das heißt, dass wir beispielsweise alle 10 Sekunden eine HTTP-Anfrage zum Server schicken und als Antwort die Änderungen oder das komplette Dokument bekommen. Wirklich Echtzeit ist dies aber nicht, da wir bis zu 10 Sekunden (plus die Zeit zum Verbindungsaufbau und Übertragen der Daten) warten müssen, um neue Änderungen zu erhalten. Das Chaos, das hier in einem gemeinsamen Dokument entstehen würde, kann man sich sicherlich denken. Spaß sieht anders aus.

Die zweite Möglichkeit ist die Nutzung von HTTP Long Polling. Hier schickt der Client eine Anfrage zum Server. Der Server hält die Verbindung so lange offen, bis tatsächlich eine Nachricht eintrifft, und beantwortet die Anfrage. Ist dies geschehen, baut der Client sofort wieder eine neue Verbindung zum Server auf, bis die nächste Nachricht zur Verfügung steht. Die Nachrichten stehen so schneller als in der ersten Variante zur Verfügung, das Ganze ist aber ineffizient, da mit jeder Anfrage und Antwort HTTP-Header übertragen werden. Auch hier kann man sich vorstellen, dass das für das Editieren eines Dokuments nicht wirklich sinnvoll geeignet ist, wenn viele Änderungen vorgenommen werden. Mit großer Wahrscheinlichkeit sind die eigentlichen Änderungen kleiner als der Overhead durch die HTTP-Header.

Die dritte Möglichkeit ist die Nutzung des WebSocket-Protokolls. Dabei handelt es sich um ein Netzwerkprotokoll, das auf TCP aufsetzt, um eine bidirektionale Verbindung zwischen Client und Server aufzubauen. Client und Server können sich so jederzeit über eine Verbindung Daten schicken. Hierbei handelt es sich allerdings nicht um HTTP-Anfragen, d. h. bei der Übermittlung der Daten müssen keine zusätzlichen Header mitgesendet werden. Die Datenpakete sind daher deutlich kleiner und beinhalten genau das, was gesendet wird, also genau unsere Änderungen im gemeinsamen Dokument.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 11.16 - "Einstieg in .NET Core"

Alle Infos zum Heft
286433Echtzeit-Notifications mit Node.js und Socket.IO
X
- Gib Deinen Standort ein -
- or -