Die SignalR-Komponente verwendet WebSocket als Transport zur Verbindung mit einem SignalR-Server; wenn dieser Transport nicht unterstützt wird, wird ein Fehler ausgelöst.
Die SignalR-Client-Komponente verfügt über eine Eigenschaft namens SignalR, in der Sie folgende Daten festlegen können:
Der Client unterstützt das Senden von Text- oder Binärdaten.
Die Hubs-API ermöglicht es, Servermethoden vom Client aus und Clientmethoden vom Server aus aufzurufen. Das für persistente Verbindungen verwendete Protokoll ist nicht reichhaltig genug, um RPC-Semantik (Remote Procedure Call) auszudrücken. Das bedeutet jedoch nicht, dass das für Hub-Verbindungen verwendete Protokoll völlig anders ist als das für persistente Verbindungen verwendete Protokoll. Vielmehr ist das für Hub-Verbindungen verwendete Protokoll größtenteils eine Erweiterung des Protokolls für persistente Verbindungen.
Wenn ein Client eine Servermethode aufruft, sendet er nicht mehr eine freie Zeichenfolge, wie es bei persistenten Verbindungen der Fall war. Stattdessen sendet er eine JSON-Zeichenfolge, die alle zum Aufrufen der Methode erforderlichen Informationen enthält. Hier ist eine Beispielnachricht, die ein Client senden würde, um eine Servermethode aufzurufen:
WriteData('{"H":"chathub","M":"Send","A":["Delphi Client","Test message"],"I":0}');
Die Payload hat die folgenden Eigenschaften:
I – Invocation-Bezeichner – ermöglicht Ihnen, Antworten mit Anforderungen abzugleichen
H – der Name des Hubs
M – der Name der Methode
A – Argumente (ein Array, kann leer sein, wenn die Methode keine Parameter hat)
Wenn das String-Argument doppelte Anführungszeichen enthält, ersetzen Sie " durch \"
Beispiel: Wenn das Argument {"test":1} lautet, senden Sie das Argument als {\"test\":1}
WriteData('{"H":"chathub","M":"Send","A":["{\"test\":1}"],"I":0}');
Die Authentifizierung kann aktiviert werden, um jeder Verbindung einen Benutzer zuzuordnen und zu filtern, welche Benutzer auf Ressourcen zugreifen können. Die Authentifizierung wird mit Bearer-Tokens implementiert: Der Client stellt ein Access-Token bereit und der Server validiert dieses Token und verwendet es, um den Benutzer zu identifizieren.
Derzeit werden nur Bearer-Token unterstützt:
Hier übergeben Sie das Token direkt an den Signal-Server (da das Token von einem anderen Server beschafft wurde).
Authentication.Enabled: wenn aktiv, wird die Autorisierung verwendet, bevor eine WebSocket-Verbindung hergestellt wird.
Authentication.Authentication: Es werden 2 Arten der Authentifizierung unterstützt: Bearer-Token oder Cookies. Beide erfordern eine externe Methode, um die erforderlichen Werte zu erhalten.
BearerToken: erhaltener Token-Wert.
Cookie: setzt den Wert des erforderlichen Cookies.
oSignalR := TsgcWSAPI_Signal.Create(nil);
oSignalR.SignalR.Enabled := True;
oSignalR.SignalR.Authentication := srcBearerToken;
oSignalR.SignalR.BearerToken.Token := 'token here';
Die Komponente hat die folgenden Ereignisse:
Dieses Ereignis wird ausgelöst, wenn der Client erfolgreich eine Verbindung zum Server herstellt.
Dieses Ereignis wird ausgelöst, wenn der Client vom Server getrennt wird.
Dieses Ereignis wird aufgerufen, wenn ein Fehler in der WebSocket-Verbindung auftritt.
Das für persistente Verbindungen verwendete Protokoll ist recht einfach. An den Server gesendete Nachrichten sind einfach Raw-Strings. Es gibt kein bestimmtes Format, in dem sie vorliegen müssen. An den Client gesendete Nachrichten sind strukturierter. Die Eigenschaften, die Sie in der Nachricht finden können, sind die folgenden:
C – Nachrichten-ID, vorhanden für alle Nachrichten außer KeepAlive
M – ein Array, das die tatsächlichen Daten enthält.
{"C":"d-9B7A6976-B,2|C,2","M":["Welcome!"]}
Dieses Ereignis wird aufgerufen, wenn Binärdaten vom Server empfangen werden.
Wenn eine Servermethode aufgerufen wird, gibt der Server eine Bestätigung zurück, dass der Aufruf abgeschlossen wurde, indem er die Aufruf-ID an den Client sendet und – falls die Methode einen Wert zurückgegeben hat – den Rückgabewert, oder – falls der Methodenaufruf fehlgeschlagen ist – den Fehler.
Hier sind Beispielergebnisse eines Servermethodenaufrufs:
{"I":"0"}
Eine void-Servermethode, deren Aufrufkennung "0" war, wurde erfolgreich abgeschlossen.
{"I":"0", "R":42}
Eine Server-Methode, die eine Zahl zurückgibt und deren Aufrufbezeichner "0" war, wurde erfolgreich abgeschlossen und gab den Wert 42 zurück.
{"I":"0", "E":"Error occurred"}
Dieses Ereignis wird ausgelöst, wenn eine KeepAlive-Nachricht vom Server empfangen wird.