Сервер на Qt

Не на C++, а на C++ + Qt.
Кроссплатформенность же.

а без Qt кроссплатформенности на c++ не бывает, да?

Какого очевидного

Очевидно, что местным тролям это такая идея не понравится.

Обертка для сокетов, обертка для взаимодействия с базой, обертка обертка, обертка.

ПРоще использовать хороший готовый тулкит для таких вещей.

Конечно, этот тулкит будет работать без оберток, кроссплатформенно.

Сервер на Qt

Вполне реально

Я понимаю, что идея плоха в корне (серверное приложение с использованием графического фреймворка, ага)

Ты не понимаешь :}

Из личного опыта: написал и сопровождаю один сервер на C++/Qt. Из интересующих тебя плюшек там:

• Реализация протокола Websockets на QTcpServer/QSslSocket (пока держит пару десятков клиентов, больше не затребовано). Сначала взял QtWebsockets, но потом пришлось переписать с нуля. Довольно легко разносить сокеты по нескольким тредам-worker'ам.
• Реализовал клиентскую часть AMI (Asterisk Management Interface). Использован QTcpSocket.
• Реализация RESTful API для сервера. Заюзал QxtWeb из библиотеки Qxt (внутри тот же QTcpServer).

Исходники могу и выложить, только причесать их надо.

Недостатки: если придётся держать сотни соединений, то от кутешных сокетов придётся отказаться в пользу libev/libevent/boost::asio (или писать вручную на epoll или в зависимости от платформы, но, ИМХО, это неразумно). Внутри кутешных сокетов толи poll, толи select, Один хрен под нагрузками скукожится.

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

Обертка для сокетов,

да

а это всё:

обертка для взаимодействия с базой, обертка обертка, обертка.

в помойку, про это речи не было

ПРоще использовать хороший готовый тулкит для таких вещей.

нет, именно в данном случае, если нужны чисто сокеты, проще написать обёртку, там пара ifdef'ов всего

Написанный на Qt сервер будет обладать огромным перимуществом - кроссплатформенность.

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

уж лучше vala

Если статически - может быть многовато.

Как раз при статической линковке обычно размер бинаря меньше, чем динамический бинарь + шаред либа. Неиспользуемый код линкер выкидывает.

Нагрузки какие будут? Если небольшие, то можно делать. Если серьезные, то лучше взять что-то более вменяемое, например boost::asio.

Кроссплатформенность С++ только для кода, не использующего специфичные для ОС вещи, то есть без: - сокетов. - потоков. - пользовательского интерфейса. - много чего еще.

Другое дело, что написать для этих вещей переносимые обертки можно и самому. Но велосипед же.

Другое дело, что не только Qt кроссплатформенный, это просто один из вариантов.

Недостатки: если придётся держать сотни соединений, то от кутешных сокетов придётся отказаться в пользу.

Приложение на Qt более-менее нормально держит 1-2 тысячи активных соединений на поток/ядро процессора с суммарным сетевым трафиком в десяток мегабит/с. На пределе ядра G620 процессора и интелевской сетевушки можно тащить 3-4 тысячи.

Сабж есть рекомендация (ВНИМАНИЕ не требование и не обязывание)

ну, это рекомендация не стучать себе молотком по яйцам и не совать лицо в вентилятор, но таки рекомендация, да

Написание даже самой примитивной обертки занимает несравнимо больше времени, чем использование существующей.

во-первых не факт, а в данном случае как раз таки вообще не факт, а во-вторых пишешь ты один раз, а поддерживаешь долго-долго, что легче, один раз написать или костыли сменные возить (всё здесь сказано безотносительно Qt как такового)? :)

Ну дык сабж «методы объекта обязаны вызываться в том же потоке» не есть ограничение Qt, это есть единственный разумный подход в плюсах вообще и только до тех пор, пока разраб не удосужится методы сделать потокобезопасными. Т.е. изначально разговор идёт про 4.2 в словах того товарища, что это сказал.

Кроме очевидного, какие недостатки будут у такой программы?

Qt - это как раз та вещь, которая компенсирует недостатки плюсов

Вопрос в том, что тебе конкретно нужно реализовать?

А вообще, если апликуха сугубо консольная, советовал бы посмотреть в сторону D

Пиши на яве. Если можешь, то на скале.

Все зависит от конкретных условий эксплуатации, на вообще сервер на Qt - вполне себе рабочее решение. Кроме того, QtGui линковаться с твоим бинарником не будет и графики соответственно никакой тоже не будет.

Boost::ASIO же

Что-бы не было мешанины из говна и палок

Расскажи рецепт

В этом случае в Qt даже особенно париться не надо, а вот ОС требует настройки. Увеличение ulimit, увеличение параметров sysctl, относящихся к сети - там надо копаться и экспериментировать, но основные: net.ipv4.neigh.default.gc_thresh* - количество соседей в сети, требуется не всегда, но для боооольной локалки нам потребовалось. net.core.*mem_default, net.core.*mem_max, net.ipv4.tcp_*mem, net.core.netdev_max_backlog, net.ipv4.tcp_max_syn_backlog

По крайней мере, нам помогло.

тот-же эрланг, например.

Я посмотрю на лоре каждый второй осилятор ерланга.

ТС не слушай кучку троллей =) ты ведь не для интерпрайза собрался писать?

C++ Qt4 в роли фреймворка для сервера это вполне нормально, если ты грамотно будешь писать.

ЗЫ могу помочь парой тройкой советов по теме. стучись в гуглоталк, есть в профиле.

ЗЗЫ erfea алоха друк =)

Я посмотрю на лоре каждый второй осилятор ерланга.

Модно же.

Модно же.

Пфф, старьё попсовое для лохов. Новинка сезона - Reia. Я уже закал футболку и кружку с логотипом.

В Qt удобные сокеты.

Это заблуждение. Ни чего удобного в них нету. Да и тормозные они.