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

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.