Клиент-серверное решение на Qt
От: AlexGin Беларусь  
Дата: 19.08.19 15:30
Оценка:
Доброе время суток, уважаемые коллеги!

Посоветуйте, пожалуйста, современное решение на Qt (Qt-5),
позволяющее полностью реализовать описанную в моём посте:

http://rsdn.org/forum/network/7502716
Автор: AlexGin
Дата: 26.07.19


сетевую архитектуру.

Уж очень не охота — варганить свои велосипеды
Предполагаю — что есть готовая библиотека на базе 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 и оно вполне (даже вроде как нормально) работает.
Тем не менее — меня гложат сомнения, что изобретаю велосипед
Отредактировано 19.08.2019 15:41 AlexGin . Предыдущая версия . Еще …
Отредактировано 19.08.2019 15:39 AlexGin . Предыдущая версия .
Отредактировано 19.08.2019 15:34 AlexGin . Предыдущая версия .
Re: Клиент-серверное решение на Qt
От: Igore Россия  
Дата: 20.08.19 08:00
Оценка: 2 (1)
Здравствуйте, 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>Тем не менее — меня гложат сомнения, что изобретаю велосипед

Как я понял у тебя основное время, это время рассчетов, тогда с транспортом чем проще тем лучше, можно посмотреть на такое https://blog.qt.io/blog/2019/02/01/qhttpserver-routing-api/ , сам не пробовал, но выглядит интересно.
Re: Клиент-серверное решение на Qt
От: SaZ Беларусь  
Дата: 20.08.19 08:34
Оценка: 4 (1) +2
Здравствуйте, AlexGin, Вы писали:

AG>Доброе время суток, уважаемые коллеги!


AG>Посоветуйте, пожалуйста, современное решение на Qt (Qt-5),

AG>позволяющее полностью реализовать описанную в моём посте:

AG>http://rsdn.org/forum/network/7502716
Автор: AlexGin
Дата: 26.07.19


AG>сетевую архитектуру.


AG>...


Ответ на самом деле очень простой. Это gRPC. Особенно с учётом того, что у вас уже есть Protobuf. gRPC так же поддерживается nginx, если у вас будет распределённая система.
Будут проблемы со сборкой gRPC под винду — обращайтесь. Она несколько нетривиальна.

P.S.
Почитал ветку, которую вы упомянули. Ещё есть SQbjectizer
Автор: so5team
Дата: 24.05.19
и ребята присутствуют тут на форуме.
Отредактировано 20.08.2019 8:36 SaZ . Предыдущая версия .
Re: Клиент-серверное решение на Qt
От: Skorodum Россия  
Дата: 20.08.19 10:56
Оценка:
Здравствуйте, AlexGin, Вы писали:

Я использовал QJSonRPC, все работало замечательно, но она не развивается больше.
Re[2]: Клиент-серверное решение на Qt
От: Kswapd Россия  
Дата: 20.08.19 11:55
Оценка:
S>Я использовал QJSonRPC, все работало замечательно, но она не развивается больше.

gRPC наверняка намного производительнее.
Re[3]: Клиент-серверное решение на Qt
От: Skorodum Россия  
Дата: 20.08.19 12:11
Оценка:
Здравствуйте, Kswapd, Вы писали:

K>gRPC наверняка намного производительнее.

Вполне может быть
Главный плюс QJSonRPC — естественная интеграция с Qt-шными сигналами и слотами.
Вообще "Qt + RPC" — это такой священный грааль, который найти никто не может, поэтому есть десяток решений разной степени кривости/заброшенности. Наверное потому что веб и встроенные в приложения браузеры победили.
Re[2]: Клиент-серверное решение на Qt
От: AlexGin Беларусь  
Дата: 20.08.19 16:46
Оценка:
Здравствуйте, уважаемый SaZ, Вы писали:

SaZ>Ответ на самом деле очень простой. Это gRPC. Особенно с учётом того, что у вас уже есть Protobuf. gRPC так же поддерживается nginx, если у вас будет распределённая система.

SaZ>Будут проблемы со сборкой gRPC под винду — обращайтесь. Она несколько нетривиальна.

Спасибо, буду иметь в виду gRPC.
Как меня информировали на стороне Заказчика — им более актуален Linux, нежели винда.
Но в любом случае — надо покапать в сторону gRPC

SaZ>P.S.

SaZ>Почитал ветку, которую вы упомянули. Ещё есть SQbjectizer
Автор: so5team
Дата: 24.05.19
и ребята присутствуют тут на форуме.

Хорошо, посмотрю. Мне казалось что SQbjectizer — это несколько другое.
Re[2]: Клиент-серверное решение на Qt
От: AlexGin Беларусь  
Дата: 20.08.19 16:51
Оценка:
Здравствуйте, уважаемый Igore, Вы писали:

I>Как я понял у тебя основное время, это время рассчетов,


Это далеко не факт!
Расчет может быть и в течении одной секунды. Пока нет определенности.
Тем более, если в качестве сервака будет тот же Linux (показавший себя серьёзно быстрее винды для математических расчетов).

I>тогда с транспортом чем проще тем лучше, можно посмотреть на такое https://blog.qt.io/blog/2019/02/01/qhttpserver-routing-api/ , сам не пробовал, но выглядит интересно.


Спасибо, гляну!

