SignalR 2长轮询"协议"请求实际上超时时，没有在本地跑 [英] SignalR 2 long polling "protocol" request actually times out when not ran locally

问题描述

目前我有一个应用程序，这是非常健谈的，需要通过一个Singleton的支持（参见下面的代码）。我升级到2.0 SignalR和我跟着升级指南，但之后，我将它部署到一个环境中，有时每一个协议的所有请求失败，signalr休息，而当它不那么打破它是推动非常慢通知下到从服务器客户端，也许这有什么用长轮询用它做什么？这里是我的服务器端代码的样子。

Currently I have an app that is very chatty and needs to be supported by a Singleton(See Code below). I upgraded to SignalR 2.0 and I followed the upgrade guide, but after I deploy it out to an environment, sometimes all requests for every "protocol" fail, and signalr breaks, and when it doesn't break then it is terribly slow to push notifications down to the client from the server, Maybe this has something to do with it using long polling? Here is what my server side code looks like.

配置方法在Owin启动类

Configuration Method in Owin Start up class

 var hubConfig = new HubConfiguration();
 hubConfig.EnableDetailedErrors = true;
 GlobalHost.DependencyResolver.UseSqlServer(ConfigurationManager.AppSettings["ConnectionString"].ToString());
 app.MapSignalR(hubConfig);

正如你可以看到我使用的是SQL背板。这里是我的集线器看起来像

As you can see I am using an SQL Backplane. Here is what my Hub looks like

public class MyHub : Hub
{
    public void JoinGroup(int someId)
    {
        Groups.Add(Context.ConnectionId, someId.ToString());
    }

    public void LeaveGroup(int someId)
    {
        Groups.Remove(Context.ConnectionId, someId.ToString());
    }
}

要在这里做的另一点是，我使用群体。这可能是问题的一部分，我注意到，群体似乎使事情更慢，仿佛signalr正在等待所有用户都从小组来完成它推动了通知之后。我的辛格尔顿看起来像这样

Another point to make here is that I am using groups. Which may be part of the problem, I have noticed that groups seem to make things go slower, as if signalr is waiting for all users from the group to finish after it pushes out a notification. My Singleton looks like this.

public class Broadcaster
    {
        private readonly static Lazy<Broadcaster> _instance =
            new Lazy<Broadcaster>(() => new Broadcaster(GlobalHost.ConnectionManager.GetHubContext<MyHub>().Clients));
        private IHubConnectionContext _context;
        private Broadcaster(IHubConnectionContext context)
        {
            _context = context;
        }
        public static Broadcaster Instance
        {
            get { return _instance.Value; }
        }
        public void UpdateClient(int someId, int moreInfo)
        {
            _context.Group(someId.ToString()).Update(someId, moreInfo);
        }
    }

最后，这些都是从客户端上的日志输出

Finally these are the outputs from the logs on the client.

• 16点37分25秒GMT-0600（中部标准时间）SignalR：客户认购
  为中心myhub 。十六点37分25秒GMT-0600（中部标准时间）SignalR：
  谈判与
  '/ API / signalr /洽谈connectionData =％5B％7B％22name％22％3A％22myhub％22？ ％7D％5D&安培; clientProtocol = 1.3'


• 然后尝试连接到一个SSE端点和失败...


• 16点37分。 ：30 GMT-0600（中部标准时间）SignalR：这个浏览器
  支持SSE，跳绳永远框架。


• 16时37分三十一秒GMT-0600（中部标准时间）SignalR：打开长轮询请求......


• 16点37分： 35 GMT-0600（中部标准时间）SignalR：longPolling超时时，
  尝试连接。



• 16时37分35秒GMT-0600（中部标准时间）SignalR：中止XHR请求。

• 16:37:25 GMT-0600 (Central Standard Time)] SignalR: Client subscribed to hub 'myhub'. 16:37:25 GMT-0600 (Central Standard Time)] SignalR: Negotiating with '/api/signalr/negotiate?connectionData=%5B%7B%22name%22%3A%22myhub%22%7D%5D&clientProtocol=1.3'.
• then it attempts to connect to an SSE Endpoint and that fails...
• 16:37:30 GMT-0600 (Central Standard Time)] SignalR: This browser supports SSE, skipping Forever Frame.
• 16:37:31 GMT-0600 (Central Standard Time)] SignalR: Opening long polling request to...
• 16:37:35 GMT-0600 (Central Standard Time)] SignalR: longPolling timed out when trying to connect.

• 16:37:35 GMT-0600 (Central Standard Time)] SignalR: Aborted xhr request.

（错误从预订到错误的集线器）SignalR错误：错误：没有传输可以成功初始化。尝试指定一个不同的传输或根本没有自动初始化。

(Error from subscribing to errors on the hub) SignalR error: Error: No transport could be initialized successfully. Try specifying a different transport or none at all for auto initialization.

有什么想法？

推荐答案

所以在2.0.0 SignalR是一个TransportConnectTimeout现在。它听起来就像你的SQL背板速度放缓导致的传输超时的连接过程

So there's a TransportConnectTimeout now in 2.0.0 SignalR. It sounds like having your SQL backplane is slowing down the connect process resulting in your transports to timeout.

您可以通过修改TransportConnectTimeout在服务器上：

You can modify the TransportConnectTimeout on the server via:

GlobalHost.Configuration.TransportConnectTimeout = TimeSpan.FromSeconds(10);

因此，每当一个客户端试图连接将通过新的超时遵守。

Therefore whenever a client tries to connect it will abide by the new timeout.

您还可以修改客户端上的此值。当修改了客户端在它的TransportConnectTimeout并将其添加到服务器，然后使用结果作为超时。下面介绍如何修改客户端：

You can also modify this value on the client. When modified the client takes it's TransportConnectTimeout and adds it to the servers and then uses the result as the timeout. Here's how to modify the client:

$.connection.hub.transportConnectTimeout = 3000;

如果服务器的TransportConnectTimeout为5秒，这意味着客户将通过787-8超时窗口恪守尝试连接时

If the server's TransportConnectTimeout is 5s that means the client will abide by an 8s timeout window when trying to connect.

您可以选择修改值中的一个，或两个值，它无关紧要，任何适合您的需求！

You can choose to modify one of the values, or both of the values, it doesn't matter, whatever fits your needs!

希望这有助于！

这篇关于SignalR 2长轮询"协议"请求实际上超时时，没有在本地跑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！