Reputation: 1051
My system is composed of
As I understand, once connected each of these clients would have its own associated ConnectionId
.
Now, I want to implement a resiliency strategy where after the SignalR server is restarted, it should still retain the Groups and Connections it used to have in the Hub.
I was thinking of achieving this by storing the Groups and ConnectionIds in an external storage (e.g. database), and restore it when the application starts up.
When the server goes down, the clients' connection might have dropped. But this can be mitigated somewhat by making the client always attempt to reconnect on disconnection. Once the server is up, the client would reconnect.
However, this solution feels rather flaky. In particular, I'm not sure whether once the client reconnects it will retain the same ConnectionId
.
Does this approach make sense? Is there a better way to do it?
Upvotes: 3
Views: 2069
Reputation: 13297
Yes, client-reconnects ALWAYS happen with the same connectionID.
The connectionID is renewed ONLY in case:
If the client is connected to a server that is about to reboot, the clients will notice upon disconnection and try to reconnect to the server with the same connectionID, all within a given timeframe, defined by the connection-timeout.
If the server, then, reboots within the connection timeout frame, the client reconnects to the server, with the existing ID.
In this case the Reconnect() event is fired on the server, without the OnConnected() event is happened. This is an exceptional signalr case.
Code your Reconnect() events very defensively.
link to official documentation explaining this issue
chapter: Server disconnection scenarios
Upvotes: 2