QThread, QEvent, QTcpServer, взаимодействия между потоками Опции

[ViGOur]

Ну вот, а на пргорге тема о высоконагруженном сервере на Qt зашла в тупик

Просто они не в ту сторону смотрели...

512es, и все же я тебе рекомендую попробовать в одном потоке держать несколько подключений.
Попробуй сделать одно оооочень медленное (например передачу огромного файла), и после этого 5-10 быстрых соединений, посмотри как они обработаются...

[512es]

ViGOur, провёл эксперимент:
подключился двумя клиентами. один из них отправлял файл на 200 мб а второй быстро посылал маленькие пакеты серверу и получал ответ. пока файл отправлялся подключился ещё двумя клиентами и тоже быстро отсылал небольшие пакеты. задержек вообще никаких не наблюдалось!) всё работало так, какбудто 200 меговый файл и не принимался.
разве что, когда закончилась передача файла и он поступил в главный поток для обработки (в данном случае для записи на диск), отсылка ответов клиентам приостановилась ненадолго. но все пакеты скапливались в очередь и сразу обработались как только запись файла завершилась =)
а если такие большие пакеты посылать в отдельный специальный поток, с низким приоритетом то вообще хоть терабайты пересылать можно, никто и не заметит =)

[ViGOur]

а если такие большие пакеты посылать в отдельный специальный поток, с низким приоритетом то вообще хоть терабайты пересылать можно, никто и не заметит =)

Вот и я об этом же, потому и рекомендую экономить ресурсы, и повесить хотя бы по 32 соединения в поток, а не 1.

32 соединения в поток, 320 соединений, это не 320 потоков, а 10, разница есть?

[512es]

тут просто разные нужды. мне важно чтобы все юзвери ансинхронно получали и отправляли маленькие пакеты. без задержек и очередей на приём\отправку. и оно отлично работает когда на каждого отдельный поток.

хотя я и планирую иногда передавать от сервера к юзверем файлы не больше 1 мб, это не файлообменник, где можно экономить на времени отклика, выстраивая отправку\приём в очередь.
вот наверное поэтому я всё никак с вами не соглашусь =))

32 соединения в поток, 320 соединений, это не 320 потоков, а 10, разница есть?

ХР может спокойно работать с 2032 потоками. 2000 пользователей меня вполне устраивают =) каких то особых тормозов от создания\удаления потоков или поедания памяти я не вижу. а ещё рассчёт на многопроцесорные машины на мноого лет вперёд))))

а если такие большие пакеты посылать в отдельный специальный поток, с низким приоритетом то вообще хоть терабайты пересылать можно, никто и не заметит =)

Вот и я об этом же, потому и рекомендую экономить ресурсы, и повесить хотя бы по 32 соединения в поток, а не 1.

тут немного ни о том речь))
1) есть много много потоков, по 1 на юзверя (с низким приоритетом)
2) есть главный поток в котором очередь обработки (логика)

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

вот и всё =)

[ViGOur]

тут немного ни о том речь))

Понятно, вам выбирать принцип работы...