Was ist ASP.NET Core SignalR?

  • 4 Minuten

Alle Anwendungen, die mit dem Internet verbunden sind, bestehen aus Servern und Clients. Clients sind auf Server angewiesen, um Daten zu erhalten. Der wichtigste Mechanismus für den Empfang von Daten ist das Senden von HTTP-Anforderungen (Hypertext Transfer-Protokoll). Für einige Clientanwendungen werden sich häufig ändernde Daten benötigt.

ASP.NET Core SignalR umfasst eine API zum Erstellen von Remoteprozeduraufrufen (RPC) zwischen Server und Client. Über die RPCs werden aus dem serverseitigen .NET Core-Code Funktionen auf Clients aufgerufen. Es werden mehrere Plattformen unterstützt, jede mit ihrem eigenen Client-SDK. Daher kann die Programmiersprache, die durch RPC-Aufrufe aufgerufen wird, variieren.

Es ist hilfreich, sich mit der allgemeinen Terminologie im Zusammenhang mit SignalR vertraut zu machen. In dieser Lerneinheit erfahren Sie, welche SignalR-Komponenten in einer Serveranwendung und welche in Clientanwendungen benötigt werden. Darüber hinaus erhalten Sie Informationen zu den verschiedenen Mechanismen für die Duplexkommunikation. SignalR umfasst mehrere Echtzeitprotokolle und macht die komplexen Vorgänge einzelner Implementierungen überflüssig. Weitere Informationen finden Sie in der Dokumentation zu ASP.NET Core SignalR.

Die wichtigsten Begriffe im Zusammenhang mit SignalR werden in den folgenden Abschnitten erläutert.

Transportprotokolle

SignalR unterstützt die folgenden Verfahren (Datentransporte) für die Verarbeitung der Echtzeitkommunikation:

  1. WebSockets
  2. Vom Server gesendete Ereignisse
  3. Lange Abrufe

Die Reihenfolge, in der die Datentransporte hier angegeben sind, entspricht der Reihenfolge für ein ordnungsgemäßes Fallback. Mit anderen Worten, WebSockets wird gegenüber Server-Sent Events und Server-Sent Events gegenüber Long Polling bevorzugt, obwohl jeder dieser Transporte verwendet werden kann. SignalR wählt automatisch die beste Transportmethode, die im Rahmen der Möglichkeiten des Servers und des Clients liegt. Weitere Informationen finden Sie in der offiziellen Spezifikation zu den SignalR-Protokollen für den Datentransport.

Server

Der Server ist dafür zuständig, einen SignalR-Endpunkt verfügbar zu machen. Der Endpunkt wird einer Unterklasse vom Typ Hub oder Hub<T> zugeordnet. Der Server kann lokal, bei einem Cloudanbieter (z. B. Azure) oder unter Azure SignalR Service vorhanden sein. Vom Server werden sowohl die Hubmethoden, die von Clients aufgerufen werden können, als auch die Ereignisse verfügbar gemacht, die Clients abonnieren können. Diese Vorgänge werden als Remoteprozeduren betrachtet.

Hub

In SignalR wird ein Hub für die Kommunikation zwischen Clients und Servern verwendet. Ein Hub ist eine allgemeine Pipeline, über die ein Client und ein Server untereinander Methoden aufrufen können. Die Verteilung über Computergrenzen hinweg wird von SignalR automatisch durchgeführt. Sie können sich einen Hub als Proxy zwischen allen verbundenen Clients und dem Server vorstellen.

Protokolle

Das SignalR-Protokoll ist ein Protokoll für bidirektionale Remoteprozeduraufrufe über beliebige nachrichtenbasierte Datentransporte. Beide Verbindungsparteien können jeweils Prozeduren der anderen Partei aufrufen, und für die Prozeduren können null oder mehr Ergebnisse oder ein Fehler zurückgegeben werden. SignalR verfügt über zwei integrierte Hubprotokolle:

  • Ein Textprotokoll, das auf JSON basiert. Dies ist die Standardeinstellung.
  • Ein binäres Protokoll, das auf MessagePack basiert. Über MessagePack werden im Allgemeinen kleinere Nachrichten als bei JSON erstellt.

Für die Verwendung des MessagePack-Protokolls muss sowohl für den Server als auch für den Client die Konfiguration aktiviert und jeweils die Unterstützung sichergestellt werden. Es gibt noch ein drittes Hubprotokoll mit dem Namen BlazorPack, das aber ausschließlich für Blazor Server-Anwendungen verwendet wird. Eine Nutzung ohne das Blazor Server-Hostingmodell ist nicht möglich. Weitere Informationen finden Sie in der offiziellen Spezifikation zum SignalR-Hubprotokoll.

Benutzer

Ein Benutzer im System handelt als Einzelperson, kann aber auch Teil einer Gruppe sein. Nachrichten können an Gruppen gesendet werden. In diesem Fall werden alle Gruppenmitglieder benachrichtigt. Ein einzelner Benutzer kann über mehrere Clientanwendungen eine Verbindung herstellen. Beispielsweise kann derselbe Benutzer ein mobiles Gerät und einen Webbrowser verwenden und gleichzeitig Echtzeitupdates für beide Komponenten abrufen.

Gruppen

Eine Gruppe verfügt über mindestens eine Verbindung. Der Server kann Gruppen erstellen, einer Gruppe Verbindungen hinzufügen und Verbindungen aus einer Gruppe entfernen. Für eine Gruppe wird ein Name vergeben, der als eindeutiger Bezeichner fungiert. Gruppen dienen als Bereichsmechanismus, um Zielnachrichten zu unterstützen. Das heißt, Echtzeitfunktionen können nur an Benutzer innerhalb einer bestimmten Gruppe gesendet werden.

Verbindungen

Für eine Verbindung mit einem Hub wird ein eindeutiger Bezeichner verwendet, der nur dem Server und dem Client bekannt ist. Es ist eine Verbindung pro Hubtyp vorhanden. Jeder Client verfügt über eine eindeutige Verbindung mit dem Server. Das heißt, ein einzelner Benutzer kann auf mehreren Clients dargestellt werden, aber jede Clientverbindung weist einen eigenen Bezeichner auf.

Clients

Der Client ist dafür zuständig, eine Verbindung mit dem Endpunkt des Servers über ein HubConnection-Objekt herzustellen. Die Hubverbindung wird auf jeder Zielplattform dargestellt:

Weitere Informationen finden Sie im Artikel zu den für ASP.NET Core SignalR unterstützten Plattformen.

Wenn eine Instanz einer Hubverbindung erfolgreich gestartet wurde, können Nachrichten ungehindert in beide Richtungen fließen. Benutzer können sowohl Benachrichtigungen an den Server senden als auch vom Server empfangen. Ein Client ist eine beliebige verbundene Anwendung, z. B. ein Webbrowser, eine mobile App oder eine Desktop-App.