SignalR 0.5

This is the rebirth of my blog. I’ve been busy over the last few months with projects like JabbR, SignalR and other stuff. With the upcoming release of SignalR 0.5, I thought it’d be good to write a blog post that touches on some of the things we did.

Webfarm Support

There’s a lot of confusion as to what webfarm support means in SignalR. This is an FYI, SignalR 0.5 will not automatically make your application work on azure with zero effort. SignalR needs a way to communicate between instances of your webserver, in 0.5 we implemented 2 of those providers on NuGet (message buses):

1. SignalR.WindowsAzureServiceBus - http://vasters.com/clemensv/2012/02/13/SignalR+Powered+By+Service+Bus.aspx (blog post slightly outdated but information is relevant).
2. SignalR.Redis – Redis message bus implementation for SignalR - https://github.com/SignalR/SignalR.Redis

When deciding to make SignalR work in a webfarm, you’ll have these 2 options. We’re going to continue improving them as well as implement solutions on top of popular message buses like NServiceBus and lower fidelity solutions built on top of SQL QNS and possibly SQL Server Service Broker.

This wasn’t the only hurdle to making SignalR work in webfarms, there were some nasty bugs that caused some bad behavior that we fixed:

1. Disconnect notifications across webfarms
2. Load balancer idle timeout in azure.

Fixing disconnect in webfarms was the most important issue to fix. Before SignalR 0.5rc, disconnect in a webfarm (using service bus or redis) could fire for the same client multiple times. This is more obvious when using longPolling and load balancing happens between web server instances. If you had control of your LB, you could affinitize clients to a server so you’d never see this behavior, but I’m glad to say we got this fixed.

For load balancer idle timeouts (especially on azure), we support keep-alive. You can now tell SignalR to send an empty packet on a specific time interval. This will fend off nosy network devices that like to kill idle connections waiting for data. This is especially important for things like server sent events and forever frame transports.

Mono Support

In the 0.4 release, SignalR only “worked” when self hosted on mono so I spent time making SignalR work across the board (ASP.NET and all). When I say work, I mean both the client and the server. You can now literally clone SignalR onto your OSX (I didn’t try linux) box and run make and get a successful build (see the README for more details). This wasn’t a simple task as I had to make changes to the NuGet targets file so that package restore worked on mono.

If you’re using Mono develop, open SignalR.Mono.sln. You can run the samples as you would normally. Here’s a glimpse of the chat demo running:

Not much time was spent optimizing and tuning specifically for mono but in the future we’ll have time to do that.

JsonP Longpolling support (XDomain)

This feature wasn’t planned for 0.5 but thanks to an awesome contribution from codeputty, this became a reality.

Dynamic Hubs Implementation

Contributor pszmyd was trying to build better integration between SignalR and Orchard and ended up adding infrastructure to SignalR to decouple Hubs from types (System.Type). This is a great example of why I love OSS development (scratch your own itch).

Continuous Integration and NuGet Server

We finally got a CI server setup on codebetter’s teamcity instance. You can view SignalR here http://teamcity.codebetter.com/project.html?projectId=project188. The CI also builds packages and pushes them to our myget feed. If you want to live on the bleeding edge but don’t want to build from source, you can configure nuget to point to http://www.myget.org/F/signalr/ (make sure you use the –Pre flag or select the Include Prerelease in the dialog).

0.5 Release

Help us test the RC now on NuGet! (http://signalr.net/releases/v0584.html). We’re reserving this week for any bugs that we consider ship stoppers.

What’s Next

We’re going to continue improving SignalR. Future releases will focus on some of the following:

• Performance Improvements
• In the box WebSockets support for Windows8
• Windows 8 .NET Client
• .NET Micro Framework Client
• Web API Host
• Build time hubs.js generation (instead of runtime).
• Better network availability handling
• Better Mobile support (optimized for battery life)
• Web Forms control

… And much more! Check the issue backlog for details on what else we've got planned for upcoming releases.

Come Talk with us

We’re always around in the signalr room on jabbr. Come say hi!