Исчерпание невыполненной работы TCP приводит к тому, что входящие соединения не сигнализируются

Я делаю следующее:

  1. Откройте прослушивающий TCP-сокет.
  2. Установите ЗАДЕРЖКУ на 10
  3. Открыть 50 соединительных сокетов (используется неблокирующее соединение)
  4. опрашивать прослушиваемый сокет и принимать соединения
  5. Соединения, способные передавать какие-либо данные, закрываются

Что я вижу, так это то, что все 50 соединений успешны, однако POLLIN на сокете прослушивания сигнализируется только ~ 30 раз. Это означает, что принимается только 30 подключений.

Когда я запускаю netstat в таком состоянии, я не вижу зависших УСТАНОВЛЕННЫХ соединений. Есть несколько соединений, зависших в состоянии TIME_WAIT, но это не имеет значения.

Вышеупомянутое наблюдалось в Linux, однако подобное поведение, по-видимому, происходит и в FreeBSD и NetBSD.

У кого-нибудь есть опыт с подобными вещами?


tcp sockets connect backlog nonblocking
person Martin Sustrik    schedule 01.06.2012    source источник
comment
Покажите какой-нибудь код - особенно для основного цикла на сокете прослушивания.   -  person selbie    schedule 01.06.2012
comment
Сам код довольно сложен, но суть такова: while (1) { poll (fd, POLLIN); принять (фд); }   -  person Martin Sustrik    schedule 01.06.2012
comment
Некоторые другие эксперименты, кажется, предполагают, что опрос прослушивающего сокета запускается по фронту, а не по уровню. Странный.   -  person Martin Sustrik    schedule 01.06.2012
comment
Неа. Обработка прослушивающего сокета как запускаемого по фронту снижает вероятность возникновения проблемы, но иногда она все же возникает.   -  person Martin Sustrik    schedule 01.06.2012

Ответы (1)


arrow_upward
2
arrow_downward

У меня есть объяснение из ряда вон выходящее. Кому интересно, может прочитать об этом здесь:

http://www.evanjones.ca/tcp-stuck-connection-mystery.html

person Martin Sustrik    schedule 01.06.2012
comment
Интересно. Увеличение отставания до более чем 50 смягчает проблему или устраняет ее? - person selbie; 01.06.2012