Udostępnij za pośrednictwem

Opis i obsługa zdarzeń okresu istnienia połączenia w usłudze SignalR 1.x

  • Artykuł

Autor: Patrick Fletcher, Tom Dykstra

Ostrzeżenie

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

Ten artykuł zawiera omówienie zdarzeń połączenia usługi SignalR, ponownego nawiązywania połączenia i rozłączania, które można obsługiwać, oraz przekroczenia limitu czasu i ustawień utrzymania aktywności, które można skonfigurować.

W tym artykule założono, że masz już pewną wiedzę na temat usługi SignalR i zdarzeń okresu istnienia połączenia. Aby zapoznać się z wprowadzeniem do usługi SignalR, zobacz SignalR — omówienie — Wprowadzenie. Aby uzyskać listę zdarzeń okresu istnienia połączenia, zobacz następujące zasoby:

Omówienie

Ten artykuł zawiera następujące sekcje:

Linki do tematów referencyjnych interfejsu API to wersja interfejsu API platformy .NET 4.5. Jeśli używasz platformy .NET 4, zobacz tematy dotyczące platformy .NET 4 interfejsu API.

Terminologia i scenariusze dotyczące okresu istnienia połączenia

Program OnReconnected obsługi zdarzeń w usłudze SignalR Hub może być wykonywany bezpośrednio po OnConnected , ale nie po OnDisconnected dla danego klienta. Przyczyną ponownego połączenia bez rozłączenia jest to, że istnieje kilka sposobów, w których słowo "połączenie" jest używane w usłudze SignalR.

Połączenia SignalR, połączenia transportowe i połączenia fizyczne

Ten artykuł rozróżnia połączenia usługi SignalR, połączenia transportowe i połączenia fizyczne:

  • Połączenie usługi SignalR odnosi się do relacji logicznej między klientem a adresem URL serwera obsługiwanym przez interfejs API usługi SignalR i jednoznacznie identyfikowanym przez identyfikator połączenia. Dane dotyczące tej relacji są obsługiwane przez usługę SignalR i służą do nawiązywania połączenia transportowego. Relacja kończy się, a usługa SignalR usuwa dane, gdy klient wywołuje Stop metodę lub osiągnięto limit czasu, gdy usługa SignalR próbuje ponownie ustanowić utracone połączenie transportowe.
  • Połączenie transportu odnosi się do relacji logicznej między klientem a serwerem obsługiwanym przez jeden z czterech interfejsów API transportu: WebSockets, zdarzenia wysyłane przez serwer, na zawsze ramkę lub długie sondowanie. Usługa SignalR używa interfejsu API transportu do utworzenia połączenia transportowego, a interfejs API transportu zależy od istnienia fizycznego połączenia sieciowego w celu utworzenia połączenia transportowego. Połączenie transportowe kończy się, gdy usługa SignalR zakończy połączenie lub gdy interfejs API transportu wykryje, że połączenie fizyczne zostanie przerwane.
  • Połączenie fizyczne odnosi się do fizycznych łączy sieciowych — przewodów, sygnałów bezprzewodowych, routerów itp. — ułatwiający komunikację między komputerem klienckim a komputerem serwera. Połączenie fizyczne musi być obecne w celu ustanowienia połączenia transportowego, a połączenie transportowe musi zostać ustanowione w celu nawiązania połączenia usługi SignalR. Jednak przerwanie połączenia fizycznego nie zawsze powoduje natychmiastowe zakończenie połączenia transportowego ani połączenia signalR, jak wyjaśniono w dalszej części tego tematu.

Na poniższym diagramie połączenie usługi SignalR jest reprezentowane przez warstwę Interfejs API koncentratorów i Interfejs API TrwałePołączenie interfejsu API SignalR, połączenie transportowe jest reprezentowane przez warstwę Transports, a połączenie fizyczne jest reprezentowane przez linie między serwerem a klientami.

