Мы столкнулись с этой ссылкой, которая определяет различные свойства тайм-аута: https://github.com/SignalR/SignalR/wiki/Configuring-SignalR
А также этот отличный пост (Когда происходит повторное подключение в signalR occour?) о том, как разъединения и повторные соединения происходят между клиентом SignalR и сервером SignalR.
Просто повторите итерацию различных ситуаций из вышеприведенного сообщения:
"Повторное подключение концентратора происходит, когда клиент переходит в автономный режим, а затем восстанавливает соединение вскоре после этого. Значения конфигурации SignalR в значительной степени определяют отметки времени следующих примеров, поэтому не принимайте время дословно.
Вот несколько примеров и их результаты (формат времени m: ss), включающий повторное подключение:
Ситуация 1
0:00 - Клиент подключается к серверу, инициируется OnConnected
0:10 - Клиент теряет соединение из-за проблем с провайдером (и понимает, что он теряет соединение)
0:15 - Клиент восстанавливает подключение
0:16 - инициировано событие OnReconnected
Ситуация 2
0:00 - Клиент подключается к серверу, инициируется OnConnected
0:10 - Клиент теряет соединение из-за вытягивания сетевого кабеля (не понимает, что он отключен)
0:15 - Клиент восстанавливает подключение
Здесь могут произойти две вещи.
A: 0:16 - Ничего не происходит, и клиент продолжает свое предыдущее соединение
B: 0: ~ 45 - Клиент реализует свой отключенный *
B: 0:46 - Клиент переходит в состояние повторного подключения
B: 0:47 - Клиент успешно повторно подключается и инициируется событие OnReconnected.
Ситуация 3
0:00 - Клиент подключается к серверу, инициируется OnConnected
0:10 - Клиент теряет соединение из-за вытягивания сетевого кабеля (не понимает, что он отключен)
0: ~ 45 - Клиент реализует свой отключенный *
0:46 - Клиент переходит в состояние повторного подключения
1:15 - Сервер определяет, что клиент слишком долго ушел, а затем забыл об этом, поставив в очередь команду "отключить" для клиента, если он снова подключится позже. ***
1:15 - срабатывает OnDisconnect 1:16 - Клиент восстанавливает соединение
1:17 - Клиент выполняет "мягкое" повторное подключение (не вызывает OnReconnected)
1:18 - Клиент извлекает команду "отключить"
1:19 - Клиент вызывает "стоп" и выполняет мягкое разъединение (не запускает OnDisconnected)
Ситуация 4
0:00 - Клиент подключается к серверу, инициируется OnConnected
0:10 - Клиент теряет соединение из-за вытягивания сетевого кабеля (не понимает, что он отключен)
0: ~ 45 - Клиент реализует свой отключенный *
0:46 - Клиент переходит в состояние повторного подключения
1:15 - Сервер определяет, что клиент слишком долго ушел, а затем забыл об этом, поставив в очередь команду "отключить" для клиента, если он снова подключится позже. ***
1:15 - срабатывает OnDisconnect 1:30 - Клиент перестает пытаться подключиться (слишком долго пытается) **
1:30 - Клиент переходит в отключенное состояние
** Из-за таймаута отключения соединения на стороне клиента: используется, чтобы определить, когда клиент повторно соединяется в течение слишком длительного периода, и, скорее всего, сервер забыл о клиенте в течение времени
*** Из-за тайм-аута отключения сервера: используется для определения того, когда клиент должен быть забыт. Это промежуток времени, который начинает нарастать, как только соединение помечено как мертвое на сервере. В конечном счете сервер ставит в очередь команду disconnect для темы клиента, которая сообщает клиенту (если он повторно подключается), что ему нужно запустить новое соединение. Команда исчезнет с сервера при очистке темы. "
Что мы находим, так это то, что мы часто получаем разъединения и повторно подключаемся (1 и 2 выше) между клиентом .NET SignalR и сервером SignalR ASP.NET MVC, а также отключается, что не приводит к переподключениям (3 и 4 выше). Мы знаем, что используется протокол ServerSentEvents.
Трудно узнать, какие свойства тайм-аута нужно настроить (увеличить или уменьшить) до:
Важно отметить, что наш клиент .NET SignalR на самом деле является службой Windows, которая постоянно подключается к серверу.
В настоящее время мы просто сохранили значения по умолчанию:
Кроме того, мы используем SignalR 1.0.1.
Ваши тайм-ауты установлены правильно. В текущем выпуске клиентская сторона не поддерживает клиента .net, чтобы гарантировать, что клиент поддерживает подключение.
В следующем выпуске вы будете иметь клиентскую сторону .net. Если вы хотите работать с dev-конструкцией проекта, функция в настоящее время доступна на ветке dev https://github.com/SignalR/SignalR/tree/dev.
Также для справки, здесь проблема связана с тем, что вы видите https://github.com/SignalR/SignalR/issues/741.
У .NET-клиента еще нет такого поведения. и он не будет повторно подключаться, если клиент неожиданно отключит соединение. Это будет в 1.1.
Используете ли вы SignalR 1.0.1? Описание процесса повторного подключения Тейлора относится к версии SignalR >= 1.0 и JS-клиенту. Причина, о которой я прошу, заключается в том, что в SignalR >= 1.0, KeepAlive должна быть не более трети от DisconnectTimeout. KeepAlive и DisconnectTimeout абсолютно не могут быть равны.
Однако, если 1.0. * вы установите DisconnectTimeout после KeepAlive, для keep-alive будет установлена третья часть DisconnectTimeout. В вашем случае это будет 10-секундное значение по умолчанию.
В SignalR 1.0 было решено много проблем, поэтому, если вы этого не сделали, это стоит модернизировать. Хотя, как указывали другие ответы, клиент .NET не будет поддерживать проверки работоспособности и не узнает, что сетевой кабель отключен до 1.1
P.S. Вы всегда можете вручную перезапустить свой Connection, если вы каким-то образом пойдете, что он отключится. В этом случае ваш идентификатор соединения будет меняться, конечно.