Grundlegendes und Behandeln von Verbindungslebensdauerereignissen in SignalR 1.x

von Patrick Fletcher, Tom Dykstra

Warnung

Diese Dokumentation ist nicht für die neueste Version von SignalR vorgesehen. Sehen Sie sich ASP.NET Core SignalR an.

Dieser Artikel bietet eine Übersicht über die SignalR-Verbindungs-, Wiederverbindungs- und Trennungsereignisse, die Sie behandeln können, sowie die Timeout- und Keepalive-Einstellungen, die Sie konfigurieren können.

In diesem Artikel wird davon ausgegangen, dass Sie bereits über Kenntnisse zu SignalR- und Verbindungslebensdauerereignissen verfügen. Eine Einführung in SignalR finden Sie unter SignalR – Übersicht – Erste Schritte. Listen der Ereignisse für die Verbindungslebensdauer finden Sie in den folgenden Ressourcen:

• Behandeln von Verbindungslebensdauerereignissen in der Hub-Klasse
• Behandeln von Verbindungslebensdauerereignissen in JavaScript-Clients
• Behandeln von Verbindungslebensdauerereignissen in .NET-Clients

Überblick

Dieser Artikel enthält folgende Abschnitte:

• Terminologie und Szenarien für die Verbindungslebensdauer

  • SignalR-Verbindungen, Transportverbindungen und physische Verbindungen
  • Szenarien für die Trennung von Transporten
  • Szenarien für die Clienttrennung
  • Servertrennungsszenarien

• Timeout- und Keepalive-Einstellungen

  • ConnectionTimeout
  • DisconnectTimeout
  • KeepAlive
  • Ändern von Timeout- und Keepalive-Einstellungen

• So benachrichtigen Sie den Benutzer über Trennungen

• Fortlaufendes Wiederherstellen der Verbindung

• Trennen eines Clients im Servercode

Links zu API-Referenzthemen beziehen sich auf die .NET 4.5-Version der API. Wenn Sie .NET 4 verwenden, lesen Sie die .NET 4-Version der API-Themen.

Terminologie und Szenarien für die Verbindungslebensdauer

Der OnReconnected Ereignishandler in einem SignalR Hub kann für einen bestimmten Client direkt nach OnConnected , aber nicht nach ausgeführt OnDisconnected werden. Der Grund, warum Sie eine erneute Verbindung ohne Trennung haben können, ist, dass es mehrere Möglichkeiten gibt, wie das Wort "Verbindung" in SignalR verwendet wird.

SignalR-Verbindungen, Transportverbindungen und physische Verbindungen

In diesem Artikel wird zwischen SignalR-Verbindungen, Transportverbindungen und physischen Verbindungen unterschieden:

• SignalR-Verbindung bezieht sich auf eine logische Beziehung zwischen einem Client und einer Server-URL, die von der SignalR-API verwaltet und durch eine Verbindungs-ID eindeutig identifiziert wird. Die Daten zu dieser Beziehung werden von SignalR verwaltet und zum Herstellen einer Transportverbindung verwendet. Die Beziehung endet, und SignalR entsorgt die Daten, wenn der Client die Stop -Methode aufruft oder ein Timeoutlimit erreicht wird, während SignalR versucht, eine verlorene Transportverbindung wiederherzustellen.
• Transportverbindung bezieht sich auf eine logische Beziehung zwischen einem Client und einem Server, die von einer der vier Transport-APIs verwaltet wird: WebSockets, vom Server gesendete Ereignisse, forever frame oder long polling. SignalR verwendet die Transport-API, um eine Transportverbindung zu erstellen, und die Transport-API hängt vom Vorhandensein einer physischen Netzwerkverbindung ab, um die Transportverbindung zu erstellen. Die Transportverbindung endet, wenn SignalR sie beendet oder wenn die Transport-API erkennt, dass die physische Verbindung unterbrochen ist.
• Physische Verbindung bezieht sich auf die physischen Netzwerkverbindungen – Kabel, Drahtlose Signale, Router usw. – die die Kommunikation zwischen einem Clientcomputer und einem Servercomputer erleichtern. Die physische Verbindung muss vorhanden sein, um eine Transportverbindung herzustellen, und eine Transportverbindung muss hergestellt werden, um eine SignalR-Verbindung herzustellen. Das Unterbrechen der physischen Verbindung beendet jedoch nicht immer sofort die Transportverbindung oder die SignalR-Verbindung, wie weiter unten in diesem Thema erläutert wird.