Diagram architektury usługi SignalR

Podczas wywoływania Start metody w kliencie signalR udostępniasz kod klienta signalR ze wszystkimi potrzebnymi informacjami w celu nawiązania fizycznego połączenia z serwerem. Kod klienta usługi SignalR używa tych informacji do tworzenia żądania HTTP i ustanawiania połączenia fizycznego, które używa jednej z czterech metod transportu. Jeśli połączenie transportowe nie powiedzie się lub serwer ulegnie awarii, połączenie usługi SignalR nie zniknie natychmiast, ponieważ klient nadal ma informacje potrzebne do automatycznego ponownego ustanowienia nowego połączenia transportowego z tym samym adresem URL usługi SignalR. W tym scenariuszu nie jest zaangażowana żadna interwencja aplikacji użytkownika, a gdy kod klienta usługi SignalR ustanawia nowe połączenie transportowe, nie uruchamia nowego połączenia usługi SignalR. Ciągłość połączenia usługi SignalR jest odzwierciedlana w tym, że identyfikator połączenia, który jest tworzony podczas wywoływania Start metody, nie zmienia się.

Procedura OnReconnected obsługi zdarzeń w centrum jest wykonywana po automatycznym ponownym nawiązaniu połączenia transportowego po utracie. Procedura OnDisconnected obsługi zdarzeń jest wykonywana na końcu połączenia usługi SignalR. Połączenie usługi SignalR może kończyć się dowolnym z następujących sposobów:

  • Jeśli klient wywołuje metodę Stop , do serwera jest wysyłany komunikat zatrzymania, a zarówno klient, jak i serwer natychmiast kończą połączenie usługi SignalR.
  • Po utracie łączności między klientem a serwerem klient próbuje ponownie nawiązać połączenie, a serwer czeka na ponowne nawiązanie połączenia z klientem. Jeśli próby ponownego nawiązania połączenia zakończą się niepowodzeniem, a okres przekroczenia limitu czasu rozłączenia zakończy się zarówno na kliencie, jak i na serwerze połączenie usługi SignalR. Klient przestaje próbować ponownie nawiązać połączenie, a serwer usuwa jego reprezentację połączenia usługi SignalR.
  • Jeśli klient przestanie działać bez możliwości wywołania Stop metody, serwer czeka na ponowne nawiązanie połączenia z klientem, a następnie kończy połączenie usługi SignalR po upływie limitu czasu rozłączenia.
  • Jeśli serwer przestanie działać, klient spróbuje ponownie nawiązać połączenie (ponownie utworzyć połączenie transportowe), a następnie zakończy połączenie usługi SignalR po upływie limitu czasu rozłączenia.

Jeśli nie występują problemy z połączeniem, a aplikacja użytkownika kończy połączenie usługi SignalR przez wywołanie Stop metody, połączenie usługi SignalR i połączenie transportu rozpoczynają się i kończą w tym samym czasie. W poniższych sekcjach opisano bardziej szczegółowo inne scenariusze.

Scenariusze rozłączania transportu

Połączenia fizyczne mogą być powolne lub mogą występować przerwy w łączności. W zależności od czynników, takich jak długość przerwy, połączenie transportowe może zostać przerwane. Usługa SignalR próbuje ponownie ustanowić połączenie transportowe. Czasami interfejs API połączenia transportowego wykrywa przerwy i przerywa połączenie transportowe, a usługa SignalR natychmiast stwierdza, że połączenie zostanie utracone. W innych scenariuszach ani interfejs API połączenia transportowego, ani usługa SignalR nie zorientuje się natychmiast, że łączność została utracona. W przypadku wszystkich transportów z wyjątkiem długiego sondowania klient usługi SignalR używa funkcji o nazwie keepalive , aby sprawdzić, czy nie można wykryć łączności z interfejsem API transportu. Aby uzyskać informacje na temat długich połączeń sondowania, zobacz Ustawienia limitu czasu i utrzymania aktywności w dalszej części tego tematu.

