SignalR long-polling is disconnected in 5 seconds

Question

My application is working under corporate network (ugly proxies and stuff). And it does not work very well. I hoped using https would help but it did not. Here is a weird pattern I see in the logs:

[14:13:32 GMT+0600 (N. Central Asia Standard Time)] SignalR: Client subscribed to hub 'modemshub'.
[14:13:32 GMT+0600 (N. Central Asia Standard Time)] SignalR: Negotiating with '/signalr/negotiate?clientProtocol=1.5&connectionToken=6aktO0sramoQKhQ9DC7Cs7EbXMUou8LooQRxfup4R0oZCHpBmWBFjyLup%2F3wJLloR8GtJEiUk10YOZJBaSqN8aiGAfXRR4G9hujTFTyiJiz%2FyJ4oMlBIdxqeCc5anI6k&connectionData=%5B%7B%22name%22%3A%22modemshub%22%7D%5D'.
[14:13:32 GMT+0600 (N. Central Asia Standard Time)] SignalR: longPolling transport starting.
[14:13:32 GMT+0600 (N. Central Asia Standard Time)] SignalR: Opening long polling request to 'https://example.com/signalr/connect?transport=longPolling&clientProt…rlCzGHl5kVLClT5ex8&connectionData=%5B%7B%22name%22%3A%22modemshub%22%7D%5D'.
[14:13:33 GMT+0600 (N. Central Asia Standard Time)] SignalR: Long poll complete.
[14:13:33 GMT+0600 (N. Central Asia Standard Time)] SignalR: LongPolling connected.
[14:13:33 GMT+0600 (N. Central Asia Standard Time)] SignalR: longPolling transport connected. Initiating start request.
[14:13:33 GMT+0600 (N. Central Asia Standard Time)] SignalR: Opening long polling request to 'https://example.com/signalr/poll?transport=longPolling&clientProtoco…rlCzGHl5kVLClT5ex8&connectionData=%5B%7B%22name%22%3A%22modemshub%22%7D%5D'.
[14:13:33 GMT+0600 (N. Central Asia Standard Time)] SignalR: The start request succeeded. Transitioning to the connected state.
[14:13:38 GMT+0600 (N. Central Asia Standard Time)] SignalR: Long poll complete.
[14:13:38 GMT+0600 (N. Central Asia Standard Time)] SignalR: Stopping connection.
[14:13:38 GMT+0600 (N. Central Asia Standard Time)] SignalR: Fired ajax abort async = true.

So the connection is established and 5 seconds later it is aborted (while ConnectionTimeout equals to 110 seconds). And this pattern is repeated again and again. That's just weird.

Answer 1

Background

According to Asp.net :

SignalR uses the transport API to create a transport connection, and the transport API depends on the existence of a physical network connection to create the transport connection. The transport connection ends when SignalR terminates it or when the transport API detects that the physical connection is broken.

Physical connections might be slow or there might be interruptions in connectivity. Depending on factors such as the length of the interruption, the transport connection might be dropped. SignalR then tries to re-establish the transport connection. Sometimes the transport connection API detects the interruption and drops the transport connection, and SignalR finds out immediately that the connection is lost. In other scenarios, neither the transport connection API nor SignalR becomes aware immediately that connectivity has been lost. For all transports except long polling, the SignalR client uses a function called keepalive to check for loss of connectivity that the transport API is unable to detect.

Troubleshooting

Note that SignalR 2.1 introduced keep-alives for long polling. This could be problematic if something is interfering with chunked HTTP responses. If you want to disable keepalive functionality, set KeepAlive to null. Keepalive functionality is automatically disabled for the long polling transport.

If you're using a Self-Host, use the followings with 3 args instead:

GlobalHost.Configuration.ConnectionTimeout = new TimeSpan(0,0,110);
GlobalHost.Configuration.DisconnectTimeout = new TimeSpan(0,0,30);
GlobalHost.Configuration.KeepAlive = new TimeSpan(0,0,10);

As a different alternatives to support a keep alive "like" feature for long polling, Create a server method name it Ping:

public class MyHub : Hub
{
    public void Ping()
    {
    }
}

Then, on the client create an interval in which you will Ping the server:

var proxy = $.connection.myHub,
    intervalHandle;  
...
$.connection.hub.disconnected(function() {
    clearInterval(intervalHandle);
});  
...  
$.connection.hub.start().done(function() {
    // Only when long polling
    if($.connection.hub.transport.name === "longPolling") {
        // Ping every 10s
        intervalHandle = setInterval(function() {
            // Ensure we're connected (don't want to be pinging in any other state).
            if($.connection.hub.state === $.signalR.connectionState.connected) {
                proxy.server.ping().fail(function() {
                    // Failed to ping the server, we could either try one more time to ensure we can't reach the server
                    // or we could fail right here.
                    TryAndRestartConnection(); // Your method
                });
            }
        }, 10000); 
    }
});

I hope to be useful.

Answer 2

Assume the tips available in Understanding and Handling Connection Lifetime Events in SignalR where you can employ good solutions to handle connection lifetime based on the network problem. Furthermore, In SignalR's issues I found the following solution for you which works with long-polling too.

You can set the KeepAlive property on the ConfigurationManager and SignalR will send an empty frame of data (based on the transport) on the specified interval to keep the connection alive (look at Allow host to specify keep alive times). The current time-out mechanism makes the streaming protocols no different.

Answer 3

Seems like this behaviour is caused by a bug in SignalR 2.1. There was a similar bug reported: https://github.com/SignalR/SignalR/issues/3557 So we downgraded SignalR to 2.0.3 and this behaviour disappeared.