Wprowadzenie do usługi SignalR

Autor : Patrick Fletcher

Ostrzeżenie

Ta dokumentacja nie jest przeznaczona dla najnowszej wersji usługi SignalR. Przyjrzyj się ASP.NET Core SignalR.

W tym artykule opisano, czym jest usługa SignalR, oraz niektóre rozwiązania, które zostały zaprojektowane do utworzenia.

Pytania i komentarze

Prześlij opinię na temat tego, jak podoba ci się ten samouczek i co możemy poprawić w komentarzach w dolnej części strony. Jeśli masz pytania, które nie są bezpośrednio związane z samouczkiem, możesz opublikować je na forum ASP.NET SignalR lub StackOverflow.com.

Co to jest usługa SignalR?

ASP.NET SignalR to biblioteka dla ASP.NET deweloperów, którzy upraszczają proces dodawania funkcji internetowych w czasie rzeczywistym do aplikacji. Funkcja internetowa w czasie rzeczywistym to możliwość natychmiastowego wypychania zawartości kodu serwera do połączonych klientów, gdy stanie się ona dostępna, zamiast oczekiwania serwera na żądanie nowych danych przez klienta.

Usługa SignalR może służyć do dodawania dowolnej funkcji internetowej "w czasie rzeczywistym" do aplikacji ASP.NET. Czat jest często używany jako przykład, ale możesz zrobić o wiele więcej. Za każdym razem, gdy użytkownik odświeży stronę internetową, aby wyświetlić nowe dane lub strona implementuje długie sondowanie w celu pobrania nowych danych, jest to kandydat do korzystania z usługi SignalR. Przykłady obejmują pulpity nawigacyjne i aplikacje do monitorowania, aplikacje współpracy (takie jak jednoczesne edytowanie dokumentów), aktualizacje postępu zadania i formularze czasu rzeczywistego.

Usługa SignalR umożliwia również zupełnie nowe typy aplikacji internetowych, które wymagają aktualizacji o wysokiej częstotliwości z serwera, na przykład gier w czasie rzeczywistym.

Usługa SignalR udostępnia prosty interfejs API do tworzenia zdalnych wywołań procedury serwer-klient (RPC), które nazywają funkcje Języka JavaScript w przeglądarkach klienta (i innych platformach klienckich) z kodu platformy .NET po stronie serwera. Usługa SignalR zawiera również interfejs API do zarządzania połączeniami (na przykład zdarzenia łączenia i rozłączania) oraz grupowania połączeń.

Usługa SignalR automatycznie obsługuje zarządzanie połączeniami i umożliwia rozgłaszanie komunikatów do wszystkich połączonych klientów równocześnie, tak w przypadku pokoju rozmów. Można również wysyłać komunikaty do określonych klientów. Połączenie między klientem i serwerem jest trwałe w odróżnieniu od klasycznego połączenia HTTP, które jest nawiązywane ponownie dla każdej komunikacji.

Usługa SignalR obsługuje funkcję "wypychania serwera", w której kod serwera może wywoływać kod klienta w przeglądarce przy użyciu zdalnych wywołań procedur (RPC), a nie modelu odpowiedzi na żądanie wspólnego w internecie.

Aplikacje signalR mogą skalować w poziomie do tysięcy klientów przy użyciu wbudowanych i innych dostawców skalowania w poziomie.

Dostawcy wbudowani to:

• Service Bus
• SQL Server
• Redis

Dostawcy innych firm to:

• NCache.

Usługa SignalR jest typu open source, dostępna za pośrednictwem usługi GitHub.

SignalR i WebSocket

Usługa SignalR korzysta z nowego transportu protokołu WebSocket, jeśli jest dostępny i wraca do starszych transportów w razie potrzeby. Chociaż na pewno możesz napisać aplikację przy użyciu protokołu WebSocket bezpośrednio, użycie usługi SignalR oznacza, że wiele dodatkowych funkcji, które należy zaimplementować, jest już gotowe. Co najważniejsze, oznacza to, że możesz kodować aplikację, aby korzystać z protokołu WebSocket bez konieczności martwienia się o utworzenie oddzielnej ścieżki kodu dla starszych klientów. Usługa SignalR chroni również przed koniecznością martwienia się o aktualizacje protokołu WebSocket, ponieważ usługa SignalR jest aktualizowana w celu obsługi zmian w transporcie bazowym, zapewniając aplikacji spójny interfejs w różnych wersjach protokołu WebSocket.

Transporty i powroty

SignalR to abstrakcja niektórych transportów, które są wymagane do wykonywania pracy w czasie rzeczywistym między klientem a serwerem. Usługa SignalR najpierw próbuje ustanowić połączenie Protokołu WebSocket, jeśli to możliwe. Protokół WebSocket jest optymalnym transportem dla usługi SignalR, ponieważ ma:

