22

Other than reading the code in github, is there any white paper type of documentation on how the SignalR.Redis package works? Specifically I am wondering what keys it adds to Redis, update/deletion strategy, etc. When looking inside Redis all I ever see is the one key specified in the following call (i.e. "SignalR.Redis.Sample"):

GlobalHost.DependencyResolver.UseRedis(server, Int32.Parse(port), password, "SignalR.Redis.Sample");

This key just seems to be a counter in Redis. I would assume other keys are being created and quickly deleted to facilitate the messages between each app server connected to Redis.

user1574808
  • 707
  • 1
  • 8
  • 20

1 Answers1

51

No there's no whitepaper and it's like 200 lines of code so not that much to swallow.

In SignalR each message goes through a thing called a message bus. When you want to scale out across nodes (or processes or app domains), the implementation of this bus needs to be able to talk to each instance of your application. To do this you can use the RedisMessageBus. Redis has a pub sub mechanism as well as it's ability to store key value pairs and we only use the former for SignalR.

OffTopic: This is VERY important! SignalR is NOT reliable messaging, it's a connection abstraction. We may buffer messages for longpolling but you **cannot* rely on the messages being there for ever. If you have important messages you need to persist, then persist them.

Each web server connects to one (or more in the new implementation) redis events to send messages between them. When a message comes in for one or more clients, it's sent to the backplane (redis) and it arrives on all web servers. Each webserver gets the message from redis and stores it in a local cache. This local cache is where SignalR clients (browsers etc), are served.

One important part of the scale out design is cursors. A cursor represents where a particular client is in an infinite stream of messages. When clients reconnect after dropping a connection or a longpolling connection comes back after getting a message it asks the bus to get me everything since some cursor value. Cursors are defined by the message bus implementation and we've normalized this in the latest sources (not yet released at time of writing but I won't go into details here). The cursor in the current implementation of redis is just a number that's incremented, nothing too complicated.

Hopefully that gives some idea of what how it works.

davidfowl
  • 37,120
  • 7
  • 93
  • 103
  • 1
    Thanks for the great explanation. Please consider the following scenario: I have a **load-balanced** web-farm in which each server is hosting a hub. Let's assume that all clients are falling-back to long-polling. _Client X_ connects via the load-balancer and his request is sent to _server 1_. On the next poll however, the load-balancer directs his request to _server 2_. My question is, does the backplane ensure that all hubs are aware of all connected clients, regardless of which hub they originally connected to? – demius May 08 '13 at 08:53
  • 1
    The backplane is aware of all servers so everything will just work. It doesn't need to know what server it originally connected to. – davidfowl May 09 '13 at 02:59