1. Czym jest SignalR:
ASP.NET SignalR to biblioteka zajęć udostępniana w celu uproszczenia procesu dodawania treści na żywo do aplikacji przez programistów deweloperskich. Funkcjonalność webowa w czasie rzeczywistym polega na umożliwieniu kodowi serwera aktywnego przesyłania treści do klientów w dowolnym momencie, zamiast czekać na żądanie klienta (przed zwróceniem zawartości).
Wszystkie "żywe" rodzaje funkcjonalności sieciowych można dodać do swojej aplikacji ASP.NET za pomocą SignalR. Najczęściej używanym przykładem są czaty, ale możemy zrobić znacznie więcej. Weźmy pod uwagę następujące sytuacje: użytkownicy muszą nieustannie odświeżać stronę internetową, aby zobaczyć najnowsze dane; Albo pobierać (i wyświetlać) nowe dane na stronie, implementując długie odpytywanie, wtedy możesz rozważyć użycie SignalR. Na przykład: pulpity i aplikacje monitorujące; aplikacje współpracujące (np. kilka osób edytujących dokumenty jednocześnie); Aktualizacje postępów w pracy i formularze prezentacji w czasie rzeczywistym itd.
SignalR nadaje się także do nowszych typów aplikacji webowych wymagających częstych aktualizacji z serwera, takich jak gry w czasie rzeczywistym. Oto dobry przykład: ShoorR.
SignalR udostępnia proste API umożliwiające użytkownikom tworzenie zdalnych wywołań procedur serwer-klient (RPC), które mogą być łatwo dostępne po stronie serwera. Kod sieciowy. SignalR zawiera także połączenia (np. zdarzenia połączenia i rozłączenia) oraz grupowanie połączeń.
SignalR może automatycznie zarządzać połączeniami. I pozwala wysyłać wiadomości broadcastowe do wszystkich podłączonych klientów, podobnie jak w pokoju czatu. Oczywiście, oprócz masowego wysyłania, możesz także wysyłać wiadomości do konkretnych klientów. Połączenie między klientem a serwerem jest trwałe, w przeciwieństwie do tradycyjnego protokołu HTTP, który wymaga ponownego nawiązania połączenia dla każdej komunikacji.
SignalR obsługuje funkcję "server push", gdzie kod serwera może wywoływać kod klienta w przeglądarce, korzystając z zdalnych wywołań procedur (RPC) zamiast obecnie powszechnie używanych żądań w sieci – odpowiadającego modelu przetwarzania.
Aplikacje SignalR mogą być rozszerzone na tysiące klientów za pomocą Service Bus, SQL SERVER lub Redis.
SignalR jest open-source i można do niego uzyskać dostęp przez GitHub.
2. SignalR i WebSocket
ignalR korzysta z metody transportu WebSocket – tam, gdzie to możliwe. I automatycznie przełączają się na starą metodę transportu (np. długie połączenie HTTP). Oczywiście możesz napisać aplikację bezpośrednio za pomocą WebSockets, ale korzystanie z SignalR oznacza więcej dodatkowych funkcji bez konieczności ciągłego wymyślania koła na nowo. Co najważniejsze, możesz skupić się na implementacji biznesowej, nie myśląc o tworzeniu kompatybilnego kodu osobno dla starego klienta. SignalR pozwala również uniknąć martwienia się o aktualizacje WebSocket, ponieważ SignalR będzie nadal aktualizowany, aby wspierać zmieniające się metody transportu i zapewnić spójny interfejs dostępu do aplikacji w różnych wersjach WebSockets.
Oczywiście możesz stworzyć rozwiązanie korzystające wyłącznie z transportu WebSocket, a SignalR oferuje wszystkie funkcje, które mogą być potrzebne do napisania własnego kodu, takie jak powrót do innych metod transportu czy modyfikacja aplikacji pod nowe implementacje WebSocket.
3. Transport i powrót
SignalR to abstrakcja technologii transportowej potrzebnej do implementacji funkcji w czasie rzeczywistym między klientami a serwerami. SignalR najpierw uruchamia połączenie za pomocą HTTP i sprawdza, czy WebSocket jest dostępny – jeśli tak, aktualizuje do połączenia WebSocket. WebSocket jest najbardziej idealną metodą transmisji dla SignalR, ponieważ wykorzystuje pamięć serwera najefektywniej, ma najniższe opóźnienia i rozbudowane funkcje podstawowe (takie jak komunikacja pełnodupleksowa między klientem a serwerem), ale spełnia także najsurowsze wymagania: serwer musi jednocześnie korzystać z systemu operacyjnego Windows Server 2012 lub Windows 8. .NET framework w wersji 4.5 i nowej. Jeśli te wymagania nie zostaną spełnione, SignalR spróbuje użyć alternatywnej metody transmisji do połączenia.
4. Wysyłka HTML5
Metoda transportu zależy od tego, czy przeglądarka klienta obsługuje HTML5, w przeciwnym razie użyta zostanie stara metoda transportu.
WebSocket (jeśli zarówno serwer, jak i przeglądarka obsługują WebSocket). WebSocket to jedyny sposób na nawiązanie prawdziwego i trwałego połączenia dwukierunkowego zarówno po stronie klienta, jak i serwera. Oczywiście WebSocket ma również najrygorystyczne wymagania: jest wspierany tylko w najnowszych wersjach IE, Chrome i FF, a w innych przeglądarkach, takich jak Opera i Safari, jest tylko częściowo zaimplementowany.
Server wysyła zdarzenia, znane również jako EventSource (jeśli przeglądarka obsługuje zdarzenia wysyłające serwer, praktycznie wszystkie przeglądarki oprócz IE obsługują tę funkcję).
5. Transmisja na kometę
Poniższe typy transportu opierają się na modelu aplikacji webowej Comet, gdzie przeglądarka lub klient utrzymuje długie żądanie połączenia HTTP, a serwer może przesyłać dane do klienta bez wyraźnego żądania ze strony klienta.
Forever Frame (tylko IE) Forever Frame utworzy ukryty IFrame, który wysyła żądanie do serwera, które nie zostanie ukończone. Serwer następnie nieprzerwanie wysyła skrypty do klienta, które są natychmiast wykonywane przez klienta, czyli jednokierunkowe połączenie w czasie rzeczywistym między serwerem a klientem. Połączenie klient-serwer korzysta z innego połączenia niż tamto. Na przykład standardowe żądanie HTML tworzy nowe połączenie dla każdego przesłanego podatku.
Długie pollowanie Ajaxu nie tworzy trwałego połączenia, lecz raczej polluje poprzez ciągłe wysyłanie żądań do serwera. Poczekaj na odpowiedź serwera i zamknij to połączenie przy każdym połączeniu, a następnie natychmiast złóż nowe żądanie. Oczywiście spowoduje to opóźnienie przy resetowaniu i ponownym łączeniu.
Informacje o metodach transportu obsługiwanych przez różne konfiguracje można znaleźć w sekcji Wspierane platformy. (IE wymaga 8 lub więcej, inne przeglądarki to aktualna wersja -1)
Proces wyboru metody transferu
Poniższa lista pokazuje, jak SignalR decyduje, którego typu użyć do transmisji.
Od IE8 i wcześniejszych używaj długich odpytań.
Jeśli JSONP jest skonfigurowany (czyli parametr jsonp jest ustawiony na true podczas łączenia), użyj długiego pollingu.
Jeśli używasz połączenia międzydomenowego (tzn. endpoint SignalR i strona nie znajdują się w tej samej domenie), użyj WebSockets, jeśli spełnione są następujące warunki:
Klient obsługuje Cross-Domain Resource Sharing (CORS), szczegóły można znaleźć w CORS
Klient obsługuje WebSocket
Serwer obsługuje WebSocket
Jeśli którykolwiek z powyższych warunków nie jest spełniony, stosuje się długie ankietowanie. Więcej informacji o połączeniach międzydomenowych znajdziesz w artykule Jak nawiązać połączenia międzydomenowe.
Jeśli nie konfigurujesz użycia JSONP i połączenie nie jest międzydomenowe, oczywiście użyj WebSocket, pod warunkiem, że zarówno klient, jak i serwer obsługują WebSocket.
Jeśli klient lub serwer nie obsługuje WebSockets, użyj serwera do wysyłania zdarzeń.
Jeśli serwer wysyła zdarzenie nie jest dostępne, użyj Forever Frame.
Jeśli Forever Frame nie jest dostępny, użyj długiego odpytywania.
Transmisja monitorowa
Możesz zobaczyć, jaką metodę transportu używa twoja aplikacja, włączając logowanie w hubie i w konsoli przeglądarki.
Aby włączyć logowanie, dodaj następujące polecenie do aplikacji klienckiej:
nnection.hub.logging = prawdziwa;
6. Inspekcja i transport:
Możesz zobaczyć, jaką metodę transportu używa twoja aplikacja, włączając logowanie w hubie i w konsoli przeglądarki. Aby włączyć logowanie, dodaj następujące polecenie do aplikacji klienckiej:
nnection.hub.logging = prawdziwa;
$.connection.hub.logging = prawdziwe;
W IE naciśnij F12, aby otworzyć narzędzia deweloperskie i kliknij zakładkę Konsola.
W Chrome naciśnij Ctrl+Shift+J, aby otworzyć konsolę
Obserwując logowanie w konsoli, można zobaczyć metodę transmisji używaną przez SignalR.
7. Wyznaczony transport transportowy:
Negocjowanie metody transmisji wymaga określonego czasu i zasobów serwera/klienta. Jeśli środowisko klienta jest znane, metoda transportu może zostać określona podczas inicjowania połączenia, aby poprawić wydajność. Poniższy kod demonstruje użycie długiego pollingu Ajax bezpośrednio przy inicjacji połączenia, jeśli wiadomo, że klient obsługuje inny protokół:
connection.start({ transport: 'longPolling' });
Jeśli chcesz, aby klient negocjował transport w określonej kolejności, możesz określić kolejność, w jakiej próba jest prowadzona. Poniższy kod pokazuje, jak najpierw spróbować użyć WebSockets, a następnie użyć długiego pollingu bezpośrednio po awarii.
connection.start({ transport: ['webSockets','longPolling'] });
Stałe ciągów znaków określonych przez użytkownika są definiowane następująco:
webSockets
forverFrame
serverSentEvents
longPolling
8. Połączenia i huby API SignalR obejmuje dwa modele komunikacji klient-serwer: trwałe połączenia oraz huby.
Połączenie reprezentuje prosty punkt końcowy do wysyłania pojedynczej, grupowej lub rozgłaszanej wiadomości. API PersistentConnection (reprezentowane przez klasę PersistentConnection w kodzie .NET) daje deweloperom bezpośredni dostęp do protokołu komunikacyjnego SignalR. Programiści, którzy korzystali z API opartych na połączeniach, takich jak WCF, będą lepiej zaznajomieni z modelem komunikacji połączenia.
Huby to oparte na API, ale zaawansowane potoki komunikacyjne, które pozwalają klientom i serwerom wywoływać metody bezpośrednio do siebie. SignalR świetnie radzi sobie z harmonogramowaniem między maszynami, pozwalając klientom łatwo wywoływać metody na serwerze, jakby wywoływali metody lokalne i odwrotnie. Programiści, którzy korzystali z AIP opartych na zdalnych połączeniach, takich jak .Net Remoting, będą lepiej zaznajomieni z modelem hub. Korzystając z huba, możesz też przekazywać mocno typowane parametry do metod i wiązać je z modelem.
Diagram architektury: Poniższy diagram pokazuje związek między węzłem, ciągłym połączeniem a technologią wykorzystywaną w transporcie.
9. Jak działa centrum:
Gdy kod serwera wywołuje klienta, serwer wysyła pakiet zawierający wywołującą metodę i parametry (gdy obiekt jest używany jako parametr metody, jest serializowany jako JSON do wysłania) do klienta. Klient następnie sprawdza odebraną nazwę metody i wykonuje wyszukiwanie dopasowania w metodzie zdefiniowanej przez klienta, a jeśli dopasowanie się powiedzie, metoda jest wykonywana, a obiekt zdeserializowany jest używany jako parametr metody.
Możesz użyć narzędzi takich jak Fiddler do monitorowania wykonywania wywołań metody. Poniższy obraz przedstawia metodę przechwyconą z logów Fiddlera, która ma być wysyłana z serwera SignalR do klienta przeglądarki www. Metoda inicjowana z hubu nazywa się MoveShapeHub, a metoda to updateShape.
W tym przykładzie nazwa huba jest identyfikowana z parametrem "H", nazwa metody z parametrem "M", a obiekt parametru wysyłany do metody jest identyfikowany z parametrem "A". Aplikacja generująca tę wiadomość została zaimplementowana w samouczku komunikacji w czasie rzeczywistym o wysokiej częstotliwości.
Wybierz model komunikacji:
Większość aplikacji korzysta z API huba, które może być używane w następujących sytuacjach:
Musisz określić format, w jakim wiadomość jest wysyłana.
Deweloperzy wolą korzystać z modelu komunikacji i planowania zamiast modelu zdalnych rozmów
Model komunikatów jest wykorzystywany w istniejących aplikacjach i planowany jest port na SignalR.
|
Opublikowano 05.07.2017 10:21:40
|
|
|
|
Ziemianin