• Najbardziej wydajne wykorzystanie pamięci serwera.
• Najniższe opóźnienie.
• Najbardziej podstawowe funkcje, takie jak pełna komunikacja dwukierunkowa między klientem a serwerem.
• Najwygodniejsze wymagania dotyczące protokołu WebSocket wymaga serwera:
  • Uruchom polecenie w systemie Windows Server 2012 lub Windows 8.
  • .NET Framework 4.5.

Jeśli te wymagania nie zostaną spełnione, usługa SignalR próbuje użyć innych transportów, aby nawiązać połączenia.

Transporty HTML 5

Te transporty zależą od obsługi kodu HTML 5. Jeśli przeglądarka kliencka nie obsługuje standardu HTML 5, starsze transporty będą używane.

• WebSocket (jeśli zarówno serwer, jak i przeglądarka wskazują, że mogą obsługiwać protokół Websocket). WebSocket to jedyny transport, który ustanawia prawdziwe trwałe, dwukierunkowe połączenie między klientem a serwerem. Jednak protokół WebSocket ma również najbardziej rygorystyczne wymagania; Jest ona w pełni obsługiwana tylko w najnowszych wersjach programu Microsoft Internet Explorer, Google Chrome i Mozilla Firefox i ma tylko częściową implementację w innych przeglądarkach, takich jak Opera i Safari.
• Zdarzenia wysłane przez serwer, znane również jako EventSource (jeśli przeglądarka obsługuje zdarzenia wysłane przez serwer, czyli w zasadzie wszystkie przeglądarki z wyjątkiem programu Internet Explorer).

Transporty komet

Następujące transporty są oparte na modelu aplikacji internetowej Comet , w którym przeglądarka lub inny klient utrzymuje długotrwałe żądanie HTTP, którego serwer może użyć do wypychania danych do klienta bez klienta żądającego.

• Na zawsze ramka (tylko w programie Internet Explorer). Forever Frame tworzy ukryty element IFrame, który wysyła żądanie do punktu końcowego na serwerze, który nie został ukończony. Następnie serwer stale wysyła skrypt do klienta, który jest natychmiast wykonywany, zapewniając jednokierunkowe połączenie w czasie rzeczywistym z serwera do klienta. Połączenie od klienta do serwera używa oddzielnego połączenia z serwerem do połączenia klienta, a podobnie jak standardowe żądanie HTTP, nowe połączenie jest tworzone dla każdego elementu danych, które należy wysłać.
• Ajax długi sondaż. Długie sondowanie nie tworzy trwałego połączenia, ale zamiast tego sonduje serwer z żądaniem, które pozostaje otwarte, dopóki serwer nie odpowie, w którym momencie połączenie zostanie zamknięte, a nowe połączenie zostanie natychmiast zażądane. Może to spowodować pewne opóźnienie podczas resetowania połączenia.

Aby uzyskać więcej informacji na temat obsługiwanych transportów w ramach konfiguracji, zobacz Obsługiwane platformy.

Proces wyboru transportu

Na poniższej liście przedstawiono kroki używane przez usługę SignalR do decydowania o tym, który transport ma być używany.

1. Jeśli przeglądarka jest używana w programie Internet Explorer 8 lub starszym, jest używane długie sondowanie.

2. Jeśli skonfigurowano protokół JSONP (czyli jsonp parametr jest ustawiony na true wartość po uruchomieniu połączenia), jest używane długie sondowanie.

3. Jeśli jest wykonywane połączenie między domenami (oznacza to, że jeśli punkt końcowy usługi SignalR nie znajduje się w tej samej domenie co strona hostingu), zostanie użyty zestaw WebSocket, jeśli spełnione są następujące kryteria:

   • Klient obsługuje mechanizm CORS (współużytkowanie zasobów między źródłami). Aby uzyskać szczegółowe informacje na temat tego, którzy klienci obsługują mechanizm CORS, zobacz CORS w caniuse.com.

   • Klient obsługuje protokół WebSocket

   • Serwer obsługuje protokół WebSocket

     Jeśli którekolwiek z tych kryteriów nie zostaną spełnione, zostanie użyte długie sondowanie. Aby uzyskać więcej informacji na temat połączeń między domenami, zobacz Jak ustanowić połączenie między domenami.

4. Jeśli protokół JSONP nie jest skonfigurowany, a połączenie nie jest między domenami, zestaw WebSocket będzie używany, jeśli klient i serwer go obsługują.

5. Jeśli klient lub serwer nie obsługują protokołu WebSocket, zdarzenia wysłane przez serwer są używane, jeśli jest dostępna.

6. Jeśli zdarzenia wysłane przez serwer nie są dostępne, próba ramki na zawsze zostanie podjęta.

7. Jeśli ramka Na zawsze zakończy się niepowodzeniem, użyto długiego sondowania.

Monitorowanie transportu

