Отлов дисконнекта клиента на стороне сервера?

Question

[DmitryKoterov]

Например, клиент посылает SQL-запрос (в PostgreSQL), сервер шлет ответ (может быть длинным), и в середине клиентский процесс вдруг внезапно умирает (например, по 9-му сигналу — возьмем для простоты).


Вопросы:

1. Как скоро сервер узнает об этом и перестанет ждать (т.е. как скоро PostgreSQL вернет процесс, обрабатывающий данное соединение, в пул готовых к новой работе)?

2. Как называется этот механизм, т.е. где о нем можно почитать?

3. Где настраивается эта задержка в Линуксе (если вообще она настраивается)?


Я просто подозреваю, что сервер может иногда узнавать о внезапном дисконнекте клиента минуты через 2-3 только. В итоге свободные процессы могут успеть закончиться, если вдруг происходит массовый мор клиентов.

Comments

[DmitryKoterov]

Да, маленькое уточнение: тут случай вроде как не с TCP_KEEPALIVE (когда соединение в IDLE состоянии и ни одна сторона, ни другая не посылают данные), а разрыв в середине передачи. Т.е. сервер отвечает, а в середине клиент отваливается. Как-то же сервер должен узнавать, что клиент отвалился, верно? Он это может узнать, только получив от принимающей стороны какой-то отлуп в ответ на очередной пакет, и вот как раз задержка этого отлупа и интересует. Или это тоже контролируется тем же TCP_KEEPALIVE'ом?

[DmitryKoterov]

… ну т.е. задержка не этого отлупа (вроде он называется RST), а задержка в ситуации, когда сервер послал очередной пакет ответа, но отлуп в течение N секунд так и не получил (из-за проблем в сети, например) — он должен решить, закрывать ли соединение, или просто оставить сообщение в буфере для ретрансмита. Т.е. финально — мне нужно узнать (и отрегулировать) максимальную задержку ожидания ответного или RST-пакета, при превышении которой соединение принудительно закрывается.

Answer 1

[DmZ]

Существует несколько ситуаций:

• Если проблем в сети нет, то отвалившийся клиент «закроет» порт и сервер получит RST на свои пакеты, т.е. сервер «увидит» падение коннекта практически сразу.
• Если существуют проблемы в сети, когда ответ от клиента не приходит, то есть параметры, которые отвечают за таймауты (выставляются через sysctl):
  

  tcp_retries1
  Целочисленная переменная tcp_retries1 определяет число неудачных попыток, после которого должна быть передана информация на сетевой уровень. В соответствии с RFC минимальное значение составляет 3 (по умолчанию установлено именно это значение), что соответствует периоду приблизительно от 3 секунд до 8 минут в зависимости от значения тайм-аута повторной передачи RTO (Retransmission time-out).
  
  tcp_retries2
  Целочисленная переменная tcp_retries2 определяет число неудачных попыток, после которого существующее соединение уничтожается. В соответствии с RFC 1122 тайм-аут должен быть больше 100 секунд. Такое значение слишком мало и по умолчания установлено число попыток 15, соответствующее тайм-ауту приблизительно от 13 до 30 минут в зависимости от RTO.
  

Все параметры описаны в документации к исходинкам ядра (Documentation/networking/ip-sysctl.txt)

Также эти параметры влияют на все TCP соединения данного сервера. Если нужно «тюнить» для конкретного своего приложения, то можно использовать параметр TCP_USER_TIMEOUT для tcp-сокета. Указывает время в миллисекундах ожидания подтверждения (ACK) данных. Параметр появился в 2.6.37.
Для более ранних ядер можно мониторить исходящую очередь на сокете, и если она не уменьшается какое-то время — значит что-то случилось.

Answer 2

[TheHorse]

На сколько я понимаю, на сервере произойдет ошибка «Connection reset by peer» (WSAECONNRESET в винде), почти моментально.

P. S. это не ответ, но надеюсь поможет в его поисках.

Comments

[Алексей Сундуков]

Не может она произойти моментально по определению.

[Алексей Сундуков]

Хотя в контексте вопроса и пары уточнений ответ будет разный. Без уточнений от автора соглашусь, что да, можно считать что очень быстро получим отлуп. Но в контексте второго уточнения ситуация уже другая.

Answer 3

[Алексей Сундуков]

1.
а) На уровне TCP:
Клиентский процесс умер, но хост клиента жив, значит TCP стек клиента в ответ на данные идущие с сервера отправит FIN. TCP сервера получит его, пошлет в ответ ACK и из ESTABLISHED перейдет в CLOSE_WAIT. После того как рабочий процесс сервера сделает close TCP стек сервера пошлет FIN и перейдет в LAST_ACK дожидаясь ACK от TCP клиента. Получив его перейдет в CLOSED.

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

б) На уровне приложения:
Не знаю, чем пишет PostgreSQL в сокет, но в любом случае при попытке записи в сокет который перешел в CLOSE_WAIT рабочий процесс получит ошибку. write по идее должен завершиться с ошибкой EPIPE, после чего рабочий процесс должно сделать close, хотя может завершится и без этого, ядро фоном это сделает само. В первом приближении все должно происходить быстро и без задержек.

P.S. Описания добавленные в уточнении вопрос противоречат первоначальной формулировке вопроса. Не полученный отлуп к клиента это проблемы с сетью или хостом клиента, но в случае умирая процесса клиента TCP стек клиента по прежнему работает и он берет на себя функции уведомления хоста сервера об ошибке поэтому все происходит достаточно быстро.