LINUX.ORG.RU

Система обмена сообщениями.

 


0

3

Есть ли какая-нибудь система обмена мообщениями, которая одновременно реализует паттерны «remote procedure call» и «publisher/subscriber». Из известных мне систем, таким функционалом обладает ros, но ros это монстр, которого в систему впихнуть не получится (Или, точнее, очень не хочется).

Смотрю в сторону mqtt, но mqtt сам по себе rpc не поддерживает, а городить его поверх попахивает велосипедом, хотя так, вроде бы, дейсттвительно делают...

В общем, никак не могу найти систему обмена сообщениями, подходящую под задачу, что мне очень странно.


попахивает велосипедом

Ну не нравится как пахнет свой велосипед, нюхай чужой.

а RPC на mqtt делается просто.

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

Да как угодно. RPC это фактически простой обмен мессаджами.

«Объявляешь» (а точнее решаешь внутри системы, что вот такого формата будут мессаджи для вызова) формат сообщения типа «call» или «function» или как угодно, хоть «pussy», шлешь такой мессадж, на другой стороне принимаешь, видишь, что это call, выполняешь указанный call с параметрами, возвращаешь ответ, либо кидаешь другой мессадж, в случае, если все асинхронное. А формат сам реши какой интересен. JSON, BSON или вон, протобуф, что аноним выше предложил. Пишется все за один вечер, даже на Си. Если брать какой-нибудь Js, или что там тебе нужно, то и того быстрее, там все уже готовое для этого есть.

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

Если mqtt позволяет общение через топики, то получается, что нодам надо договорится, какие топики они используют. Как это диспетчеризовать в случае, если у меня на один сервис по десять клиентов?

Mirmik
() автор топика
Ответ на: комментарий от anonymous

ZeroMQ -это хорошо. Это очень хорошо. А вот, касаемо protobuf... Какую пользу с него можно взять? Что с него можно получить. Я так понимаю, что это некая библиотека для сериализации?

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

Если mqtt позволяет общение через топики, то получается, что нодам надо договорится, какие топики они используют

Я невкурсе, чего тебе надо. Я знаю, что одна сторона может отправить мессадж, другая может на этот мессадж выполнить некую процедуру и вернуть первой результат. Это и есть RPC. Все остальное это уже архитектурные вопросы.

Какую пользу с него можно взять?

Позволит тебе описать мессаджи в .proto файлах и потом пользовать их везде, где этот протобуф поддерживается.

+: в результате сериализации мессаджи занимают небольшой объем, обратная совместимость, если добавлять поля или удалять (не затрагивая, однако, индекс) -: только по бинарному формату (без изначального .proto) ты не сможешь со 100% точностью сказать, что именно в блоке данных.

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

RPC

Как такового там RPC нет (ну я про 2 версию сейчас). То есть нет транспорта и нет мессаджей описывающих сами RPC вызовы. Есть просто интерфейс для сервисов и вызовов. Остальное - сам, в рукопашную :D Ну или сторонних лисапедов полно. Можно выбрать, какой лучше пахнет.

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

То есть нет транспорта и нет мессаджей описывающих сами RPC вызовы.

Это же плюс.

Есть просто интерфейс для сервисов и вызовов.

И protoc.

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

Я знаю, что одна сторона может отправить мессадж, другая может на этот мессадж выполнить некую процедуру и вернуть первой результат.

Это точно про MQTT? Один клиент может опубликовать сообщение, подписчик это сообщение может получить. Но вот вернуть результат обработки полученного сообщения подписчик может лишь опубликовав свое сообщение в каком-то топике.

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

Это же плюс.

Именно. За это он мне и нравится. Пока ничего лишнего не натолкали. Просто сериализатор с интерфейсами сервисов.

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

Это точно про MQTT?

Нет, это про RPC. Как оно будет реализовано дело второе. Хоть через топики, хоть голубиной почтой.

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

Если mqtt позволяет общение через топики, то получается, что нодам надо договорится, какие топики они используют. Как это диспетчеризовать в случае, если у меня на один сервис по десять клиентов?

Каждый клиент может создать свой собственный топик с уникальным именем. Например, формата /client/<ID>/<request_type>/resp. Где ID — это уникальный идентификатор клиента, а request_type — это тип запроса, на который клиент хочет получить ответ (потребуется только если клиент выдает разные типы запросов). Когда клиент кому-то шлет запрос (публикует сообщение-запрос в топик с заранее оговоренным именем), он в этом запросе сообщает имя темы, в которую хочет получить ответ.

Например, есть клиент 00012a, который хочет зарегистрировать свой заказ (тип запроса place_order). Он публикует сообщение вида:

{ "reply_topic" : "/client/00012a/place_order/resp", ...}
в тему /orders/new. Кто-то обрабатывает этот запрос и публикует ответное сообщение в теме /client/00012a/place_order/resp.

Сам же RPC придется делать вручную (т.е. после publish-а виснуть на ожидании ответного сообщения).

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

Полагаю, тут слишком много лишней информации придется туда сюда передавать. Применение таки реалтаймовое...

Пожалуй, действительно имеет смысл брать ZeroMQ, но несколько смущает применение ZeroMQ в контексте АСУТП...

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

Применение таки реалтаймовое...
но несколько смущает применение ZeroMQ в контексте АСУТП...

Ага, а у MQTT внезапно найдутся какие-то волшебные гарантии для реалтайма :)

Мне вот интересно, где таких специалистов к проектированию реалтаймовых АСУТП допускают?

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

Не зная ничего про вашу задачу — ничего не порекомендую.

Разве что нанять опытного человека, который уже знает что к чему.

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

Ну надо же учиться...

Задача состоит в управлении позиционером. Реализованно это в виде встраиваемого компьютера, управляющего сервоприводами.

Позиционер может иметь различное для разных систем количество осей, которые принимают команды типа - Инкрементальное перемещение оси такой-то на столько-то. - Установить скорость по оси такой-то столько-то.

Возможны команды относящиеся ко всей системе. - Считать количество осей системы.

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

Кроме того желательно передавать клиенту и другие сообщения.

Мы эти задачи в общем-то решили, но самопально. Сейчас стоит вопрос о переводе системы на более соответствующее стандартам програмное решение.

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

в режиме реального времени (с большой точностью и малой задержкой) пинать клиента, что ось вышла в заданную точку

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

capcha «HERR Schrödinger» кстати очень сильно намекает...

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

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

Миллисекунды в сети терпимы. У меня есть ттл тригер, который позволяет синхронно выполнить все, что требует совсем уж крутой синхронизации, и выполняется оно минуя все компьютеры. Сразу после этого по сети к клиенту идет информация о том, что оно сработало. Задержка критична, но 4-5 миллисекунд я могу позволить. В своё время пришлось ради этого забарковать винду и перейти на линух с реалтаймовым ядром.

Задания положен я импульсами используется, но контроль положения все равно приходится делать, так как то, что я задаю и то, что система реально выполняет отлиается на десятки микрон, что для системы недопустимо.

Короче говоря, эта штука работает, хотя над ней пришлось помучаться.

Mirmik
() автор топика
Ответ на: комментарий от chimera19

Если ТС пишет на С, можно взять protobuf-c. Который, к стати, имеет и свою реализацию RPC.

anonymous
()

gRPC недавно зарелизился, есть под плюсы. Но пабсаб придется писать вручную.

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

Это какая-то многокомпьютерная система? Если так, то максимум скорости что можно выжать из IP сети, это UDP датаграммы. И уже поверх них прикрутить все что хочется. А то, что хочется, имеющимися надстройками сделать маловероятно. Поэтому и точат все как могут.

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