Have you heard about the new web technique called SignalR? It's a new endeavor by Microsoft to enable real-time updates to websites. Companies such as Google and Apple have implemented some of these techniques into their products. The GMail website is a excellent example of a service that does not require refreshing. Microsoft is taking this idea to the masses by providing an open source solution available to the development community.

Developers have been attempting persistent server connections for years. It started with constant polling. This technique required each client to continually send requests every few seconds. This led to the idea of long polling. With this technique a client sends a request to the server and the server keeps the request open until it times out. If updates are found within that time, the server sends down the data and the traditional connection is closed. At that time the client must initiate another request. This technique lead to a new protocol called WebSockets. In WebSockets persistant connections can be opened between a client and server over a browser.

With WebSockets available it sounds like an open and shut case for persistent connections. Right? Unfortunately, only Chrome 16+, Firefox 11+, Internet Explorer 10 and IIS8 support WebSockets. Regrettably we are forced into older technologies for the next few years. Microsoft is aiming to make this transition as smooth as possible with the introduction of SignalR. This library will attempt to make the most efficient connection possible based on the capabilities of the server and client. It automatically defaults to less efficient methods if necessary. The options are specified below (in order):

WebSockets - which currently has limited browser and server support
Server-Sent Events (Event Source) - this technique supports "push" style notifications (not available in Internet Explorer)
IFrame Injection - this technique sends script blocks to a hidden iframe
Long Polling - this is the technique mentioned previously

Let's look under the hood a little bit more. SignalR uses a concept called "hubs" to separate communication between different areas of a website. This is not automatic and some development is required. Each connection to a hub is assigned a GUID. Keeping track of the GUID to user relationship is the developer's responisibilty. The library contains connect and disconnect intrinsics which eliminates unnecessary communication with disconnected clients. In addition, messages can be broadcast to all, groups, or individual connections. Data within SignalR is communicated through strings but will support complex types that can be serialized to JSON.

If scalability, performance and longevity are concerns, Microsoft offers two service bus options for cross server synchronization and scalability: Redis and Windows Azure. Redis is an open source solution that was ported from Linux. Windows Azure is Microsoft's cloud platform solution. Initial load tests show a 50% performance increase over standard http requests. Microsoft has tasked themselves with tripling this efficiency in the coming months. The initial support for SignalR includes: Javascript, .NET, Silverlight, Windows Phone 7 and WinRT (Windows Metro). The open source community has already provided iOS and Mono solutions with more to come. An excellent wiki provided by Microsoft is available on GitHub for getting started.

Final Thoughts
SignalR has a bright future in store. It has the potential to impact the web in the same manner as Ajax or JQuery. Envisioning the future of websites is endless. There are a variety of places where we could see direct impact such as chat applications, live dashboards and Windows 8 Metro apps. The real potential is in the unknown. Once this library takes root, developers will push it to its limits and beyond. This is another great step in closing the gap between desktop and internet applications.

What are you thoughts? Questions?

An introduction to SignalR (a.k.a Signal Arrrrrrr)