Im folgenden Diagramm wird die SignalR-Verbindung durch die Hubs-API und die SignalR-Ebene der PersistentConnection-API dargestellt, die Transportverbindung wird durch die Transportebene und die physische Verbindung durch die Zeilen zwischen dem Server und den Clients dargestellt.

Wenn Sie die Start -Methode in einem SignalR-Client aufrufen, geben Sie signalR-Clientcode mit allen Informationen an, die zum Herstellen einer physischen Verbindung mit einem Server benötigt werden. Der SignalR-Clientcode verwendet diese Informationen, um eine HTTP-Anforderung zu erstellen und eine physische Verbindung herzustellen, die eine der vier Transportmethoden verwendet. Wenn die Transportverbindung fehlschlägt oder der Server ausfällt, wird die SignalR-Verbindung nicht sofort getrennt, da der Client noch über die Informationen verfügt, die er benötigt, um automatisch eine neue Transportverbindung mit derselben SignalR-URL herzustellen. In diesem Szenario ist kein Eingriff der Benutzeranwendung beteiligt, und wenn der SignalR-Clientcode eine neue Transportverbindung herstellt, wird keine neue SignalR-Verbindung gestartet. Die Kontinuität der SignalR-Verbindung spiegelt sich darin wider, dass sich die Verbindungs-ID, die beim Aufrufen der Start -Methode erstellt wird, nicht ändert.

Der OnReconnected Ereignishandler auf dem Hub wird ausgeführt, wenn eine Transportverbindung nach dem Verlust automatisch wiederhergestellt wird. Der OnDisconnected Ereignishandler wird am Ende einer SignalR-Verbindung ausgeführt. Eine SignalR-Verbindung kann auf eine der folgenden Arten enden:

• Wenn der Client die Stop -Methode aufruft, wird eine Stoppmeldung an den Server gesendet, und sowohl der Client als auch der Server beenden die SignalR-Verbindung sofort.
• Nachdem die Verbindung zwischen Client und Server unterbrochen wurde, versucht der Client, die Verbindung wiederherzustellen, und der Server wartet, bis der Client die Verbindung wiederhergestellt hat. Wenn die Versuche, die Verbindung wiederherzustellen, nicht erfolgreich sind und das Zeitlimit für die Trennung endet, beenden sowohl der Client als auch der Server die SignalR-Verbindung. Der Client versucht nicht mehr, die Verbindung wiederherzustellen, und der Server entsorgt seine Darstellung der SignalR-Verbindung.
• Wenn die Ausführung des Clients beendet wird, ohne die Stop -Methode aufrufen zu können, wartet der Server darauf, dass der Client erneut eine Verbindung herstellt, und beendet dann die SignalR-Verbindung nach dem Zeitlimit für die Trennung.
• Wenn die Ausführung des Servers beendet wird, versucht der Client, die Verbindung wiederherzustellen (erstellen Sie die Transportverbindung erneut) und beendet dann die SignalR-Verbindung nach dem Timeout für die Trennung.

Wenn keine Verbindungsprobleme auftreten und die Benutzeranwendung die SignalR-Verbindung durch Aufrufen der Stop -Methode beendet, beginnen und enden die SignalR-Verbindung und die Transportverbindung ungefähr zur gleichen Zeit. In den folgenden Abschnitten werden die anderen Szenarien ausführlicher beschrieben.