Gdy połączenie jest nieaktywne, serwer okresowo wysyła pakiet keepalive do klienta. Od daty pisania tego artykułu domyślna częstotliwość jest co 10 sekund. Nasłuchiwanie tych pakietów umożliwia klientom określenie, czy wystąpił problem z połączeniem. Jeśli pakiet keepalive nie zostanie odebrany w oczekiwany sposób, po krótkim czasie klient zakłada, że występują problemy z połączeniem, takie jak spowolnienie lub przerwy. Jeśli czas utrzymania aktywności nadal nie jest odbierany po dłuższym czasie, klient zakłada, że połączenie zostało przerwane i rozpoczyna próbę ponownego nawiązania połączenia.

Na poniższym diagramie przedstawiono zdarzenia klienta i serwera, które są zgłaszane w typowym scenariuszu, gdy występują problemy z połączeniem fizycznym, które nie są natychmiast rozpoznawane przez interfejs API transportu. Diagram ma zastosowanie do następujących sytuacji:

  • Transport to WebSockets, forever frame lub zdarzenia wysyłane przez serwer.
  • Istnieją różne okresy przerw w działaniu fizycznego połączenia sieciowego.
  • Interfejs API transportu nie zdaje sobie sprawy z przerw, dlatego usługa SignalR korzysta z funkcji utrzymania aktywności, aby je wykryć.

Rozłączenia transportu

Jeśli klient przechodzi w tryb ponownego nawiązywania połączenia, ale nie może ustanowić połączenia transportowego w ramach limitu czasu rozłączenia, serwer przerywa połączenie usługi SignalR. W takim przypadku serwer wykonuje metodę centrum OnDisconnected i kolejkuje komunikat rozłączenia w celu wysłania do klienta w przypadku, gdy klient będzie zarządzał nawiązaniem połączenia później. Jeśli klient następnie ponownie nawiązie połączenie, otrzyma polecenie disconnect i wywoła metodę Stop . W tym scenariuszu OnReconnected nie jest wykonywane po ponownym połączeniu klienta i OnDisconnected nie jest wykonywane, gdy klient wywołuje metodę Stop. Na poniższym diagramie przedstawiono ten scenariusz.

Zakłócenia transportu — przekroczenie limitu czasu serwera

