November 2012 - Posts

Microsoft ASP.NET SignalR

Yes, you read that right, Microsoft.AspNet.SignalR. It’s been a while since I last blogged as we’re super busy trying to make SignalR rock solid and 1.0 quality for you all to use. I’ve also given my first talk ever at Monkeyspace and then BUILD - both on SignalR. SignalR 1.0 alpha has been live for just over 2 weeks on NuGet, and a few seconds ago I just published alpha2. A lot has changed since 0.5.3 and there have been several people poking around trying to find out what’s changed and what’s new in the alpha. There’s also been lots of confusion about what to use, so I’m going to clear things up by enumerating the list of major changes.

New Packages

There are new packages that you can use today in your applications.

  • Microsoft.AspNet.SignalR – meta package (use this)
  • Microsoft.AspNet.SignalR.Client – .NET 4 and WinRT client
  • Microsoft.AspNet.SignalR.JS – The Javascript client.
  • Microsoft.AspNet.SignalR.Core – Core server package with no host implementation
  • Microsoft.AspNet.SignalR.Hosting.AspNet – The ASP.NET host
  • Microsoft.AspNet.SignalR.Hosting.Utils – utilities for signalr (signalr.exe)
  • Microsoft.AspNet.SignalR.Redis – Redis message bus implementation
  • Microsoft.AspNet.SignalR.ServiceBus – Service bus message bus implementation

If you’re using the NuGet dialog, pick the IncludePrerelease in the dropdown to see them. If you’re using the package manager console, use the –pre flag to install it.

Install-Package Microsoft.AspNet.SignalR –pre

Visual Studio Integration

When you install the ASP.NET 2012 Fall Update, you’ll see a few new things in your Add New Item menu.

VsIntegration

These will bring in the alpha1 packages but you can update them using NuGet to get the latest and greatest.

Hub API changes

First thing to notice is the client and server members on the hub object. This came about because there was a subtle issue with naming methods on the client and server. If they were called the same thing it just wouldn’t work so we decided to separate the namespaces. As you already guessed, you can declare methods that the server calls on the client object and call methods that exist on the server with the server object.

On the server side we’ve added quite a few new APIs for hubs after lots of feedback and discussion.

This is a dump of all the new surface we’ve added for hubs. The comments are pretty self explanatory but as part of this work we resolved this long standing feature request https://github.com/SignalR/SignalR/issues/105 (it’s almost a year old!).

Connected, Disconnected and Reconnected

Before we had these awful interfaces you had to implement to detect this, now it’s just an override on the Hub itself.

No more magic?

There’s obviously still some magic, just a bit less than before. When using hubs, people always wondered how this magic ~/signalr/hubs url was getting registered. This is now an explicit call the developer has to make to enable this route. When you install the new package, it’ll add a RegisterHubs.cs file to the project in the App_Start folder.

There's even a little comment telling you what MapHubs does. If you want to, you can remove this file and just add the call to your global asax with the rest of your route registration.

Hub Pipeline

This is the most powerful feature we’ve added in the new release. Think of the hub pipeline like mvc filters but more powerful. You get to inject any piece of code anywhere in the hub pipeline for incoming and outgoing calls. Here’s an example of a hub pipeline module that logs all outgoing and incoming calls.

The module has a bunch of different methods you can override, the above sample only shows 2 of them. Each method takes the appropriate context so you can get whatever information you want about the incoming or outgoing invocation. The next feature on the list builds on the pipeline implementation.

Authorization

Many of you wanted an easy way to mark a hub as requiring authorization and now you can do that by just specifying an attribute similar to MVC.

Now you can decorate your hubs or hub methods or both to get different granularities of security. The first example shows requires authorization for all connections to the hub and calls to any incoming methods. In the second example, any connection to the hub as well as calls to Send require authorization, but calls to Send2 do not.

Client side keep alive

This feature allows clients to react to slow/buggy networks that drop connectivity often. The JavaScript client checks for a keep alive ping from the server on a configurable interval and raises the “connection slow” event before it drops the connection and starts reconnecting.

Rejoining Groups

There’s tons of confusion about how groups work in SignalR and how it works in scaled out environments (http://stackoverflow.com/questions/11143220/signalr-groups-filtering-handled-on-client-or-server). SignalR stores enough state on the server to make groups work, but all groups that a client is a member of is round-tripped with that client. This of course means that any client can claim they are in a group and spy on your messages. Groups are not a security feature, it’s about message filtering. By default, SignalR will ignore groups that are sent from client to server (to be secure by default). Clients will not be able to receive messages for groups they were in after a reconnect for most transports, but for longpolling it will be immediate. Developers can re-enable the default behavior by enabling a pipeline module that trusts the client’s groups.

If you’re more advanced and want to apply a custom filter to pre-process groups for particular clients, you can write a custom pipeline module to do so.

New Scale Out Providers

We’ve completely re-worked the scale out providers for service bus and redis and added sql server to the list (not shipping with this release but you can use the source). As part of this work, we’ve abstracted a ScaleOutMessageBus base class that each of these providers derive from in order to cleanly plug into SignalR. Check out the class for more details.

More Memory Efficient and huge throughput gains

The MessageBus was complete re-written and optimized for small messages (we normally test with 32 byte sized message payloads) and high throughput. More memory efficient means that we can get more connections on a single node. By the time we RTM, we’ll have documentation and guidance on how to do capacity planning on your webservers and on azure.

Performance Counters

We have a utility called signalr.exe (in the Microsoft.AspNet.SignalR.Hosting.Utils package) that you can use to do a few things.

  • Install/Uninstall SignalR performance counters
  • Generate a static js file for the magic ~/signalr/hubs url.

You can install the performance counters if you want to see more detailed information about your SignalR applications. Here’s a view of what that looks like:

Counters

 

NOTE: To use these on full IIS you need to add the app pool user for your application to the Performance Monitor Users group.

Message payload size

We’ve made some changes (not in alpha2 but later) to reduce the size of our payload dramatically and as a result changed the protocol for 1.0 as well. I’ll talk about this more in a later post.

Documentation

We’re in the process of updating it as well as preparing content for http://www.asp.net/signalr. Stay tuned!

THANK YOU ALL

Thank you all for being a part of this amazing journey from side project to official project. Thanks to your enthusiasm it has has grown rapidly into a framework that people just love to use! Keep giving us feedback! Ping me on jabbr or twitter if you have any questions!

Posted by davidfowl with 24 comment(s)
More Posts