Ich habe das endlich herausgefunden. Folgendes habe ich gelernt, seit ich mit dieser Frage angefangen habe:
Hintergrund: Wir erstellen eine iOS-App mit Xamarin / Monotouch und dem .NET SignalR 2.0.3-Client. Wir verwenden die Standard-SignalR-Protokolle - und es scheint, dass SSE anstelle von Web-Sockets verwendet wird. Ich bin mir noch nicht sicher, ob es möglich ist, Web-Sockets mit Xamarin / Monotouch zu verwenden. Alles wird über Azure-Websites gehostet.
Wir brauchten die App, um schnell wieder eine Verbindung zu unserem SignalR-Server herzustellen, aber wir hatten immer wieder Probleme, bei denen die Verbindung nicht von selbst wiederhergestellt wurde - oder die erneute Verbindung dauerte genau 30 Sekunden (aufgrund eines zugrunde liegenden Protokoll-Timeouts).
Es gab drei Szenarien, auf die wir getestet haben:
Szenario A - Verbindung beim ersten Laden der App herstellen. Dies funktionierte vom ersten Tag an einwandfrei. Die Verbindung wird auch über mobile 3G-Verbindungen in weniger als 0,25 Sekunden hergestellt. (vorausgesetzt, das Radio ist bereits eingeschaltet)
Szenario B - Wiederverbindung mit dem SignalR-Server, nachdem die App 30 Sekunden lang inaktiv / geschlossen war. In diesem Szenario stellt der SignalR-Client möglicherweise ohne besondere Arbeit selbstständig wieder eine Verbindung zum Server her. Es scheint jedoch genau 30 Sekunden zu warten, bevor versucht wird, die Verbindung wiederherzustellen. (viel zu langsam für unsere App)
Während dieser Wartezeit von 30 Sekunden haben wir versucht, HubConnection.Start () aufzurufen, was keine Auswirkungen hatte. Das Aufrufen von HubConnection.Stop () dauert ebenfalls 30 Sekunden. Ich habe einen verwandten Fehler auf der SignalR-Site gefunden, der behoben zu sein scheint , aber wir haben immer noch das gleiche Problem in Version 2.0.3.
Szenario C - Wiederverbindung mit dem SignalR-Server, nachdem die App 120 Sekunden oder länger inaktiv / geschlossen war. In diesem Szenario ist das SignalR-Transportprotokoll bereits abgelaufen, sodass der Client die Verbindung nie automatisch wiederherstellt. Dies erklärt, warum der Client manchmal, aber nicht immer, die Verbindung von selbst wieder herstellte. Die gute Nachricht ist, dass das Aufrufen von HubConnection.Start () fast sofort wie in Szenario A funktioniert.
Es dauerte eine Weile, bis mir klar wurde, dass die Bedingungen für die erneute Verbindung unterschiedlich waren, je nachdem, ob die App 30 Sekunden lang oder mehr als 120 Sekunden lang geschlossen war. Und obwohl die SignalR-Ablaufverfolgungsprotokolle beleuchten, was mit dem zugrunde liegenden Protokoll vor sich geht, glaube ich nicht, dass es eine Möglichkeit gibt, die Ereignisse auf Transportebene im Code zu behandeln. (Das Closed () -Ereignis wird in Szenario B nach 30 Sekunden sofort in Szenario C ausgelöst. Die State-Eigenschaft sagt während dieser Wartezeiten für die erneute Verbindung "Verbunden". Keine anderen relevanten Ereignisse oder Methoden.)
Lösung:
Die Lösung liegt auf der Hand. Wir warten nicht darauf, dass SignalR seine Wiederverbindungsmagie ausführt. Wenn die App aktiviert ist oder die Netzwerkverbindung des Telefons wiederhergestellt ist, bereinigen wir einfach die Ereignisse und referenzieren die HubConnection (kann nicht entsorgt werden, da dies 30 Sekunden dauert, hoffentlich wird die Speicherbereinigung dies beheben ) und Erstellen einer neuen Instanz. Jetzt funktioniert alles super. Aus irgendeinem Grund dachte ich, wir sollten eine dauerhafte Verbindung wiederverwenden und die Verbindung wiederherstellen, anstatt nur eine neue Instanz zu erstellen.