18

さまざまなタイムアウト プロパティを指定するこのリンクに遭遇しました: https://github.com/SignalR/SignalR/wiki/Configuring-SignalR

また、この優れた投稿 ( When does a reconnect in signalR occour? ) では、SignalR クライアントと SignalR サーバーの間で切断と再接続がどのように発生するかについて説明しています。

上記の投稿とは異なる状況を繰り返します。

「クライアントがオフラインになり、その後すぐに接続を回復すると、ハブの再接続が発生します。SignalR の構成値によって、次の例のタイムスタンプが大きく決まるため、時間を逐語的にとらないでください。

以下に、再接続動作を含むいくつかの例とその結果 (時間形式 m:ss) を示します。

状況 1

0:00 - クライアントがサーバーに接続し、OnConnected がトリガーされます

0:10 - ISP の問題が原因でクライアントが接続を失う (そして、接続が失われたことに気付く)

0:15 - クライアントが接続を回復

0:16 - OnReconnected イベントがトリガーされる

状況 2

0:00 - クライアントがサーバーに接続し、OnConnected がトリガーされます

0:10 - イーサネット ケーブルを引っ張ったためにクライアントが接続を失った (切断されたことに気付いていない)

0:15 - クライアントが接続を回復

ここで 2 つのことが起こります

A: 0:16 - 何も起こらず、クライアントは以前の接続を続行します

B: 0:~45 - クライアントが切断を認識 *

B: 0:46 - クライアントは再接続状態に移行します

B: 0:47 - クライアントが正常に再接続し、OnReconnected イベントがトリガーされます。

状況 3

0:00 - クライアントがサーバーに接続し、OnConnected がトリガーされます

0:10 - イーサネット ケーブルを引っ張ったためにクライアントが接続を失った (切断されたことに気付いていない)

0:~45 - クライアントが切断を認識 *

0:46 - クライアントは再接続状態に移行します

1:15 - サーバーは、クライアントがあまりにも長い間離れていたと判断し、それを忘れて、少し後で再接続した場合にクライアントが受け取る「切断」コマンドをキューに入れます. ***

1:15 - OnDisconnect がトリガーされる 1:16 - クライアントが接続を回復する

1:17 - クライアントが「ソフト」再接続を行う (OnReconnected をトリガーしない)

1:18 - クライアントは「切断」コマンドを取得します

1:19 - クライアントは「停止」を呼び出し、ソフト切断を行います (OnDisconnected をトリガーしません)

状況 4

0:00 - クライアントがサーバーに接続し、OnConnected がトリガーされます

0:10 - イーサネット ケーブルを引っ張ったためにクライアントが接続を失った (切断されたことに気付いていない)

0:~45 - クライアントが切断を認識 *

0:46 - クライアントは再接続状態に移行します

1:15 - サーバーは、クライアントがあまりにも長い間離れていたと判断し、それを忘れて、少し後で再接続した場合にクライアントが受け取る「切断」コマンドをキューに入れます. ***

1:15 - OnDisconnect がトリガーされます 1:30 - クライアントが再接続の試行を停止します (試行が長すぎます) **

1:30 - クライアントが切断状態に移行する

  • クライアント側のキープ アライブ チェックが原因: キープ アライブがないためにクライアントがオフラインになったことを判断するために使用されます。ロング ポーリング トランスポートには使用されない

** クライアント側の切断タイムアウトが原因: クライアントが再接続している時間が長すぎて、その間にサーバーがクライアントを忘れている可能性があることを判断するために使用されます

*** サーバー切断タイムアウトのため: クライアントをいつ忘れるべきかを判断するために使用されます。これは、サーバー上で接続が停止しているとタグ付けされると発生し始める時間です。最終的に、サーバーはクライアントのトピックの切断コマンドをキューに入れ、クライアントに (再接続する場合) 新しい接続を開始する必要があることを伝えます。トピックがクリーンアップされると、コマンドはサーバーから消えます。」


私たちが見つけたのは、.NET SignalR クライアントと ASP.NET MVC SignalR サーバーの間で切断と再接続が頻繁に発生し (上記の 1 と 2)、再接続に至らない切断も発生していることです (上記の 3 と 4)。ServerSentEvents プロトコルが使用されていることがわかっています。

次のように微調整 (増加または減少) する必要があるタイムアウト プロパティを特定するのは困難です。

  1. 切断と再接続の回数を減らします。
  2. 状況 3 と 4 にはまったくなりません。

ここで注意すべき重要なことは、.NET SignalR クライアントは、実際には常にサーバーに接続されている Windows サービスであるということです。

現在、次のデフォルトのままにしています。

  • 接続タイムアウト = 110 秒
  • 切断タイムアウト = 30 秒
  • キープアライブ = 30 秒

また、SignalR 1.0.1 を使用しています。

4

3 に答える 3

9

.NET クライアントには、まだこの動作はありません。クライアントが突然接続を切断した場合、再接続しません。1.1 になります。

于 2013-03-21T03:18:00.020 に答える
7

タイムアウトが適切に設定されています。現在のリリースでは、.net クライアントが接続を維持することを保証するクライアント側のキープ アライブはありません。

次のリリースでは、.net クライアント側でキープ アライブが行われます。プロジェクトの開発ビルドを使用する場合、この機能は現在、開発ブランチhttps://github.com/SignalR/SignalR/tree/devで利用できます。

また、参考までに、https://github.com/SignalR/SignalR/issues/741に表示されている問題に関連する問題を次に示します。

于 2013-03-21T01:06:43.457 に答える
4

SignalR 1.0.1 を使用していますか? Taylor による再接続プロセスの説明は、SignalR バージョン >= 1.0 および JS クライアントに適用されます。私が尋ねる理由は、SignalR >= 1.0 ではKeepAliveDisconnectTimeout. KeepAliveと は絶対DisconnectTimeoutに等しくありません。

ただし、1.0.* でDisconnectTimeoutafterを設定するKeepAliveと、keep-alive は の 3 分の 1 に設定されDisconnectTimeoutます。あなたの場合、これは 10 秒のデフォルトになります。

SignalR 1.0 では多くの問題が解決されているため、まだアップグレードしていない場合は、アップグレードする価値があります。ただし、他の回答が指摘しているように、.NET クライアントはキープアライブ チェックをサポートせず、1.1 までネットワーク ケーブルが抜かれたことを認識しません。

ConnectionPS切断されたことに何らかの形で気付いた場合は、いつでも手動で再起動できます。このシナリオでは、接続 ID はもちろん変更されます。

于 2013-03-21T01:15:24.677 に答える