私はついにこれを理解しました。この質問を始めてから私が学んだことは次のとおりです。
背景: Xamarin / Monotouchと.NETSignalR2.0.3クライアントを使用してiOSアプリを構築しています。デフォルトのSignalRプロトコルを使用していますが、Webソケットの代わりにSSEを使用しているようです。Xamarin / MonotouchでWebソケットを使用できるかどうかはまだわかりません。すべてがAzureWebサイトを使用してホストされます。
SignalRサーバーにすばやく再接続するにはアプリが必要でしたが、接続がそれ自体で再接続されない、または再接続に正確に30秒かかった(基になるプロトコルタイムアウトのため)という問題が引き続き発生しました。
最終的にテストしたシナリオは3つありました。
シナリオA-アプリが最初に読み込まれたときに接続します。これは初日から完璧に機能しました。3Gモバイル接続でも、接続は0.25秒未満で完了します。(ラジオがすでにオンになっていると仮定)
シナリオB-アプリが30秒間アイドル状態/クローズされた後、SignalRサーバーに再接続します。このシナリオでは、SignalRクライアントは、特別な作業を行わなくても、最終的にはサーバーに自動的に再接続しますが、再接続を試みる前に正確に30秒待機しているようです。(私たちのアプリには遅すぎます)
この30秒間の待機期間中に、HubConnection.Start()を呼び出してみましたが、効果はありませんでした。また、HubConnection.Stop()の呼び出しにも30秒かかります。SignalRサイトで解決されたように見える関連するバグを見つけましたが、v2.0.3でも同じ問題が発生しています。
シナリオC-アプリが120秒以上アイドル状態/クローズされた後、SignalRサーバーに再接続します。このシナリオでは、SignalRトランスポートプロトコルがすでにタイムアウトしているため、クライアントが自動的に再接続することはありません。これは、クライアントが時々、しかし常にではないが、それ自体で再接続していた理由を説明しています。幸いなことに、HubConnection.Start()の呼び出しは、シナリオAのようにほぼ瞬時に機能します。
そのため、アプリを30秒以上閉じたかどうかによって再接続条件が異なることに気付くのに少し時間がかかりました。また、SignalRトレースログは、基盤となるプロトコルで何が起こっているかを明らかにしますが、コードでトランスポートレベルのイベントを処理する方法はないと思います。(Closed()イベントは、シナリオBでは30秒後に発生し、シナリオCでは即座に発生します。Stateプロパティは、これらの再接続待機期間中に「接続済み」と表示します。他の関連するイベントやメソッドはありません)
解決策:
解決策は明らかです。SignalRが再接続の魔法を実行するのを待っていません。代わりに、アプリがアクティブ化されたとき、または電話のネットワーク接続が復元されたときに、イベントをクリーンアップしてHubConnectionの参照を解除するだけです(30秒かかるため、破棄できません。ガベージコレクションで処理されるといいのですが) )そして新しいインスタンスを作成します。今、すべてがうまく機能しています。何らかの理由で、新しいインスタンスを作成するだけでなく、永続的な接続を再利用して再接続する必要があると思いました。