Использование sys-вызова Listen () на многопоточном TCP-сервере

Question

Я нахожусь в процессе разработки многопоточного TCP-сервера с использованием Berkely SOCKET API под Linux на системно-независимом языке Си.Сервер должен выполнять мультиплексирование ввода-вывода, поскольку сервер является централизованным контроллером, который управляет клиентами (которые постоянно поддерживают постоянное соединение с сервером (если только на компьютере, на котором работает клиент, происходит сбой и т.д.)).Сервер должен обрабатывать как минимум 500 клиентов.У меня есть 16-ядерная машина, я хочу, чтобы я создал 16 потоков (по одному на ядро) и основной поток.Основной поток будет listen() подключаться, а затем отправлять каждое подключение в списке очередей потоку, который затем вызовет accept(), а затем использует вызов select() sys для выполнения мультиплексирования ввода / вывода.Теперь проблема в том, как мне узнать, когда нужно отправлять поток для вызова accept().Я имею в виду, как мне узнать в главном потоке, что на listen() ожидается соединение, ожидающее подключения, чтобы я мог назначить поток для обработки этого соединения.Вся помощь высоко ценится.Спасибо.

Answer 1

Вызов функции listen () подготавливает сокет для приема входящих соединений.Затем вы используете select () на этом сокете и получаете уведомление о получении нового соединения.Затем вы вызываете accept на серверном сокете, и будет возвращен новый идентификатор сокета.Если вам нравится, вы можете передать этот идентификатор сокета в свой поток.

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

Answer 2

Обратите внимание, что если каждый из ваших 16 потоков будет работать select (или опросить, или что-то еще) в любом случае, нет проблем с тем, чтобы все они добавляли сокет сервера в свои наборы выбора.

Может проснуться больше одного, когда сокет сервера находится во входящем соединении, но только один успешно вызовет accept, поэтому он должен работать.

Pro: легко кодировать.

Con:

• Наивная реализация не балансирует нагрузку (потребуется, например, глобальная статистика по числу принятых сокетов, обработанных каждым потоком, с высоконагруженные потоки, удаляющие сокет сервера из их наборов выбора)
• громоподобное стадное поведение может быть проблематичным при высоких скоростях приема

Answer 3

epoll или aio / asio. Я подозреваю, что вы не получили ответов на свое предыдущее сообщение, потому что вы не указали linux, когда просили масштабируемое высокопроизводительное решение. Асинхронные решения в разных ОС реализованы с существенной поддержкой ядра, и linux aio, Windows IOCP и т. Д. Настолько различаются, что «системно-независимый» на самом деле не применяется - никто не может дать вам ответ.

Теперь, когда вы сузили ОС до linux, найдите соответствующие асинхронные решения.