Zdarzenia okresu istnienia połączenia usługi SignalR, które mogą być wywoływane na kliencie, są następujące:

  • ConnectionSlow zdarzenie klienta.

    Podniesione, gdy od czasu odebrania ostatniego komunikatu lub otrzymania polecenia ping na czas utrzymywania aktywności upłynął wstępnie ustawiony odsetek okresu czasu utrzymania aktywności. Domyślny limit czasu utrzymania aktywności wynosi 2/3 limitu czasu utrzymania. Limit czasu utrzymania na żywo wynosi 20 sekund, więc ostrzeżenie występuje około 13 sekund.

    Domyślnie serwer wysyła polecenia ping keepalive co 10 sekund, a klient sprawdza, czy są wysyłane polecenia ping na żywo co 2 sekundy (jedna trzecia różnicy między wartością limitu czasu utrzymania aktywności a wartością ostrzeżenia o limitie czasu utrzymania aktywności).

    Jeśli interfejs API transportu wie o rozłączeniu, usługa SignalR może zostać poinformowana o rozłączeniu przed upływem okresu ostrzeżenia dotyczącego limitu czasu utrzymania. W takim przypadku ConnectionSlow zdarzenie nie zostanie podniesione, a usługa SignalR przejdzie bezpośrednio do Reconnecting zdarzenia.

  • Reconnecting zdarzenie klienta.

    Zgłoszone, gdy (a) interfejs API transportu wykryje, że połączenie zostanie utracone lub (b) upłynął limit czasu utrzymania od czasu ostatniego komunikatu lub odebrano polecenie ping na żywo. Kod klienta usługi SignalR rozpoczyna próbę ponownego nawiązania połączenia. To zdarzenie można obsłużyć, jeśli aplikacja ma podjąć jakąś akcję po utracie połączenia transportowego. Domyślny okres limitu czasu utrzymania na żywo wynosi obecnie 20 sekund.

    Jeśli kod klienta próbuje wywołać metodę koncentratora, gdy usługa SignalR jest w trybie ponownego łączenia, usługa SignalR spróbuje wysłać polecenie. W większości przypadków takie próby nie powiedzą się, ale w pewnych okolicznościach mogą odnieść sukces. W przypadku zdarzeń wysyłanych przez serwer, na zawsze ramek i długich transportów sondowania usługa SignalR używa dwóch kanałów komunikacyjnych, jeden używany przez klienta do wysyłania komunikatów i jeden używany do odbierania komunikatów. Kanał używany do odbierania jest trwale otwarty i jest to kanał, który jest zamknięty po przerwaniu połączenia fizycznego. Kanał używany do wysyłania pozostaje dostępny, więc jeśli łączność fizyczna zostanie przywrócona, wywołanie metody od klienta do serwera może zakończyć się pomyślnie przed ponownym nawiązaniem kanału odbierania. Wartość zwracana nie zostanie odebrana, dopóki usługa SignalR nie otworzy ponownie kanału używanego do odbierania.

  • Reconnected zdarzenie klienta.

    Podniesione po ponownym utworzeniu połączenia transportowego. Procedura OnReconnected obsługi zdarzeń w centrum jest wykonywana.

  • Closed zdarzenie klienta (disconnected zdarzenie w języku JavaScript).

    Podniesiono, gdy okres przekroczenia limitu czasu rozłączenia wygasa, gdy kod klienta usługi SignalR próbuje ponownie nawiązać połączenie po utracie połączenia transportowego. Domyślny limit czasu rozłączenia wynosi 30 sekund. (To zdarzenie jest również wywoływane, gdy połączenie kończy się, ponieważ metoda jest wywoływana Stop ).

Przerwy w połączeniu transportowym, które nie są wykrywane przez interfejs API transportu i nie opóźniają odbioru poleceń ping keepalive z serwera przez dłuższy niż okres ostrzegawczy limitu czasu utrzymania na żywo, może nie spowodować podniesienia żadnych zdarzeń okresu istnienia połączenia.

Niektóre środowiska sieciowe celowo zamykają bezczynne połączenia, a inną funkcją pakietów keepalive jest pomoc w zapobieganiu temu, pozwalając tym sieciom wiedzieć, że połączenie usługi SignalR jest używane. W skrajnych przypadkach domyślna częstotliwość poleceń ping keepalive może być niewystarczająca, aby zapobiec zamkniętym połączeniom. W takim przypadku można skonfigurować polecenia ping keepalive do wysyłania częściej. Aby uzyskać więcej informacji, zobacz Limit czasu i ustawienia keepalive w dalszej części tego tematu.

Uwaga

Ważne

Sekwencja zdarzeń opisanych tutaj nie jest gwarantowana. Usługa SignalR podejmuje każdą próbę podniesienia zdarzeń okresu istnienia połączenia w przewidywalny sposób zgodnie z tym schematem, ale istnieje wiele odmian zdarzeń sieciowych i wiele sposobów obsługi podstawowych struktur komunikacyjnych, takich jak interfejsy API transportu. Na przykład Reconnected zdarzenie może nie zostać zgłoszone, gdy klient ponownie się połączy lub OnConnected program obsługi na serwerze może zostać uruchomiony, gdy próba nawiązania połączenia nie powiedzie się. W tym temacie opisano tylko efekty, które zwykle byłyby generowane przez pewne typowe okoliczności.

Scenariusze rozłączenia klienta

