Закрытие TCP-коннекта операционной системой

1) до смерти процесса. На длительность соединения нет ограничений.

2) тот кто пишет в сокет получит ошибку через некоторое время.

Спасибо за ответ

2) тот кто пишет в сокет получит ошибку через некоторое время.

Я так понимаю это будет в момент когда закончится буфер отправки внутри ОС + какое-то время, так?

1) это если не было разрывов :)

2) если очередной tcp-keep-alive не дойдет, то раньше. Но узнать можно только читая/пиша вроде бы.

upd: без кипалайва только хардкор, да.

1) это если не было разрывов :)

Вот в этом и вопрос. Отсутствие разрывов, когда никто не пишет и не читает вроде как эквивалентно полной потере сегментов на этом соединении, так?

http://www.opennet.ru/docs/RUS/tcpip/#c4_6_3_keep_timer

http://rfc.com.ru/rfc793.htm

http://www.opennet.ru/docs/RUS/tcpip/#c4_6_3_keep_timer

Первое(4.6.3. Таймер закрытия связи) да, такой вариант есть.Это корректное завершение через close и дополнительный таймаут на блуждающие пакеты. Хорошо описано например в http://kalinin.ru/programming/network/29_10_00.shtml

Второе я так понял про keep alive

http://rfc.com.ru/rfc793.htm

К сожалению, не нашел там варианты которые описал в начале. Т.е. FIN никто никому не посылал.

Я немного про другое. Может ли сокет висеть скажем пару суток, если из состояния [ESTABLISHED <-> ESTABLISHED] начать 100% дроп сегментов туда обратно + один сокет только ждет чтения, а второй уже ничего не может послать(из-за дропа или иных причин)?

Если честно не знаю, тут просто нужно проверить и всё.

То есть пишущая сторона пишет, но не получает ACK? Тогда писатель заметит, читатель - нет. Интервал через сколько заметит читатель - зависит от конкретной реализации. Вряд ли это где специфицированно. Файрволы так могут делать. http://en.wikipedia.org/wiki/Black_hole_(networking)

В моем случае про пишущую сторону мало что известно - это внешний сервис. А клиент(мое приложение) только ждало данные и делало это трое суток. С той стороны их уже не писали(проверял через tcpdump), а сокет продолжал висеть в состоянии ESTABLISHED.

Не очень понятно насколько это нормально(с точки зрения rfc) и каким параметром это регулируется и регулируется ли вообще.

За термин black hole спасибо, может по нему, что-нибудь найдется.

Нет, когда кончится буфер, то процесс будет приостановлен, а когда закончится таймауты у TCP, то процессу будет возвращен код ошибки на write()/send() и в некоторых случаях SIGPIPE.

С SIGPIPE сталкивался, но глубоко не копал. Не помнишь названия этого таймаута? Или документа в котором он описан?

Только пинговать надо писателя. Больше ничего. Чем keep-alive не нравится? Он для этого и придуман. Твое соединение может отрезать кто-нибудь по середине, например какой-нибудь роутер, но тебе может ничего и не прислать.

Чем keep-alive не нравится?

Может и нравится :) Надо выяснить что произошло сейчас и потом уже решать наиболее удобным способом.

Твое соединение может отрезать кто-нибудь по середине, например какой-нибудь роутер, но тебе может ничего и не прислать.

Вот мне нужно понимание, что ОС на это никак не реагирует(даже большим с таймаутом) и это поведение стандартно, а не ОС глючит. И что решить мне это надо на уровне приложения, может быть и через keep-alive.

Думаю, что TCP-стек для такого как раз и придумал keep-alive, который даже включен по умолчанию.

В системе он есть, однако для коннекта эта опция не задается по умолчанию похоже. Проверил программу по ссылке: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/programming.html

Вывод на centos и gentoo одинаковый:

SO_KEEPALIVE is OFF
SO_KEEPALIVE set on socket
SO_KEEPALIVE is ON

setsockopt( SO_RCVTIMEO / SO_SNDTIME ) ?

Да, это тоже вариант.

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

2) О проблемах на канальном уровне всегда сообщает железка. ОС тут ни при чем. В контексте Ethernet, если разрыв будет совсем близко к хосту - сразу выкинет ошибку. Если разрыв между маршутизаторами, то соединения будут висеть у обоих сторон до тех пор пока маршутизатор не вернет ответ в духе host unreachable. Чтобы словить этот момент раньше отправки данных или перед их получением был придуман keep-alive. Без последнего сокет работает по таймаутам: RTO (rfc 793 параграф 3.7) и пользовательские таймауты.

Ссылки:

http://www.faqs.org/docs/iptables/tcpconnections.html

http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-d...

http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/

http://rfc2.ru/793.rfc

что такое TCP-стек?

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

Ах да... есть еще один сценарий - ОС опустила ифейс. Тогда, да, сокетам хана. Собственно сейчас этим балуются всякие Network-manager'ы, которые реагируют на изменение состояния физического линка.

Но в остальном... ты можешь выдернуть шланг из обеих машин и воткнуть на совершеннолетие твоего ребенка, спустя много лет, и если ОС с софтом все это время работали без остановки, то данные вновь полетят по этому TCP линку.

http://ru.wikipedia.org/wiki/TCP/IP

а где там написано что TCP — это стек? Может стейк?