Russian Qt Forum

Реально ли реализовать на Qt высоконагруженный сервер с 500-1500 одновременными долговременными подключениями?
Я не особо знаком с этой частью на Linux/MacOSX, но под виндовс это возможно через connection port, использует ли подобные технологии Qt?
Варианты реализации с отдельными потоками на каждое соединений или отдельными потоками на группу из 16-32 соединений не выдерживают больше сотни-двух подключений не зависимо от можности сервера.
 

ИМХО, Так же, как и Виста на втором третьем пне, я думаю.


А что в потоки выносится? Обработка подключений? Обработка запросов клиентов?

В потоках вся обработка сообщений. В общем что то типа чат-сервера, приходит сообщение от пользователя, его заголовок проверяется от кого и для какой группы и далее оно пересылается с небольшими изменениями всем другим пользователям той же группы.
На Windows у меня реализовано руками через connection-port c двумя рабочими потоками, 500-600 подключений держит стабильно. Но хотелосьбы кросплатформенного решения.

я бы порекомендовал для начала почитать отличия apache1 от apache2 - как они сделаны ( кроссплатнформенный он)
почитать про клиент Ultima Online, он в исходах доступен и кучу народа держит по отзывам
потом посмотреть как это к QT привязать

PS: я не большой тут спец, может че не так написал

а что если использовать класс QxtAbstractConnectionManager из qxt?
http://docs.libqxt.org/latest/classQxtAbstractConnectionManager.html

Судя по всему этот "connection port" - аналог классического select-а?
2 Detonator дай хоть ссылку на документацию. Чтоб можно было точно понять что это. :)

to Detonator, а вы смотрели экзампл чата поставляющийся вместе ку кьюти QTDIR/examples/network/chat/? хз, может поможет.  :)

Извиняюсь, ошибся в названии, на самом деле называется "I/O completion ports"
http://www.gamedev.ru/community/mmorpg/articles/?id=6

Но есть ли аналог под Linux/MacOSX я до сих пор не нашел.

Простой select не масштабируем, т.к. очень медленный когда работаешь с сотнями сокетов. Я с этим еще давно столкнулся.
Вот тут к примеру хорошо описана эта проблема, но статья старая, я не знаю найдено сейчас кросплатформенное решение или нет.
http://www.atnf.csiro.au/people/rgooch/linux/docs/io-events.html

Делить сокеты на группы по 16-32 штук в каждой и каждую в группу обрабатывать в своем потоке - такой способ реализации я предполагаю на крайний случай если не найдется найти ничего лучшего, взаимодействие между самими такими потоками сильно усложнит программу, к тому же незнаю как в линуксе, а под виндовс каждый новый поток отнимает около 1Мб памяти, да и при большом количестве потоков только на переключение и синхронизацию меджду ними тратится ну очень много времени, программа ведет себя уже не очень предсказуемо.

http://w0.sao.ru/hq/vch/Publications/Russ/html/linux-posix/node7.html
http://lrn.ru/index.php?module=library&action=show&docid=76&part=878
Ну и вообще google асинхронный+ввод+вывод+linux смотрел?

Смотрел. А еще о aio_read() читал такое: "This model looks appealing, until we look under the hood of some aio_*() implementations. The Linux glibc implementation is a case in point: there is no kernel support. Instead, the C library (glibc 2.1) launches a thread per FD for which there are outstanding AIO requests (up to the maximum number of configured threads)."
Ну и кому нужна такая реализация с тысячей потоков в фоне?

Есть еще такая штука, как QSocketNotifier... Вроде для  ИОПорта то что нужно, только вместо очереди эвентов видимо надо ждать сигнала...