我的應用程序在公司網絡（醜陋的代理和東西）下工作。而且它不能很好地工作。我希望使用https將有所幫助，但事實並非如此。這是一個奇怪的圖案我在日誌中看到：SignalR長輪詢在5秒內斷開連接

[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.

所以在建立連接並在5秒後，它被中止（而ConnectionTimeout等於到110秒）。而這種模式一再重複。這很奇怪。

來源

2015-10-01 SiberianGuy

似乎這種行爲是由SignalR 2.1中的一個錯誤引起的。有一個類似的bug報告：https://github.com/SignalR/SignalR/issues/3557所以我們將SignalR降級到2.0.3，這種行爲消失了。

來源

2015-10-16 09:15:14 SiberianGuy

背景

根據Asp.net：

SignalR使用傳輸API創建傳輸連接，並且傳輸API取決於物理網絡連接以創建傳輸連接的存在。當SignalR終止傳輸連接或傳輸API檢測到物理連接斷開時，傳輸連接結束。

物理連接可能很慢，或者連接可能會中斷。根據中斷的長度等因素，傳輸連接可能會丟失。 SignalR然後嘗試重新建立傳輸連接。傳輸連接API有時會檢測到中斷並丟棄傳輸連接，SignalR立即發現連接丟失。在其他情況下，傳輸連接API和SignalR都不會立即意識到連接已丟失。 對於除長輪詢以外的所有傳輸，SignalR客戶端使用稱爲keepalive的函數來檢查傳輸API無法檢測到的連接丟失。

Troubleshooting

注意 SignalR 2.1推出的保持有效指示爲長輪詢。如果某些內容干擾分塊的HTTP響應，這可能會有問題。如果您想要disablekeepalive功能，請將KeepAlive設置爲null。 Keepalive功能自動disabled爲長輪詢運輸。

如果你using a Self-Host，請使用以下3 ARGS代替：

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

由於不同的替代方案，以支持保活「喜歡」功能的長輪詢，創建一個服務器的方法名它Ping：

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

然後，客戶機上創建的，您將Ping服務器的間隔：

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); 
    } 
});

我希望能夠有用。

來源

2015-10-05 10:42:01

假設Understanding and Handling Connection Lifetime Events in SignalR中的提示可用於您根據網絡問題使用良好解決方案來處理連接生命週期。此外，在SignalR的問題中，我找到了適合您的以下解決方案，它也適用於長輪詢。

您可以在ConfigurationManager上設置KeepAlive屬性，並且SignalR將在指定的時間間隔內發送一個空幀數據（基於傳輸）以保持連接處於活動狀態（請參閱Allow host to specify keep alive times）。目前的超時機制使得流協議沒有什麼不同。

來源

2015-10-06 09:18:55 Manraj

SignalR長輪詢在5秒內斷開連接

回答

Troubleshooting

相關問題