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

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

для решения подобной проблемы многие протоколы предусматривают "heartbeat" "пинги" (специальные пакеты определяемые в протоколе передачи, вовсе не ICMP), которые если вдруг не приходят после относительно короткого таймаута, то приложение самостоятельно решает закрыть сокет, не полагаясь на ОС. как пример — вебсокеты, там дефолтный пинг каждые 30 секунд и если через 60 не было ни одного пинга, то соединение закрывается.

это другая проблема. Т.е. если удалённый конец просто "выдернули из сети", то да, он как /dev/null ведёт себя и надо решать описанным тобой способом. А вот локальное отключение интерфейса, афаик, к ошибкам должно приводить (как при чтении), и если я прав, локально с таймауты не особо нужны для этого случая.

> как пример — вебсокеты, там дефолтный пинг каждые 30 секунд и если через 60 не было ни одного пинга

а вот про это поподробней, плз. Это по рфц как-то?

а в чём разница? он же вырубает вайфай физически, как я понял, рутер просто продолжает ждать, что он появится, тцп не в курсе пропажи, просто тупо копит таймауты, которые там ахренеть какие

в рфц, насколько я помню, описаны пинги, но не конкретные таймауты. конкретные таймауты — это мои замеры и такое же мнение vti

где-то тут про пинг-понг вебсокетов: https://tools.ietf.org/html/rfc6455#page-37

я когда сначала сделал поддержку вебсокетов, не сдела пинг-понг. и удивлялся, чего это браузер соединение просто так закрывает

>    NOTE: A Ping frame may serve either as a keepalive or as a means to
  verify that the remote endpoint is still responsive.

можно использовать для детекта, но вовсе не обязательно.

я тебе практику говорю. делаешь вебсокет сервер, коннектишь к нему браузер и не шлёшь пинги — через 60 сек соединение закрывается браузером

а, да, согласен т.к. это удалённое устройство, то да, до ядра только через нек. время дойдёт

я так понимаю браузер шлёт пинги? ну тогда да, это особенность браузера. В принципе разумно

сервер тоже должен пинги слать. я не помню про браузер сходу, лень идти код смотреть, я помню, что автоматический понг предусмотрел :)

это откуда?

стековерфлоу, но может быть это мисинформация, там дальше дискуссия...

твой случай вот этот:

TCP does not notify of disconnects when RST/FIN packets were not received. TCP only detects dropped connections when a sender attempts to send on a disconnected connection.

но, кстати, я тоже не помню пингов от браузера, просто закрывает соединение, если от сервера давно не было пингов. видимо, чтобы не плодить трафик в обе стороны.

спасибо большущее