SignalR seltsam Wiederverbindungsmuster

Question

Ich arbeite mit SignalR unter sehr spezifischen Netzwerkbedingungen (ein verrückter Proxy). Also funktionieren Sockets überhaupt nicht und ich muss Long-Polling verwenden. Wenn ich eine Seite aktualisiere, scheint es für eine Weile zu funktionieren, aber dann passiert die erste Trennung. Ich versuche, automatisch getrennt Ereignis zu verbinden und das folgende Muster:

1. Nachdem die Seite geladen wird, Hub trennt in etwa 110 Sekunden (Standard-Timeout)
2. Es dauert 3 Disconnected Ereignisse eine Nabe neu starten, nachdem die erste trennen (so dass es nur auf den 4. Versuch verbindet)
3. Danach wieder verbindet es immer beim ersten Versuch, aber trennt nach etwa 10-15 Sekunden (nicht 110 Sekunden). Es sieht also so aus, als wäre das Keep-Alive-Timeout hier irgendwie in Kraft (während es beim ersten Versuch nicht war).

Dieses Verhalten scheint seltsam. Kann ich etwas tun, um es zu verbessern?

Answer 1

Nehmen Sie die in Understanding and Handling Connection Lifetime Events in SignalR verfügbaren Tipps an, in denen Sie auf Basis des Netzwerkproblems gute Lösungen für die Verbindungslebensdauer verwenden können. Außerdem habe ich in SignalRs Ausgaben die folgende Lösung gefunden, die auch mit Long-Polling funktioniert.

Sie können die KeepAlive Eigenschaft auf den ConfigurationManager und SignalR einen leeren Rahmen von Daten (basierend auf dem Transport) auf dem angegebenen Intervall zu halten um die Verbindung aufrecht (siehe Allow host to specify keep alive times) senden. Der aktuelle Timeout-Mechanismus unterscheidet die Streaming-Protokolle nicht.

Answer 2

Verwenden Sie ConnectionStatusStream. Dieser Stream OnNexts, wenn die clientseitigen SignalR-Hub-Proxy-Ereignisse ausgelöst werden. So sehen wir Dinge wie Verbinden, Verbunden, ConnectionSlow, Reconnecting, Reconnected, Closed, Uninitialized. Alle diese Ereignisse begannen als Ereignisse auf dem SignalR-Hub-Proxy und wurden über eine der vielen RX-Factorys in einen IObservable-Stream umgewandelt. In diesem Fall IObservable.FromEvent.

Wie auch immer, hier ist das gesamte ConnectivityStatusViewModel, das wir verwenden, um die Informationen in der unteren Statusleiste der App anzuzeigen.

Siehe dazu:

ConnectionStatusStream