SignalR 客户端由于不活动而停止连接

Question

我在控制台应用程序和 WPF 客户端中有一个 signalR 集线器。 在启动时，signalR 连接初始化，并且应该始终保持活动状态。 每秒有一条消息使用当前 SystemTime 从服务器推送到客户端（这就是您可以在日志中使用 'SystemTimeUpdateNotification' 看到的内容）

我现在描述的行为是在 Windows7 设备上：每隔一段时间我就会看到客户端失去与服务器的连接。 由于某种原因，客户端检测到它已不活动并停止连接。我不知道“自 2017 年 4 月 20 日凌晨 3:04:06 以来处于非活动状态”和“超时 00:00:50”的来源。 如果我大约在同一时间检查服务器上的日志，我可以看到没有 keepalive 消息。

2017-04-20 05:04:04.0728,Trace,收到通知 SystemTimeUpdateNotification 2017-04-20 05:04:05.0859,Trace,收到通知 SystemTimeUpdateNotification 2017-04-20 05:04:06.0999,Trace,收到通知 SystemTimeUpdateNotification 2017-04-20 05:05:13.1020,Trace,收到通知 SystemTimeUpdateNotification 2017-04-20 05:05:14.1160,Trace,收到通知 SystemTimeUpdateNotification 2017-04-20 05:05:14.5511，信息，客户端自 2017 年 4 月 20 日凌晨 3:04:06 以来一直处于非活动状态，并且已超过 00:00:50 的非活动超时。停止连接。 2017-04-20 05:05:14.5871，信息，SignalR 连接状态从“已连接”更改为“已断开” 2017-04-20 05:05:14.5871，跟踪，收到通知 NotificationConnectionStateChanged 2017-04-20 05:05:14.5981,信息,断开连接... 2017-04-20 05:05:14.5981，信息，取消正在进行的操作 2017-04-20 05:05:19.6104，信息，SignalR 连接状态从“断开连接”更改为“连接中” 2017-04-20 05:05:19.6104，跟踪，收到通知 NotificationConnectionStateChanged 2017-04-20 05:05:19.6104，信息，断开连接... 2017-04-20 05:05:19.6454，信息，SignalR 连接状态从“正在连接”更改为“已连接” 2017-04-20 05:05:19.6454，跟踪，收到通知 NotificationConnectionStateChanged 2017-04-20 05:05:19.6454,信息,连接... 2017-04-20 05:05:19.6524，调试，执行客户端/服务器兼容性检查 2017-04-20 05:05:19.6524，调试，软件兼容 2017-04-20 05:05:19.6524，信息，开始检索初始数据 2017-04-20 05:05:20.0344，信息，初始数据检索 2017-04-20 05:05:20.2044,Trace,收到通知 SystemTimeUpdateNotification 2017-04-20 05:05:21.2144,Trace,收到通知 SystemTimeUpdateNotification

登录服务器端：

2017-04-20 05:03:31.6069;跟踪;KeepAlive(6a12952a-1cb4-4933-b6b1-db16158958a9) 2017-04-20 05:03:41.6225;跟踪;KeepAlive(6a12952a-1cb4-4933-b6b1-db16158958a9) 2017-04-20 05:03:51.6371;跟踪;KeepAlive(6a12952a-1cb4-4933-b6b1-db16158958a9) 2017-04-20 05:04:01.6527;跟踪;KeepAlive(6a12952a-1cb4-4933-b6b1-db16158958a9) 2017-04-20 05:05:14.5661；信息；中止（6a12952a-1cb4-4933-b6b1-db16158958a9） 2017-04-20 05:05:14.5661;信息;删除连接 6a12952a-1cb4-4933-b6b1-db16158958a9 2017-04-20 05:05:14.5661；信息；结束（6a12952a-1cb4-4933-b6b1-db16158958a9） 2017-04-20 05:05:14.5841;Trace;DrainWrites(6a12952a-1cb4-4933-b6b1-db16158958a9) 2017-04-20 05:05:14.5841;信息;CompleteRequest (6a12952a-1cb4-4933-b6b1-db16158958a9) 2017-04-20 05:05:19.6344;信息;连接 9249a8a5-8653-450c-b8da-c5b7a4c7df81 是新的。 2017-04-20 05:05:27.6738;跟踪;KeepAlive(9249a8a5-8653-450c-b8da-c5b7a4c7df81) 2017-04-20 05:05:37.6874;跟踪;KeepAlive(9249a8a5-8653-450c-b8da-c5b7a4c7df81)

