If you haven’t heard about ASP.NET SignalR, I must tell you, you should. SignalR is now an official Microsoft product, part of the ASP.NET family, and even better, is an open source library (source code in GIT, released under the Apache 2.0 License), which is, well, mega useful for real-time web applications.
I heard about SignalR early versions last year from a couple of colleagues. However, it was until I attended BUILD 2012 last year, that this bad boy positioned itself as a must-know library for web developers. Greg Glass, a veteran in programming, currently holding the title Chief Scientist at R/GA asked me to dig into the topic and put together a presentation for our global tech team.
This post contains the outcome of my research and experience playing around with SignalR, and hopefully it will help you to get started and push the boundaries of real-time web apps on your own.
I have based most of this post in the original BUILD 2012 presentation, the official web site, documentation and source code, and quite a few prototypes that I have been working on myself, replicating and extending what the creators have made available to the community. So, with that being said, lets jump right into it!
What is SignalR?
So, what is real-time web functionality?
It is the ability to have server-side code push content to connected clients instantly as it becomes available (rather than request-response pattern or long pulling).
How does it work? (in pseudo-code)
if WebSockets then Cool,
if !WebSockets then Server Sent Events,
if !Server Sent Events then Forever Frame,
if !Forever Frame then Long Polling
What’s the story?
It started as a side project from two Microsoft developers, Damian Edwards and David Fowler, who started to build the library on their spare time, and 18 months after, it became a full ASP.NET open source product.
Got it? Lets make sure!
SignalR is a real-time, persistent connection abstraction over HTTP for .NET.
Dashboards and Monitoring, Collaborative Anything, User activity feedback, Job Progress, Chat, Gaming, Real-time multiscreen synchronization
What do you get?
Connections API (low-level), which provides you with connect, reconnect and disconnect semantics; ability to broadcast to all clients, groups and individuals; raw data access.
Hubs API (high-level), which is built on top of the Connections API; provides you with remote procedure calls (RPCs) from client-to-server AND server-to-client; provides automatic client proxy generation.
SignalR is asynchronous, from the server, all the way to the client!
How does it compare to WebSockets?
Well, WebSockets are great, but in practice, they only work if:
- Server (OS) and client (Browser) support it
- Infrastructure and Network are compatible and don’t get in the way
- Load balancer/reverse proxy supports it
- Client proxy supports it
- If you are happy programing Raw sockets
- If you can scale-out yourself (synchronization between nodes and connected clients)
What about SignalR’s reach?
- Works everywhere
- Cross browser
- Cross platform (early stages)
- Simple and Powerful API
- Does everything possible to maintain logical connections up
- Scale-out to web farms by the library
What are the current clients supporting SignalR?
- .NET 4.0/4.5
- Silverlight 5
- Windows Store Apps
- iOS (community maintained)
- MonoTouch (community maintained)
Future clients in the works?
- Windows Phone8
- MonoTouch (official)
- MonoDroid (official)
- iOS (official)
- .NET Micro Framework
Cross-browser: IE / Chrome / Safari / FireFox
Cross-Platform: Windows / iOS (Mono) / Linux (Mono)
What is in the latest version?
- Complete rewrite of the internals
- Hub Authorization
- Hub Pipeline Modules (like action filters) – model binding, traces, etc.
- Client-side keep alive
What about performance? Give me some numbers!
- Single Box (100K messages per second)
- Very low memory overhead
- Azure (100K to 500K messages per depending on the data load)
- 100k – 460k concurrent connections on a single box
Can it be optimized?
Out of the box, it will work right away with the standard configuration for around 80% of the cases. However, SignalR is greatly configurable, providing ways to optimize the library for specific use cases and/or specific applications.
Does it scale?
SignalR offers something called the “bus backplane”, which is basically an abstraction to scale real-time web apps using the library across web farms. Basically, it provides a few approaches to sync the different nodes running on a web farm.
SignalR supports three Bus Backplane alternatives:
- Windows Azure and Windows 2012 Service Bus
- MS SQL Server
SignalR offers a Load Test Harness tool that can be compiled, deployed and used on any environment to load test web apps using the library.
ASP.NET SignalR is, without a doubt, the simplest and most robust way to add real-time functionality for .NET web applications. It offers both low-level and high-level APIs, providing a lot of flexibility and customization options. Although is part of the official Microsoft’s ASP.NET family, is a community driven library, which makes it the best of both worlds. It works everywhere, offering graceful degradation to the lowest common denominator supported both by server and client, without you having to worry about it. And on top of all that, you can run it on Apple and Linux environments with Mono.
I’ll be publishing step-by-step articles to help you ramp up and also share any good tutorials and sample apps out there. Feel free to leave your comments and share useful information and experiences.