Вопрос от начинающего разработчика, слабо знакомого с архитектурой распределенных приложений
Подскажите, на чем бы построить двусторонний обмен данными в клиент-серверном приложении для реализации следующей задачи:
1) клиент посылает синхронные запросы серверу с обязательным ответом
2) иногда клиенту от сервера приходят асинхронные управляющие сигналы (фактически, callback вызовы)
3) клиент точно на linux (raspberry pi), серверная инфраструктура — пока вопрос открытый
Здравствуйте, Шульженко Андрей, Вы писали:
ША>Всем привет!
ША>Вопрос от начинающего разработчика, слабо знакомого с архитектурой распределенных приложений ША>Подскажите, на чем бы построить двусторонний обмен данными в клиент-серверном приложении для реализации следующей задачи: ША>1) клиент посылает синхронные запросы серверу с обязательным ответом ША>2) иногда клиенту от сервера приходят асинхронные управляющие сигналы (фактически, callback вызовы) ША>3) клиент точно на linux (raspberry pi), серверная инфраструктура — пока вопрос открытый
ША>Буду признателен за любую помощь ША>Андрей.
1) клиент посылает синхронные запросы серверу с обязательным ответом [x]
2) иногда клиенту от сервера приходят асинхронные управляющие сигналы (фактически, callback вызовы) — Streams one directional, bidirectional server-> client, client -> serve
3) клиент точно на linux (raspberry pi), серверная инфраструктура — пока вопрос открытый C++, go, c#, etc...
Здравствуйте, Шульженко Андрей, Вы писали:
ША>Всем привет!
ША>Вопрос от начинающего разработчика, слабо знакомого с архитектурой распределенных приложений ША>Подскажите, на чем бы построить двусторонний обмен данными в клиент-серверном приложении для реализации следующей задачи: ША>1) клиент посылает синхронные запросы серверу с обязательным ответом ША>2) иногда клиенту от сервера приходят асинхронные управляющие сигналы (фактически, callback вызовы) ША>3) клиент точно на linux (raspberry pi), серверная инфраструктура — пока вопрос открытый
Здравствуйте, Шульженко Андрей, Вы писали:
ША>Всем привет!
ША>Вопрос от начинающего разработчика, слабо знакомого с архитектурой распределенных приложений ША>Подскажите, на чем бы построить двусторонний обмен данными в клиент-серверном приложении для реализации следующей задачи: ША>1) клиент посылает синхронные запросы серверу с обязательным ответом ША>2) иногда клиенту от сервера приходят асинхронные управляющие сигналы (фактически, callback вызовы) ША>3) клиент точно на linux (raspberry pi), серверная инфраструктура — пока вопрос открытый
websocket + WAMP (Web Application Messaging Protocol)
WAMP умеет и RPC, и Pub/Sub. Реализация есть на очень многих языках (С++ и другие)
Здравствуйте, Шульженко Андрей, Вы писали:
ША>Подскажите, на чем бы построить двусторонний обмен данными в клиент-серверном приложении для реализации следующей задачи: ША>1) клиент посылает синхронные запросы серверу с обязательным ответом
REST API ША>2) иногда клиенту от сервера приходят асинхронные управляющие сигналы (фактически, callback вызовы)
SignalR ША>3) клиент точно на linux (raspberry pi), серверная инфраструктура — пока вопрос открытый
ASP.NET Core — сервер. Клиент можно в браузере. Ну или зависит от планируемого десктопа на малине.
ША>Буду признателен за любую помощь ША>Андрей.
Здравствуйте, Шульженко Андрей, Вы писали:
ША>1) клиент посылает синхронные запросы серверу с обязательным ответом
Обычный HTTP запрос-ответ.
ША>2) иногда клиенту от сервера приходят асинхронные управляющие сигналы (фактически, callback вызовы)
По другому соединению клиент делает HTTP запрос, на который сервер отвечает в тот момент, когда хочет сделать этот самый callback. Должен быть таймаут, например 30 секунд. Через 30 секунд сервер отвечает специальным кодом. После получения callback-а клиент заново делает этот запрос. HTTP polling называется технология.
Это самая простая и совместимая реализация на мой взгляд.
Здравствуйте, Шульженко Андрей, Вы писали:
ША>Подскажите, на чем бы построить двусторонний обмен данными в клиент-серверном приложении для реализации следующей задачи:
Правильный ответ в 2020 году: любой готовый брокер сообщений. RabbitMQ, ZeroMQ, whateverMQ.
Re[2]: Двусторонний обмен данными между приложениями
Здравствуйте, Maniacal, Вы писали:
M>с++, потоки, сокеты, очереди, семафоры.
Я про то, что если и клиент и сервер в руках одного разработчика, то это же банальный велосипед, собирающийся из говна и палок стандартных библиотек за пару дней полностью отлаженный с нуля. Или я уже слишком старым системным стал, как программист-велосипедист?
Re[2]: Двусторонний обмен данными между приложениями
Здравствуйте, vsb, Вы писали:
vsb>Обычный HTTP запрос-ответ. vsb>По другому соединению клиент делает HTTP запрос, на который сервер отвечает в тот момент, когда хочет сделать этот самый callback. Должен быть таймаут, например 30 секунд. Через 30 секунд сервер отвечает специальным кодом. После получения callback-а клиент заново делает этот запрос. HTTP polling называется технология. vsb>Это самая простая и совместимая реализация на мой взгляд.
Спасибо, мне ближе всего была реализация веб сервиса, думаю что на нем легко будет сделать HTTP polling.
Re[2]: Двусторонний обмен данными между приложениями
Здравствуйте, Буравчик, Вы писали:
Б>Прошу пример любой библиотеки (любой язык) для работы с брокером MQTT или AMQP, в которой был бы реализован синхронный ответ на запрос.
Вот эта штука довльно удобно работает с эмуляцией синхронных RPC. Работает с кроликом.
Вот тут.
Здравствуйте, Буравчик, Вы писали:
Б>Это второй слой — библиотека, работающая поверх библиотеки, работающей с брокером. Я же имел ввиду библиотеку, непосредственно работающей с брокером.
Вряд ли найдется что-то кроме этого в случае с короликом.
</farsight>
Re[3]: Двусторонний обмен данными между приложениями
ША> Я рассматривал RabbitMQ и SQS, но мне показалось что одно не делает синхронно, другое не делает асинхронно.
В RabbitMQ есть довольно простой пример RPC вызова Remote procedure call (RPC)
Там используются 2 очедери — в первую отправляется сообщение и вместе с сообщением отправляется имя очереди через которую будет возвращаться response.
Из всего прочитанного мною в этой ветке я так и не понял зачем вам блокирующий вызов ?
Да, и не совсем понимаю если у вас сервер всего один (впрочем как и клиент) то смысла в RMQ я большого не вижу очереди созданы в т.ч. для удобной балансировки нагрузки между несколькими инстансами рабочих процессов.
Хочу так-же заметить что в случае разрыва TCP канала между Rabbit и сервером сообщение которое принял сервер но на которое не успел послать ACK будет еще раз выслано этому же серверу так что если нужна уникальность то
прийдется как-либо помечать все сообщения уникальными идентификаторами и где-то их на сервере сохранять и проверять что сообщение не дубликат.
Ну в итоге конечно решать вам что выбрать.
NetDigitally yours ....
Re[2]: Двусторонний обмен данными между приложениями
M>Правильный ответ в 2020 году: любой готовый брокер сообщений. RabbitMQ, ZeroMQ, whateverMQ.
Истинно так. Только не в 2020, а начиная где-то с 2010.
Если персистентность (сообщений) не нужна, то можно и без брокера, "руками", взять готовый Erlang/Elixir/... — и просто использовать (не зря ж тот же Кролик на Эрланге написан).
