Não, não há whitepaper e são como 200 linhas de código, então não é muito para engolir.

No SignalR, cada mensagem passa por uma coisa chamada barramento de mensagens. Quando você deseja expandir em nós (ou processos ou domínios de aplicativo), a implementação desse barramento precisa ser capaz de se comunicar com cada instância do seu aplicativo. Para fazer isso, você pode usar o RedisMessageBus. O Redis tem um mecanismo de sub de publicação, bem como a capacidade de armazenar pares de valores de chave e usamos apenas o primeiro para SignalR.

OffTopic:Isso é MUITO importante! SignalR NÃO é uma mensagem confiável, é uma abstração de conexão. Podemos armazenar mensagens em buffer para longpolling, mas você **não pode* confiar que as mensagens estarão lá para sempre. Se você tiver mensagens importantes que precisa persistir, persista-as.

Cada servidor web se conecta a um (ou mais na nova implementação) eventos redis para enviar mensagens entre eles. Quando uma mensagem chega para um ou mais clientes, ela é enviada para o backplane (redis) e chega em todos os servidores web. Cada servidor web recebe a mensagem do redis e a armazena em um cache local. Este cache local é onde os clientes SignalR (navegadores, etc.) são servidos.

Uma parte importante do design de expansão são os cursores. Um cursor representa onde um determinado cliente está em um fluxo infinito de mensagens. Quando os clientes se reconectam depois de descartar uma conexão ou uma conexão longpolling volta depois de receber uma mensagem, ele pede ao barramento para me obter tudo desde algum valor de cursor. Os cursores são definidos pela implementação do barramento de mensagens e normalizamos isso nas fontes mais recentes (ainda não lançadas no momento da redação, mas não entrarei em detalhes aqui). O cursor na implementação atual do redis é apenas um número que é incrementado, nada muito complicado.

Espero que isso dê uma ideia de como funciona.