Свойства таймаута SignalR - программирование

Свойства таймаута SignalR

Мы столкнулись с этой ссылкой, которая определяет различные свойства тайм-аута: 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.

Трудно узнать, какие свойства тайм-аута нужно настроить (увеличить или уменьшить) до:

  • Уменьшите количество отключений и снова подключитесь.
  • Не заканчивается в ситуациях 3 и 4 вообще.

Важно отметить, что наш клиент .NET SignalR на самом деле является службой Windows, которая постоянно подключается к серверу.

В настоящее время мы просто сохранили значения по умолчанию:

  • ConnectionTimeout = 110 секунд
  • DisconnectTimeout = 30 секунд
  • KeepAlive = 30 секунд

Кроме того, мы используем SignalR 1.0.1.

4b9b3361

Ответ 1

Ваши тайм-ауты установлены правильно. В текущем выпуске клиентская сторона не поддерживает клиента .net, чтобы гарантировать, что клиент поддерживает подключение.

В следующем выпуске вы будете иметь клиентскую сторону .net. Если вы хотите работать с dev-конструкцией проекта, функция в настоящее время доступна на ветке dev https://github.com/SignalR/SignalR/tree/dev.

Также для справки, здесь проблема связана с тем, что вы видите https://github.com/SignalR/SignalR/issues/741.

Ответ 2

У .NET-клиента еще нет такого поведения. и он не будет повторно подключаться, если клиент неожиданно отключит соединение. Это будет в 1.1.

Ответ 3

Используете ли вы 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, если вы каким-то образом пойдете, что он отключится. В этом случае ваш идентификатор соединения будет меняться, конечно.