Вопрос от начинающего разработчика, слабо знакомого с архитектурой распределенных приложений
Подскажите, на чем бы построить двусторонний обмен данными в клиент-серверном приложении для реализации следующей задачи:
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/... — и просто использовать (не зря ж тот же Кролик на Эрланге написан).
Re[5]: Двусторонний обмен данными между приложениями
Здравствуйте, Буравчик, Вы писали:
Б>Прошу пример любой библиотеки (любой язык) для работы с брокером MQTT или AMQP, в которой был бы реализован синхронный ответ на запрос.
В чем видится принципиальная невозможность этого сделать? Выше уже советовали две очереди. О возможности речи, кмк, нет.
Речь о нужности rpc через mq.
Здравствуйте, Шульженко Андрей, Вы писали:
ША>Вопрос от начинающего разработчика, слабо знакомого с архитектурой распределенных приложений ША>Подскажите, на чем бы построить двусторонний обмен данными в клиент-серверном приложении для реализации следующей задачи: ША>1) клиент посылает синхронные запросы серверу с обязательным ответом
Стоит отметить, что такое желание чаще всего результат подчёркнутого выше, а не реальная необходимость. Надо отказываться от идеи синхронных запросов и переходить на архитектуру с асинхронными сообщениями.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Двусторонний обмен данными между приложениями
Здравствуйте, Шульженко Андрей, Вы писали:
ША> Спасибо, мне ближе всего была реализация веб сервиса, думаю что на нем легко будет сделать HTTP polling.
Простая арифметика показывает, что при росте количества клиентов сервер очень быстро заткнется от количества входящих запросов, либо лантентность будет исчисляться минутами. Всякие WebSockets или хотя бы long polling не от хорошей жизни придуманы.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: Двусторонний обмен данными между приложениями
