SignalR で接続の有効期間イベントの処理の理解と 1.xUnderstanding and Handling Connection Lifetime Events in SignalR 1.x

によってPatrick FletcherTom Dykstraby Patrick Fletcher, Tom Dykstra


この記事では、ASP.NET SignalR を指します。This article refers to ASP.NET SignalR. SignalR を使用して、Java、Node.js、またはサーバーレス シナリオでは、リアルタイムのシナリオを有効にする方法と思う場合を見てASP.NET Core SignalRします。If you're thinking about using SignalR to enable real-time scenarios with Java, Node.js, or in a serverless scenario, take a look at ASP.NET Core SignalR. 既に ASP.NET SignalR を使用した場合を見て、のバージョンの違いバージョンの違いと ASP.NET Core SignalR での機能強化を理解するページ。If you've already used ASP.NET SignalR, take a look at the version differences page to understand the differences in the versions and the improvements in ASP.NET Core SignalR. 最後に、Microsoft Azure でリアルタイム アプリを実行することがわかっている場合を見て、 Azure SignalR サービスなど、アプリを必要とすると、クラウド ベースのスケール アウトを提供します。Finally, if you know you'll be running your real-time apps in Microsoft Azure, take a look at the Azure SignalR Service, as it provides cloud-based scale-out once your apps need it.

この記事では、SignalR 接続や再接続、切断イベントを処理することができますとタイムアウトとキープア ライブの設定を構成することができますの概要を示します。This article provides an overview of the SignalR connection, reconnection, and disconnection events that you can handle, and timeout and keepalive settings that you can configure.

この記事では、SignalR と接続の有効期間イベントの一部に関する知識がある前提としています。The article assumes you already have some knowledge of SignalR and connection lifetime events. SignalR の概要については、次を参照してください。 SignalR - 概要 - Getting Startedします。For an introduction to SignalR, see SignalR - Overview - Getting Started. 接続の有効期間イベントのリストは、次のリソースを参照してください。For lists of connection lifetime events, see the following resources:


この記事は、次のセクションで構成されています。This article contains the following sections:

.NET 4.5 バージョンの API は API のリファレンス トピックへのリンクです。Links to API Reference topics are to the .NET 4.5 version of the API. .NET 4 を使用している場合は、次を参照してください。 .NET 4 のバージョンを API のトピックのします。If you're using .NET 4, see the .NET 4 version of the API topics.

接続の有効期間の用語とシナリオConnection lifetime terminology and scenarios

OnReconnected SignalR ハブのイベント ハンドラーは、すぐ後に実行できるOnConnectedがいない後OnDisconnected指定のクライアント。The OnReconnected event handler in a SignalR Hub can execute directly after OnConnected but not after OnDisconnected for a given client. 再接続、切断されることがなくすることが理由では、「接続」という単語が SignalR で使用されているいくつかの方法があることです。The reason you can have a reconnection without a disconnection is that there are several ways in which the word "connection" is used in SignalR.

SignalR 接続、トランスポートの接続、および物理的な接続SignalR connections, transport connections, and physical connections

この記事では区別SignalR 接続トランスポート接続、および物理接続:This article will differentiate between SignalR connections, transport connections, and physical connections:

  • SignalR 接続クライアントとサーバーの URL、SignalR の API によって管理され、接続の ID によって一意に識別間に論理リレーションシップを参照SignalR connection refers to a logical relationship between a client and a server URL, maintained by the SignalR API and uniquely identified by a connection ID. このリレーションシップに関するデータは、SignalR が管理し、トランスポート接続を確立するために使用します。The data about this relationship is maintained by SignalR and is used to establish a transport connection. クライアントを呼び出すときのデータのリレーションシップの end と SignalR が破棄、Stopメソッドまたはタイムアウト制限に達すると、SignalR が失われるトランスポート接続を再確立しようとしています。The relationship ends and SignalR disposes of the data when the client calls the Stop method or a timeout limit is reached while SignalR is attempting to re-establish a lost transport connection.
  • トランスポート接続クライアントと管理 Api の 4 つのトランスポートのいずれかによって、サーバーの間の論理リレーションシップを参照します。Websocket、サーバーによって送信されるイベント、無限のフレームまたはポーリング時間の長い。Transport connection refers to a logical relationship between a client and a server, maintained by one of the four transport APIs: WebSockets, server-sent events, forever frame, or long polling. SignalR はトランスポート API を使用してトランスポート接続を作成して、トランスポートの API がトランスポート接続を作成する物理ネットワーク接続の存在に依存します。SignalR uses the transport API to create a transport connection, and the transport API depends on the existence of a physical network connection to create the transport connection. トランスポート接続は、SignalR でが終了するとき、またはトランスポート API は、物理的な接続が切断されたことを検出したときに終了します。The transport connection ends when SignalR terminates it or when the transport API detects that the physical connection is broken.
  • 物理的な接続を指す、物理ネットワークへのリンク - ワイヤ、ワイヤレス信号をルーター、- などをクライアント コンピューターとサーバー コンピューター間の通信を容易にします。Physical connection refers to the physical network links -- wires, wireless signals, routers, etc. -- that facilitate communication between a client computer and a server computer. 物理的な接続のトランスポート接続を確立するために存在する必要があり、SignalR の接続を確立するためにトランスポート接続を確立する必要があります。The physical connection must be present in order to establish a transport connection, and a transport connection must be established in order to establish a SignalR connection. ただし、互換性に影響する物理接続は常に即座に終了トランスポート接続や、SignalR 接続このトピックの後半で説明するようです。However, breaking the physical connection doesn't always immediately end the transport connection or the SignalR connection, as will be explained later in this topic.

次の図で SignalR 接続は、ハブの API と PersistentConnection API SignalR レイヤーで表されるトランスポート接続は、トランスポート レイヤーで表され、物理接続は、サーバー間の線で表されますクライアントとします。In the following diagram, the SignalR connection is represented by the Hubs API and PersistentConnection API SignalR layer, the transport connection is represented by the Transports layer, and the physical connection is represented by the lines between the server and the clients.

SignalR のアーキテクチャ図

呼び出すと、Startメソッド SignalR クライアントで、サーバーへの物理接続を確立するために必要なすべての情報を SignalR クライアント コードが提供されます。When you call the Start method in a SignalR client, you are providing SignalR client code with all the information it needs in order to establish a physical connection to a server. SignalR クライアント コードでは、この情報を使用して、HTTP 要求を作成し、4 つのトランスポートのいずれかを使用する物理接続を確立します。SignalR client code uses this information to make an HTTP request and establish a physical connection that uses one of the four transport methods. トランスポート接続が失敗したか、サーバーが失敗した場合、SignalR 接続は離れたはすぐに、クライアントがまだ SignalR のと同じ URL への新しいトランスポート接続を自動的に再確立するために必要な情報。If the transport connection fails or the server fails, the SignalR connection doesn't go away immediately because the client still has the information it needs to automatically re-establish a new transport connection to the same SignalR URL. このシナリオでは、ユーザー アプリケーションによる介入は必要ありませんし、SignalR クライアント コードでは、新しいトランスポート接続を確立するときに新しい SignalR 接続は開始されません。In this scenario, no intervention from the user application is involved, and when the SignalR client code establishes a new transport connection, it does not start a new SignalR connection. SignalR 接続の継続性は、ファクトに反映されますを呼び出すときに作成される接続 ID、Startメソッドでは変更されません。The continuity of the SignalR connection is reflected in the fact that the connection ID, which is created when you call the Start method, does not change.

OnReconnected紛失になった後のトランスポート接続が自動的に再確立されたときに、ハブにイベント ハンドラーが実行されます。The OnReconnected event handler on the Hub executes when a transport connection is automatically re-established after having been lost. OnDisconnected SignalR 接続の最後にイベント ハンドラーを実行します。The OnDisconnected event handler executes at the end of a SignalR connection. SignalR 接続は、次の方法のいずれかで終了できます。A SignalR connection can end in any of the following ways:

  • クライアントを呼び出す場合、Stopメソッド、停止メッセージは、サーバーに送信され、クライアントとサーバーの両方、SignalR 接続がすぐに終了します。If the client calls the Stop method, a stop message is sent to the server, and both client and server end the SignalR connection immediately.
  • クライアントとサーバー間の接続が失われた後、クライアントが再接続を試行し、サーバーが再接続するクライアントの待機します。After connectivity between client and server is lost, the client tries to reconnect and the server waits for the client to reconnect. 再接続の試行が失敗することと、切断のタイムアウト期間の終了する場合、クライアントとサーバーの両方に SignalR 接続が終了します。If the attempts to reconnect are unsuccessful and the disconnect timeout period ends, both client and server end the SignalR connection. クライアントが再接続するには中止し、サーバーは、SignalR 接続の表現の破棄します。The client stops trying to reconnect, and the server disposes of its representation of the SignalR connection.
  • クライアントを呼び出す機会をしなくても実行が停止した場合、Stopメソッド、再接続するには、クライアントのサーバーが待機し、切断のタイムアウト期間後、SignalR 接続を終了します。If the client stops running without having a chance to call the Stop method, the server waits for the client to reconnect, and then ends the SignalR connection after the disconnect timeout period.
  • かどうか、サーバーが実行を停止、クライアントの再接続しよう (再トランスポート接続) を作成し、切断のタイムアウト期間後、SignalR 接続を終了します。If the server stops running, the client tries to reconnect (re-create the transport connection), and then ends the SignalR connection after the disconnect timeout period.

接続の問題がないと、ユーザーのアプリケーションを呼び出して、SignalR 接続の終了、Stopメソッド、SignalR 接続とトランスポート接続を開始し、ほぼ同時に終了します。When there are no connection problems, and the user application ends the SignalR connection by calling the Stop method, the SignalR connection and the transport connection begin and end at about the same time. 次のセクションでは、他のシナリオをさらに詳しくについて説明します。The following sections describe in more detail the other scenarios.

トランスポート切断シナリオTransport disconnection scenarios

物理的な接続が遅くなるまたは接続の中断がある可能性があります。Physical connections might be slow or there might be interruptions in connectivity. 中断時間の長さなどの要因によってトランスポート接続が削除される可能性があります。Depending on factors such as the length of the interruption, the transport connection might be dropped. SignalR はトランスポート接続を再確立を試みます。SignalR then tries to re-establish the transport connection. トランスポート接続 API が場合があります、中断を検出し、トランスポートの接続が切断し、SignalR がすぐに、接続が失われることです。Sometimes the transport connection API detects the interruption and drops the transport connection, and SignalR finds out immediately that the connection is lost. 他のシナリオでのトランスポート接続 API も、SignalR 認識はすぐになり接続が失われたこと。In other scenarios, neither the transport connection API nor SignalR becomes aware immediately that connectivity has been lost. SignalR クライアントが呼び出される関数を使用して、ロング ポーリングを除くすべてのトランスポートでkeepaliveトランスポート API が検出できない接続が失われるを確認します。For all transports except long polling, the SignalR client uses a function called keepalive to check for loss of connectivity that the transport API is unable to detect. 時間の長いポーリングの接続については、次を参照してください。タイムアウトとキープア ライブ設定このトピックで後述します。For information about long polling connections, see Timeout and keepalive settings later in this topic.

接続がアクティブでない場合、サーバーはクライアントにキープア ライブ パケットを送信定期的にします。When a connection is inactive, periodically the server sends a keepalive packet to the client. この記事では、書き込まれる時点で、既定の頻度が 10 秒ごとにできます。As of the date this article is being written, the default frequency is every 10 seconds. これらのパケットをリッスンして、クライアントは接続の問題があるかどうかを指示することができます。By listening for these packets, clients can tell if there is a connection problem. キープア ライブ パケットが受信されない場合予想される場合、短期間のうちに、クライアントが想定パフォーマンスの低下や中断などの接続に関する問題があること。If a keepalive packet is not received when expected, after a short time the client assumes that there are connection problems such as slowness or interruptions. 長い時間が経過したら、keepalive が受信されないままの場合、クライアントで、接続が切断されてと再接続しようとしていますが開始されます。If the keepalive is still not received after a longer time, the client assumes that the connection has been dropped, and it begins trying to reconnect.

次の図は、トランスポート API によって認識されないすぐに物理接続に問題が発生する一般的なシナリオで発生するクライアントとサーバーのイベントを示します。The following diagram illustrates the client and server events that are raised in a typical scenario when there are problems with the physical connection that aren't immediately recognized by the transport API. 図は、次の状況に適用されます。The diagram applies to the following circumstances:

  • トランスポートは、Websocket、永久にフレームまたはサーバー送信イベントには。The transport is WebSockets, forever frame, or server-sent events.
  • 物理ネットワーク接続の中断の期間があります。There are varying periods of interruption in the physical network connection.
  • SignalR は、それらを検出するためにキープア ライブ機能に依存するようにはトランスポート API は、中断の認識なりません。The transport API does not become aware of the interruptions, so SignalR relies on the keepalive functionality to detect them.


クライアントが再接続するモードになる切断のタイムアウト制限内でのトランスポート接続を確立できない場合は、サーバーには、SignalR 接続が終了します。If the client goes into reconnecting mode but can't establish a transport connection within the disconnect timeout limit, the server terminates the SignalR connection. サーバーが、ハブを実行する場合は、OnDisconnectedメソッドおよび接続解除の後で接続するクライアントを管理する場合に、クライアントに送信するメッセージをキューします。When that happens, the server executes the Hub's OnDisconnected method and queues up a disconnect message to send to the client in case the client manages to connect later. 接続解除コマンドと呼び出し場合は、クライアント、再接続は、受信、Stopメソッド。If the client then does reconnect, it receives the disconnect command and calls the Stop method. このシナリオでOnReconnectedクライアントが再接続するときは実行されずOnDisconnectedクライアントを呼び出すときは実行されませんStopします。In this scenario, OnReconnected is not executed when the client reconnects, and OnDisconnected is not executed when the client calls Stop. 次の図は、このシナリオを示します。The following diagram illustrates this scenario.

トランスポートの中断 - サーバーのタイムアウト

SignalR 接続の有効期間イベント、クライアントで発生する可能性がありますを次に示します。The SignalR connection lifetime events that may be raised on the client are the following:

  • ConnectionSlow クライアントのイベントです。ConnectionSlow client event.

    Keepalive タイムアウト期間のプリセットの比率は、最後のメッセージから経過したか、キープア ライブの ping を受信したときに発生します。Raised when a preset proportion of the keepalive timeout period has passed since the last message or keepalive ping was received. キープア ライブの既定のタイムアウト警告期間は、keepalive タイムアウトの 2/3 です。The default keepalive timeout warning period is 2/3 of the keepalive timeout. Keepalive タイムアウトは、約 13 秒で警告が発生したために、20 秒が。The keepalive timeout is 20 seconds, so the warning occurs at about 13 seconds.

    既定では、10 秒ごとにキープア ライブの ping を送信するサーバーと、クライアントは keepalive ping (キープア ライブのタイムアウト値と、キープア ライブのタイムアウト警告値の差の 3 分の 1) 2 秒ごとの詳細について確認します。By default, the server sends keepalive pings every 10 seconds, and the client checks for keepalive pings about every 2 seconds (one third of the difference between the keepalive timeout value and the keepalive timeout warning value).

    API のトランスポートが切断の対応になると、keepalive タイムアウト警告が渡される前に SignalR は切断の通知可能性があります。If the transport API becomes aware of a disconnection, SignalR might be informed of the disconnection before the keepalive timeout warning period passes. その場合は、ConnectionSlowイベントは発生しませんが、SignalR に直接移動して、Reconnectingイベント。In that case, the ConnectionSlow event would not be raised, and SignalR would go directly to the Reconnecting event.

  • Reconnecting クライアントのイベントです。Reconnecting client event.

    (A)、トランスポート API 検出を接続が失われた、または最後のメッセージから (b)、キープア ライブのタイムアウト期間が経過または keepalive ping を受信したときに発生します。Raised when (a) the transport API detects that the connection is lost, or (b) the keepalive timeout period has passed since the last message or keepalive ping was received. SignalR クライアント コードでは、再接続を試行を開始します。The SignalR client code begins trying to reconnect. トランスポート接続が失われた場合に、何らかのアクションを実行するアプリケーションの場合は、このイベントを処理することができます。You can handle this event if you want your application to take some action when a transport connection is lost. キープア ライブの既定のタイムアウト期間は、20 秒では現在です。The default keepalive timeout period is currently 20 seconds.

    クライアント コードでは、SignalR がモードの再接続の間のハブ メソッドを呼び出すしようとして、SignalR は、コマンドを送信しようとします。If your client code tries to call a Hub method while SignalR is in reconnecting mode, SignalR will try to send the command. ほとんどの場合は、このような試行は失敗しますが、状況によっては成功する可能性があります。Most of the time, such attempts will fail, but in some circumstances they might succeed. サーバー送信イベント、永久にフレーム、および時間の長いポーリング トランスポート、SignalR は、いずれかのメッセージを受信するために使用して、クライアントを使用してメッセージを送信する 1 つの 2 つの通信チャネルを使用します。For the server-sent events, forever frame, and long polling transports, SignalR uses two communication channels, one that the client uses to send messages and one that it uses to receive messages. 受信するために使用されるチャネルは完全にオープンの 1 つと、物理的な接続が中断されたときに閉じられている 1 つです。The channel used for receiving is the permanently open one, and that's the one that is closed when the physical connection is interrupted. あるため受信チャネルが再確立される前に成功した可能性がありますがクライアントからサーバーへのメソッド呼び出しで物理的な接続が復元された場合に、使用可能なままの送信に使用するチャネル。The channel used for sending remains available, so if physical connectivity is restored, a method call from client to server might be successful before the receive channel is re-established. 戻り値は、SignalR は、受信するために使用されるチャネルを再度開くまで受信できません。The return value would not be received until SignalR re-opens the channel used for receiving.

  • Reconnected クライアントのイベントです。Reconnected client event.

    トランスポート接続が再度確立されたときに発生します。Raised when the transport connection is reestablished. OnReconnectedハブでイベント ハンドラーを実行します。The OnReconnected event handler in the Hub executes.

  • Closed クライアント イベント (disconnected JavaScript でのイベント)。Closed client event (disconnected event in JavaScript).

    切断のタイムアウト期間は、SignalR クライアント コードがトランスポート接続の切断後に再接続しようとしたときに有効期限が切れるときに発生します。Raised when the disconnect timeout period expires while the SignalR client code is trying to reconnect after losing the transport connection. 切断の既定のタイムアウトは 30 秒です。The default disconnect timeout is 30 seconds. (接続のため、終了時にこのイベントは発生も、Stopメソッドが呼び出されます)。(This event is also raised when the connection ends because the Stop method is called.)

トランスポート API で検出されない、keepalive ping キープア ライブのタイムアウト警告期間よりも長くサーバーからの受信を延期しないトランスポート接続の中断は、任意の接続が発生します。 有効期間イベントを発生させないことがあります。Transport connection interruptions that are not detected by the transport API and don't delay the reception of keepalive pings from the server for longer than the keepalive timeout warning period might not cause any connection lifetime events to be raised.

一部のネットワーク環境は意図的に、アイドル状態の接続を閉じるし、キープア ライブ パケットの別の関数は、これらのネットワークは、SignalR の接続が使用されているを知ることによってこれを防ぐためにします。Some network environments deliberately close idle connections, and another function of the keepalive packets is to help prevent this by letting these networks know that a SignalR connection is in use. 極端なケースで keepalive ping の既定の頻度が十分でない閉じられた接続を防ぐため。In extreme cases the default frequency of keepalive pings might not be enough to prevent closed connections. その場合はより多くの場合、送信される ping をキープア ライブを構成できます。In that case you can configure keepalive pings to be sent more often. 詳細については、次を参照してください。タイムアウトとキープア ライブ設定このトピックで後述します。For more information, see Timeout and keepalive settings later in this topic.



ここで説明するイベントの順序は保証されません。The sequence of events described here is not guaranteed. SignalR は、このスキームに従って、予測可能な方法で接続の有効期間イベントを発生させるすべての試行が、ネットワーク イベントの多くのバリエーションとトランスポート Api などの基になる通信フレームワークがそれらに対応する多くの方法があります。SignalR makes every attempt to raise connection lifetime events in a predictable manner according to this scheme, but there are many variations of network events and many ways in which underlying communications frameworks such as transport APIs handle them. たとえば、Reconnectedクライアントが再接続するとき、イベントが発生しないまたはOnConnected接続を確立する試行が成功すると、サーバー上のハンドラーが実行可能性があります。For example, the Reconnected event might not be raised when the client reconnects, or the OnConnected handler on the server might run when the attempt to establish a connection is unsuccessful. このトピックでは、特定の一般的な状況によって通常生成される効果のみについて説明します。This topic describes only the effects that would normally be produced by certain typical circumstances.

クライアントが切断されたときのシナリオClient disconnection scenarios

ブラウザー クライアントでは、SignalR の接続を維持する SignalR クライアント コードは、web ページの JavaScript のコンテキストで実行されます。In a browser client, the SignalR client code that maintains a SignalR connection runs in the JavaScript context of a web page. ですが SignalR 接続が終了のいずれかから移動したときに、なぜページ別、およびその 's なぜ複数接続がある複数の接続 Id で複数のブラウザー ウィンドウまたはタブから接続する場合。That's why the SignalR connection has to end when you navigate from one page to another, and that's why you have multiple connections with multiple connection IDs if you connect from multiple browser windows or tabs. SignalR クライアント コードでは、そのブラウザーのイベントを処理して、呼び出しのために、SignalR 接続をすぐに終了、ユーザーは、ブラウザーのウィンドウまたはタブを閉じますまたは新しいページに移動するか、ページを更新、ときに、Stopメソッド。When the user closes a browser window or tab, or navigates to a new page or refreshes the page, the SignalR connection immediately ends because SignalR client code handles that browser event for you and calls the Stop method. これらのシナリオで、または任意のクライアント プラットフォーム、アプリケーションを呼び出すときに、Stopメソッド、OnDisconnectedイベント ハンドラーは、サーバーですぐに実行して、クライアント、Closedイベント (イベントの名前はdisconnectedでJavaScript の場合)。In these scenarios, or in any client platform when your application calls the Stop method, the OnDisconnected event handler executes immediately on the server and the client raises the Closed event (the event is named disconnected in JavaScript).

クライアント アプリケーションまたはで実行されているコンピューターがクラッシュまたはスリープ モードになる (たとえば、ユーザーがラップトップを閉じる)、サーバーが発生した事象に関する通知されません。If a client application or the computer that it's running on crashes or goes to sleep (for example, when the user closes the laptop), the server is not informed about what happened. サーバーが知っている限り、接続の中断により、クライアントが失われる可能性があり、クライアントが再接続を試行する可能性があります。As far as the server knows, the loss of the client might be due to connectivity interruption and the client might be trying to reconnect. クライアントに再接続する機会を提供する、サーバーが待機するこれらのシナリオでそのため、およびOnDisconnected切断のタイムアウト期間 (既定では約 30 秒) が経過するまでは実行されません。Therefore, in these scenarios the server waits to give the client a chance to reconnect, and OnDisconnected does not execute until the disconnect timeout period expires (about 30 seconds by default). 次の図は、このシナリオを示します。The following diagram illustrates this scenario.

クライアント コンピューターの障害

サーバーが切断されたときのシナリオServer disconnection scenarios

サーバーがオフラインになると--再起動、失敗した場合、アプリ ドメインのリサイクルなど、結果は、接続が失われましたのような可能性がありますまたはトランスポート API と SignalR 可能性がありますすぐにわかること、サーバーがないためとなしの再接続を試みる SignalR が始まります発生させる、ConnectionSlowイベント。When a server goes offline -- it reboots, fails, the app domain recycles, etc. -- the result might be similar to a lost connection, or the transport API and SignalR might know immediately that the server is gone, and SignalR might begin trying to reconnect without raising the ConnectionSlow event. クライアントが再接続するモードに移動し、サーバーの復旧または再起動や、新しいサーバーがオンラインになる切断のタイムアウト期間の有効期限が切れる前に場合は、クライアントは、復元、または新しいサーバーに再接続します。If the client goes into reconnecting mode, and if the server recovers or restarts or a new server is brought online before the disconnect timeout period expires, the client will reconnect to the restored or new server. その場合は、SignalR 接続はクライアントの継続とReconnectedイベントが発生します。In that case, the SignalR connection continues on the client and the Reconnected event is raised. 最初のサーバーでOnDisconnectedは決して実行と、新しいサーバーOnReconnectedが実行されるOnConnected前に、そのサーバーにクライアントが、実行されなかった。On the first server, OnDisconnected is never executed, and on the new server, OnReconnected is executed although OnConnected was never executed for that client on that server before. (効果は同じ場合であるため、サーバーが再起動し、同じサーバーにクライアントが再起動またはアプリのドメイン リサイクルでは後、再接続の前回の接続のアクティビティのメモリがありません)。次の図は、トランスポート API がすぐに、接続が失われましたの対応が前提としています。 そのため、ConnectionSlowイベントは発生しません。(The effect is the same if the client reconnects to the same server after a reboot or app domain recycle, because when the server restarts it has no memory of prior connection activity.) The following diagram assumes that the transport API becomes aware of the lost connection immediately, so the ConnectionSlow event is not raised.


サーバーは、切断のタイムアウト期間内で使用可能なならない、SignalR 接続は終了します。If a server does not become available within the disconnect timeout period, the SignalR connection ends. このシナリオで、Closedイベント (disconnected JavaScript クライアントでは) は、クライアントで発生しますが、OnDisconnectedサーバーで呼び出されることはありません。In this scenario, the Closed event (disconnected in JavaScript clients) is raised on the client but OnDisconnected is never called on the server. 次の図は、トランスポート API はならないこと、接続が切断されたに注意してください SignalR keepalive 機能によって検出されたため、前提としています。 およびConnectionSlowイベントが発生します。The following diagram assumes that the transport API does not become aware of the lost connection, so it is detected by SignalR keepalive functionality and the ConnectionSlow event is raised.


タイムアウトとキープア ライブ設定Timeout and keepalive settings

既定のConnectionTimeoutDisconnectTimeout、およびKeepAlive値は、ほとんどのシナリオに適した、環境内に特別なニーズに変更することができます。The default ConnectionTimeout, DisconnectTimeout, and KeepAlive values are appropriate for most scenarios but can be changed if your environment has special needs. たとえば、ネットワーク環境では、5 秒間アイドル状態になって接続が閉じ、キープア ライブ値を小さく必要があります。For example, if your network environment closes connections that are idle for 5 seconds, you might have to decrease the keepalive value.


この設定は、オープンで終了して、新しい接続を開く前に応答を待機しているトランスポート接続のままにする時間数を表します。This setting represents the amount of time to leave a transport connection open and waiting for a response before closing it and opening a new connection. 既定値は、110 秒です。The default value is 110 seconds.

この設定は適用のみ keepalive 機能は無効にした場合、通常、時間の長いにのみ適用されるトランスポートをポーリングします。This setting applies only when keepalive functionality is disabled, which normally applies only to the long polling transport. 次の図は、時間の長いでこの設定の効果のトランスポート接続をポーリングします。The following diagram illustrates the effect of this setting on a long polling transport connection.



この設定から発生する前にトランスポート接続が失われるまで待機する時間を表す、Disconnectedイベント。This setting represents the amount of time to wait after a transport connection is lost before raising the Disconnected event. 既定値は 30 秒です。The default value is 30 seconds. 設定するとDisconnectTimeoutKeepAliveの 1/3 に自動的に設定されて、DisconnectTimeout値。When you set DisconnectTimeout, KeepAlive is automatically set to 1/3 of the DisconnectTimeout value.


この設定は、アイドル状態の接続経由でキープア ライブ パケットを送信する前に待機する時間を表します。This setting represents the amount of time to wait before sending a keepalive packet over an idle connection. 既定値は、10 秒です。The default value is 10 seconds. この値はの複数の 1/3 をすることはできません、DisconnectTimeout値。This value must not be more than 1/3 of the DisconnectTimeout value.

両方を設定する場合DisconnectTimeoutKeepAlive設定KeepAliveDisconnectTimeoutします。If you want to set both DisconnectTimeout and KeepAlive, set KeepAlive after DisconnectTimeout. それ以外の場合、KeepAlive設定が上書きされるときにDisconnectTimeoutが自動的に設定KeepAliveタイムアウト値の 1/3 にします。Otherwise your KeepAlive setting will be overwritten when DisconnectTimeout automatically sets KeepAlive to 1/3 of the timeout value.

キープア ライブの機能を無効にする場合は、設定KeepAliveを null にします。If you want to disable keepalive functionality, set KeepAlive to null. Keepalive 機能は使用できませんに自動的に、時間の長いトランスポートをポーリングします。Keepalive functionality is automatically disabled for the long polling transport.

タイムアウトとキープア ライブ設定を変更する方法How to change timeout and keepalive settings

設定すると、これらの設定の既定値を変更するには、Application_Startで、 Global.asaxファイルを次の例に示すようにします。To change the default values for these settings, set them in Application_Start in your Global.asax file, as shown in the following example. サンプル コードに表示される値は、既定値の場合と同じです。The values shown in the sample code are the same as the default values.

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

接続の切断についてユーザーに通知する方法How to notify the user about disconnections

