No, non c'è white paper ed è come 200 righe di codice, quindi non così tanto da ingoiare.
In SignalR ogni messaggio passa attraverso una cosa chiamata bus di messaggi. Quando si desidera eseguire la scalabilità orizzontale tra nodi (o processi o domini di app), l'implementazione di questo bus deve essere in grado di comunicare con ogni istanza dell'applicazione. Per fare ciò puoi utilizzare il RedisMessageBus. Redis ha un meccanismo secondario pub e la capacità di archiviare coppie di valori chiave e utilizziamo solo il primo per SignalR.
OffTopic:Questo è MOLTO importante! SignalR NON è un messaggio affidabile, è un'astrazione di connessione. Possiamo memorizzare nel buffer i messaggi per il longpolling, ma **non puoi* fare affidamento sul fatto che i messaggi siano lì per sempre. Se hai messaggi importanti che devi persistere, mantienili.
Ogni server Web si connette a uno (o più nella nuova implementazione) eventi redis per inviare messaggi tra di loro. Quando un messaggio arriva per uno o più client, viene inviato al backplane (redis) e arriva su tutti i server web. Ogni server web riceve il messaggio da redis e lo archivia in una cache locale. Questa cache locale è dove vengono serviti i client SignalR (browser, ecc.).
Una parte importante del design della scalabilità orizzontale sono i cursori. Un cursore rappresenta dove si trova un particolare client in un flusso infinito di messaggi. Quando i client si riconnettono dopo aver interrotto una connessione o una connessione longpolling ritorna dopo aver ricevuto un messaggio, chiede al bus di ricevermi tutto da un valore del cursore. I cursori sono definiti dall'implementazione del bus di messaggi e l'abbiamo normalizzato nelle ultime fonti (non ancora rilasciate al momento della scrittura ma non entrerò nei dettagli qui). Il cursore nell'attuale implementazione di redis è solo un numero che viene incrementato, niente di troppo complicato.
Si spera che questo dia un'idea di come funziona.
