A new open source contribution enables scaled out, high throughput messaging for the asynchronous ASP.NET web event engine, SignalR. In a recent blog post, Clemens Vasters, an Architect on the Windows Azure team, described a new GitHub project that that uses the Windows Azure Service Bus to distribute messages bi-directionally between servers and clients.
SignalR, which is similar to real-time JavaScript frameworks like Socket.IO, enables asynchronous communication from a client to server and also support pushing events from a server to browser clients. While not directly tied to ASP.NET, the open source SignalR project was created by Microsoft’s ASP.NET team to provide a persistent connection mechanism for ASP.NET web applications. SignalR connections occur via the increasingly-popular WebSockets API, or if WebSockets are not available, it transparently falls back to a long-polling technique. To work with SignalR, developers use JavaScript and frameworks like jQuery in the client tier, and write .NET code for server-side applications and services. SignalR has multiple programming models (PersistentConnections and Hubs) that give developers different levels of access to connections, message recipient groups and event handlers.
While SignalR has been shown to scale to tens of thousands of connections on a single machine, developers cannot deploy server-side components across multiple web servers. This leaves solutions with a single point of failure and limits the number of concurrent connections that an application can support. Vasters described how he solved this problem with the Azure Service Bus.
Last week, I built a Windows Azure Service Bus backplane for SignalR that allows deploying SignalR solutions to multiple nodes with message distribution across those nodes and ensuring proper ordering on a per-sender basis as well as node-to-node correctness and consistency for the cursor cookies. That code is Apache licensed and now available on github.
You can use this backplane irrespective where you host solutions that use SignalR, as long as your backend host has access to a Service Bus namespace. That’s obviously best in one of the Windows Azure datacenters, but will work just as well anywhere else, albeit with a few [milliseconds]more latency.
Users of this Azure-backed SignalR project can choose to split messaging traffic across Service Bus Topics which increases throughput beyond what a single Topic can support. This project from Vasters takes advantage of supported SignalR extension points and requires only a small modification to the server application. You can download or view the source code of this project by visiting its site on GitHub.