W kliencie przeglądarki kod klienta usługi SignalR, który utrzymuje połączenie usługi SignalR, jest uruchamiany w kontekście języka JavaScript strony internetowej. Dlatego połączenie usługi SignalR musi zakończyć się po przejściu z jednej strony do innej i dlatego istnieje wiele połączeń z wieloma identyfikatorami połączeń, jeśli łączysz się z wielu okien przeglądarki lub kart. Gdy użytkownik zamknie okno przeglądarki lub kartę albo przejdzie do nowej strony lub odświeży stronę, połączenie usługi SignalR natychmiast się kończy, ponieważ kod klienta usługi SignalR obsługuje to zdarzenie przeglądarki i wywołuje metodę Stop . W tych scenariuszach lub na dowolnej platformie klienta, gdy aplikacja wywołuje Stop metodę, OnDisconnected program obsługi zdarzeń jest wykonywany natychmiast na serwerze, a klient zgłasza Closed zdarzenie (zdarzenie ma nazwę disconnected w języku JavaScript).

Jeśli aplikacja kliencka lub komputer, na którym jest uruchomiona, ulega awarii lub przechodzi w stan uśpienia (na przykład gdy użytkownik zamknie laptopa), serwer nie jest informowany o tym, co się stało. Jeśli serwer wie, utrata klienta może być spowodowana przerwą w łączności, a klient może próbować ponownie nawiązać połączenie. W związku z tym w tych scenariuszach serwer czeka, aby dać klientowi szansę na ponowne nawiązanie połączenia i OnDisconnected nie zostanie wykonany do momentu wygaśnięcia limitu czasu rozłączenia (domyślnie około 30 sekund). Na poniższym diagramie przedstawiono ten scenariusz.

Niepowodzenie komputera klienckiego

Scenariusze rozłączenia serwera

Gdy serwer przechodzi w tryb offline — uruchamia się ponownie, kończy się niepowodzeniem, odtwarzaniem domeny aplikacji itp. — wynik może być podobny do utraconego połączenia lub interfejs API transportu i signalR może natychmiast wiedzieć, że serwer zniknął, a usługa SignalR może zacząć próbować ponownie nawiązać połączenie bez zgłaszania ConnectionSlow zdarzenia. Jeśli klient przejdzie w tryb ponownego połączenia, a jeśli serwer odzyska lub uruchomi ponownie lub nowy serwer zostanie przełączony w tryb online przed wygaśnięciem limitu czasu rozłączenia, klient ponownie połączy się z przywróconym lub nowym serwerem. W takim przypadku połączenie usługi SignalR będzie kontynuowane na kliencie, a Reconnected zdarzenie jest wywoływane. Na pierwszym serwerze OnDisconnected nigdy nie jest wykonywany, a na nowym serwerze jest wykonywany, OnReconnected chociaż OnConnected nigdy wcześniej nie został wykonany dla tego klienta na tym serwerze. (Efekt jest taki sam, jeśli klient ponownie nawiąże połączenie z tym samym serwerem po ponownym uruchomieniu lub ponownym uruchomieniu domeny aplikacji, ponieważ po ponownym uruchomieniu serwera nie ma pamięci wcześniejszej aktywności połączenia). Na poniższym diagramie założono, że interfejs API transportu natychmiast zdaje sobie sprawę z utraconego połączenia, więc ConnectionSlow zdarzenie nie jest zgłaszane.

Niepowodzenie serwera i ponowne nawiązywanie połączenia

Jeśli serwer nie stanie się dostępny w ramach limitu czasu rozłączenia, połączenie usługi SignalR kończy się. W tym scenariuszu Closed zdarzenie (disconnected w klientach JavaScript) jest wywoływane na kliencie, ale OnDisconnected nigdy nie jest wywoływane na serwerze. Na poniższym diagramie założono, że interfejs API transportu nie zdaje sobie sprawy z utraconego połączenia, dlatego jest wykrywany przez funkcję keepalive usługi SignalR i ConnectionSlow zgłaszane jest zdarzenie.

