Multiple signalR connections/hubs on your website

If I have multiple pages that could use multiple hub classes, what is the best way to manage this?

For instance:

Is it bad to navigate to another page in the website and essentially "reopen" the connection to the same hub class that was open on the previous page?
Am I correct in thinking that opening multiple hub connections on a page is ok because they are all unified in one connection, even if they are different hub classes?

回答1:

You can have multiple hubs sharing one connection on your site. SignalR 2.0 was updated to handle multiple hubs over one signlar connection with no lost in performance.

Official docs: http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-server#multiplehubs

All clients will use the same URL to establish a SignalR connection with your service ("/signalr" or your custom URL if you specified one), and that connection is used for all Hubs defined by the service.

There is no performance difference for multiple Hubs compared to defining all Hub functionality in a single class.

回答2:

To start with Hubs read the WIKI entry for Hubs and Client Side of Hubs. There are couple of things according to the context of a multiple pages.

When you start a hub it gives your client an ID which stays the same for that hub (someone can confirm with example) over multiple pages.
Its not bad to reopen the connection to the same hub. You might have hub.start client side method running on all pages however if its one client opening multiple windows or going from one page to another you will have same connection ID on that hub so you can keep in contact. If it was multiple hubs then you have to manage hubs as well as connection IDs. So this question is like "Is it bad to have multiple ISPs serving my internet connection for different websites". You can have them but it is an overkill. A single ISP can server all pages to you as well.
Multiple hubs on a single page is not ideal but it will work. Again the answer need a bit of context to the problem but in general you can differentiate between various requests on same connection ID via groups or using other parameter based approach. Having two hubs on same page may take more resources (need to test this) than using parameters or groups to separate different areas of messaging.

Example:

You have a page that has two parts, a graph which shows real time user activity and an area to see real time data changes done by users as a table. Will you create two hubs or two groups or what? There are other pages which use same graph and data table.

My Solution:

I will create a single hub for the application to recieve real time data from the server.
I will create different methods on server to send graph points and data tables.
I will create client side method on all pages that use these graphs to communicate with server methods on the same hub.

When you switch between pages the client will connect with same hub and request getGraph or getDataTable or both and populate its client with relevant data. Similarly on server when data changes you can call client side method to update all clients or group of them (lets add this complexity)

Assume you have students and teachers looking at your application. They require different level of data access. You can use groups to keep them separate on the hub so you are not sending teachers info to students and students data to teachers.

On your hub join you can add them to join a group associated with their role or any differentiating function.
When you send to all clients , now you can send to group of clients that is teachers or students. Not creating another hub for teachers or students, they are all on same hub.

Coming back to your question of "is it bad" and "is ok" this is difficult to establish without context of actual application. I cant think of a scenario where you can justify multiple hubs apart from Performance.