Why are we checking context.connectionId when a recconect in signalR occurs?

Question

As I know, The OnReconnected event handler in a SignalR Hub can execute directly after OnConnected but not after OnDisconnected for a given client. (source: http://www.asp.net/signalr/overview/guide-to-the-api/handling-connection-lifetime-events)

So, if onReconnected will never be happened after onDisconnected and context.connectionId will remain the same, why official example checks context.connectionId in user connections and add it if not exists.

Link: http://www.asp.net/signalr/overview/guide-to-the-api/mapping-users-to-connections

Erkan Demirel Erkan Demirel · Accepted Answer · 2016-03-02T11:39:24

  public override Task OnDisconnected(bool stopCalled)
        {
            string name = Context.User.Identity.Name;

            _connections.Remove(name, Context.ConnectionId);

            return base.OnDisconnected(stopCalled);
        }

If disconnect occurs gracefully, stopCalled will be true. Otherwise, it will be false (timeout etc), but that doesn't mean signalr is disconnected for sure.

If SignalR is behind a load balancer with scaleout configured, the client may still be connected to another SignalR server.

Even client is not disconnected, OnDisconnected(false) can be fired. Then you remove Context.ConnectionId.

But if client is still connected, then reconnect will be fired. So that time you should check may be you removed this connection with OnDisconnected(false) which is not actual disconnect.

Why are we checking context.connectionId when a recconect in signalR occurs?

1 Answers