1

我们正在收到对信号器客户端的待处理请求，这些请求在轮询响应中以数组的形式聚集在一起，如下所示：

{"C":"s-0,9E632",
"M":[
84
{"H":"MyHub","M":"SetSomething","A":[{"myProp1":"setting","myProp2":59.0}]}
1,
84
{"H":"MyHub","M":"SetSomething","A":[{"myProp1":"setting","myProp2":60.0}]}
1,
84
{"H":"MyHub","M":"SetSomething","A":[{"myProp1":"setting","myProp2":61.0}]} 
1,
84
{"H":"MyHub","M":"SetSomething","A":[{"myProp1":"setting","myProp2":62.0}]}
1,
6b
{"H":"MyHub","M":"SetMore","A":[{"myProp3":"Somestring","myProp4":0}]}
2
]}

通常，对民意调查的单个响应如下所示：

{"C":"s-0,9E621","M":[
6b
{"H":"MyHub","M":"SetSomething","A":[{"myProp1":"setting","myProp2":59.0}]}
2
]}

我相信环形缓冲区将消息存储到 DefaultMessageBufferSize 限制，并且在轮询时会将这些消息发送给客户端。我的问题是它们会被一个一个地发送，就像一个队列，一个对一个轮询的响应，还是作为对第一个轮询的响应一起发送的所有消息（就像我们得到的，上面提到的）？

背景和实际问题：我们有一个信号器客户端（C1）在云中进行长轮询和我们的 SignalR 服务器。有一个用户（U1）连接到服务器并为 C1 发送消息，我们使用服务器上的 Clients.User({C1}).{Method} 将这些消息转发给 C1。当 U1 向 C1 发送多个快速请求，而 C1 无法足够快地处理它们时，我们会看到发送给 C1 的成束响应。C1 未配置为处理成束响应，并且它拒绝该响应，并且我们看到服务器对 C1 的相同成束响应的无休止循环，用于每次进一步的轮询。

对此有任何见解将不胜感激。提前致谢。

4

1 回答 1

-1

关于这个问题的答案，首先SignalR在长池中默认永远不会连接。

SignalR的工作流程-

  1. 它尝试与 WebSocket 连接。

  2. 如果它无法连接，那么它会尝试连接服务器发送的事件。

  3. 即使它失败了，它也会尝试使用服务器框架。

  4. 即使它失败了，它也使用长轮询作为后备。

更多可以在这里找到。

关于它的性能，你可以在这里找到更多。

因此，经过测试，SignalR可以处理与网络设备一样多的请求，因此数据传输几乎没有限制。

你的问题的答案——

在您的情况下，我们需要检查几件事。

  1. 是否启用了 HTTPS？如果没有，请按照此链接设置 HTTPS，因为没有 HTTPS，您将永远无法使用 WebSocket，建议您这样做。

  2. 如果启用了 HTTP，那么它应该与 WebSocket 通信，如果网络正常，这种问题将永远不会发生。但是对于您的情况，我认为您的网络存在一些问题，因此丢失了一些数据，这就是它一次发送太多数据的原因。

  3. 请检查 signalR 的超时配置。您可以尝试更改SignalR的超时设置。

我认为，如果您遵循这三件事，您可以找到解决问题的方法。

于 2017-02-16T10:01:28.517 回答