Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How does SignalR.Redis work under the hood?

Tags:

redis

signalr

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.

like image 452
user1574808 Avatar asked Oct 24 '12 17:10

user1574808


1 Answers

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.

like image 179
davidfowl Avatar answered Oct 15 '22 17:10

davidfowl