P.S. В QTcpServer на мой взгляд всё вполне разумно (и всего хватает).
Но я рассчитываю найти подходящее комплексное решение:
Которое не только обеспечит работу этого самого сервера, но и обеспечит скрытый процесс (возможно — ещё и логирование),
также вполне возможно — некоторую поддержку и более высокоуровневых (кроме транспорта) протоколов...

Конечно же, можно и велосипедить
Вопрос: нужно ли?
Тем более, что на сегодняшний день почти все приложения — трехуровневые, клиент-серверные.

Также и поддержка микросервисной архитектуры — была бы совсем не лишней (...и тут Остапа понесло...)
Отредактировано 21.08.2019 5:05 AlexGin . Предыдущая версия . Еще …
Отредактировано 20.08.2019 19:10 AlexGin . Предыдущая версия .
Re[4]: Клиент-серверное решение на Qt
От: AlexGin Беларусь  
Дата: 20.08.19 16:59
Оценка:
Здравствуйте, уважаемый Skorodum, Вы писали:

S>Здравствуйте, Kswapd, Вы писали:


S>Вообще "Qt + RPC" — это такой священный грааль, который найти никто не может, поэтому есть десяток решений разной степени кривости/заброшенности.

S>Наверное потому что веб и встроенные в приложения браузеры победили.

Скорее потому, что на серверной стороне применяются более легковесные, нежели Qt-шные, решения.
Ну и работа с БД — через OTL (или POCO — на крайняк).
Тем более, что GUI там никому не нужен (от слова вообше).

А закрыть потребности клиента — бери QtNetwork и вперёд

P.S. Сама по себе Qt — всё-таки довольно немаленькая библиотека, но для GUI — самое то!!!
Отредактировано 20.08.2019 17:04 AlexGin . Предыдущая версия . Еще …
Отредактировано 20.08.2019 17:01 AlexGin . Предыдущая версия .
Re: Клиент-серверное решение на Qt
От: AlexGin Беларусь  
Дата: 21.08.19 07:00
Оценка:
Здравствуйте, AlexGin, Вы писали:
...

Я тут нашел вот это:

https://github.com/qtproject/qt-solutions

Но у меня всё-же складывается впечатление, что оно достаточно древнее?
Стоит ли в этом направлении копать?

Возможно, что применение Protobuf + gRPC является более перспективным решением, нежели то, что по ссыылке?
Re[2]: Клиент-серверное решение на Qt
От: Igore Россия  
Дата: 21.08.19 10:29
Оценка: 6 (1) +3
Здравствуйте, AlexGin, Вы писали:

AG>Я тут нашел вот это:


AG>https://github.com/qtproject/qt-solutions


AG>Но у меня всё-же складывается впечатление, что оно достаточно древнее?

AG>Стоит ли в этом направлении копать?
Я на него выше и давал ссылку , использовал оттуда qtsingleapplication и qtservice никаких нареканий не замечено, тебе от туда вроде только qtservice нужен, чтобы самому демонизацию не писать.
Re[3]: Клиент-серверное решение на Qt
От: Skorodum Россия  
Дата: 21.08.19 10:33
Оценка: 6 (1)
Здравствуйте, Igore, Вы писали:

I>Я на него выше и давал ссылку , использовал оттуда qtsingleapplication и qtservice никаких нареканий не замечено, тебе от туда вроде только qtservice нужен, чтобы самому демонизацию не писать.

Подвтерждаю: использовал и то и другое, все нормально работало (мне нужна была только винда).
Re[2]: Клиент-серверное решение на Qt
От: SaZ Беларусь  
Дата: 22.08.19 08:51
Оценка: 4 (1)
Здравствуйте, AlexGin, Вы писали:

AG>...

AG>Возможно, что применение Protobuf + gRPC является более перспективным решением, нежели то, что по ссыылке?


gRPC включает в себя и использует Protobuf по умолчанию. Почти все гугловые сервисы это юзают.
Re[3]: Клиент-серверное решение на Qt
От: AlexGin Беларусь  
Дата: 22.08.19 11:06
Оценка:
Здравствуйте, уважаемый SaZ, Вы писали:

SaZ>gRPC включает в себя и использует Protobuf по умолчанию. Почти все гугловые сервисы это юзают.


Я понимаю, что это: Protobuf + gRPC
вполне возможно и будет наиболее оптимальным вариантом.

Однако, я должен рассмотреть также и альтернативы.

Замечу, что у технологии Protobuf много как поклонников, так и критиков.

Обзоры первых (сторонников и поклонников):
https://i-osipov.ru/post/protocol-buffers
https://www.andrewconnell.com/blog/grpc-and-protocol-buffers-an-alternative-to-rest-apis-and-json
https://blog.conan.io/2019/03/06/Serializing-your-data-with-Protobuf.html
https://www.codeproject.com/Articles/1260597/Protocol-Buffer-A-Beginners-Walkthrough
...
и ещё много где хвалят данную технологию...

Но есть и отзывы критиков:
https://habr.com/ru/post/310032
https://habr.com/ru/post/427265

Я сам пока экспериментирую с применением Protobuf в Linux (Ubuntu 16.04).
При этом, я прекрасно осознаю, что "серебрянной_пули" в IT и софто-разработке нет.

Посему, хотелось бы принять наиболее адекватное нашим проектам решение.
Кроме этого, очень хотелось бы чётко представлять аргументацию выбранного решения (а также его pros- and cons-)
Отредактировано 22.08.2019 11:14 AlexGin . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.