То, почему я делаю пересадку, отказалось после 1 024 соединений?

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

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

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

На странице руководства accept упоминается, что вы должны получить возвращаемое значение:

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

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

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

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

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?

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

Your limitation is from linux user limitation. If not specified the linux limits are to 1024 open files. To change that permanently edit /etc/security/limits.conf and add

user soft nofile 16535 user hard nofile 16535

or from console try

ulimit -n 16535

Regards

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

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

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