Здравствуйте, AlexGin, Вы писали:
AG>Я тут нашел вот это:
AG>https://github.com/qtproject/qt-solutions
AG>Но у меня всё-же складывается впечатление, что оно достаточно древнее? AG>Стоит ли в этом направлении копать?
Я на него выше и давал ссылку , использовал оттуда qtsingleapplication и qtservice никаких нареканий не замечено, тебе от туда вроде только qtservice нужен, чтобы самому демонизацию не писать.
Здравствуйте, AlexGin, Вы писали:
AG>Доброе время суток, уважаемые коллеги!
AG>Посоветуйте, пожалуйста, современное решение на Qt (Qt-5), AG>позволяющее полностью реализовать описанную в моём посте:
AG>http://rsdn.org/forum/network/7502716
Ответ на самом деле очень простой. Это gRPC. Особенно с учётом того, что у вас уже есть Protobuf. gRPC так же поддерживается nginx, если у вас будет распределённая система.
Будут проблемы со сборкой gRPC под винду — обращайтесь. Она несколько нетривиальна.
P.S.
Почитал ветку, которую вы упомянули. Ещё есть SQbjectizer
Здравствуйте, Igore, Вы писали:
I>Я на него выше и давал ссылку , использовал оттуда qtsingleapplication и qtservice никаких нареканий не замечено, тебе от туда вроде только qtservice нужен, чтобы самому демонизацию не писать.
Подвтерждаю: использовал и то и другое, все нормально работало (мне нужна была только винда).
Здравствуйте, AlexGin, Вы писали:
AG>Доброе время суток, уважаемые коллеги!
AG>Предполагаю — что есть готовая библиотека на базе QtNetwork.
AG>Принимаем, как аксиому, следующие отправные точки: AG>a) Между Applicatin-Server и Client-Layer применяется TCP протокол (ни о каком UDP вопрос не ставиться); AG>b) Клиенты могут быть соединены с серверами не очень надежными линиями (применеие SO_KEEPALIVE или какой-либо альтернативы ей); AG>c) Клиенты могут быть запущены раньше или позже сервера — неважно. Соединение должно быть установлено в любом случае. AG>d) Факт обрыва связи должен выявляться — как на стороне клиента, так и на стороне сервера.
Я не совсем понял чего именно не хватает в QTcpServer?
AG>ПРИМЕЧАНИЕ: AG>Скорее всего в качестве протокола верхнего уровня будет применяться Protobuf: AG>https://developers.google.com/protocol-buffers AG>но это — планирую сделать — как отдельную под-систему (не завязанную на Qt).
AG>Есть ли подобные библиотеки? AG>Поддерживают ли они запуск и работу сервера в качастве windows-сервиса или linux-демона?
Ммм, не совсем понял вопрос, если у тебя есть написаное приложение и тебе надо его в service или daemon перевести, можешь воспользоваться https://github.com/qtproject/qt-solutions/tree/master/qtservice
AG>Заранее благодарен за любые соображения
AG>P.S. Я пока сделал простое решение с применением QTcpServer; QTcpSocket и оно вполне (даже вроде как нормально) работает. AG>Тем не менее — меня гложат сомнения, что изобретаю велосипед
Уж очень не охота — варганить свои велосипеды
Предполагаю — что есть готовая библиотека на базе QtNetwork.
Принимаем, как аксиому, следующие отправные точки:
a) Между Applicatin-Server и Client-Layer применяется TCP протокол (ни о каком UDP вопрос не ставиться);
b) Клиенты могут быть соединены с серверами не очень надежными линиями (применеие SO_KEEPALIVE или какой-либо альтернативы ей);
c) Клиенты могут быть запущены раньше или позже сервера — неважно. Соединение должно быть установлено в любом случае.
d) Факт обрыва связи должен выявляться — как на стороне клиента, так и на стороне сервера.
ПРИМЕЧАНИЕ:
Скорее всего в качестве протокола верхнего уровня будет применяться Protobuf: https://developers.google.com/protocol-buffers
но это — планирую сделать — как отдельную под-систему (не завязанную на Qt).
Есть ли подобные библиотеки?
Поддерживают ли они запуск и работу сервера в качастве windows-сервиса или linux-демона?
Заранее благодарен за любые соображения
P.S. Я пока сделал простое решение с применением QTcpServer; QTcpSocket и оно вполне (даже вроде как нормально) работает.
Тем не менее — меня гложат сомнения, что изобретаю велосипед
Здравствуйте, Kswapd, Вы писали:
K>gRPC наверняка намного производительнее.
Вполне может быть
Главный плюс QJSonRPC — естественная интеграция с Qt-шными сигналами и слотами.
Вообще "Qt + RPC" — это такой священный грааль, который найти никто не может, поэтому есть десяток решений разной степени кривости/заброшенности. Наверное потому что веб и встроенные в приложения браузеры победили.
Здравствуйте, уважаемый SaZ, Вы писали:
SaZ>Ответ на самом деле очень простой. Это gRPC. Особенно с учётом того, что у вас уже есть Protobuf. gRPC так же поддерживается nginx, если у вас будет распределённая система. SaZ>Будут проблемы со сборкой gRPC под винду — обращайтесь. Она несколько нетривиальна.
Спасибо, буду иметь в виду gRPC.
Как меня информировали на стороне Заказчика — им более актуален Linux, нежели винда.
Но в любом случае — надо покапать в сторону gRPC
SaZ>P.S. SaZ>Почитал ветку, которую вы упомянули. Ещё есть SQbjectizer
Здравствуйте, уважаемый Igore, Вы писали:
I>Как я понял у тебя основное время, это время рассчетов,
Это далеко не факт!
Расчет может быть и в течении одной секунды. Пока нет определенности.
Тем более, если в качестве сервака будет тот же Linux (показавший себя серьёзно быстрее винды для математических расчетов).
I>тогда с транспортом чем проще тем лучше, можно посмотреть на такое https://blog.qt.io/blog/2019/02/01/qhttpserver-routing-api/ , сам не пробовал, но выглядит интересно.
Спасибо, гляну!
P.S. В QTcpServer на мой взгляд всё вполне разумно (и всего хватает).
Но я рассчитываю найти подходящее комплексное решение:
Которое не только обеспечит работу этого самого сервера, но и обеспечит скрытый процесс (возможно — ещё и логирование),
также вполне возможно — некоторую поддержку и более высокоуровневых (кроме транспорта) протоколов...
Конечно же, можно и велосипедить
Вопрос: нужно ли?
Тем более, что на сегодняшний день почти все приложения — трехуровневые, клиент-серверные.
Также и поддержка микросервисной архитектуры — была бы совсем не лишней (...и тут Остапа понесло...)
Здравствуйте, уважаемый Skorodum, Вы писали:
S>Здравствуйте, Kswapd, Вы писали:
S>Вообще "Qt + RPC" — это такой священный грааль, который найти никто не может, поэтому есть десяток решений разной степени кривости/заброшенности. S>Наверное потому что веб и встроенные в приложения браузеры победили.
Скорее потому, что на серверной стороне применяются более легковесные, нежели Qt-шные, решения.
Ну и работа с БД — через OTL (или POCO — на крайняк).
Тем более, что GUI там никому не нужен (от слова вообше).
А закрыть потребности клиента — бери QtNetwork и вперёд
P.S. Сама по себе Qt — всё-таки довольно немаленькая библиотека, но для GUI — самое то!!!
Я сам пока экспериментирую с применением Protobuf в Linux (Ubuntu 16.04).
При этом, я прекрасно осознаю, что "серебрянной_пули" в IT и софто-разработке нет.
Посему, хотелось бы принять наиболее адекватное нашим проектам решение.
Кроме этого, очень хотелось бы чётко представлять аргументацию выбранного решения (а также его pros- and cons-)
, использовал оттуда qtsingleapplication и qtservice никаких нареканий не замечено, тебе от туда вроде только qtservice нужен, чтобы самому демонизацию не писать.