Możesz określić transport używany przez aplikację, włączając rejestrowanie w centrum i otwierając okno konsoli w przeglądarce.

Aby włączyć rejestrowanie zdarzeń centrum w przeglądarce, dodaj następujące polecenie do aplikacji klienckiej:

$.connection.hub.logging = true;

• W programie Internet Explorer otwórz narzędzia deweloperskie, naciskając klawisz F12, a następnie kliknij kartę Konsola.

  

• W przeglądarce Chrome otwórz konsolę, naciskając klawisze Ctrl+Shift+J.

  

Po włączeniu otwierania i rejestrowania konsoli będzie można zobaczyć, który transport jest używany przez usługę SignalR.

Określanie transportu

Negocjowanie transportu trwa pewien czas i zasoby klienta/serwera. Jeśli są znane możliwości klienta, można określić transport po uruchomieniu połączenia klienta. Poniższy fragment kodu pokazuje rozpoczęcie połączenia przy użyciu transportu Ajax Long Polling, jak byłoby używane, jeśli wiadomo, że klient nie obsługuje żadnego innego protokołu:

connection.start({ transport: 'longPolling' });

Możesz określić kolejność rezerwową, jeśli chcesz, aby klient próbował wykonać określone transporty w kolejności. Poniższy fragment kodu pokazuje próbę użycia protokołu WebSocket i kończy się niepowodzeniem, przechodząc bezpośrednio do długiego sondowania.

connection.start({ transport: ['webSockets','longPolling'] });

Stałe ciągów do określania transportu są definiowane w następujący sposób:

• webSockets
• foreverFrame
• serverSentEvents
• longPolling

Połączenia i koncentratory

Interfejs API usługi SignalR zawiera dwa modele komunikacji między klientami i serwerami: połączenia trwałe i koncentratory.

Połączenie reprezentuje prosty punkt końcowy do wysyłania wiadomości jedno-adresata, grupowanych lub rozgłaszanych. Interfejs API trwałego połączenia (reprezentowany w kodzie platformy .NET przez klasę PersistentConnection) zapewnia deweloperowi bezpośredni dostęp do protokołu komunikacyjnego niskiego poziomu uwidacznianego przez usługę SignalR. Korzystanie z modelu komunikacji Połączenia będzie znane deweloperom, którzy korzystali z interfejsów API opartych na połączeniach, takich jak Windows Communication Foundation.

Centrum to bardziej ogólny potok oparty na interfejsie API połączenia, który umożliwia klientowi i serwerowi bezpośrednie wywoływanie metod nawzajem. Usługa SignalR obsługuje wysyłanie między granicami maszyny tak, jakby przez magię, umożliwiając klientom wywoływanie metod na serwerze tak łatwo, jak metody lokalne i odwrotnie. Korzystanie z modelu komunikacji usługi Hubs będzie znane deweloperom, którzy używali zdalnych interfejsów API wywołań, takich jak komunikacja zdalna. Użycie centrum umożliwia również przekazywanie silnie typiowanych parametrów do metod, co umożliwia powiązanie modelu.

Diagram architektury

Na poniższym diagramie przedstawiono relację między centrami, połączeniami trwałymi i podstawowymi technologiami używanymi do transportu.

Jak działają centra

Gdy kod po stronie serwera wywołuje metodę na kliencie, pakiet jest wysyłany przez aktywny transport zawierający nazwę i parametry metody do wywołania (gdy obiekt jest wysyłany jako parametr metody, jest serializowany przy użyciu formatu JSON). Następnie klient dopasuje nazwę metody do metod zdefiniowanych w kodzie po stronie klienta. Jeśli istnieje dopasowanie, metoda klienta zostanie wykonana przy użyciu deserializowanych danych parametrów.

Wywołanie metody można monitorować przy użyciu narzędzi, takich jak Fiddler. Na poniższej ilustracji przedstawiono wywołanie metody wysyłane z serwera SignalR do klienta przeglądarki internetowej w okienku Dzienniki programu Fiddler. Wywołanie metody jest wysyłane z centrum o nazwie MoveShapeHub, a wywoływana metoda nosi nazwę updateShape.

W tym przykładzie nazwa centrum jest identyfikowana z H parametrem; nazwa metody jest identyfikowana z M parametrem, a dane wysyłane do metody są identyfikowane z parametrem A . Aplikacja, która wygenerowała ten komunikat, jest tworzona w samouczku High-Frequency Realtime .

Wybieranie modelu komunikacji

Większość aplikacji powinna używać interfejsu API usługi Hubs. Interfejs API połączeń może być używany w następujących okolicznościach:

• Należy określić format rzeczywistego wysłanego komunikatu.
• Deweloper preferuje pracę z obsługą komunikatów i wysyłaniem modelu, a nie zdalnego modelu wywołania.
• Istniejąca aplikacja korzystająca z modelu obsługi komunikatów jest przenoszona do korzystania z usługi SignalR.