Является ли TCP Keepalive единственным механизмом определения неработающей ссылки?

Question

Недавно я столкнулся с проблемой, когда промежуточное соединение между сервером TCP и клиентом не работало. У клиента есть требование подключения к вторичному серверу, если основной сервер не работает. Когда основной сервер выкуплен (например, путем выполнения ^ C на терминале), выполняется последовательность выключения TCP, и клиент успешно обнаруживает разорванную связь и пытается выполнить вторичный. Однако, если промежуточное соединение не работает, клиент и сервер не будут знать об этом. Единственный способ, которым клиент может обнаружить, - это когда его буферы TCP заполняются ошибочными операциями отправки.

В качестве решения этой проблемы был использован механизм TCP Keepalive. Это работает удовлетворительно.

Мой вопрос - «Keepalive TCP» - единственное решение?

-Prabhu

Answer 1

Другое решение - использовать сердцебиение на отдельной розетке. Таким образом, вы почти сразу узнаете, не работает ли соединение. Это полезно, когда ваше основное соединение отправляет потоковые данные без границ сообщений.

Answer 2

Я всегда обрабатывал это на уровне приложения, расширяя протокол, обменивающийся данными по протоколу TCP между клиентом и серверами с помощью сообщения «Keep Alive». Сервер и клиент отправляют это сообщение, например каждую секунду, и если они не получили сообщение «Keep Alive» в течение 2 секунд, соединение, вероятно, закрыто.

Механизм Keep-Alive TCP хорош, но сложен в использовании, особенно при работе на разных платформах.

Answer 3

Даже без установленного SO_KEEPALIVE, если вы пытаетесь отправить данные по неработающему TCP-соединению, оно обычно сбрасывается или в конечном итоге истекает - любое из них в конечном итоге отправляет ошибку приложению.

SO_KEEPALIVE означает, что это может быть обнаружено раньше при неактивном соединении. Вот и все.

Answer 4

Keepalive был разработан для работы с так называемыми полуоткрытыми соединениями, когда одна из сторон (обычно сервер, который получает запросы) не знает, что соединение было разорвано. Клиент обычно знает об этом, потому что попытка отправить запрос на сервер вернет вам ошибку.

Другой вариант - сохранить работу прослушивателя - когда клиент обнаруживает проблемы со связью, он просто пытается снова подключиться к серверу. Сервер получает входящее соединение, проверяет его с того же IP-адреса и, если это так, закрывает открытое соединение и устанавливает новое.

Но если клиент не знает, что соединение разорвано, и серверу нужно что-то отправить, сервер не сможет восстановить соединение, кроме TCP-активности.

Если вы не хотите использовать keepalive, вы можете использовать keepalive на уровне приложения, например, отправка чего-то вроде специфичных для приложения эхо-сообщений.

Answer 5

Вы можете изобрести и реализовать свой собственный метод поддержки активности с помощью функции внеполосного управления TCP, но я бы даже не подумал об этом, если у вас не возникнет какой-либо существенной проблемы с той, которая уже создана для вас.