Einführung in SignalR

von Patrick Fletcher

Warnung

Diese Dokumentation ist nicht für die neueste Version von SignalR vorgesehen. Sehen Sie sich ASP.NET Core SignalR an.

In diesem Artikel wird beschrieben, was SignalR ist, und einige der Lösungen, für die es entwickelt wurde.

Fragen und Kommentare

Bitte hinterlassen Sie Feedback darüber, wie Ihnen dieses Tutorial gefallen hat und was wir in den Kommentaren unten auf der Seite verbessern könnten. Wenn Sie Fragen haben, die sich nicht direkt auf das Tutorial beziehen, können Sie diese im ASP.NET SignalR-Forum oder im StackOverflow.com posten.

Was ist SignalR?

ASP.NET SignalR ist eine Bibliothek für ASP.NET Entwickler, die das Hinzufügen von Echtzeit-Webfunktionen zu Anwendungen vereinfacht. Die Webfunktionalität in Echtzeit ist die Möglichkeit, Dass Servercode Inhalte sofort an verbundene Clients pushen kann, sobald sie verfügbar sind, anstatt dass der Server darauf wartet, dass ein Client neue Daten angibt.

SignalR kann verwendet werden, um Ihrer ASP.NET-Anwendung jede Art von "Echtzeit"-Webfunktionalität hinzuzufügen. Während Chat oft als Beispiel verwendet wird, können Sie noch viel mehr tun. Jedes Mal, wenn ein Benutzer eine Webseite aktualisiert, um neue Daten anzuzeigen, oder wenn die Seite lange Abrufe implementiert, um neue Daten abzurufen, ist sie ein Kandidat für die Verwendung von SignalR. Beispiele hierfür sind Dashboards und Überwachungsanwendungen, gemeinsame Anwendungen (z. B. die gleichzeitige Bearbeitung von Dokumenten), Aktualisierungen des Auftragsstatus und Echtzeitformulare.

SignalR ermöglicht auch völlig neue Arten von Webanwendungen, die hochfrequente Updates vom Server erfordern, z. B. Echtzeitspiele.

SignalR bietet eine einfache API zum Erstellen von Server-zu-Client-Remoteprozeduraufrufen (RPC), die JavaScript-Funktionen in Clientbrowsern (und anderen Clientplattformen) aus serverseitigem .NET-Code aufrufen. SignalR umfasst auch die API für die Verbindungsverwaltung (für instance, Verbindungs- und Trennungsereignisse) und Gruppierung von Verbindungen.

SignalR übernimmt die Verbindungsverwaltung automatisch und ermöglicht Ihnen, Nachrichten an alle verbundenen Clients gleichzeitig zu übertragen, wie in einem Chatroom. Nachrichten können auch nur an bestimmte Clients gesendet werden. Die Verbindung zwischen Client und Server besteht permanent und unterscheidet sich damit von einer klassischen HTTP-Verbindung, die für jede Kommunikation neu hergestellt wird.

SignalR unterstützt die Funktion "Serverpush", bei der Servercode den Clientcode im Browser mithilfe von Remoteprozeduraufrufen (REMOTE Procedure Calls, RPC) aufrufen kann, anstatt das derzeit im Web übliche Anforderungs-Antwort-Modell.

SignalR-Anwendungen können mithilfe integrierter Anbieter von horizontaler Skalierung von Drittanbietern auf Tausende von Clients hochskaliert werden.

Zu den integrierten Anbietern gehören:

• Service Bus
• SQL Server
• Redis

Zu den Drittanbietern gehören:

• NCache.

SignalR ist Open Source und kann über GitHub zugänglich sein.

SignalR und WebSocket

SignalR verwendet den neuen WebSocket-Transport, sofern verfügbar, und greift bei Bedarf auf ältere Transporte zurück. Sie könnten Ihre App zwar mit WebSocket direkt schreiben, aber die Verwendung von SignalR bedeutet, dass viele der zusätzlichen Funktionen, die Sie implementieren müssen, bereits für Sie erledigt sind. Vor allem bedeutet dies, dass Sie Ihre App programmieren können, um WebSocket zu nutzen, ohne sich gedanken über die Erstellung eines separaten Codepfads für ältere Clients machen zu müssen. SignalR schützt Sie auch davor, sich um Updates für WebSocket kümmern zu müssen, da SignalR aktualisiert wird, um Änderungen am zugrunde liegenden Transport zu unterstützen, sodass Ihrer Anwendung eine konsistente Schnittstelle für die Versionen von WebSocket zur Verfügung steht.

Transporte und Fallbacks

SignalR ist eine Abstraktion über einige der Transporte, die für die Echtzeitarbeit zwischen Client und Server erforderlich sind. SignalR versucht zunächst, nach Möglichkeit eine WebSocket-Verbindung herzustellen. WebSocket ist der optimale Transport für SignalR, da es Folgendes aufweist:

