Если не отправлено сообщение FIN или RST, единственный другой способ, которым стандартный TCP знает, вышла ли другая сторона или ушла, - истечение времени ожидания.
Это действительно лучшее, что вы можете сделать по своему замыслу, если вы делаете наименьшее количество предположений о "другой стороне", насколько это возможно, и ваше единственное соединение с этой "другой стороной" - это единый сетевой интерфейс.
Событие с меньшим значением в модели OSI может привести к тому, что ОС сама разорвет соединение или предоставит информацию, которая может сказать клиенту об отказе, например, об удалении соответствующего сетевого адаптера или изменении состояния канала на быть отключенным. Это не должно случиться, все же.
Общее решение состоит в том, чтобы отправлять периодические сообщения без значимых данных, называемых сообщениями активности, через соединение. TCP поддерживает это, но вы можете сделать это и на уровне приложений.
- FileZilla может быть настроен на отправку сообщений поддержки активности. Вы можете видеть, что он посылает команды, которые не делают ничего полезного, а просто выдаются, чтобы что-то бросить в трубу и сохранять его «занятым».
- У PuTTY, например, есть опции keepalive .
- Вы также можете установить опцию keepalive на сервере, но обычно лучше установить ее на клиенте SSH.
- Многие протоколы маршрутизации отправляют сообщения активности на прикладном уровне, чтобы убедиться, что другие маршруты работают и доступны, BGP, для одного.
- TCP также изначально поддерживает сообщения keepalive, в основном это нулевые пакеты Ethernet, которые отправляются очень часто для проверки соединения. Эта статья tldp.org хорошо объясняет.