SignalR: cómo dejar de crear una nueva conexión en la recarga de la página

Cada conexión solo tiene un ciclo de vida durante el tiempo que el usuario pasa en una página determinada. Cuando navegan a otra página, se establece una nueva conexión. Además, si un usuario tiene más de una pestaña o ventana del navegador abierta, tendrá varias identificaciones de conexión. No creo que desee intentar conservar la identificación de la conexión más allá de su ciclo de vida previsto.

En un escenario similar en el que trabajo, almacenamos los ID de conexión OnConnect y los eliminamos OnDisconnect. Cuando es necesario enviar un mensaje a un usuario determinado, lo enviamos a todos sus identificadores de conexión. Esto asegura que el mensaje se enviará a todas las pestañas/ventanas.

EDIT 1 lo siguiente es en respuesta a los comentarios de @Saurabh:

Considere cuál es el alcance del Hub y el de sus otras clases y el cliente. El Hub está ahí para facilitar las comunicaciones entre el navegador y el servidor. Si bien es posible hacer mucho trabajo dentro del hub, creo que es mejor trasladar la mayor parte del alcance fuera de las comunicaciones a otros lugares.

El cliente sabe que acaba de recargar una página, por lo que es un buen candidato para tomar la decisión de que se trata de un evento de reconexión.

_chatHub.server.reJoinRooms();

Luego, el concentrador puede consultar las salas del usuario, por ID de usuario, en lugar de por ID de conexión.

public Task ReJoinRooms()
{
// get the user's rooms from your repository
// optionally get the user's connectionIds from your repository
// Clients.Caller.onJoinRooms(rooms);
// or Clients.Clients(_connectionIds).onJoinRooms(rooms);
}

Entonces el cliente puede decidir si tomar acción o no:

$chatModule.client.onJoinRooms = function (rooms) {
   for (var i in rooms) {
           var _room = rooms[i];
           // if I'm not already in this room, add it to my rooms
           console.log('joining room', _room)
       }
}

Podrías desollar esto de muchas maneras diferentes. El cliente también podría poseer el alcance de las salas de memoria, en lugar de un repositorio del lado del servidor.

EDIT 2

Si la cantidad de grupos/salas a las que pertenece un usuario es cada vez mayor, es posible que el ejemplo anterior no se amplíe muy bien.

En ese caso, cada usuario podría unirse a fuentes personales en su lugar (es decir, unirse a una fuente con el nombre del GUID del usuario). Mantendríamos un registro de cada usuario que está afiliado a un grupo. Cuando se envía un mensaje a ese grupo, iteramos sobre los de esos usuarios y publicamos un mensaje en cada feed.