0

we are looking for a way to have a background process to push out messages to the connected clients.

The approach we are taking is that whenever a new connection is established (OnConnected) we stored the connectionId alone with some request metadata (for later filtering) in our mongo db. And when an event happened (triggered from client or backend process), a workerrole (another background process) will listen to those events (via messaging or whatever) then based on the event detail it will filter the connected client using the metadata captured.

The approach seems to be ok, but we have a problem when

  1. signalr server goes down
  2. before the server comes backup, the client disconnects (close browser or whatever)

  3. signalr server goes back up

  4. we are left with connections in the mongodb which we dont know their connection status

i am wondering if there is a better way to do this, the goal is to be able to target specific connected client to push message to from a backend service (worker role)

by the way, we are using scaleout option with service bus backplane

Eatdoku
  • 6,569
  • 13
  • 63
  • 98
  • You could make it so on application start for the server it assigns the disconnect date or whatever flag you are using to any open connections. – Tony Jul 24 '14 at 18:30

1 Answers1

0

The following guide on Mapping SignalR Users to Connections goes over several options you have for managing connections.

The approach you are currently taking falls under the "Permanent, external storage" option.

If you want/need to stick with that option, you could add some sort of cleanup procedure that periodically removes connections from your database that have been inactive for longer than a specified time. Of course, you can also proactively remove old entries when a client with matching metadata reconnects with a new connectionId.

I think the better alternative is to use a IUserIdProvider or (single-user?) groups assuming your filtering requirements aren't too complex. Using either of these options should make it unnecessary to store connectionIds in your database. These options also make it fairly easy to send messages to multiple devices/tabs that a single user could have open simultaneously.

halter73
  • 15,059
  • 3
  • 49
  • 60
  • that's a good option too, new client connection that matches the saved metadata – Eatdoku Jul 24 '14 at 18:47
  • one problem with using group is that they are not persisted, to over come that you basically need to manage the group and connections in the group anyways~ – Eatdoku Jul 31 '14 at 06:36
  • The client should stay in the group until stop is called on the client, or the client otherwise completely disconnects from the server (i.e. it has stopped tying to automatically reconnect). If you want to use the group solution, you should have a way to always add the same user to the same group in OnConnected in case you have to manually restart the client. – halter73 Jul 31 '14 at 18:35