Szenarien für die Trennung von Transporten

Physische Verbindungen sind möglicherweise langsam, oder es kann zu Unterbrechungen der Konnektivität kommen. Abhängig von Faktoren wie der Dauer der Unterbrechung kann die Transportverbindung gelöscht werden. SignalR versucht dann, die Transportverbindung erneut herzustellen. Manchmal erkennt die Transportverbindungs-API die Unterbrechung und löscht die Transportverbindung, und SignalR erkennt sofort, dass die Verbindung unterbrochen ist. In anderen Szenarien wird weder der Transportverbindungs-API noch SignalR sofort bewusst, dass die Konnektivität unterbrochen wurde. Für alle Transporte mit Ausnahme von langen Abrufvorgängen verwendet der SignalR-Client eine Funktion namens keepalive , um auf Konnektivitätsverluste zu überprüfen, die die Transport-API nicht erkennen kann. Informationen zu langen Abrufverbindungen finden Sie weiter unten in diesem Thema unter Timeout- und Keepalive-Einstellungen .

Wenn eine Verbindung inaktiv ist, sendet der Server in regelmäßigen Abständen ein Keepalive-Paket an den Client. Ab dem Datum, an dem dieser Artikel geschrieben wird, ist die Standardhäufigkeit alle 10 Sekunden. Durch das Lauschen auf diese Pakete können Clients erkennen, ob ein Verbindungsproblem vorliegt. Wenn ein Keepalive-Paket nicht bei Bedarf empfangen wird, geht der Client nach kurzer Zeit davon aus, dass Verbindungsprobleme wie Langsamkeit oder Unterbrechungen vorliegen. Wenn keepalive nach längerer Zeit immer noch nicht empfangen wird, geht der Client davon aus, dass die Verbindung unterbrochen wurde, und beginnt mit dem Versuch, die Verbindung wiederherzustellen.

Das folgende Diagramm veranschaulicht die Client- und Serverereignisse, die in einem typischen Szenario ausgelöst werden, wenn Probleme mit der physischen Verbindung auftreten, die von der Transport-API nicht sofort erkannt werden. Das Diagramm gilt für die folgenden Umstände:

• Der Transport ist WebSockets, Forever Frame oder vom Server gesendete Ereignisse.
• Es gibt unterschiedliche Unterbrechungszeiten bei der physischen Netzwerkverbindung.
• Die Transport-API erkennt die Unterbrechungen nicht, sodass SignalR auf die Keepalive-Funktionalität angewiesen ist, um sie zu erkennen.

Wenn der Client in den Modus für die erneute Verbindung wechselt, aber innerhalb des Timeoutlimits für die Trennung keine Transportverbindung herstellen kann, beendet der Server die SignalR-Verbindung. In diesem Fall führt der Server die -Methode des Hubs OnDisconnected aus und stellt eine Nachricht zum Trennen in die Warteschlange, die an den Client gesendet werden soll, falls der Client später eine Verbindung herstellen kann. Wenn der Client dann die Verbindung wiederhergestellt, empfängt er den Befehl disconnect und ruft die Stop -Methode auf. In diesem Szenario wird nicht ausgeführt, OnReconnected wenn der Client erneut eine Verbindung hergestellt hat, und OnDisconnected wird nicht ausgeführt, wenn der Client aufruft Stop. Das folgende Diagramm veranschaulicht dieses Szenario.

Die SignalR-Verbindungslebensdauerereignisse, die auf dem Client ausgelöst werden können, lauten wie folgt:

