0

SignalR documentation says that scaleout/backplane works well in case of server broadcast type of load/implementation. However I doubt that in case of pure server broadcast it will cause duplicate messages to be sent to the clients. Consider the following scenario:

  1. I have two instances of my hub sitting on two web servers behind a load balancer on my web farm.
  2. The hub on each server implements a timer for database polling to fetch some updates and broadcast to clients in groups, grouped on a topic id.
  3. The clients for a group/topic might be divided between the two servers.
  4. Both the hub instances will fetch the same or overlapping updates from the database.
  5. Now as each hub sends the updates to clients via the backplane, will it not result in duplicate updates sent to the clients?

Please suggest.

Nagesh Chopra
  • 111
  • 7
  • Why you need a time ?? you can use sql update notifier or manual trigger method. you can take look on this https://github.com/anik123/Chat-With-Angularjs-Signalr-Web-Api---Sql-server – Anik Islam Abhi Apr 05 '15 at 01:56
  • @AnikIslamAbhi : My application is of real time communication nature and is going to have a very high frequency of updates and I do not want to be flooded with update notifier or triggers. Instead what I want is an interval pooling to fetch and send updates to clients without causing a very high number of connections to the database from the receiving end. – Nagesh Chopra Apr 07 '15 at 05:58
  • by saying manual trigger i wanna to mean that notify on user action like if user insert something . then send notification about update to everyone – Anik Islam Abhi Apr 07 '15 at 06:05
  • I have implement something like this. check on my provided github link – Anik Islam Abhi Apr 07 '15 at 06:06
  • @Anik-Islam-Abhi: So the "manual trigger" makes it a "user event driven" or "client-to-client" scenario/application and not "Server Broadcast". My concern is the documentation that says the backplane can be a bottleneck in case of "client-to-client" scenario. Ref: http://www.asp.net/signalr/overview/older-versions/scaleout-in-signalr – Nagesh Chopra Apr 07 '15 at 09:24

1 Answers1

0

The problem is not with SignalR, but with your database polling living inside your hubs. A backplane deals correctly with broadcast replication, but if you add another responsibility to your hubs then it's a different story. That's the part that is duplicating messages, not SignalR, because now you have N pollers doing broadcast across all server instances.

You could, for example, remove that logic from hubs into something else, and letting just one single instance of your server applications use this new piece in order to do the generation of messages by polling, using maybe a piece of configuration to decide which one. This way you would send messages only from there, and SignalR's backplane would take care of the replication. It's just a very basic suggestion and it could be done differently, but the key point is that your poller should not be replicated, and that's not directly related to SignalR.

It's also true that polling might not be the best way to deal with your scenario, but IMO that would be answering a different question.

Wasp
  • 3,395
  • 19
  • 37
  • That makes sense. I actually had this idea but I was concerned that if the one server designated for additional responsibility to fetch and broadcast the updates would go down then the application would stop. This might mean implementing separate logic to monitor the activity of this first server and the second server to track it so that it can take it's turn to do the additional responsibility if the first server is down. – Nagesh Chopra Apr 07 '15 at 06:13
  • I can probably also implement client to client scenario instead of broadcast. But I am curious to know that where does broadcast scenario with SiganlR backplane in a web farm really makes sense if the broadcast responsibility must be assigned to one server only? – Nagesh Chopra Apr 07 '15 at 06:13
  • It makes sense for any client-initiated broadcast (think about a chat system where one user wants to say "hello" to everybody). It also make sense if you have N server which are not just doing SignalR stuff, and any of them can do traditional HTTP behind a load balancer, in such a case you might have a HTTP POST hitting one specific server and generating a broadcast. The problem you have is specific to your case, and your comments make sense, but there are many other cases where broadcasts are initiated "from outside" of the system, and they work just fine with a backplane. – Wasp Apr 07 '15 at 06:34
  • I think the a client-initiated broadcast (e.g. chat) as you say is rather a "Client-to-Client" or "user event driven" scenario and not "Server Broadcast" scenario. Ref: http://www.asp.net/signalr/overview/older-versions/scaleout-in-signalr My application is really a similar user event driven scenario including chat in addition to the other core feature that generates very high frequency updates from a few users to groups of other users. And I was concerned about the documentation (Refer link above) saying that the backplane might be a bottleneck in client-to-client scenario. – Nagesh Chopra Apr 07 '15 at 09:10
  • And so I was thinking of to implement it as a Server broadcast where the messages/updates are not delivered to target clients/group directly & immediately as received from the source client but the server should control the transmission to targets via regular polling of updates from the DB. So far I think that in SignalR broadcast scenario, a web farm will only help increase the servers capacity for max. connections and load but it cannot provide redundancy in case of node failure out of the box. – Nagesh Chopra Apr 07 '15 at 09:21
  • Agree. I took your question in comments more as a general question, and not strictly related to the server context. What you say makes sense, so I guess you'd have to go for a solution where the polling strategy lives outside and its properly made redundant. Or, you "embrace" the fact that messages can be duplicated and implement a client side strategy to discard duplication, i.e. with a TTL strategy. Could it be flooding? Yes, but it might not, it depends on the sizing of your system and it might be acceptable (sometimes it is), that I can't tell. – Wasp Apr 07 '15 at 09:34