L'oggetto Hub di ASP.NET SignalR, per default, mantiene una coda di messaggi in memory sul server. Questo approccio, per quanto semplice, ha il limite di non funzionare correttamente in uno scenario federato, dove abbiamo a disposizione una batteria di server dietro a un load balancer: in questo caso, infatti, non è garantito (anzi, è assolutamente improbabile) che ogni server web abbia a disposizione la lista completa delle connessioni attive e sia in grado di inoltrare correttamente il messaggio.

Questa problematica si verifica, per esempio, quando stiamo utilizziamo Windows Azure, e abbiamo già visto in uno script su WinFXItalia.com di questo stesso speciale che, in questo scenario, possiamo sfruttare Service Bus per mantenere e indirizzare la coda dei messaggi.

Se però non abbiamo a disposizione Windows Azure, possiamo comunque gestire facilmente questa problematica. Tutto ciò che dobbiamo fare è installare un package di NuGet denominato Microsoft.AspNet.SignalR.SqlServer, che sfrutta un database SQL Server per mantenere una coda dei messaggi da inviare. Una volta terminata l'installazione, possiamo attivare questa modalità di funzionamento con il codice seguente su Global.asax:

protected void Application_Start()
{
  GlobalHost.DependencyResolver.UseSqlServer(
    ConfigurationManager.ConnectionStrings["SignalR"].ConnectionString);

  // ...
}

L'extension method UseSqlServer accetta come parametro una stringa di connessione verso il nostro database; quest'ultimo, dovrà essere già esistente sul server, anche se vuoto: sarà infatti l'engine stesso a creare le tabella necessarie.

Sebbene sia in grado di funzionare anche in modalità tradizionale, per incrementare le prestazioni può essere conveniente abilitare il service broker di SQL Server sul database utilizzato da ASP.NET SignalR con questa istruzione T-SQL:

ALTER DATABASE SignalR SET ENABLE_BROKER

Un'ultima nota riguarda il fatto che, una volta attivata questa funzionalità, ASP.NET SignalR esegue continui polling sulla base dati per verificare la presenza di messaggi da inoltrare. Pertanto può essere consigliabile utilizzare un'istanza di SQL Server ad-hoc, per evitare di sovraccaricare troppo quella utilizzato per la vera e propria gestione dei dati.