从服务器到客户端方法的SignalR Hub（在云中）回调的间歇性问题

到目前为止，SignalR Hubs已经在我的开发机器上与IIS 7.5中的本地托管网站完美配合。 我让客户端在点击事件上向服务器发出信号器调用，然后服务器在将响应发送回客户端上的回调方法之前执行20秒的线程延迟。 这适用于所有浏览器。 但是，当我将应用程序部署到Windows Azure云时，SignalR开始出现这些间歇性问题。 具体来说，服务器在客户端上达到回调方法似乎存在问题。 我通过观看Chrome开发工具中的网络流量来validation这一点。 我可以清楚地看到POST连接是由signalr做出的。 它处于“挂起”状态20秒，然后当服务器响应时POST成功完成。 但是，客户端的回调方法（带有简单的警报消息）并不总是因某种原因而触发。 注意：在我的测试中，我注意到一些奇怪的行为，当回调方法没有触发时，我可以通过正常下载文件来解决它（通过使用href = window.baseUrl +’/ CloudStorage / DownloadZip？’ ）然后单击触发信号器的按钮。 正如我在网络流量中看到这一点，不知何故window.baseUrl BOM命令触发信号器重新连接。 非常感谢任何帮助！

编辑：我正在使用IE 10，最新的Chrome和最新的Firefox进行所有测试。 当应用程序在云端时，IE 10似乎与signalr有最多的问题，这对我来说有点奇怪，因为这是一个MS产品。 另外，我正在使用SignalR的1.1.2版本。

这是我的代码片段：

服务器端：

[HubName("MultiFile")] public class MultiFile : Hub { [HubMethodName("Send")] public void Send(string DocID) { System.Threading.Thread.Sleep(20000); // Call the addMessage method on caller client Clients.Caller.addMessage(DocID); } } 

客户端：

  $('#dBtn').click(function () { var docIds = sceneLayoutService.getSelection(); var href; var docIdsParam; if (docIds.length === 0) { // signalr test code below // Proxy created on the fly var test_connection = $.connection.MultiFile; // Declare a function on the MultiFile hub so the server can invoke it test_connection.client.addMessage = function (message) { alert(message); }; // Start the connection $.connection.hub.start().done(function () { // Call the chat method on the server test_connection.server.Send("you need to select one!"); }); return false; } else if (docIds.length == 1) { docIdsParam = "docId=" + docIds; href = window.baseUrl + '/CloudStorage/Download?' + docIdsParam; } else { docIdsParam = jQuery.param(docIds.map(function (value) { //var parts = value.match(/[e[B|b]:\/\/[^\/]*\/\d*\/(\d*)/); //return { "name": "docIds", "value": parts[1] }; return { "name": "docIds", "value": value }; })); href = window.baseUrl + '/CloudStorage/DownloadZip?' + docIdsParam; } $(this).attr('href', href); return true; }); 

包装清单：

Answer 1

事实certificate，在我的Windows Azure配置中运行了2个Web角色实例。 当有多个Azure实例在运行时，需要使用“背板”，因为我们无法控制Azure负载均衡器选择的实例。 这就是为什么从服务器发送回客户端的消息在50％的时间内都失败了。

http://www.asp.net/signalr/overview/performance-and-scaling/scaleout-in-signalr