LINUX.ORG.RU

Сервер на Qt

 


0

2

Я понимаю, что идея плоха в корне (серверное приложение с использованием графического фреймворка, ага), но все же.
В Qt удобные сокеты. Мне лично понравились. Можно собирать проекты без графической части (+core -gui). Кроме очевидного, какие недостатки будут у такой программы?

Перемещено mono из talks

Но зачем вообще здесь кресты?

dmfd ()

серверное приложение с использованием графического фреймворка

А кто сказал, что Qt — это исключительно графический фреймворк? Нравится — делай, ничего такого сверхстрашного в этом нет.

SoulThreads ()

кто-то на лоре даже приводил историю успеха по этому поводу

nexus86 ()

Во всех нормальных дистрах qt уже давно поделён на отдельные компоненты и вполне можно поставить core и прочие нужные пакеты без gui и прочих не нужных, что тебе, собственно, и требуется.

INFOMAN ★★★★★ ()

Qt
графического фреймворка

/0

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

Какие недостатки вам очевидны?! ЗЫ если руки не из зада, проблем не вижу.

erfea ★★★★★ ()
Ответ на: комментарий от INFOMAN

Во всех нормальных дистрах qt уже давно поделён на отдельные компоненты и вполне можно поставить core и прочие нужные пакеты без gui и прочих не нужных, что тебе, собственно, и требуется.

Скажу больше, у меня даже работает. На серве где графического вообще ничего нету. USE="-X" глобально.

erfea ★★★★★ ()

серверное приложение с использованием графического фреймворка, ага

new project -> console app //как то так

Кроме очевидного

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

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

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

ymuv ★★★★ ()
Ответ на: комментарий от ymuv

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

Погоды не сделает. Может только если запустить over9000 приложений на оперативе даст ощутимый эффект.... А дисковое пространство так эпично экономить точно ни к чему )))

erfea ★★★★★ ()

Пишу небольшую клиент-серверную игрушку j4f на кутях. Всем доволен, но для реального проекта лучше использовать более «серверные» языки, тот-же эрланг, например.

Dragon59 ★★ ()

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

Thero ★★★★★ ()
Ответ на: комментарий от erfea

Чем лучше-то?

Но зачем писать сервер на относительно низкоуровневых плюсах, если скорость некритична, когда на том-же эрланге это можно сделать в 3 раза быстрее, не сношая мозг масштабированием, распарелливанием и отладкой?

Dragon59 ★★ ()
Ответ на: комментарий от erfea

но лучше прелинк и динамическая линковка.

Thero ★★★★★ ()
Ответ на: комментарий от Dragon59

и теперь: а на эрланге есть удобные сокеты?

Thero ★★★★★ ()
Ответ на: комментарий от Dragon59

Но зачем писать сервер на относительно низкоуровневых плюсах, если скорость некритична, когда на том-же эрланге это можно сделать в 3 раза быстрее, не сношая мозг масштабированием, распарелливанием и отладкой?

Если тебе знакомы кресты, а эрланг нет? Думаю по времени будет всё с точность до наоборот...

erfea ★★★★★ ()
Ответ на: комментарий от Thero

и теперь: а на эрланге есть удобные сокеты?

С сокетами в эрланге только поверхностно работал, но кутишным явно не уступают. Единственный плюс qt в этом плане - свой протокол, который не надо заного изобретать.

Dragon59 ★★ ()

Из недостатков могу лишь вспомнить неправильную работу с SSL, в частности, с ключами, которая была пару лет назад.

placeholder ()

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

А грамотно написанное приложение работает ооочень шустро.

grondek ()
Ответ на: комментарий от placeholder

Вспомнил: есть ограничения по использованию QObject-based классов и в многопоточном приложении: методы объекта обязаны вызываться в том же потоке, где был создан объект.

grondek ()

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

Торвальдс, увидев твою программу, потеряет еще пять волосин и три других поседеет.

bk_ ★★ ()
Ответ на: комментарий от Dragon59

если скорость некритична
распарелливанием

ВИП же?

WatchCat ★★★★★ ()

В Qt удобные сокеты. Мне лично понравились

В Qt очень медленные сокеты.

staseg ★★★★★ ()

не осилил BSD сокеты напрямую юзать? Фуу как не стыдно :)

Harald ★★★★★ ()
Ответ на: комментарий от WatchCat

ВИП же?

Распараллеливание не всегда ради скорости же. Особенно в серверных приложениях, где нужно работать с множеством клиентов одновременно.

Dragon59 ★★ ()
Ответ на: комментарий от grondek