现在我进入了真正奇怪的部分。 “偶尔”实际上是相当固定的。我查看了过去几天的日志条目，似乎总是每 11 小时左右一次

与先前 LogEntry 的非活动时间戳差异 2017 年 4 月 17 日 17:59:44 0:00:00 客户端自 2017 年 4 月 17 日下午 3:58:35 以来一直处于非活动状态，并且已超过 00:00:50 的非活动超时。停止连接。 2017 年 4 月 17 日 17:59:44 11:01:06 客户端自 2017 年 4 月 17 日下午 3:58:35 起一直处于非活动状态，并且已超过 00:00:50 的非活动超时。停止连接。 17/04/2017 06:58:38 10:01:01 自 2017 年 4 月 17 日凌晨 4:57:34 以来，客户端一直处于非活动状态，并且已超过 00:00:50 的非活动超时。停止连接。 2017 年 4 月 16 日 20:57:37 11:01:06 客户端自 2017 年 4 月 16 日下午 6:56:29 以来一直处于非活动状态，并且已超过 00:00:50 的非活动超时。停止连接。 16/04/2017 09:56:31 11:01:06 自 2017 年 4 月 16 日上午 7:55:23 以来，客户端一直处于非活动状态，并且已超过 00:00:50 的非活动超时。停止连接。 2017 年 4 月 15 日 22:55:25 11:01:06 客户端自 2017 年 4 月 15 日晚上 8:54:17 起一直处于非活动状态，并且已超过 00:00:50 的非活动超时。停止连接。 2017 年 4 月 15 日 11:54:19 0:00:00 客户端自 2017 年 4 月 15 日上午 9:53:09 以来一直处于非活动状态，并且已超过 00:00:50 的非活动超时。停止连接。 2017 年 4 月 15 日 11:54:19 11:01:07 客户端自 2017 年 4 月 15 日上午 9:53:09 以来一直处于非活动状态，并且已超过 00:00:50 的非活动超时。停止连接。 15/04/2017 00:53:12 11:01:06 客户端自 2017 年 4 月 14 日晚上 10:52:03 以来一直处于非活动状态，并且已超过 00:00:50 的非活动超时。停止连接。 14/04/2017 13:52:06 11:01:06 客户端自 2017 年 4 月 14 日上午 11:50:58 以来一直处于非活动状态，并且已超过 00:00:50 的非活动超时。停止连接。 14/04/2017 02:51:00 客户端自 2017 年 4 月 14 日上午 12:49:52 起一直处于非活动状态，并且已超过 00:00:50 的非活动超时。停止连接。

是否存在最大连接时间或可能导致此行为的原因？

编辑 1： 如果我在 Windows 8 上运行相同的代码，我就没有这个问题。 我想这与 Windows 7 上使用的传输方法有关（不支持 websockets）

编辑 2：

服务器客户端不活动问题 赢 8 赢 8 没有 赢 7 赢 7 是 赢 7 赢 8 没有 赢 8 赢 7 是

看来和客户端的操作系统有关。

Answer 1

如documentation 中所述，保持连接的一种方法是在断开连接后不断重新连接。在您的客户端中设置断开连接的功能

$.connection.hub.disconnected(function() {
   setTimeout(function() {
       $.connection.hub.start();
   }, 5000); // Restart connection after 5 seconds.
});