• Die effizienteste Verwendung des Serverspeichers.
• Die niedrigste Latenz.
• Die meisten zugrunde liegenden Features, z. B. die Vollduplexkommunikation zwischen Client und Server.
• Die strengsten Anforderungen, WebSocket erfordert den Server:
  • Führen Sie unter Windows Server 2012 oder Windows 8 aus.
  • .NET Framework 4.5.

Wenn diese Anforderungen nicht erfüllt sind, versucht SignalR, andere Transporte zu verwenden, um seine Verbindungen herzustellen.

HTML 5-Transporte

Diese Transporte hängen von der Unterstützung für HTML 5 ab. Wenn der Clientbrowser den HTML 5-Standard nicht unterstützt, werden ältere Transporte verwendet.

• WebSocket (wenn sowohl der Server als auch der Browser angeben, dass websocket unterstützt werden kann). WebSocket ist der einzige Transport, der eine echte persistente bidirektionale Verbindung zwischen Client und Server herstellt. WebSocket hat jedoch auch die strengsten Anforderungen. es wird nur in den neuesten Versionen von Microsoft Internet Explorer, Google Chrome und Mozilla Firefox vollständig unterstützt und verfügt nur über eine teilweise Implementierung in anderen Browsern wie Opera und Safari.
• Vom Server gesendete Ereignisse, auch bekannt als EventSource (wenn der Browser gesendete Serverereignisse unterstützt, was im Grunde alle Browser außer Internet Explorer.)

Kometentransporte

Die folgenden Transporte basieren auf dem Comet-Webanwendungsmodell , bei dem ein Browser oder ein anderer Client eine lang gehaltene HTTP-Anforderung verwaltet, mit der der Server Daten an den Client pushen kann, ohne dass der Client dies ausdrücklich anfordert.

• Forever Frame (nur für Internet Explorer). Forever Frame erstellt einen ausgeblendeten IFrame, der eine Anforderung an einen Endpunkt auf dem Server sendet, der nicht abgeschlossen wird. Der Server sendet dann kontinuierlich ein Skript an den Client, das sofort ausgeführt wird, und stellt eine unidirektionale Echtzeitverbindung von Server zu Client bereit. Die Verbindung von Client zu Server verwendet eine separate Verbindung vom Server mit der Clientverbindung, und wie bei einer HTTP-Standardanforderung wird für jeden Zusendungsabschnitt eine neue Verbindung erstellt.
• Lange Ajax-Abrufe. Bei langen Abrufvorgängen wird keine dauerhafte Verbindung hergestellt, sondern stattdessen wird der Server mit einer Anforderung abgefragt, die geöffnet bleibt, bis der Server antwortet. An diesem Punkt wird die Verbindung geschlossen und sofort eine neue Verbindung angefordert. Dies kann zu einer gewissen Latenz führen, während die Verbindung zurückgesetzt wird.

Weitere Informationen dazu, welche Transporte unter welchen Konfigurationen unterstützt werden, finden Sie unter Unterstützte Plattformen.

Transportauswahlprozess

Die folgende Liste zeigt die Schritte, die SignalR verwendet, um zu entscheiden, welcher Transport verwendet werden soll.

1. Wenn der Browser internet Explorer 8 oder früher ist, wird Long Polling verwendet.

2. Wenn JSONP konfiguriert ist (d. h. der jsonp Parameter wird auf true festgelegt, wenn die Verbindung gestartet wird), wird Long Polling verwendet.

3. Wenn eine domänenübergreifende Verbindung hergestellt wird (das heißt, wenn sich der SignalR-Endpunkt nicht in derselben Domäne wie die Hostingseite befindet), wird WebSocket verwendet, wenn die folgenden Kriterien erfüllt sind:

   • Der Client unterstützt CORS (Cross-Origin Resource Sharing). Ausführliche Informationen dazu, welche Clients CORS unterstützen, finden Sie unter CORS unter caniuse.com.

   • Der Client unterstützt WebSocket.

   • Der Server unterstützt WebSocket.

     Wenn eines dieser Kriterien nicht erfüllt ist, wird Long Polling verwendet. Weitere Informationen zu domänenübergreifenden Verbindungen finden Sie unter Herstellen einer domänenübergreifenden Verbindung.

4. Wenn JSONP nicht konfiguriert ist und die Verbindung nicht domänenübergreifend ist, wird WebSocket verwendet, wenn sowohl der Client als auch der Server dies unterstützen.

5. Wenn der Client oder Server WebSocket nicht unterstützt, werden gesendete Serverereignisse verwendet, sofern verfügbar.

6. Wenn vom Server gesendete Ereignisse nicht verfügbar sind, wird versucht, Forever Frame zu erstellen.

7. Wenn Forever Frame fehlschlägt, wird Long Polling verwendet.

Überwachen von Transporten

Sie können bestimmen, welchen Transport Ihre Anwendung verwendet, indem Sie die Protokollierung auf Ihrem Hub aktivieren und das Konsolenfenster in Ihrem Browser öffnen.

Um die Protokollierung für die Ereignisse Ihres Hubs in einem Browser zu aktivieren, fügen Sie der Clientanwendung den folgenden Befehl hinzu:

