Komponent SignalR używa WebSocket jako transportu do łączenia się z serwerem SignalR; jeśli ten transport nie jest obsługiwany, zostanie zgłoszony błąd.
Komponent klienta SignalR ma właściwość SignalR, w której można ustawić następujące dane:
Klient obsługuje wysyłanie danych tekstowych lub binarnych.
Hubs API umożliwia wywoływanie metod serwera przez klienta oraz metod klienta przez serwer. Protokół używany do trwałych połączeń nie jest wystarczająco rozbudowany, aby wyrażać semantykę RPC (zdalnego wywołania procedur). Nie oznacza to jednak, że protokół używany dla połączeń z hubami jest całkowicie inny niż protokół dla połączeń trwałych. Protokół połączeń z hubami jest w dużej mierze rozszerzeniem protokołu dla połączeń trwałych.
Gdy klient wywołuje metodę serwera, nie wysyła już swobodnego ciągu znaków jak w przypadku połączeń trwałych. Zamiast tego wysyła ciąg JSON zawierający wszystkie informacje niezbędne do wywołania metody. Poniżej znajduje się przykładowa wiadomość, którą klient wysyłałby w celu wywołania metody serwera:
WriteData('{"H":"chathub","M":"Send","A":["Delphi Client","Test message"],"I":0}');
Ładunek posiada następujące właściwości:
I — identyfikator wywołania — umożliwia dopasowanie odpowiedzi do żądań
H — nazwa huba
M — nazwa metody
A – argumenty (tablica; może być pusta, jeśli metoda nie ma żadnych parametrów)
Jeśli argument łańcuchowy zawiera cudzysłowy, należy zastąpić " przez \"
Przykład: jeśli argument to {"test":1}, należy wysłać argument jako {\"test\":1}
WriteData('{"H":"chathub","M":"Send","A":["{\"test\":1}"],"I":0}');
Uwierzytelnianie można włączyć, aby powiązać użytkownika z każdym połączeniem i filtrować, którzy użytkownicy mogą uzyskiwać dostęp do zasobów. Uwierzytelnianie jest realizowane przy użyciu tokenów Bearer: klient dostarcza token dostępu, a serwer weryfikuje ten token i używa go do identyfikacji użytkownika.
Obecnie obsługiwane są wyłącznie tokeny Bearer:
Tutaj token jest przekazywany bezpośrednio do serwera Signal (ponieważ token został uzyskany z innego serwera).
Authentication.Enabled: jeśli aktywne, autoryzacja będzie stosowana przed nawiązaniem połączenia WebSocket.
Authentication.Authentication: Obsługiwane są 2 typy uwierzytelniania: token Bearer lub pliki cookie. Oba wymagają zewnętrznego sposobu uzyskania wymaganych wartości.
BearerToken: uzyskana wartość tokenu.
Cookie: ustaw wartość wymaganego pliku cookie.
oSignalR := TsgcWSAPI_Signal.Create(nil);
oSignalR.SignalR.Enabled := True;
oSignalR.SignalR.Authentication := srcBearerToken;
oSignalR.SignalR.BearerToken.Token := 'token here';
Komponent posiada następujące zdarzenia:
Zdarzenie to jest wywoływane, gdy klient pomyślnie połączy się z serwerem.
Zdarzenie jest wywoływane po rozłączeniu klienta z serwerem.
Zdarzenie jest wywoływane w przypadku wystąpienia błędu w połączeniu WebSocket.
Protokół używany do połączenia stałego jest dość prosty. Wiadomości wysyłane do serwera są zwykłymi ciągami tekstowymi bez wymaganego określonego formatu. Wiadomości wysyłane do klienta mają bardziej uporządkowaną strukturę. Właściwości dostępne w wiadomości są następujące:
C – identyfikator wiadomości, obecny we wszystkich wiadomościach innych niż KeepAlive.
M – tablica zawierająca rzeczywiste dane.
{"C":"d-9B7A6976-B,2|C,2","M":["Welcome!"]}
Zdarzenie to jest wywoływane po otrzymaniu danych binarnych z serwera.
Po wywołaniu metody serwera, serwer zwraca potwierdzenie zakończenia wywołania, wysyłając do klienta identyfikator wywołania oraz, jeśli metoda zwróciła wartość, tę wartość, lub, jeśli wywołanie metody nie powiodło się, błąd.
Poniżej przedstawiono przykładowe wyniki wywołania metody serwera:
{"I":"0"}
Metoda serwera void z identyfikatorem wywołania „0" zakończyła się pomyślnie.
{"I":"0", "R":42}
Metoda serwera zwracająca liczbę, której identyfikator wywołania wynosił "0", zakończyła się pomyślnie i zwróciła wartość 42.
{"I":"0", "E":"Error occurred"}
To zdarzenie jest wywoływane po odebraniu wiadomości KeepAlive z serwera.