SignalR and Browser Connection limit

Question

I made a simple app with SignalR for testing. When the page loads it calls a function on the server, that function then calls a client function that prints a message on the screen. I did that to check that both the client and server function works and SignalR communication works ok.

My problem is that if I open the same page on two different tabs (did it in Chrome), the first page loads ok, but the second page doesn't call the server's functions - ONLY if I close the first page.

So as far as I understand, their is probably a connection limitation that is related to the browser that doesn't allow SignalR to connect more then once (actually two, one for receiving and one for sending)

Update: I've find our that other tabs where open, but now I've checked it through and it allows only 4 tabs / pages to be active with connections. If I try to put the same page on a new tab no data is being sent, when I close one of the other tabs, the new tab sends the data right away.

What I wanted to know if there is any solution for that, because I want this connectivity to be available if the user decide to open the same page on two tabs or more.

I don't believe that it has anything to do with IIS, because from what I know it can accept thousands of connections.

Answer 1

Make sure SignalR can use and is using WebSockets and it won't use one of the limited number of connections your application is allowed to use.

SignalR kan use different transport protocols and how SignalR decides which to use is described here:

HTML 5 transports

These transports depend on support for HTML 5. If the client browser does not support the HTML 5 standard, older transports will be used.

• WebSocket (if both the server and browser indicate they can support Websocket). WebSocket is the only transport that establishes a true persistent, two-way connection between client and server. However, WebSocket also has the most stringent requirements; it is fully supported only in the latest versions of Microsoft Internet Explorer, Google Chrome, and Mozilla Firefox, and only has a partial implementation in other browsers such as Opera and Safari.
• Server Sent Events, also known as EventSource (if the browser supports Server Sent Events, which is basically all browsers except Internet Explorer.)

and

Transport selection process The following list shows the steps that SignalR uses to decide which transport to use.

1. If the browser is Internet Explorer 8 or earlier, Long Polling is used.

2. If JSONP is configured (that is, the jsonp parameter is set to true when the connection is started), Long Polling is used.

3. If a cross-domain connection is being made (that is, if the SignalR endpoint is not in the same domain as the hosting page), then WebSocket will be used if the following criteria are met:

   • The client supports CORS (Cross-Origin Resource Sharing). For details on which clients support CORS, see CORS at caniuse.com.

   • The client supports WebSocket

   • The server supports WebSocket

     If any of these criteria are not met, Long Polling will be used. For more information on cross-domain connections, see How to establish a cross-domain connection.

4. If JSONP is not configured and the connection is not cross-domain, WebSocket will be used if both the client and server support it.

5. If either the client or server do not support WebSocket, Server Sent Events is used if it is available.

6. If Server Sent Events is not available, Forever Frame is attempted.

7. If Forever Frame fails, Long Polling is used.

Using developer tools, check the network calls made on your page. You should be able to see something like:

.../connect?transport=webSockets&clientProtocol=1.5&connectionToken=...

If transport is something else than webSockets (for example serverSentEvents or longPolling) you might want to troubleshoot client and server to see why the handshake does not result in using WebSockets. (In my case, I had missed installing the WebSocket protocol windows feature for IIS.

Answer 2

I've created IWC-SignalR utility which allows to have single SignalR connection for all windows (tabs) of the same application.

How it works

One of the windows becomes a connection owner (choosen randomly) and holds the real SignalR connection. If connection owner is closed or crashed another window becomes a connection owner - this happens automatically. Inter-window communication is done by means of inter-window communication library (based on localStorage). This library provides functionality to communicate between windows as between parallel processes (locks, shared data, event bus...). Hope it will be useful for someone.

Answer 3

This problem would be best addressed by the future Channel Messaging specification, which has not been implemented by any browsers to-date, but I managed to solve it by limiting the number of connections as described by Alex Ford and using localStorage as a message bus between tabs.

The storage event lets you propagate data between tabs while keeping a single SignalR connection open (thereby preventing connection saturation). Calling localStorage.setItem('sharedKey', sharedData) will raise the storage event in all other tabs (not the caller):

$(window).bind('storage', function (e) {
    var sharedData = localStorage.getItem('sharedKey');
    if (sharedData !== null)
        console.log(
            'A tab called localStorage.setItem("sharedData",'+sharedData+')'
        );
});

You can test if ($.connection.hub.state === 1) to determine if a given tab should notify the other tabs via localStorage (courtesy of Alex) to prevent duplicate localStorage.setItem calls.

Facebook overcomes this browser limitation by serving persistent connections over several sub-domains, but this can complicate deployment and testing.

Caveats

Old Connections: In Alex's solution, you need to be careful of Disconnect() not being called (e.g. exception), and you filling up your HubConnections bucket (or repository) with old hub connections. If the Session ID does not change (can happen), this may prevent new clients from establishing a SignalR connection even though none are active. Alternatively, timestamp new connections and have a sliding expiration to minimise potential impact.

Locking: localStorage may be subject to race conditions as it does not implement any locking as described here.

To support different types of events, you should encode an eventType in your JSON messages and test for it on the storage event.

Fallbacks

If a SignalR connection cannot be established, I fall back onto polling the server every 45 seconds to retrieve a notification count.

If you don't want to use localStorage, you can use cookies, but it's not as clean.

Answer 4

To expand on @FreshCode's answer, this is how I implemented his idea.

I had a need to pass two different actions between tabs. I can either set notifications or remove notifications. These notifications are received by the browser and stored as timeouts that will fire at a specified time. The first tab has the SignalR connection and all the others do not. One issue I had to overcome was that the "storage" event would fire no matter which action I was intending to perform (set/remove).

What I ended up doing was passing along a custom JSON object with a property containing the action I wanted to perform:

$(window).bind('storage', function () {
    var updateInfo = JSON.parse(localStorage.getItem('updateInfo'));
    if (updateInfo.action == 'removeNotification')
        removeNotification(updateInfo.notificationId);
    else if (updateInfo.action == 'setNotification')
        setNotification(updateInfo.notification);
});

This way each time I set an item in local storage, I just specify the action that needs to occur and only that action will happen on the other tabs. For example, if I update a notification it is a combination of both actions when it is received by the client. It removes the notification and sets the notification with the updated values. So two calls to localStorage.setItem are being made.

function removeNotification(id) {
    // Check if signalR is connected. If so, I am the tab that will update
    // the other tabs.
    if ($.connection.hub.state === 1) {
        var updateInfo = {
            action: 'removeNotification',
            notificationId: id
        };
        localStorage.setItem('updateInfo', JSON.stringify(updateInfo));
    }
    // brevity brevity
}

Likewise, the setNotification function.

function setNotification(notification) {
    if ($.connection.hub.state === 1) {
        var updateInfo = {
            action: 'setNotification',
            notification: notification
        };
        localStorage.setItem('updateInfo', JSON.stringify(updateInfo));
    }
    // brevity brevity
}