Niepowodzenie serwera i przekroczenie limitu czasu

Limit czasu i ustawienia keepalive

Domyślne ConnectionTimeoutwartości , i KeepAlive są odpowiednie dla większości scenariuszy, DisconnectTimeoutale można je zmienić, jeśli środowisko ma specjalne potrzeby. Jeśli na przykład środowisko sieciowe zamyka połączenia bezczynne przez 5 sekund, może być konieczne zmniejszenie wartości keepalive.

Connectiontimeout

To ustawienie reprezentuje czas, przez jaki połączenie transportowe jest otwarte i czeka na odpowiedź przed jego zamknięciem i otwarciem nowego połączenia. Wartość domyślna to 110 sekund.

To ustawienie ma zastosowanie tylko wtedy, gdy funkcja keepalive jest wyłączona, co zwykle ma zastosowanie tylko do długiego transportu sondowania. Na poniższym diagramie przedstawiono wpływ tego ustawienia na długie sondowanie połączenia transportowego.

Długie połączenie transportowe sondowania

DisconnectTimeout

To ustawienie reprezentuje czas oczekiwania po utracie połączenia transportowego przed podniesieniem Disconnected zdarzenia. Wartość domyślna to 30 sekund. Po ustawieniu parametru DisconnectTimeoutKeepAlive jest automatycznie ustawiana wartość 1/3 DisconnectTimeout wartości.

Keepalive

To ustawienie reprezentuje czas oczekiwania przed wysłaniem pakietu keepalive przez bezczynne połączenie. Wartość domyślna to 10 sekund. Ta wartość nie może być większa niż 1/3 DisconnectTimeout wartości.

Jeśli chcesz ustawić zarówno , jak DisconnectTimeout i KeepAlive, ustaw KeepAlive po DisconnectTimeout. KeepAlive W przeciwnym razie ustawienie zostanie zastąpione, gdy DisconnectTimeout ustawienie zostanie automatycznie ustawiona KeepAlive na 1/3 wartości limitu czasu.

Jeśli chcesz wyłączyć funkcję keepalive, ustaw wartość KeepAlive null. Funkcja Keepalive jest automatycznie wyłączona dla długiego transportu sondowania.

Jak zmienić limit czasu i ustawienia keepalive

Aby zmienić wartości domyślne dla tych ustawień, ustaw je w Application_Start pliku Global.asax , jak pokazano w poniższym przykładzie. Wartości wyświetlane w przykładowym kodzie są takie same jak wartości domyślne.

protected void Application_Start(object sender, EventArgs e)
{
    // Make long polling connections wait a maximum of 110 seconds for a
    // response. When that time expires, trigger a timeout command and
    // make the client reconnect.
    GlobalHost.Configuration.ConnectionTimeout = TimeSpan.FromSeconds(110);
    
    // Wait a maximum of 30 seconds after a transport connection is lost
    // before raising the Disconnected event to terminate the SignalR connection.
    GlobalHost.Configuration.DisconnectTimeout = TimeSpan.FromSeconds(30);
    
    // For transports other than long polling, send a keepalive packet every
    // 10 seconds. 
    // This value must be no more than 1/3 of the DisconnectTimeout value.
    GlobalHost.Configuration.KeepAlive = TimeSpan.FromSeconds(10);
}

Jak powiadomić użytkownika o rozłączeniach