• ConnectionSlow Clientereignis.

  Wird ausgelöst, wenn ein voreingestellter Anteil des Keepalive-Timeoutzeitraums seit dem Empfang der letzten Nachricht oder des keepaliven Pings vergangen ist. Der standardmäßige Warnzeitraum für das keepalive Timeout beträgt 2/3 des Keepalive-Timeouts. Das Keepalive-Timeout beträgt 20 Sekunden, sodass die Warnung bei etwa 13 Sekunden auftritt.

  Standardmäßig sendet der Server keepalive Pings alle 10 Sekunden, und der Client überprüft etwa alle 2 Sekunden auf keepalive Pings (ein Drittel des Unterschieds zwischen dem Keepalive-Timeoutwert und dem Keepalive Timeout-Warnwert).

  Wenn die Transport-API eine Trennung erkennt, wird SignalR möglicherweise über die Trennung informiert, bevor der warnende Timeoutzeitraum verstreicht. In diesem Fall würde das ConnectionSlow Ereignis nicht ausgelöst, und SignalR würde direkt an das Reconnecting Ereignis gesendet.

• Reconnecting Clientereignis.

  Wird ausgelöst, wenn (a) die Transport-API erkennt, dass die Verbindung unterbrochen ist, oder (b) der keepalive Timeoutzeitraum seit dem Empfang der letzten Nachricht oder des keepaliven Pings abgelaufen ist. Der SignalR-Clientcode versucht, die Verbindung wiederherzustellen. Sie können dieses Ereignis behandeln, wenn Ihre Anwendung eine Aktion ausführen soll, wenn eine Transportverbindung unterbrochen wird. Der standardmäßige Keepalive-Timeoutzeitraum beträgt derzeit 20 Sekunden.

  Wenn Ihr Clientcode versucht, eine Hub-Methode aufzurufen, während SignalR sich im Modus für die erneute Verbindung befindet, versucht SignalR, den Befehl zu senden. In den meisten Fällen werden solche Versuche fehlschlagen, aber unter bestimmten Umständen können sie erfolgreich sein. Für die vom Server gesendeten Ereignisse, für immer frame und lange Abruftransporte verwendet SignalR zwei Kommunikationskanäle, einen, den der Client zum Senden von Nachrichten verwendet, und einen, der zum Empfangen von Nachrichten verwendet wird. Der für den Empfang verwendete Kanal ist der dauerhaft geöffnete Kanal, der geschlossen wird, wenn die physische Verbindung unterbrochen wird. Der für das Senden verwendete Kanal bleibt verfügbar. Wenn also die physische Konnektivität wiederhergestellt wird, kann ein Methodenaufruf vom Client an den Server erfolgreich sein, bevor der Empfangskanal wiederhergestellt wird. Der Rückgabewert wird erst empfangen, wenn SignalR den für den Empfang verwendeten Kanal erneut öffnet.

• Reconnected Clientereignis.

  Wird ausgelöst, wenn die Transportverbindung wiederhergestellt wird. Der OnReconnected Ereignishandler im Hub wird ausgeführt.

• Closed Clientereignis (disconnected Ereignis in JavaScript).

  Wird ausgelöst, wenn der Timeoutzeitraum für die Trennung abläuft, während der SignalR-Clientcode versucht, die Verbindung nach dem Verlust der Transportverbindung wiederherzustellen. Das Standardmäßige Trennungstimeout beträgt 30 Sekunden. (Dieses Ereignis wird auch ausgelöst, wenn die Verbindung beendet wird, da die Stop -Methode aufgerufen wird.)

Transportverbindungsunterbrechungen, die von der Transport-API nicht erkannt werden und den Empfang von keepalive Pings vom Server nicht länger als den warnenden Timeoutzeitraum verzögern, führen möglicherweise nicht dazu, dass Ereignisse für die Verbindungslebensdauer ausgelöst werden.

Einige Netzwerkumgebungen schließen absichtlich Verbindungen im Leerlauf, und eine weitere Funktion der Keepalive-Pakete besteht darin, dies zu verhindern, indem sie diese Netzwerke darüber informieren, dass eine SignalR-Verbindung verwendet wird. In extremen Fällen reicht die Standardhäufigkeit von Keepalive-Pings möglicherweise nicht aus, um geschlossene Verbindungen zu verhindern. In diesem Fall können Sie keepalive Pings so konfigurieren, dass sie häufiger gesendet werden. Weitere Informationen finden Sie weiter unten in diesem Thema unter Timeout- und Keepalive-Einstellungen .

