Запрос ответа — новые возможности MQTT 5.0

MQTT v5 содержит множество новых функций, и мы постараемся представить эти функции в простой для понимания форме и обсудить влияние этих функций на разработчиков. До сих пор мы обсуждали эти новые возможности MQTT v5. Сегодня мы продолжим обсуждение: Ответ на запрос.

Ответ на запрос

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

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

Однако это не очень хорошая реализация. Мы рассчитываем, что получатель запроса должен обращать внимание только на то, как обрабатывать запросы, не тратя лишних усилий на то, чтобы правильно вернуть ответ запрашивающему. Поэтому MQTT 5.0 добавляет новый атрибут Тема ответаи определите следующий процесс взаимодействия запрос-ответ:

1. MQTT-клиент (заявитель) опубликовать сообщение запроса, включая Тема ответа к теме запроса.
2. Если есть другие MQTT-клиенты (ответчики), подписавшиеся на фильтр темы, который соответствует имени темы, используемому при запросе публикации сообщений, то сообщение запроса будет получено.
3. Ответчик предпринимает соответствующие действия в соответствии с сообщением запроса, а затем публикует ответные сообщения в теме, указанной этим атрибутом. Тема ответа.

Корреляционные данные

В отличие от модели HTTP-запрос-ответ, MQTT запрос-ответ является асинхронным, что создает проблему, заключающуюся в том, как связать ответное сообщение с сообщением запроса. Наиболее часто используемый метод заключается в переносе одного характеристического поля в сообщение запроса. Ответчик будет без изменений возвращать полученные поля, когда он получит ответное сообщение. Очевидно, MQTT тоже это учитывает, поэтому добавляем новый атрибут Корреляционные данные для пакета PUBLISH.

Ответное сообщение

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

Чтобы решить эту проблему, MQTT 5.0 определяет новый атрибут, называемый ответным сообщением, в пакете CONNACK. Сервер может использовать этот атрибут, чтобы указать клиенту, как выбрать тему ответа для использования. Этот механизм является необязательным для сервера и клиента. При подключении клиент будет запрашивать у сервера отправку ответных сообщений, устанавливая информационный атрибут запроса-ответа в пакете CONNECT. Это заставит сервер вставить атрибут информации об ответе в пакет CONNACK, и запрашивающая сторона сможет использовать информацию об ответе для создания темы ответа.

Рекомендации по использованию

• Из-за некоторых ограничений модели публикации-подписки использование только QoS больше 0 может гарантировать, что сообщение достигнет противоположного конца, а не подписчика. Если подписка не завершена при публикации сообщений, сообщение будет потеряно, но издатель об этом не знает. Поэтому для некоторых сообщений с более строгими требованиями к доставке вы можете подтвердить, дошло ли сообщение до подписчика, запросив ответ.

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

• Если вы использовали Корреляционные данные атрибут правильно, вы можете использовать общие подписки для респондентов с уверенностью.

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

Первоначально опубликовано на https://www.emqx.com.