Сам стек TCP вряд ли сообщит вам своевременно, если соединение более не является жизнеспособным (если оно не локально не работает, и ОС может сообщать о локальных сбоях стека). Из-за тайм-аута повторной передачи (см. here) и что бы это ни было, может потребоваться «достаточно времени» до того, как запись вернет сообщение об отсутствии соединения. Это, конечно, по дизайну, просто дизайн не согласуется с тем, что вы хотите сделать.
Вы можете попробовать использовать TCP keep alives, но IMHO это не стоит усилий, и вы бы лучше реализовали ACK какого-то уровня приложения, если это возможно, чтобы вы могли заставить ваш протокол уровня приложения отправлять обратно ответ, как только он получит некоторые данные от вас. Если вы не можете этого сделать, и ваш запрос вызывает ответ с другого конца соединения, вы можете просто настроить таймер в зависимости от того, сколько времени вы готовы ждать ответа, прежде чем считать, что соединение мертво. По истечении таймера вы закрываете соединение и устанавливаете новый.
Возможно, вы можете устранить новую попытку подключения и отправить запрос по старому соединению, если новое соединение станет доступным, прежде чем вы получите ответ от старого, тогда вы можете отправить запрос на новый соединение и закрыть старый ... Конечно, это зависит от того, как ваше приложение может справиться с подобными вещами.
И, наконец, если соединение прерывается из-за неактивности, возможно, вы можете добавить пинг на уровне приложения в свой протокол, который может быть настроен для отправки сообщения так часто, чтобы: a) обеспечить соединение живым и b) останавливать маршрутизаторы или брандмауэры, думая, что соединение мертво.
«ACK означает, что он имеет только TCP/IP-стек peer». Это достаточно для меня. Я пытаюсь отличить чрезвычайно распространенный отказ от крайне редкого. – Joshua
@Joshua Это не «достаточно хорошо» для вас, так как вы не можете его обнаружить. – EJP