$.connection.hub.logging = true;

• Öffnen Sie in Internet Explorer die Entwicklertools, indem Sie F12 drücken, und klicken Sie auf die Registerkarte Konsole.

  

• Öffnen Sie in Chrome die Konsole, indem Sie STRG+UMSCHALT+J drücken.

  

Wenn die Konsole geöffnet und die Protokollierung aktiviert ist, können Sie sehen, welcher Transport von SignalR verwendet wird.

Angeben eines Transports

Das Aushandeln eines Transports nimmt eine bestimmte Zeit und Client-/Serverressourcen in Anspruch. Wenn die Clientfunktionen bekannt sind, kann beim Starten der Clientverbindung ein Transport angegeben werden. Der folgende Codeausschnitt veranschaulicht das Starten einer Verbindung mithilfe des Ajax Long Polling-Transports, wie es verwendet wird, wenn bekannt ist, dass der Client kein anderes Protokoll unterstützt:

connection.start({ transport: 'longPolling' });

Sie können eine Fallbackreihenfolge angeben, wenn ein Client bestimmte Transporte in der Reihenfolge ausprobieren soll. Der folgende Codeausschnitt veranschaulicht das Ausprobieren von WebSocket, und wenn dies fehlschlägt, wechseln Sie direkt zu Long Polling.

connection.start({ transport: ['webSockets','longPolling'] });

Die Zeichenfolgenkonstanten zum Angeben von Transporten sind wie folgt definiert:

• webSockets
• foreverFrame
• serverSentEvents
• longPolling

Verbindungen und Hubs

Die SignalR-API enthält zwei Modelle für die Kommunikation zwischen Clients und Servern: persistente Verbindungen und Hubs.

Eine Verbindung stellt einen einfachen Endpunkt zum Senden von Nachrichten mit einzelnen Empfängern, gruppierten Oder Broadcastnachrichten dar. Die API für persistente Verbindungen (dargestellt in .NET-Code durch die PersistentConnection-Klasse) gewährt dem Entwickler direkten Zugriff auf das Low-Level-Kommunikationsprotokoll, das SignalR verfügbar macht. Die Verwendung des Verbindungskommunikationsmodells ist Entwicklern vertraut, die verbindungsbasierte APIs wie Windows Communication Foundation verwendet haben.

Ein Hub ist eine allgemeinere Pipeline, die auf der Verbindungs-API basiert, die es Ihrem Client und Server ermöglicht, Methoden direkt aufeinander aufzurufen. SignalR verarbeitet die Verteilung über Computergrenzen hinweg wie von Zauberhand, sodass Clients Methoden auf dem Server genauso einfach aufrufen können wie lokale Methoden und umgekehrt. Die Verwendung des Hubs-Kommunikationsmodells ist Entwicklern vertraut, die Remoteaufruf-APIs wie .NET Remoting verwendet haben. Mithilfe eines Hubs können Sie auch stark typisierte Parameter an Methoden übergeben, wodurch die Modellbindung aktiviert wird.

Architekturdiagramm

Das folgende Diagramm zeigt die Beziehung zwischen Hubs, persistenten Verbindungen und den zugrunde liegenden Technologien, die für Transporte verwendet werden.

Funktionsweise von Hubs

Wenn serverseitiger Code eine Methode auf dem Client aufruft, wird ein Paket über den aktiven Transport gesendet, das den Namen und die Parameter der methode enthält, die aufgerufen werden soll (wenn ein Objekt als Methodenparameter gesendet wird, wird es mithilfe von JSON serialisiert). Der Client gleicht dann den Methodennamen mit methoden ab, die im clientseitigen Code definiert sind. Wenn eine Übereinstimmung vorhanden ist, wird die Clientmethode mithilfe der deserialisierten Parameterdaten ausgeführt.

Der Methodenaufruf kann mit Tools wie Fiddler überwacht werden. Die folgende Abbildung zeigt einen Methodenaufruf, der von einem SignalR-Server an einen Webbrowserclient im Bereich Protokolle von Fiddler gesendet wird. Der Methodenaufruf wird von einem Hub namens MoveShapeHubgesendet, und die aufgerufene Methode wird aufgerufen updateShape.

In diesem Beispiel wird der Hubname mit dem H Parameter identifiziert. Der Methodenname wird mit dem M Parameter identifiziert, und die an die Methode gesendeten Daten werden mit dem A Parameter identifiziert. Die Anwendung, die diese Nachricht generiert hat, wird im Tutorial zu Hochfrequenz in Echtzeit erstellt.

Auswählen eines Kommunikationsmodells

Die meisten Anwendungen sollten die Hubs-API verwenden. Die Verbindungs-API kann unter den folgenden Umständen verwendet werden:

• Das Format der tatsächlich gesendeten Nachricht muss angegeben werden.
• Der Entwickler arbeitet lieber mit einem Messaging- und Dispatching-Modell als mit einem Remoteaufrufmodell.
• Eine vorhandene Anwendung, die ein Messagingmodell verwendet, wird zur Verwendung von SignalR portiert.