1. Was ist SignalR:
ASP.NET SignalR ist eine Bibliothek von Klassen, die bereitgestellt wird, um den Prozess des Hinzufügens von Live-Webinhalten zu Anwendungen durch Entwicklungsentwickler zu vereinfachen. Echtzeit-Web-Funktionalität bezieht sich darauf, dass Servercode Inhalte jederzeit aktiv an die Clients senden kann, anstatt dass der Server auf eine Anfrage vom Client wartet (bevor er Inhalte zurückgibt).
Alle "live"-Arten von Web-Funktionalität können mit SignalR in Ihre ASP.NET-Anwendung aufgenommen werden. Das am häufigsten verwendete Beispiel sind Chatrooms, aber wir können noch viel mehr tun. Betrachten Sie folgende Situationen: Nutzer müssen die Webseite ständig aktualisieren, um die neuesten Daten zu sehen; Oder rufen Sie neue Daten auf der Seite ab (und zeigen Sie sie an), indem Sie Long Polling implementieren, dann können Sie dafür SignalR verwenden. Zum Beispiel: Dashboards und Überwachungsanwendungen; Kollaborative Anwendungen (z. B. mehrere Personen gleichzeitig Dokumente bearbeiten); Updates zum Jobfortschritt und Echtzeit-Präsentationsformulare usw.
SignalR eignet sich auch für neuere Arten von Webanwendungen, die hochfrequente Updates vom Server erfordern, wie zum Beispiel Echtzeit-Gaming. Hier ein gutes Beispiel: ShoorR.
SignalR bietet eine einfache API, mit der Nutzer Server-zu-Client Remote Procedure Calls (RPCs) erstellen können, die problemlos von Serverseite aus zugänglich sind. Netzcode. SignalR umfasst auch Verbindungen (z. B. Verbindungs- und Trennereignisse) sowie Verbindungsgruppierung.
SignalR kann Verbindungen automatisch verwalten. Und ermöglicht es, Broadcast-Nachrichten an alle verbundenen Clients zu senden, ähnlich wie in einem Chatroom. Natürlich können Sie neben dem Massenversenden auch Nachrichten an bestimmte Kunden senden. Die Verbindung zwischen Client und Server ist persistent, im Gegensatz zum traditionellen HTTP-Protokoll, das die Wiederherstellung der Verbindung für jede Kommunikation erfordert.
SignalR unterstützt die Funktion "Server Push", bei der Servercode Client-Code im Browser aufrufen kann, indem er Remote Procedure Calls (RPC) verwendet, anstatt der derzeit im Web üblichen Anfragen – dem entsprechenden Verarbeitungsmodell – zu verwenden.
SignalR-Anwendungen können auf Tausende von Clients mit Service Bus, SQL SERVER oder Redis erweitert werden.
SignalR ist Open Source und kann über GitHub abgerufen werden.
2. SignalR und WebSocket
ignalR verwendet die WebSocket-Transportmethode – wo möglich. Und automatisch auf die alte Transportmethode umsteigen (z. B. HTTP Long Connection). Du kannst deine Anwendung natürlich direkt mit WebSockets schreiben, aber mit SignalR hast du mehr zusätzliche Funktionen, ohne das Rad neu erfinden zu müssen. Am wichtigsten ist, dass Sie sich auf die Geschäftsimplementierung konzentrieren können, ohne daran zu denken, kompatiblen Code separat für den alten Client zu erstellen. SignalR ermöglicht es Ihnen außerdem, sich keine Sorgen um WebSocket-Updates machen zu müssen, da SignalR weiterhin aktualisiert wird, um die Änderung der zugrunde liegenden Transportmethoden zu unterstützen, um eine konsistente Zugriffsschnittstelle für Anwendungen in verschiedenen WebSockets-Versionen bereitzustellen.
Natürlich kann man eine Lösung erstellen, die ausschließlich WebSocket-Transport verwendet, und SignalR bietet alle Funktionen, die man benötigt, um eigenen Code zu schreiben, wie zum Beispiel auf andere Transportmethoden zurückzugreifen und die Anwendung für neuere WebSocket-Implementierungen anzupassen.
3. Transport und Rückkehr
SignalR ist eine Abstraktion der Transporttechnologie, die zur Implementierung von Echtzeitfunktionen zwischen Clients und Servern erforderlich ist. SignalR startet die Verbindung zunächst mit HTTP und prüft, ob der WebSocket verfügbar ist – falls ja, upgrade auf die Verbindung des WebSockets. WebSocket ist die idealste Übertragungsmethode für SignalR, da es den Serverspeicher am effizientesten nutzt, die geringste Latenz und umfassende zugrundeliegende Funktionen aufweist (wie Vollduplex-Kommunikation zwischen Client und Server), aber auch die strengsten Anforderungen stellt: Der Server muss gleichzeitig das Betriebssystem Windows Server 2012 oder Windows 8 verwenden. .NET Framework Version 4.5 und höher. Wenn diese Anforderungen nicht erfüllt werden, wird SignalR versuchen, eine alternative Übertragungsmethode zur Verbindung zu verwenden.
4. HTML5-Versand
Die verwendete Transportmethode hängt davon ab, ob der Client-Browser HTML5 unterstützt, ansonsten wird die alte Transportmethode verwendet.
WebSocket (falls sowohl der Server als auch der Browser WebSocket unterstützen). WebSocket ist der einzige Weg, eine echte und dauerhafte zweiseitige Verbindung sowohl auf der Client- als auch auf der Serverseite herzustellen. Natürlich hat WebSocket auch die strengsten Anforderungen: Es wird nur in den neuesten Versionen von IE, Chrome und FF unterstützt und ist nur teilweise in anderen Browsern wie Opera und Safari implementiert.
Der Server sendet Ereignisse, auch bekannt als EventSource (wenn der Browser das Serversenden von Ereignissen unterstützt, unterstützen im Grunde alle Browser außer IE diese Funktion).
5. Kometenübertragung
Die folgenden Transportarten basieren auf dem Comet-Webanwendungsmodell, bei dem der Browser oder Client eine lange HTTP-Verbindungsanfrage aufrechterhält und der Server Daten ohne explizite Anfrage an den Client senden kann.
Forever Frame (IE nur): Forever Frame erstellt ein verstecktes IFrame, das eine Anfrage an den Server sendet, die jedoch nicht abgeschlossen wird. Der Server sendet dann kontinuierlich Skripte an den Client, die sofort vom Client ausgeführt werden, also eine einseitige Echtzeitverbindung vom Server zum Client. Die Client-zu-Server-Verbindung verwendet eine andere Verbindung als diese Verbindung. Zum Beispiel erzeugt eine Standard-HTML-Anfrage für jede gesendete Daten eine neue Verbindung.
Ajax-Long-Polling erzeugt keine persistente Verbindung, sondern pollt vielmehr, indem ständig Anfragen an den Server gesendet werden. Warte, bis der Server antwortet, schließe diese Verbindung bei jeder Verbindung und stelle dann sofort eine neue Anfrage. Natürlich führt das zu einer Verzögerung, wenn die Verbindung zurückgesetzt und wieder verbunden wird.
Informationen zu den von verschiedenen Konfigurationen unterstützten Transportmethoden finden Sie unter Unterstützte Plattformen. (D.h. benötigt 8 oder höher, andere Browser sind die aktuelle Version -1)
Auswahlprozess der Übertragungsmethode
Die folgende Liste zeigt, wie SignalR entscheidet, welchen Typ für die Übertragung verwendet wird.
IE8 und früher, verwenden Sie Long Polling.
Wenn JSONP konfiguriert ist (d. h. der jsonp-Parameter wird beim Verbinden auf true gesetzt), verwenden Sie Long Polling.
Wenn Sie eine domänenübergreifende Verbindung verwenden (d. h. das SignalR-Endpunkt und die Seite sind nicht in derselben Domäne), verwenden Sie WebSockets, wenn die folgenden Bedingungen erfüllt sind:
Der Client unterstützt Cross-Domain Resource Sharing (CORS), siehe CORS unter für Details
Der Client unterstützt WebSocket
Der Server unterstützt WebSocket
Wenn eine der oben genannten Bedingungen nicht erfüllt ist, wird eine lange Umfrage verwendet. Für weitere Informationen zu domänenübergreifenden Verbindungen siehe Wie man domänenübergreifende Verbindungen herstellt.
Wenn du die Nutzung von JSONP nicht konfigurierst und die Verbindung nicht domänenübergreifend ist, nutze natürlich WebSocket, vorausgesetzt, sowohl Client als auch Server unterstützen WebSocket.
Wenn der Client oder Server WebSockets nicht unterstützt, verwenden Sie den Server, um Ereignisse zu senden.
Wenn der Server ein Ereignis sendet, ist nicht verfügbar, benutze ein Forever Frame.
Wenn Forever Frame nicht verfügbar ist, verwenden Sie Long Polling.
Überwachungsübertragung
Sie können sehen, welche Transportmethode Ihre Anwendung verwendet, indem Sie Hub-Logging aktivieren und in der Browserkonsole tätigen.
Um das Logging zu ermöglichen, fügen Sie der Client-Anwendung folgenden Befehl hinzu:
nnection.hub.logging = wahr;
6. Inspektion und Transport:
Sie können sehen, welche Transportmethode Ihre Anwendung verwendet, indem Sie Hub-Logging aktivieren und in der Browserkonsole tätigen. Um das Logging zu ermöglichen, fügen Sie der Client-Anwendung folgenden Befehl hinzu:
nnection.hub.logging = wahr;
$.connection.hub.logging = true;
In IE drücken Sie F12, um die Entwicklertools zu öffnen, und klicken Sie auf den Console-Tab.
In Chrome drücken Sie Strg+Shift+J, um die Konsole zu öffnen
Indem Sie die Protokollierung in der Konsole beobachten, können Sie die Übertragungsmethode erkennen, die SignalR verwendet.
7. Benannte Schifffahrt:
Die Aushandlung der Übertragungsmethode erfordert eine bestimmte Zeit und die Ressourcen des Servers/Clients. Wenn die Client-Umgebung bekannt ist, kann die Transportmethode beim Verbindungsinitiieren angegeben werden, um die Leistung zu verbessern. Der folgende Code demonstriert, wie Ajax' Long Poling direkt bei Verbindungsinitiierung verwendet wird, falls der Client ein anderes Protokoll unterstützt:
connection.start({ transport: 'longPolling' });
Wenn Sie möchten, dass ein Kunde den Transport in einer bestimmten Reihenfolge verhandelt, können Sie die Reihenfolge festlegen, in der die Verhandlung versucht wird. Der untenstehende Code zeigt, wie man zuerst WebSockets ausprobieren und direkt nach einem Fehler Long Poling durchführen kann.
connection.start({ transport: ['webSockets','longPolling'] });
Die vom Benutzer angegebenen String-Konstanten sind wie folgt definiert:
webSockets
forverFrame
serverSentEvents
LongPolling
8. Verbindungen und Hubs Die SignalR-API umfasst zwei Client-Server-Kommunikationsmodelle: persistente Verbindungen und Hubs.
Eine Verbindung stellt einen einfachen Endpunkt dar, um eine einzelne, gruppierte oder Broadcast-Nachricht zu senden. Die PersistentConnection API (dargestellt durch die PersistentConnection-Klasse in .NET-Code) gewährt Entwicklern direkten Zugriff auf das zugrundeliegende Kommunikationsprotokoll von SignalR. Entwickler, die verbindungsbasierte APIs wie WCF verwendet haben, sind mit dem Verbindungskommunikationsmodell vertrauter.
Hubs sind API-basierte, aber höherstufige Kommunikationspipelines, die es Clients und Servern ermöglichen, Methoden direkt aufeinander zu rufen. SignalR macht einen hervorragenden Job bei der Planung über mehrere Maschinen hinaus, sodass Clients Methoden auf dem Server einfach aufrufen können, als würden sie lokale Methoden aufrufen, und umgekehrt. Entwickler, die remote call-basierte AIPs wie .Net Remoting verwendet haben, sind mit dem Hub-Modell vertrauter. Mit dem Hub kannst du auch stark typisierte Parameter an Methoden übergeben und sie an das Modell binden.
Architekturdiagramm: Das untenstehende Diagramm zeigt die Beziehung zwischen dem Hub, der kontinuierlichen Verbindung und der zugrunde liegenden Technologie, die für den Transport verwendet wird.
9. Wie der Hub funktioniert:
Wenn der Servercode den Client aufruft, sendet der Server ein Paket mit der aufrufenden Methode und den Parametern (wenn das Objekt als Methodenparameter verwendet wird, wird es als JSON serialisiert und gesendet) an den Client. Der Client prüft dann den empfangenen Methodennamen und führt eine Übereinstimmung in der clientsdefinierten Methode durch, und wenn das Match erfolgreich ist, wird die Methode ausgeführt und das deserialisierte Objekt als Methodenparameter verwendet.
Du kannst Tools wie Fiddler verwenden, um die Ausführung von Methodenaufrufen zu überwachen. Das folgende Bild zeigt eine Methode, die aus Fiddlers Logs aufgenommen wurde, um vom SignalR-Server an den Webbrowser-Client gesendet zu werden. Die vom Hub initiierte Methode heißt MoveShapeHub, und die Methode updateShape.
In diesem Beispiel wird der Name des Hubs mit dem Parameter "H" identifiziert, der Methodenname mit dem Parameter "M" und das an die Methode gesendete Parameterobjekt mit dem Parameter "A". Die Anwendung, die die Nachricht erzeugte, wurde im Hochfrequenz-Echtzeit-Kommunikationstutorial implementiert.
Wählen Sie ein Kommunikationsmodell:
Die meisten Anwendungen nutzen die API des Hubs, die in folgenden Situationen eingesetzt werden kann:
Du musst das Format angeben, in dem die Nachricht gesendet wird.
Entwickler bevorzugen ein Messaging- und Scheduling-Modell anstelle eines Remote Call-Modells
Das Messaging-Modell wird in bestehenden Anwendungen verwendet und soll auf SignalR portiert werden.
|
Veröffentlicht am 05.07.2017 10:21:40
|
|
|
|
Vermieter