Hinweis

Wichtig

Die hier beschriebene Abfolge von Ereignissen ist nicht garantiert. SignalR versucht, Ereignisse für die Verbindungslebensdauer gemäß diesem Schema auf vorhersagbare Weise auszulösen, es gibt jedoch viele Varianten von Netzwerkereignissen und viele Möglichkeiten, wie zugrunde liegende Kommunikationsframeworks wie Transport-APIs sie behandeln. Beispielsweise wird das Reconnected Ereignis möglicherweise nicht ausgelöst, wenn der Client erneut eine Verbindung herstellt, oder der OnConnected Handler auf dem Server wird ausgeführt, wenn der Versuch, eine Verbindung herzustellen, nicht erfolgreich ist. In diesem Thema werden nur die Auswirkungen beschrieben, die normalerweise durch bestimmte typische Umstände erzeugt würden.

Szenarien für die Clienttrennung

In einem Browserclient wird der SignalR-Clientcode, der eine SignalR-Verbindung verwaltet, im JavaScript-Kontext einer Webseite ausgeführt. Aus diesem Grund muss die SignalR-Verbindung beendet werden, wenn Sie von einer Seite zu einer anderen navigieren, und aus diesem Grund haben Sie mehrere Verbindungen mit mehreren Verbindungs-IDs, wenn Sie über mehrere Browserfenster oder Registerkarten eine Verbindung herstellen. Wenn der Benutzer ein Browserfenster oder eine Registerkarte schließt oder zu einer neuen Seite navigiert oder die Seite aktualisiert, wird die SignalR-Verbindung sofort beendet, da der SignalR-Clientcode dieses Browserereignis für Sie verarbeitet und die Stop -Methode aufruft. In diesen Szenarien oder auf einer beliebigen Clientplattform, wenn Ihre Anwendung die Stop -Methode aufruft, wird der OnDisconnected Ereignishandler sofort auf dem Server ausgeführt, und der Client löst das Closed Ereignis aus (das Ereignis wird in JavaScript benannt disconnected ).

Wenn eine Clientanwendung oder der Computer, auf dem sie ausgeführt wird, abstürzt oder in den Standbymodus wechselt (z. B. wenn der Benutzer den Laptop schließt), wird der Server nicht über das Geschehen informiert. Soweit der Server weiß, kann der Verlust des Clients auf eine Verbindungsunterbrechung zurückzuführen sein, und der Client versucht möglicherweise, die Verbindung wiederherzustellen. Daher wartet der Server in diesen Szenarien, um dem Client die Möglichkeit zu geben, die Verbindung wiederherzustellen, und OnDisconnected wird erst ausgeführt, wenn der Zeitraum für die Trennung abläuft (standardmäßig etwa 30 Sekunden). Das folgende Diagramm veranschaulicht dieses Szenario.

Servertrennungsszenarien

Wenn ein Server offline geschaltet wird, wird er neu gestartet, schlägt fehl, die App-Domäne wird wiederverwendet usw. – Das Ergebnis ähnelt möglicherweise einer unterbrochenen Verbindung, oder die Transport-API und SignalR wissen möglicherweise sofort, dass der Server nicht mehr vorhanden ist, und SignalR versucht möglicherweise, die Verbindung wiederherzustellen, ohne das ConnectionSlow Ereignis auszulösen. Wenn der Client in den Verbindungswiederholungsmodus wechselt und der Server wiederhergestellt oder neu gestartet wird oder ein neuer Server online geschaltet wird, bevor der Timeoutzeitraum für die Trennung abläuft, stellt der Client wieder eine Verbindung mit dem wiederhergestellten oder neuen Server her. In diesem Fall wird die SignalR-Verbindung auf dem Client fortgesetzt, und das Reconnected Ereignis wird ausgelöst. Auf dem ersten Server OnDisconnected wird nie ausgeführt, und auf dem neuen Server wird ausgeführt, OnReconnected obwohl OnConnected noch nie zuvor für diesen Client auf diesem Server ausgeführt wurde. (Der Effekt ist identisch, wenn der Client nach einem Neustart oder einer Wiederverwertung der App-Domäne wieder eine Verbindung mit demselben Server herstellt, da der Server beim Neustarten über keinen Arbeitsspeicher der vorherigen Verbindungsaktivität verfügt.) Im folgenden Diagramm wird davon ausgegangen, dass die Transport-API die unterbrochene Verbindung sofort erkennt, sodass das ConnectionSlow Ereignis nicht ausgelöst wird.

