June 2012 - Posts

SignalR 0.5.1 Released

Here comes another exciting release of SignalR. This release has some new features that you can take advantage of as well as a few bug fixes. Let’s go over the big changes for this release.

Windows 8 Client support

With the Windows 8 Release Preview, we’ve finally added a new client to support “.NET for Metro Style Apps” and also made some fixes so that SignalR’s JavaScript client works with WinJS.

WebSocket Support

Previously, websocket support required a separate package, now it’s built into SignalR. The ASP.NET host is the only one that supports this and that’s only when running an application targeting .NET 4.5 on IIS8.

Improved Cross Domain Support

We introduced cross domain support for SignalR in 0.5. In this release we’ve improved that support in a few ways:

  1. All SignalR end points are CORS enabled by default. This means you can point the JavaScript client to the endpoint and have it just work without having to manually add the cors header to web.config.
  2. SignalR will choose automatically negotiate the transport so there’s no need to specify it or the xdomain flag (which is no longer supported).
$.connection.hub.url = 'http://localhost:8081/signalr;

$.connection.hub.start();

The above code is all you need to do to connect to a remote server using SignalR.

Connection State Changes

A SignalR connection has always been a black box to the user and this made it hard to detect changes in the underlying connection state. We’ve exposed a new stateChanged event in the JavaScript and .NET clients. This allows you to listen for state changes and react to them in different ways. Here’s an example that shows the user a message if the connection went into a reconnecting state and didn’t recover after 10 seconds:

var chat = $.connection.chat;
var timeout = null;
var
interval = 10000;

chat.addMessage =
function
(msg) {
    $(
'#messages').append('<li>' + msg + '</li>'
);
};

$.connection.hub.stateChanged(
function
(change) {
   
if
(change.newState === $.signalR.connectionState.reconnecting) {
        timeout = setTimeout(
function
() {
            $(
'#state').css('backgroundColor', 'red'
)
                        .html(
'The server is unreachable...'
);
        }, interval);
    }
   
else if
(timeout && change.newState === $.signalR.connectionState.connected) {
        $(
'#state').css('backgroundColor', 'green'
)
                        .html(
'The server is online'
);

        clearTimeout(timeout);
        timeout =
null;
    }
});

$.connection.hub.start();

When the connection state changes to reconnecting, we set a 10 second timer, if the state doesn’t change to “connected” in those 10 seconds then we set the message to say the server is unreachable. When the connection comes back online (i.e the state the connected), we set the message, “The server is online”.

This feature should give app developers a chance to deliver nicer user experiences when for clients on crappy connections or when servers go down unexpectedly. We’ll continue to improve this in the future.

Clean Disconnect

Normally when a connection is broken between the browser and server, the underlying http request takes some time to go away (you can use fiddler to see this). In 0.5.1 we’ve added the ability for the client to send a packet to the server whenever a connection is stopped or the browser is closed. This means disconnect will fire more immediately on browser close or on page refreshes.

Hubify.exe

It’s not a nuget package but will be in the http://chocolatey.org/ gallery soon. For now, you can run get hubify.exe by building https://github.com/SignalR/SignalR/tree/master/SignalR.ProxyGenerator. You can run this against your project’s bin directory or a remote url to generate or download the hubs.js file that would normally be dynamically generated when referencing the magic script url:

<script src="signalR/hubs" type="text/javascript"></script>

You can add this to a post build event in your project to generate the file a build time so that you can take advantage of http caching when you deploy your application (See an example here).

Keep Alive

Keep alive is now on by default and is set to 30 seconds.

Those are the highlights, view the release notes for more information.

Get it on NuGet today!

Posted by davidfowl with 11 comment(s)
More Posts