Почему я получаю отказ от соединения после 1024 соединений?

Если вы подключаетесь быстрее, чем ваш сервер зовет accept(), очередь ожидающих соединений может быть заполнена. Максимальная длина очереди устанавливается вторым аргументом в listen() на сервере, или значение sysctl net.core.somaxconn (обычно 128), если ниже.

возможно, вы достигли предела процесса для открытых файловых дескрипторов.

Я не уверен, правильно ли я вас понимаю: у вас есть как серверная, так и клиентская стороны в одном процессе? Тогда вы будете использовать вдвое больше файловых дескрипторов. Это близко к тому, что вы видите с ulimit. Если это не так может быть проблема на стороне сервера? Возможно, серверный процесс исчерпал дескрипторы и больше не может принимать больше подключение.

на принять man page указано, что вы должны получить возвращаемое значение:

EMFILE
Достигнут предел для каждого процесса открытых файловых дескрипторов.

ENFILE
Системное ограничение на общее количество открытых файлов.

какой код ошибки вы получаете? Очевидно, вы можете добавлять только те соединения, которые были успешно _accept_ed в выберите или опрос.

Я знаю, что вы уже знаете, как проверить ограничение, но другие не могут:

ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 40448
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4096
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 40448
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

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

какой верхний предел, по словам другой группы, имеет сервер?

в одной программе, за которой я присматривал (несколько лет назад), был бит кода, который установил максимальный размер файла в 1 МБ. Жаль, что, когда он был впервые добавлен, он увеличил размер, но с течением времени и ростом ограничений файлов это означало, что позже он уменьшался! Есть ли возможно, у сервера есть аналогичная проблема-он устанавливает максимальное количество открытых файлов на смехотворно большое число, например 1024?

извиняюсь за, в основном, тривиальные вопросы :)
вы перекомпилировали сервер, когда сказали "изменено на опрос"? Сервер работает под одной учетной записью? Это fork - ing или, может быть, потоковый сервер? Вы получаете errno == ECONNREFUSED после вызова connect() на клиенте? Можете ли вы подтвердить, что получите RST в ответ на SYN С tcpdump? Номера клиентских портов используются повторно? Есть ли связи в TIME_WAIT государство?

Я видел комментарий, который вы сделали с оператором close(sock_fd) в процедуре обработки ошибок.

вы явно закрываете сокеты после их использования-close () или shutdown ().

Я бы предположил, что нет. У вас действительно есть 1024 + параллельных активных соединения? Для этого вам придется задействовать pthreads. Это верно?

У меня были те же симптомы. Даже после увеличения ulimit-n я все еще не мог справиться с более чем 1024 входящими соединениями...

моя проблема заключалась в том, что я использовал select, который не может обрабатывать socket-FDs выше 1024. Поэтому, когда я увеличил свой лимит, моя проблема действительно изменилась!!!(сначала я этого не заметил...)

Итак, чтобы помочь кому-либо с подобными проблемами:

если вы хотите больше, чем 1024 сокета у вас к

• увеличить код ограничения для открытого FDs (ulimit-n)
• и возможно Не использовать select() (использовать опрос (), а)

ваше ограничение от ограничения пользователя linux. Если не указано, ограничения linux должны составлять 1024 открытых файла. Чтобы изменить это, постоянно редактируйте /etc/security / limits.conf и добавить

пользователь soft nofile 16535 пользователь hard nofile 16535

или из консоли try

параметр ulimit -Н 16535

в отношении