Назад | Перейти на главную страницу

Тайм-ауты TCP-соединения, которые сохраняются - невыполнение очереди слушателя?

У меня есть приложение, работающее на AIX 6.1, в котором есть один серверный процесс, который прослушивает и опрашивает TCP-соединения и просто пересылает сообщения другому процессу, используя очередь сообщений IPC. Он эксплуатируется годами и обычно без проблем обрабатывает 1000 и более соединений. Но вчера у нас была ситуация, когда соединения с этим сервером в большинстве случаев отключались по тайм-ауту. В то же время подключения к другому экземпляру этого сервера (прослушивание другого номера порта на той же машине) работали нормально. Также передача данных по существующим соединениям прошла нормально, а загрузка процессора была небольшой.

Эта ситуация сохранялась в течение нескольких часов и продолжалась даже после перезапуска рассматриваемого слушателя. Затем, сегодня утром, внезапно все прояснилось и все стало нормально работать.

Что действительно странно в этом, так это то, что внутренние соединения клиентского процесса, запущенного на том же сервере, также задерживались и иногда истекали по таймауту.

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

Спасибо Роб

Обратите внимание - возможно, мы решили эту проблему. Похоже, что было сетевое расположение, которое достигало частичных соединений (возможно, входящие пакеты были маршрутизируемыми, но не исходящими). В любом случае в состоянии SYN_RCVD была куча подключений, а параметр 'backlog' в прослушивающем сокете сервера был всего 5, поэтому группы пользователей, пытающихся подключиться из плохого места, было достаточно, чтобы съесть весь доступный задел и не впускать никого - я думаю, пока что-то не истекло время частичных подключений.

Итак, я думаю, что изменю свой вопрос и просто поинтересуюсь хорошим практическим правилом для установки параметра «Backlog» на listen (). Я пока увеличил его с 5 до 20, но мы прожили с 5 годами без проблем.