Запросить образец ответа с mosca MQTT

Question

Есть ли способ реализовать шаблон запроса-ответа с mosca MQTT, чтобы "проверить ответ от клиента и повторно опубликовать sh, если я не получу ожидаемый ответ в течение ожидаемого времени".

Я считаю, что это возможно в Mqtt 5, но на данный момент мне приходится использовать брокер Mosca с QoS 1 (который поддерживает до Mqtt 3.1.1)

Я ищу Node js обходной путь для достижения этой цели.

Answer 1

Согласно моему комментарию, вы можете реализовать шаблон запрос-ответ с любым брокером MQTT, но до v5 вам нужно реализовать это самостоятельно (либо иметь один ответ на topi c и идентификатор сообщения, либо включить спецификация c topi c в каждом сообщении).

Поскольку MQTT 3.11 сам по себе не предоставляет эту функциональность напрямую и не существует стандартного формата для полезной нагрузки MQTT (всего несколько байтов!), Невозможно создать универсальную реализацию c (уникальный идентификатор какой-то вид необходим в запросе). Это решено в MQTT v5 благодаря возможности включать свойства , включая Response Topi c и Данные корреляции . Для более ранних версий вы застряли с добавлением некоторой дополнительной информации в полезную нагрузку (используя любой выбранный вами механизм кодирования).

Есть несколько вопросов о переполнении стека, которые могут дать некоторое представление:

• MQTT topi c имена для запроса / ответа
• RP C стиль запроса с MQTT

Другие статьи:

• Eclipse Kura
• Stock Explorer
• Разработка приложений IoT с использованием шаблона запроса-ответа с MQTT (Academi c статья - покупка необходима для прочтения целиком).
• Темы MQTT теневого устройства Amazon (например, отправьте сообщение на $aws/things/thingName/shadow/get и AWS IoT отвечает на /get/accepted или /get/rejected).

Вот несколько пакетов узлов (примечание: они не обновлялись в течение некоторого времени, и я не проверял код):

• ответчик
• resmetry

Даже с MQTT v5 вы потребуется реализовать бит ожидания простоя самостоятельно. Если вы используете QOS 1/2, то брокер позаботится о повторной отправке сообщения (до тех пор, пока не получит PUBACK / PUBCOMP), поэтому повторная отправка сообщения может быть контрпродуктивной (множество идентичных сообщений поставлено в очередь, пока связь comms не работает)

Answer 2

Сводка рабочего процесса, который я выполнил

• Добавление «Идентификатора корреляции» для каждого сообщения
• Ожидаемый ответ сохраняется в Redis как полезная нагрузка запроса (Запрос с корреляцией Идентификатор в качестве ключа) для сравнения ответа от клиента.
• Запись будет удалена из Redis, если ожидаемое сообщение эквивалентно ожидаемому ответу topi c и полезной нагрузке.
• Время ожидания использует задания cron узла для каждого ответа от клиента на сервер.