есть ограничения по использованию QObject-based классов

какие?

методы объекта обязаны вызываться в том же потоке, где был создан объект.

и кто такие обязательства выписал?

erfea ★★★★★ ()

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

а ещё сигналы

какие недостатки будут у такой программы

те, которые запилишь лично ты :)

PS от Qt ещё никто не умирал

shty ★★★★★ ()
Ответ на: комментарий от Thero

а на эрланге есть удобные сокеты?

на эрланге вся сетевая часть на порядки удобнее

shty ★★★★★ ()
Ответ на: комментарий от erfea

и кто такие обязательства выписал?

да вот выписали:

As mentioned above, developers must always be careful when calling objects' methods from other threads. Thread affinity does not change this situation. Qt documentation marks several methods as thread-safe. postEvent() is a noteworthy example.

A thread-safe method may be called from different threads simultaneously. In cases where there is usually no concurrent access to methods, calling non-thread-safe methods of objects in other threads may work thousands of times before a concurrent access occurs, causing unexpected behavior.

отсюда: http://doc.qt.nokia.com/4.7-snapshot/thread-basics.html#qobject-and-threads

shty ★★★★★ ()

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

Deleted ()

Давай перейдем к общему. «Сервер на C++!?!»

vertexua ★★★☆☆ ()
Ответ на: комментарий от erfea

Как минимум, если сокет (QTcpSocket) создан в одном потоке, а poll происходит в другом, не срабатывает оповещение о приходе данных. И это ограничения архитектуры Qt4. Собстаенно и нефиг путать данные потоков так-то.

grondek ()

Тащить Qt только ради сокетов - некрасивая, плохая идея.

Deleted ()
Ответ на: комментарий от Deleted

Так-то да, библиотека разбита на довольно крупные модули. Также при использовании QtNetwork обязательно потянется QtCore (куда ж без него).

Вот если использовать всю мощь тулкита, то оно того стоит наверное. Но зависит от задачи.

grondek ()
Ответ на: комментарий от ymuv

QtCore весит 3 Мб. Если оно будет линковаться динамически, все норм. Если статически - может быть многовато.

Deleted ()
Ответ на: комментарий от Harald

Кроссплатформенность же. Нет смысла катать еще одну обертку, умеющую на одной платформе юзать сокеты BSD, а на другой - WINSOCK.

Deleted ()
Ответ на: комментарий от Deleted

Может, использовать Vala? Нормальный современный язык без крестопроблем, из зависимостей - только glib.

reserved ()
Ответ на: комментарий от reserved

А может, использовать нормальные кресты с glibmm?

Deleted ()
Ответ на: комментарий от Deleted

Нет смысла катать еще одну обертку, умеющую на одной платформе юзать сокеты BSD, а на другой - WINSOCK.

там обёртка на полкопейки

shty ★★★★★ ()
Ответ на: комментарий от shty

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

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

grondek ()
Ответ на: комментарий от shty

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

Deleted ()

Я понимаю, что идея плоха в корне

Чем плоха? Нормальная идея. Qt - отличный фреймворк и он не только гуёвый. Другое дело - что если нужен Ъ-хайлоад - то будут проблемы, тут лучше на чистом С.

Saloed ()
Ответ на: Я просто скастую это здесь... от Kalashnikov

Re: Я просто скастую это здесь...

«Чуть что, так сразу косой» ©

>В Qt удобные сокеты. Мне лично понравились.
Если будешь пользоваться, возможно ещё передумаешь :} Лично я не в курсе деталей, но в симуляторе покемон онлайна заменили его чем-то другим (SFML?). А там всего-то с тысячу пользователей онлайн на сервер.

Deleted ()
Ответ на: комментарий от shty

Читать научись... Сабж есть рекомендация (ВНИМАНИЕ не требование и не обязывание) использовать не потокобезопасные методы только из того треда к которому относится объект. КО одсказывает, что это и так очевидность. Ну а во втором обзаце КО петросянит на тему того, что потокобезопасные методы можно юзать как в бошку взбредёт. Слова обязан/обязательно/етц я не вижу.

erfea ★★★★★ ()
Ответ на: комментарий от grondek

Как минимум, если сокет (QTcpSocket) создан в одном потоке, а poll происходит в другом, не срабатывает оповещение о приходе данных. И это ограничения архитектуры Qt4. Собстаенно и нефиг путать данные потоков так-то.

И где тут «ограничения по использованию QObject-based классов» или «методы объекта обязаны вызываться в том же потоке, где был создан объект»?!

erfea ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.