Wenn ein Server innerhalb des Timeoutzeitraums für die Trennung nicht verfügbar ist, wird die SignalR-Verbindung beendet. In diesem Szenario wird das Closed -Ereignis (disconnected in JavaScript-Clients) auf dem Client ausgelöst, aber OnDisconnected nie auf dem Server aufgerufen. Im folgenden Diagramm wird davon ausgegangen, dass die Transport-API die unterbrochene Verbindung nicht erkennt, sodass sie von der Keepalive-Funktion von SignalR erkannt wird und das ConnectionSlow Ereignis ausgelöst wird.

Timeout- und Keepalive-Einstellungen

Die Standardwerte ConnectionTimeout, DisconnectTimeoutund KeepAlive sind für die meisten Szenarien geeignet, können jedoch geändert werden, wenn Ihre Umgebung besondere Anforderungen hat. Wenn Ihre Netzwerkumgebung beispielsweise Verbindungen, die sich im Leerlauf befinden, fünf Sekunden lang schließt, müssen Sie möglicherweise den Keepalive-Wert verringern.

ConnectionTimeout

Diese Einstellung stellt die Zeitspanne dar, die eine Transportverbindung geöffnet lässt und auf eine Antwort wartet, bevor sie geschlossen und eine neue Verbindung geöffnet wird. Der Standardwert ist 110 Sekunden.

Diese Einstellung gilt nur, wenn die Keepalive-Funktionalität deaktiviert ist, was normalerweise nur für den langen Abruftransport gilt. Das folgende Diagramm veranschaulicht die Auswirkungen dieser Einstellung auf eine lange Abruf-Transportverbindung.

DisconnectTimeout

Diese Einstellung stellt die Zeit dar, die gewartet werden muss, nachdem eine Transportverbindung unterbrochen wurde, bevor das Disconnected Ereignis ausgelöst wird. Der Standardwert ist 30 Sekunden. Wenn Sie festlegen DisconnectTimeout, KeepAlive wird automatisch auf 1/3 des DisconnectTimeout Werts festgelegt.

KeepAlive

Diese Einstellung stellt die Zeit dar, die vor dem Senden eines Keepalive-Pakets über eine Verbindung im Leerlauf gewartet werden muss. Der Standardwert beträgt 10 Sekunden. Dieser Wert darf nicht mehr als 1/3 des DisconnectTimeout Werts sein.

Wenn Sie sowohl als KeepAliveauch DisconnectTimeout festlegen möchten, legen Sie nach DisconnectTimeoutfestKeepAlive. Andernfalls wird Ihre KeepAlive Einstellung überschrieben, wenn DisconnectTimeout automatisch auf 1/3 des Timeoutwerts festgelegt KeepAlive wird.

Wenn Sie keepalive Funktionen deaktivieren möchten, legen Sie auf NULL fest KeepAlive . Keepalive-Funktionalität wird für den langen Abruftransport automatisch deaktiviert.

Ändern von Timeout- und Keepalive-Einstellungen

