Как сервер может обнаружить отключение питания клиента в топологии сервер / клиент
Я создал клиентские и серверные программы, которые обмениваются данными через сокет TCP.
Когда у меня несколько клиентов, я вижу, что сервер запускает процесс для каждого клиента. Но если мой клиент внезапно выключается, сервер не закрывает соответствующий процесс.
Пожалуйста, помогите обнаружить отключение питания клиента на стороне сервера, чтобы можно было завершить соответствующий процесс.
Проверка, если клиент жив, должна быть выполнена программно, и проверка связи не возможна, потому что это не разрешено брандмауэром
1 ответ
См. Этот документ: https://blog.stephencleary.com/2009/05/detection-of-half-open-dropped.html
Из приведенного выше документа, рейтинг от лучшего к худшему:
- Добавить сообщение поддержки активности в кадре протокола приложения (пустое сообщение). Системы с префиксом длины и разделителями могут отправлять пустые сообщения (например, префикс длины «0 байтов» или один «конечный разделитель»).
Преимущества. Протокол более высокого уровня (фактические сообщения) не затрагивается.
К недостаткам. Это требует изменения в программном обеспечении на обеих сторонах соединения, так что это может быть невозможно, если протокол приложения уже указан и неизменен.
- Добавить сообщение поддержки активности в действующий протокол приложения («нулевое» сообщение). Это добавляет новое сообщение к протоколу приложения: «нулевое» сообщение, которое следует просто игнорировать.
Преимущества. Это может быть использовано, если протокол приложения использует неоднородную систему формирования сообщений. В этом случае первое решение не может быть использовано.
К недостаткам. (То же, что и в первом решении). Это требует изменения программного обеспечения на обеих сторонах соединения, поэтому это может быть невозможно, если протокол приложения уже указан и неизменен.
- Явный таймер, предполагающий худшее. Имейте таймер и предполагайте, что соединение было разорвано, когда истекает таймер (конечно, таймер сбрасывается при каждой передаче данных). Именно так работают HTTP-серверы, если они поддерживают постоянные соединения.
Преимущества. Не требует изменений в протоколе приложения; в ситуациях, когда код на удаленной стороне не может быть изменен, первые два решения не могут быть использованы. Кроме того, это решение вызывает меньше сетевого трафика; это единственное решение, которое не включает отправку пакетов keepalive (то есть «вы все еще там?»).
К недостаткам. В зависимости от протокола, это может привести к разрыву большого количества допустимых соединений.
- Управление настройками пакетов поддержки активности TCP / IP. Это весьма спорное решение, которое имеет сложные аргументы в пользу обоих плюсы и минусы. Это подробно обсуждается в книге Стивенса, глава 23. По сути, это предписывает стеку TCP / IP периодически отправлять пакеты поддержки активности от имени приложения.
Преимущества. Как только код для установки параметров keepalive заработает, приложению больше ничего не нужно менять. Все другие решения имеют события таймера, на которые должно реагировать приложение; это «поставь и забудь».
К недостаткам. RFC 1122, раздел 4.2.3.6 указывает, что подтверждения для сообщений активности TCP без данных не могут надежно передаваться маршрутизаторами; это может привести к разрыву действительных соединений. Более того, стеки TCP / IP вообще не обязаны поддерживать пакеты активности (а многие встроенные стеки этого не делают), поэтому это решение может не переводиться на другие платформы.