Russian Qt Forum

Здравствуйте!

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

- Сервер будет держать около 50 клиентов постоянно подключенными;
- Общение происходит текстовыми строками в xml-подобном варианте. В основном по принципу запрос-ответ, но также сервер может рассылать команды самостоятельно, в т.ч. по запросу одного из клиентов;
- Необходима графическая среда для отслеживания ошибок и управления подключениями;
- В основном, в сервере сосредоточена несложная логика системы, но много SQL-запросов.

На примере fortune server и своих домыслов я бы сделал так:
1. Основной поток - для UI
2. В дополнительном потоке вертится постоянно слушающий порт QTcpServer и диспетчер подключений
3. Как только создается новое подключение, создается новый поток и новый сокет перенаправляется туда.
4. В потоке, обслуживающем сокет создается отдельное подключение к базе данных

Читая различные материалы, я понял, что это достаточное избыточное решение, слишком много потоков.
Как сделать правильно? Какова общая архитектура сервера?

для 50 клиентов наверное по фигу как реализовывать.
А так на форуме уже много раз поднималась подобная тема. Правда все разбросано по темам.

Именно что все разбросано.
Не выходит в голове построить оптимальную модель.
Да, 50 клиентов - не так и много, но хочется же сделать правильно.

В целом идеология поток на соединение избыточна.
Поэтому один поток должен обслуживать некоторое количество соединений (пул соединений).
А какое количество соединений оптимально на один поток мне неизвестно)
Видимо нужно делать это параметром и смотреть как себя ведет сервер в нагрузке.

Ну так и создавай один поток коммуникатор, который занимается обслуживанием клиентов, а второй обработчик, который и занимается рутинной работой - обработка информации, получил что то, поставил в очередь, отдал потоку обработчика, принимаешь другие запросы, как только поток обработчик что то выполнил он передает потоку коммуникатору результат.

Просто видишь, сколько потоков не мути, количество процессоров у тебя не увеличится) а количество оперативной памяти на их обслуживание увеличится. Так что смысла в 100500 потоках не вижу, тут достаточно 3-х: главный - уи, 2-й коммуникатор, 3-й обработчик. И будет счастье, для синхронизации работы, или использовать стандартные средства для реализации очередей, либо писать свой класс очереди, под свои нужды(специфические форматы данных).

Есть смысл использовать плавающий пул потоков

можно поподробнее об этом?