SignalR: Echtzeit-Client/Server-Kommunikation
SignlR macht die bidirektionale und dauerhafte Verbindung zwischen Server und Client möglich. Dadurch können ASP.NET-Entwickler in Echtzeit arbeiten. Kursleiter Alejandro Amrein zeigt anhand eines einfachen Beispiels auf, wie diese Technologie genutzt werden kann.
Vor allem Collaboration-fähige Web-Applikationen benötigen heute die Möglichkeit, Nachrichten direkt vom Server an die Clients zu pushen. Das ist mit HTTP nicht von Natur aus möglich. HTTP ist ein sogenanntes *state-less*-Protokoll. Der Client (meist ein Browser) sendet eine Anfrage, der Server antwortet, und danach wird die Verbindung geschlossen.
**SignalR** hat das Ziel, bidirektionale, dauerhafte Verbindungen zwischen Client und Server einfach und zuverlässig zu ermöglichen.
Wie kommunizierte man vor SignalR in Echtzeit?
Vor SignalR gab es verschiedene Wege, wie Client und Server in einer Web-Applikation kommunizieren konnten:
- HTML WebSockets
- Nicht alle Browser unterstützen sie, und wenn doch, dann oft nicht einheitlich.
- Nicht alle Webserver können damit umgehen.
- Es handelt sich um *raw Sockets*, das heisst, du musst selbst für die Protokolllogik sorgen.
- Auch Proxy-Server können Schwierigkeiten damit haben.
- Periodisches Polling
- Der Server wird in kurzen Abständen gefragt, ob neue Daten vorhanden sind.
- Das verbraucht unnötig Bandbreite.
- Es ist keine echte Echtzeit-Kommunikation.
Beispiel für periodisches Polling:
setInterval(function() {
$.ajax({
url: "server",
success: function(data) {
// data verwenden
},
dataType: "json"
});
}, 30000);
- Long Polling
- Diese Methode blockiert Server-Threads und Verbindungsressourcen.
Beispiel für Long Polling:
(function poll() {
$.ajax({
url: "server",
success: function(data){
// data verwenden
},
dataType: "json",
complete: poll,
timeout: 30000
});
})();
SignalR-Lösung
Ähnlich wie WCF verschiedene Kommunikationstechnologien abstrahiert, vereinfacht **SignalR** den Zugriff auf Echtzeit-Kommunikation.
Im Hintergrund nutzt SignalR die genannten Technologien, bietet dir als Entwickler/in aber eine einheitliche und einfache Schnittstelle. Du definierst JavaScript-Funktionen im Client und .NET-Methoden im Server, die über eine dauerhafte Verbindung miteinander kommunizieren können.
SignalR bietet viele Möglichkeiten. Hier ein einfaches Beispiel, damit du schnell einsteigen kannst und siehst, wie einfach sich Echtzeit-Kommunikation umsetzen lässt.
Schritt 1: Projekt erstellen und konfigurieren
Starte Visual Studio 2013 und erstelle eine neue leere Web-Applikation (*HelloSignalR*). In dieser Version ist SignalR bereits integriert.
Wenn du mit älteren Versionen arbeitest, musst du SignalR als NuGet-Package installieren (mehr dazu unter http://www.asp.net/signalr(http://www.asp.net/signalr)).
Füge danach SignalR in die OWIN-Pipeline ein (siehe Blog zu OWIN).
Schritt 2: Den Server vorbereiten
Serverseitig erstellst du einen sogenannten *Hub*. Er bildet die Verbindung und stellt dem Client Methoden zur Verfügung (im Beispiel nur die Methode *hello*).
Schritt 3: Den Client vorbereiten
Der Client-Code besteht aus zwei Teilen:
- HTML-Seite
- JavaScript-Funktionalität
Die HTML-Seite enthält ein Eingabefeld, einen Button und ein *div*-Element.
Das JavaScript registriert sich beim Server-Hub (*helloHub*), registriert die Funktion *broadcastMessage* und startet die Verbindung.
Sobald sie aktiv ist, reagiert der Button auf Klicks, ruft die Server-Funktion *hello* auf und verteilt die Nachricht an alle verbundenen Clients.
Schritt 4: Testen
Zum Testen öffnest du drei Browser-Sitzungen und gibst in der ersten «Alejandro» ein. Sofort erscheint der Name auch in den anderen Sitzungen.
Dasselbe funktioniert mit weiteren Eingaben wie «Peter» oder «Hans».
Fazit
SignalR vereinfacht Echtzeit-Kommunikation, indem es verschiedene Technologien wie *Polling*, *Long Polling* oder *WebSockets* abstrahiert.
So kannst du Client- und Server-Funktionen definieren, die sich gegenseitig aufrufen – ganz ohne komplexe Infrastruktur oder manuelles Verbindungsmanagement.