© Maisei Raman/Shutterstock.com, olenadesign/Shutterstock.com
Aktive Kommunikation vom Server zum Client

Don’t call us, we’ll call you!


Native Applikationen sind derzeit ein großes Thema. Mit WebSocket haben Entwickler nun ein Werkzeug an der Hand, um bidirektionale Kommunikation über ein TCP-basiertes Netzwerkprotokoll zu nutzen.

Moderne Single Page Applications fühlen sich, wenn sie richtig entwickelt wurden, wie eine native Applikation der jeweiligen Umgebung an. Mit Hilfe von Service Workers und weiteren Browserschnittstellen können sie auf einem System installiert und sogar ohne bestehende Netzwerkverbindung weiterverwendet werden. Das herausragende Merkmal einer solchen Applikation ist, dass sie über längere Zeit ohne Reload auskommt. Für den Benutzer wirkt das, als würde es sich um eine native Applikation handeln. Das Frontend lädt alle Daten, die es anzeigen soll, aktiv vom Server. Bewegen sich mehrere Benutzer parallel auf dem Backend und arbeiten damit, indem sie die Daten sowohl lesen als auch neue Informationen produzieren, müssen die anderen Benutzer hiervon erfahren und entsprechende Aktualisierungen erhalten. Bei HTTP, dem Kommunikationsprotokoll, das im Web mit Abstand am häufigsten verwendet wird, wird die Kommunikation immer vom Client angestoßen. Der Server verarbeitet die eingehende Anfrage und sendet eine Antwort zurück. Dabei hat der Server keine Möglichkeit, den Client seinerseits aktiv mit Informationen zu versorgen. Diese Art der Aktualisierung lässt sich jedoch mit einer Reihe verschiedener Schnittstellen und Protokolle lösen.

Die ersten Ansätze der bidirektionalen Kommunikation

Die Anforderung, dass Client und Server gleichberechtigte Partner in der Kommunikation sein sollen, gibt es schon länger. Eines der ältesten Lösungsszenarien, die auf den damals verfügbaren Webstandards aufbauen, ist das Long Polling. Hierbei handelt es sich jedoch nicht um eine saubere Lösung, sondern vielmehr um einen Hack. Beim Long Polling nutzen Sie als Entwickler die Tatsache aus, dass eine HTTP-Anfrage vom Server eine gewisse Zeitverzögerung haben kann, bevor sie vom Client mit einem Timeout-Fehler geschlossen wird. Während die Verbindung offen ist, kann der Server eine Nachricht an den Client zurücksenden. Falls der Server bis zum Timeout keine Nachricht gesendet hat, baut der Browser erneut eine Verbindung auf und wartet wieder bis zum Timeout. Der Nachteil dieser Implementierung ist, dass der ständige Verbindungsaufbau relativ ressourcenintensiv ist und der Server nicht wirklich aktiv eine Nachricht an den Client senden kann. Aus diesen Gründen wird Long Polling mittlerweile ni...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang