18

We have come across this link which specifies the different time out properties: https://github.com/SignalR/SignalR/wiki/Configuring-SignalR

And also this excellent post (When does a reconnect in signalR occour?) on how disconnections and reconnections happen between a SignalR client and a SignalR server.

Just to re-iterate the different situations from the above post:

"A hub reconnect occurs when a client goes offline then regains connectivity shortly after. SignalR configuration values largely determine the time stamps of the following examples so do not take the times verbatim.

Here are several examples and their outcomes (time format m:ss) involving reconnecting behavior:

Situation 1

0:00 - Client connects to server, OnConnected is triggered

0:10 - Client loses connection due to ISP issues (and realizes it loses connection)

0:15 - Client Regains connectivity

0:16 - OnReconnected event is triggered

Situation 2

0:00 - Client connects to server, OnConnected is triggered

0:10 - Client loses connection due to pulling ethernet cable (doesn't realize it's disconnected)

0:15 - Client Regains connectivity

Two things can happen here

A: 0:16 - Nothing happens and client continues on with its previous connection

B: 0:~45 - Client Realizes its disconnected *

B: 0:46 - Client transitions into the reconnecting state

B: 0:47 - Client successfully reconnects and the OnReconnected event is triggered.

Situation 3

0:00 - Client connects to server, OnConnected is triggered

0:10 - Client loses connection due to pulling ethernet cable (doesn't realize it's disconnected)

0:~45 - Client Realizes its disconnected *

0:46 - Client transitions into the reconnecting state

1:15 - Server determines that client has been gone for too long and then forgets about it, queuing up a "disconnect" command for the client to receive if it reconnects slightly later. ***

1:15 - OnDisconnect is triggered 1:16 - Client regains connectivity

1:17 - Client does a "soft" reconnect (does not trigger OnReconnected)

1:18 - Client retrieves the "disconnect" command

1:19 - Client calls "stop" and does a soft disconnect (does not trigger OnDisconnected)

Situation 4

0:00 - Client connects to server, OnConnected is triggered

0:10 - Client loses connection due to pulling ethernet cable (doesn't realize it's disconnected)

0:~45 - Client Realizes its disconnected *

0:46 - Client transitions into the reconnecting state

1:15 - Server determines that client has been gone for too long and then forgets about it, queuing up a "disconnect" command for the client to receive if it reconnects slightly later. ***

1:15 - OnDisconnect is triggered 1:30 - Client stops trying to reconnect (been trying too long) **

1:30 - Client transitions into disconnected state

  • Due to client side keep alive check: Used to determine when a client is offline due to lack of keep alives. Not utilized for the long polling transport

** Due to client side disconnect timeout: Used to determine when a client has been reconnecting for too long of a period and chances are the server has forgotten about the client during the time

*** Due to server disconnect timeout: Used to determine when a client should be forgotten about. It's a time span that starts accruing once a connection is tagged as dead on the server. Ultimately the server queues a disconnect command for the client's topic which tells the client (if it reconnects) that it needs to start a fresh connection. The command will disappear from the server when the topic is cleaned up."

What we are finding is that we get disconnects and reconnects quite often (1 and 2 above) between a .NET SignalR client and an ASP.NET MVC SignalR server, and also disconnects that do not result in reconnections (3 and 4 above). We know that ServerSentEvents protocol is being used.

It is hard to know what timeout properties we need to tweak (increase or decrease) to:

  1. Reduce the number of disconnects and reconnects.
  2. Not end up in situations 3 and 4 at all.

An important thing to note here is that our .NET SignalR Client is actually a windows service which is connected to the server all the time.

We have currently just kept the defaults, which are:

  • ConnectionTimeout = 110 seconds
  • DisconnectTimeout = 30 seconds
  • KeepAlive = 30 seconds

Also, we are using SignalR 1.0.1.

Community
  • 1
  • 1
smitra
  • 587
  • 2
  • 6
  • 18

3 Answers3

9

The .NET client does NOT have this behavior yet. and it will not reconnect if the client suddenly drops a connection. It will in 1.1.

davidfowl
  • 32,805
  • 7
  • 81
  • 91
  • 13
    I'm confused as to why people have down voted this answer, especially as dfowler actually wrote the framework which this question is about... – Not loved Mar 24 '13 at 21:05
  • 3
    @david can't seem to find this feature in 2.2 as well, any update? – Krazibit312 Aug 31 '15 at 14:24
  • I'm testing this with both the .NET client and JavaScript client, and reconnects seem to be working with both. Using 2.3.0. – Brain2000 Aug 21 '18 at 04:42
7

Your timeouts are properly set. In the current release there is no client side keep alive for the .net client to ensure that the client maintains connectivity.

In the next release you will have a .net client side keep alive. If you're willing to work with a dev build of the project the feature is currently available on the dev branch https://github.com/SignalR/SignalR/tree/dev.

Also for reference, here's the issue related to what you're seeing https://github.com/SignalR/SignalR/issues/741.

N. Taylor Mullen
  • 17,571
  • 6
  • 46
  • 72
  • 1
    Thanks. This gives us something to work with. PS. would vote up but I don't have enough rep points apparently :-( I will mark this as answer as soon as I have confirmed that the client-side Keep Alive helps us with the disconnects. – smitra Mar 21 '13 at 02:18
  • Hi again, I couldn't actually find the .NET Client-side KeepAlive in the dev branch. It does not seem to be a property on the Connection class. The closest I could find was the KeepAliveData with a timeout property on the IConnection interface. I assume this is what we are referring to? – smitra Mar 21 '13 at 22:49
  • It uses the heartbeat monitor, for more detail you can dive into the issue #741 to see the commits associated with the keep alive. – N. Taylor Mullen Mar 21 '13 at 22:55
  • Had to get the DEV build and use this. This seems to solve the connection issues we were having. The server-side timeouts were also set: DisconnectTimeOut = 200 sec, KeepAlive = 60 sec. – smitra Mar 27 '13 at 04:10
4

Are you using SignalR 1.0.1? Taylor's description of the reconnect process applies to SignalR version >= 1.0 and the JS client. The reason I ask is because in SignalR >= 1.0, KeepAlive must be no more than a third of the DisconnectTimeout. The KeepAlive and the DisconnectTimeout absolutely cannot be equal.

However, if 1.0.* you set the DisconnectTimeout after KeepAlive, the keep-alive will be set to a third of the DisconnectTimeout. In your case, this would be the 10 second default.

A lot of issues were resolved in SignalR 1.0, so it's definitely worth upgrading if you haven't. Though, as other answers have pointed out, the .NET client will not support keep-alive checks and will not recognize the network cable has become unplugged until 1.1

P.S. You can always manually restart your Connection if you realize somehow that it becomes disconnected. In this scenario your connection id will change of course.

halter73
  • 14,442
  • 3
  • 44
  • 54
  • Hi, thanks for the explanation. Sorry I should have mentioned that we are on version 1.0.1. The original question has now been updated. – smitra Mar 21 '13 at 01:58
  • Client side keep alive for the .net client is still not available in 1.0.1 just to be clear. – N. Taylor Mullen Mar 21 '13 at 02:21