SignalR: Why choose Hub vs. Persistent Connection?

There are two ways to use SignalR: you can access it at a low level by overriding its PersistentConnection class, which gives you a lot of control over it; or you can let SignalR do all of the heavy lifting for you, by using the high level ‘Hubs’.

Persistent Connection is a lower level API, you can perform actions on more specific time when the connection is opened or closed, in most applications the Hub is the best choice

The main difference is that you can't do RPC with PersistentConnection, you can only send raw data. So instead of sending messages from the server like this

Clients.All.addNewMessageToPage(name, message);

you'd have to send an object with Connection.Broadcast() or Connection.Send() and then the client would have to decide what to do with that. You could, for example, send an object like this:

Connection.Broadcast(new {
    method: "addNewMessageToPage",
    name: "Albert",
    message: "Hello"
});

And on the client, instead of simply defining

yourHub.client.addNewMessageToPage = function(name, message) { 
    // things and stuff
};

you'd have to add a callback to handle all incoming messages:

function addNewMessageToPage(name, message) {
    // things and stuff
}

connection.received(function (data) {
    var method = data.method;

    window[method](data.name, data.message);
});

You'd have to do the same kind of dispatching on the server side in the OnReceived method. You'd also have to deserialize the data string there instead of receiving the strongly typed objects as you do with hub methods.

There aren't many reasons to choose PersistentConnection over Hubs. One reason I'm aware of is that it is possible to send preserialized JSON via PersistentConnection, which you can't do using hubs. In certain situations, this might be a relevant performance benefit.

Apart from that, see this quote from the documentation:

Choosing a communication model

Most applications should use the Hubs API. The Connections API could be used in the following circumstances:

• The format of the actual message sent needs to be specified.

• The developer prefers to work with a messaging and dispatching model rather than a remote invocation model.

• An existing application that uses a messaging model is being ported to use SignalR.

Depending on your message structure, you might also get small perfomance benefits from using PersistentConnection.

You may want to take a look at the SignalR samples, specifically this here.

From what I see in the Connection and Hubs section it seems that Hubs provide a topic system overlaying the lower-level persistent connections.

From the highly up-voted comment below:

Partially correct. You can get topics or groups in persistent connections as well. The big difference is dispatching different types of messages. For example you have different kinds of messages and you want to send different kinds of payloads. With persistent connections you have to embed the message type in the payload (see Raw sample) but hubs gives you the ability to do RPC over a connection (lets you call methods on on the client from the server and from the server to the client). Another big thing is model binding. Hubs allow you to pass strongly typed parameters to methods.

The example used in the documentation uses a chat room metaphor, where users can join a specific room and then only get messages from other users in the same room. More generically your code subscribes to a topic and then get just messages published to that topic. With the persistent connections you'd get all messages.

You could easily build your own topic system on top of the persistent connections, but in this case the SignalR team did the work for you already.