[ACCEPTED]-SignalR: Why choose Hub vs. Persistent Connection?-signalr

Accepted answer
Score: 96

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

From the highly up-voted 25 comment below:

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

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

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

Score: 67

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

Clients.All.addNewMessageToPage(name, message);

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

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

And on the client, instead of simply 25 defining

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

you'd have to add a callback to 24 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 23 to do the same kind of dispatching on the 22 server side in the OnReceived method. You'd also have 21 to deserialize the data string there instead 20 of receiving the strongly typed objects 19 as you do with hub methods.

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

Apart 13 from that, see this quote from the documentation:

Choosing 12 a communication model

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

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

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

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

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

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

Score: 25

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

Score: 5

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

Score: 4

There are three major points to consider 14 when comparing these two:

  • Message Format
  • Communication model
  • SignalR customization

With hubs message 13 formatting is basically handled from you 12 but with persistent connections the message 11 is raw and has be tokenized and parsed back 10 and forth. If the message size is important 9 then also note that the payload of a persistent 8 connection is much less that that of a hub.

When 7 it comes to the communication model persistent 6 connections basically have a function for 5 sending and receiving messaging while hubs 4 take a remote procedure call model with unique function per requirement.

When 3 it comes to customization since persistent 2 connections are more low level they may 1 give you more control over customization.

More Related questions