W niektórych aplikacjach możesz wyświetlić użytkownikowi komunikat, gdy występują problemy z łącznością. Istnieje kilka opcji, aby dowiedzieć się, jak i kiedy to zrobić. Poniższe przykłady kodu są przeznaczone dla klienta JavaScript przy użyciu wygenerowanego serwera proxy.

  • Obsługa zdarzenia w celu wyświetlenia komunikatu connectionSlow , gdy tylko usługa SignalR jest świadoma problemów z połączeniem, zanim przejdzie do trybu ponownego połączenia.

    $.connection.hub.connectionSlow(function() {
    notifyUserOfConnectionProblem(); // Your function to notify user.
});

  • Obsługa zdarzenia w celu wyświetlenia komunikatu reconnecting , gdy usługa SignalR jest świadoma rozłączenia i przechodzi w tryb ponownego nawiązywania połączenia.

    $.connection.hub.reconnecting(function() {
    notifyUserOfTryingToReconnect(); // Your function to notify user.
});

  • Obsługa zdarzenia w celu wyświetlenia komunikatu po przekroczeniu disconnected limitu czasu próby ponownego nawiązania połączenia. W tym scenariuszu jedynym sposobem ponownego nawiązania połączenia z serwerem jest ponowne uruchomienie połączenia usługi SignalR przez wywołanie Start metody , co spowoduje utworzenie nowego identyfikatora połączenia. Poniższy przykładowy kod używa flagi, aby upewnić się, że powiadomienie jest wystawiane dopiero po ponownym połączeniu limitu czasu, a nie po normalnym zakończeniu połączenia usługi SignalR spowodowanego wywołaniem Stop metody.

    var tryingToReconnect = false;

$.connection.hub.reconnecting(function() {
    tryingToReconnect = true;
});

$.connection.hub.reconnected(function() {
    tryingToReconnect = false;
});

$.connection.hub.disconnected(function() {
    if(tryingToReconnect) {
        notifyUserOfDisconnect(); // Your function to notify user.
    }
});

Jak stale ponownie nawiązować połączenie

W niektórych aplikacjach możesz chcieć automatycznie ponownie nawiązać połączenie po jego utracie, a próba ponownego nawiązania połączenia przekroczyła limit czasu. W tym celu można wywołać metodę Start z Closed programu obsługi zdarzeń (disconnected program obsługi zdarzeń na klientach JavaScript). Możesz poczekać pewien czas przed wywołaniem wywołania Start , aby uniknąć zbyt częstego wykonywania tej czynności, gdy serwer lub połączenie fizyczne są niedostępne. Poniższy przykład kodu dotyczy klienta JavaScript przy użyciu wygenerowanego serwera proxy.

$.connection.hub.disconnected(function() {
   setTimeout(function() {
       $.connection.hub.start();
   }, 5000); // Restart connection after 5 seconds.
});

Potencjalny problem, który należy wziąć pod uwagę w klientach mobilnych, polega na tym, że ciągłe próby ponownego połączenia, gdy serwer lub połączenie fizyczne nie jest dostępne, może spowodować niepotrzebne opróżnienie baterii.

Jak odłączyć klienta w kodzie serwera

Usługa SignalR w wersji 1.1.1 nie ma wbudowanego interfejsu API serwera do odłączania klientów. Istnieją plany dodawania tej funkcji w przyszłości. W bieżącej wersji usługi SignalR najprostszym sposobem odłączenia klienta od serwera jest zaimplementowanie metody rozłączenia na kliencie i wywołanie tej metody z serwera. Poniższy przykładowy kod przedstawia metodę rozłączenia klienta JavaScript przy użyciu wygenerowanego serwera proxy.

var myHubProxy = $.connection.myHub
myHubProxy.client.stopClient = function() {
    $.connection.hub.stop();
};

Ostrzeżenie

Zabezpieczenia — ani ta metoda rozłączania klientów, ani proponowanego wbudowanego interfejsu API nie rozwiąże scenariusza zhakowanych klientów, którzy uruchamiają złośliwy kod, ponieważ klienci mogą ponownie nawiązać połączenie lub kod zhakowany może usunąć stopClient metodę lub zmienić to, co robi. Odpowiednie miejsce do wdrożenia ochrony stanowej typu "odmowa usługi" (DOS) nie znajduje się w strukturze ani w warstwie serwera, ale raczej w infrastrukturze frontonu.