а можете подсказать почему так: создаю тсп сокет в локалке, сокет подсоединился данных ходят, все хорошо. отключаю wi-fi на ноуте по сути сети больше нет, но сокет чувствует себя хорошо. из сокета читаю readline(), в сокет пишу $socket->send(). подскажите как ловить такое?

Э-э-э. Так у так оно, вроде, работает когда 1 мессадж  = 1 фрейм. А если несколько фреймов с одним пейэлоадом, но 1 мессадж? Там тоже можно выкрутиться flush'ем (другим), но это ухудшает качество компрессии.

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

это рфц. Мессадж может состоять из нескольких фреймов.

ты теоретизируешь или у вас правда сообщение может не отправиться по команде "послать фрейм"?

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

да, авто-ответ понгом должен, а вот пинги - не должен (на усмотрение). АФАИК проще сделать - нету данных по tcp столько-то времени - закрываем. Кроме того обычно клиент "более заинтересован" в поддержании коннекшена, поэтому он и пингует. Хотя если вывернутая наизнанку схема, т.е. клиент "подписывается" на события от сервера и просто их получает, то и в таком случае клиент(!) должен пинговать сервер о том что он живой, а не сервер.

Как пример я делал как-то для камеры по GigE протоколу, и там фреймы по UDP от камеры приходили. И там да, клиент должен камеру пинговать. По смыслу такой подход и логично для сервера : чем ставить ещё N таймеров на N клиентов дешевле, обычно, каждому клиенту поставить у себя таймер.

Так что с цитатой с SO не согласен.

ну вообще не "ахренеть" какие, если только ты не с Луной контачишь, он замеряет RTT же