Имена тем MQTT для запроса / ответа

Question

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

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

Темой для запросов может быть: mysystem/slaveId/req, поэтому подчиненные могут подписаться на эту тему, а ведущее публикуется в той же теме.Только адресованный ведомый получит запрос, как и должно быть.

Мой вопрос заключается в том, как определить тему для ответов.Я сомневаюсь между: mysystem/slaveId/res/masterId или просто mysystem/slaveId/res.

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

Во втором случае ответ получат все активные мастера, поскольку в теме нет masterId.Ведущий, который отправляет запрос, должен определить его ответ, посмотрев requestId в полезной нагрузке (которая также была отправлена ​​в полезной нагрузке запроса).

Я думаю, что первый выбор лучше, однако Устройство Shadow сервиса AWS использует названия тем, аналогичные второму выбору.Например, устройство, которое отвечает на запрос get, публикует сообщение на $aws/things/myLightBulb/shadow/get/accepted.Таким образом, каждое устройство получит сообщение, а не только запрашиваемое.

Я думаю, что AWS делает хороший выбор, поэтому я испытываю желание следовать ему ... однако я не уверен, понял ли я, что они делают.

Answer 1

«Хороший выбор» зависит от контекста, и здесь контексты отличаются. Тень устройства предназначена для отслеживания и точного отражения состояния устройства. На странице, на которую вы ссылаетесь, не обсуждается наличие нескольких теней для одного устройства, и, возможно, она написана не с учетом нескольких получателей. Тем не менее, его простая тематическая архитектура будет работать в системе с несколькими тенями на устройство, потому что shadow должна получать все ответы от своего устройства. Любой из этих ответов может выявить изменение состояния устройства, и любая тень, клиент которой не получит ответ, будет устаревшей и не синхронизированной с другими тенями.

Ваши мастера не похожи на тени. Возможно, они независимо сообщают о своих результатах в хранилище данных, которое функционирует как тень. Возможно, ничто в ответах не представляет изменения состояния, стоящие за запросом. В любом случае, документация не соответствует вашей цели.

Я поддерживаю ваши предпочтения по первому выбору, особенно по мере роста количества узлов. Основным недостатком является дополнительная работа по отслеживанию запрашивающего главного идентификатора. Это легко для мастеров (каждый может подписаться на mySystem/+/res/masterId, а в системе с контролем доступа к темам их можно даже изолировать). Если тело запроса в противном случае простое (не для анализа уже нескольких атрибутов), вы можете рассмотреть возможность отправки мастерами сообщения на mysystem/slaveId/req/masterId (ведомый может подписаться на mysystem/slaveId/req/+).

Самым большим примером, который можно извлечь из AWS, может быть четкое чувство иерархии в темах. Если удобство парсинга при наличии masterId в конце темы не является вашей главной задачей, возможно, имеет смысл сделать заказ как: mysystem/masterId/slaveId/req (или res). Очень зависит от вашей системы и целей.