Um die Standardwerte für diese Einstellungen zu ändern, legen Sie sie in Application_Start Der Datei Global.asax fest, wie im folgenden Beispiel gezeigt. Die im Beispielcode angezeigten Werte sind mit den Standardwerten identisch.

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);
}

So benachrichtigen Sie den Benutzer über Trennungen

In einigen Anwendungen möchten Sie dem Benutzer möglicherweise eine Meldung anzeigen, wenn Konnektivitätsprobleme auftreten. Sie haben mehrere Möglichkeiten, wie und wann dies zu tun ist. Die folgenden Codebeispiele gelten für einen JavaScript-Client, der den generierten Proxy verwendet.

• Behandeln Sie das connectionSlow Ereignis, um eine Meldung anzuzeigen, sobald SignalR von Verbindungsprobleme kenntnis hat, bevor es in den Modus für die erneute Verbindung wechselt.

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

• Behandeln Sie das reconnecting Ereignis, um eine Meldung anzuzeigen, wenn SignalR eine Trennung erkennt und in den Modus für die erneute Verbindung wechselt.

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

• Behandeln Sie das disconnected Ereignis, um eine Meldung anzuzeigen, wenn beim Versuch, eine verbindung wiederherzustellen, ein Timeout aufgetreten ist. In diesem Szenario besteht die einzige Möglichkeit zum erneuten Herstellen einer Verbindung mit dem Server darin, die SignalR-Verbindung durch Aufrufen der Start -Methode neu zu starten, wodurch eine neue Verbindungs-ID erstellt wird. Im folgenden Codebeispiel wird ein Flag verwendet, um sicherzustellen, dass Sie die Benachrichtigung erst nach einem Timeout für die erneute Verbindung ausgeben, nicht nach einem normalen Ende der SignalR-Verbindung, die durch den Aufruf der Stop -Methode verursacht wird.

  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.
      }
  });
  

Fortlaufendes Wiederherstellen der Verbindung

In einigen Anwendungen möchten Sie möglicherweise automatisch eine Verbindung erneut herstellen, nachdem sie unterbrochen wurde und das Zeitlimit für den Versuch, die Verbindung wiederherzustellen, aufgetreten ist. Dazu können Sie die Start -Methode aus Ihrem Closed Ereignishandler (disconnected Ereignishandler auf JavaScript-Clients) aufrufen. Möglicherweise möchten Sie vor dem Aufruf Start eine Zeit warten, um zu vermeiden, dass dies zu häufig erfolgt, wenn der Server oder die physische Verbindung nicht verfügbar ist. Das folgende Codebeispiel gilt für einen JavaScript-Client, der den generierten Proxy verwendet.

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

Ein potenzielles Problem, das bei mobilen Clients zu beachten ist, ist, dass kontinuierliche Wiederholungsversuche, wenn der Server oder die physische Verbindung nicht verfügbar ist, zu einer unnötigen Akkuauslastung führen können.

Trennen eines Clients im Servercode

SignalR Version 1.1.1 verfügt nicht über eine integrierte Server-API zum Trennen von Clients. Es ist geplant, diese Funktionalität in Zukunft hinzuzufügen. In der aktuellen SignalR-Version besteht die einfachste Möglichkeit zum Trennen eines Clients vom Server darin, eine Disconnect-Methode auf dem Client zu implementieren und diese Methode vom Server aufzurufen. Das folgende Codebeispiel zeigt eine Disconnect-Methode für einen JavaScript-Client mit dem generierten Proxy.

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

Warnung

Sicherheit: Weder diese Methode zum Trennen von Clients noch die vorgeschlagene integrierte API adressiert das Szenario gehackter Clients, die bösartigen Code ausführen, da die Clients die Verbindung wiederherstellen oder der gehackte Code die stopClient Methode entfernen oder ändern könnte, was sie tut. Der geeignete Ort zum Implementieren des zustandsbehafteten DoS-Schutzes (Denial-of-Service) befindet sich nicht im Framework oder auf der Serverebene, sondern in der Front-End-Infrastruktur.