一部のアプリケーション接続の問題がある場合、ユーザーにメッセージを表示する場合があります。In some applications you might want to display a message to the user when there are connectivity problems. これを行う方法のいくつかのオプションとがあります。You have several options for how and when to do this. 次のコード サンプルでは、生成されたプロキシを使用して JavaScript クライアント用です。The following code samples are for a JavaScript client using the generated proxy.

  • 処理、connectionSlow再接続モードに入る前に、SignalR は接続の問題を認識するとすぐにメッセージを表示するイベントです。Handle the connectionSlow event to display a message as soon as SignalR is aware of connection problems, before it goes into reconnecting mode.

    $.connection.hub.connectionSlow(function() {
        notifyUserOfConnectionProblem(); // Your function to notify user.
  • 処理、 reconnecting SignalR は切断を認識し、再接続モードに入って、ときに、メッセージを表示するイベントです。Handle the reconnecting event to display a message when SignalR is aware of a disconnection and is going into reconnecting mode.

    $.connection.hub.reconnecting(function() {
        notifyUserOfTryingToReconnect(); // Your function to notify user.
  • 処理、disconnected再接続しようとすると、ときにメッセージを表示するイベントがタイムアウトしました。このシナリオでもう一度サーバーとの接続を再確立する唯一の方法は、呼び出すことによって、SignalR 接続をStartメソッドで、新しい接続 ID が作成されますHandle the disconnected event to display a message when an attempt to reconnect has timed out. In this scenario, the only way to re-establish a connection with the server again is to restart the SignalR connection by calling the Start method, which will create a new connection ID. 次のコード サンプルは、SignalR の接続を呼び出すことによって発生する通常の終了後の再接続のタイムアウト後にのみ通知を発行することを確認する、フラグを使用して、Stopメソッド。The following code sample uses a flag to make sure that you issue the notification only after a reconnecting timeout, not after a normal end to the SignalR connection caused by calling the Stop method.

    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.

継続的に再接続する方法How to continuously reconnect

一部のアプリケーションに自動的に失われ、再接続を試行がタイムアウトした後に接続を再確立する可能性があります。そのために呼び出すことができます、Startからメソッド、Closedイベント ハンドラー (disconnected JavaScript クライアントでのイベント ハンドラー)。In some applications you might want to automatically re-establish a connection after it has been lost and the attempt to reconnect has timed out. To do that, you can call the Start method from your Closed event handler (disconnected event handler on JavaScript clients). 呼び出しの前に、期間を待機するStartもこれを回避するために頻繁に、サーバーまたは物理的な接続が使用できない場合。You might want to wait a period of time before calling Start in order to avoid doing this too frequently when the server or the physical connection are unavailable. 次のコード サンプルは、生成されたプロキシを使用して JavaScript クライアントによってです。The following code sample is for a JavaScript client using the generated proxy.

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

モバイル クライアントで注意すべき潜在的な問題は、サーバーまたは物理接続を利用できない場合、継続的な再接続の試行には、不要なバッテリの消耗可能性があります。A potential problem to be aware of in mobile clients is that continuous reconnection attempts when the server or physical connection isn't available could cause unnecessary battery drain.

サーバー コードでクライアントを切断する方法How to disconnect a client in server code

SignalR バージョン 1.1.1 には、クライアントが切断の組み込みのサーバー API はありません。SignalR version 1.1.1 does not have a built-in server API for disconnecting clients. ある、今後この機能を追加するためのプランします。There are plans for adding this functionality in the future. SignalR の現在のリリースで、サーバーからクライアントを切断する最も簡単な方法は、クライアントの切断メソッドを実装し、サーバーからそのメソッドを呼び出すには。In the current SignalR release, the simplest way to disconnect a client from the server is to implement a disconnect method on the client and call that method from the server. 次のコード サンプルでは、生成されたプロキシを使用して JavaScript クライアントを切断メソッドを示します。The following code sample shows a disconnect method for a JavaScript client using the generated proxy.

var myHubProxy = $.connection.myHub
myHubProxy.client.stopClient = function() {


セキュリティ - クライアントを切断するのには、このメソッドも、提案された組み込みの API はアドレス、クライアントが再接続でした、ハッキングされたコードが削除または悪意のあるコードを実行しているハッキングされたクライアントのシナリオ、stopClientメソッドまたは変更動作します。Security - Neither this method for disconnecting clients nor the proposed built-in API will address the scenario of hacked clients that are running malicious code, since the clients could reconnect or the hacked code might remove the stopClient method or change what it does. ステートフルなサービス拒否 (DOS) の保護を実装するために適切な場所は、フレームワークや、サーバー層ではなく、フロント エンドのインフラストラクチャではなくです。The appropriate place to implement stateful denial-of-service (DOS) protection is not in the framework or the server layer, but rather in front-end infrastructure.