Быстродействие сервера

[sidsukana]

Есть сервер (допустим некой игры). Соответственно есть опкоды, которым он обменивается с клиентами и их хендлеры. Этих опкодов может быть очень много (ну на разные игровые события) соответственно много хендлеров. Так вот есть такой вопрос - как правильно реализовать обработку хендлеров? Правильно ли будет при приеме очередного пакета с клиента, использовать сигнал-слот для передачи данных в хендлер? Или же по старинке использовать указатель на функцию хендлера? Вообще использование сигналов-слотов в реализации клиент-серверного пинг-понга это будет нормально, или же постепенно глобальный eventloop Qt будет переполняться и все пойдет под откос?))

И опять же, мы говорим про серверную сторону - клиентов может быть и 10 и 100 и 1000. Естественно будет необходима многопоточная реализация.

[Bepec]

Если нагрузка на сервер минимальна (100-300 соединений) то сигналы спокойно справятся.
Если нагрузка больше, то желательно обойтись без сигнал-слотов на каждый чих.

У нас есть один интересный человек, alexis(тут много цифр). Он реализовал вроде сервер на С++. Можете спросить совета у него.

[alexis031182]

Верес прав. Если нужен максимально быстрый отклик, то лучше без сигнал-слотов обойтись. Также, лучше не использовать QTcpServer. Он удобен и прост, но относительно медленный при большом количестве соединений. Для виндовса рекомендовать ничего не могу (попросту не работаю с этой ОС), а для Linux используйте epoll.

[sidsukana]

QTcpServer он же просто принимает соединения, или я не прав? Вся работа же лежит на QTcpSocket(AbstractSocket)?

[Bepec]

Там по идее всё на сигнал слотах, соответственно каждое соединение тормозит на всё большее время и так пропорционально нагрузке.

[sidsukana]

Соединение же одноразовое. Черт, я забыл сказать что используются сессии.

[alexis031182]

QTcpServer он же просто принимает соединения, или я не прав? Вся работа же лежит на QTcpSocket(AbstractSocket)?

Да, я имел в виду не использовать связку QTcpServer и QTcpSocket.

[alexis031182]

Соединение же одноразовое. Черт, я забыл сказать что используются сессии.

Если клиент - браузер, то как минимум одно соединение с каждого клиента остаётся подключенным. Если конечно сервер работает на HTTP/1.1 и "вручную" не отключает соединение после отправки данных клиенту. Если же клиент - не браузер, то имеет смысл рассмотреть вариант с неодноразовыми подключениями.

[sidsukana]

В общем сделать на Qt хорошо организованный сервер не выйдет, да?
Я просто к чему. Мне очень нравится фреймворк, и есть задача реализовать такой сервер средствами Qt. Т.е даже без гуи, просто использовать кросс-платформенные возможности Qt не как gui фреймворка.

[alexis031182]

В общем сделать на Qt хорошо организованный сервер не выйдет, да?

Выйдет, и довольно быстро сделаете, просто он будет работать медленно при большом количестве соединений.

Я просто к чему. Мне очень нравится фреймворк, и есть задача реализовать такой сервер средствами Qt. Т.е даже без гуи, просто использовать кросс-платформенные возможности Qt не как gui фреймворка.

Я тоже с этого начал, делал (и делаю) HTTP-сервер. Но потом пришлось отказаться от сетевой части Qt, т.к. скорость работы оставляла желать лучшего в сравнении с тем же nginx. Перешёл на epoll (Linux) - совсем другое дело стало. Так что Вы можете основную часть программы реализовать на Qt, а поддержку сети лучше делать другими средствами.