В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
Вадим
АнастасияПротокол MQTT – Message Queuing Telemetry Transport – протокол для передачи последовательности сообщений с телеметрическими данными, то есть информации от датчиков температуры, влажности, освещенности и др.
MQTT был предложен в 1999 г. Энди Стандфордом-Кларком в качестве протокола, который бы служил для передачи данных о состоянии нефтепровода и газопровода в реальном времени. Разработка велась компанией IBM для нового трубопровода крупнейшей американской нефтяной компании ConocoPhillips. В рамках создания диспетчерской системы управления и сбора данных (SCADA) необходимо было обеспечить гарантированный сбор самой различной информации: состояние насосов, температура подшипников, скорость потоков, состояние клапанов, уровни в баках и т.д. При этом необходимо было учесть дороговизну каналов связи и узкую полосу пропускания. Ни один из существующих протоколов не подходил под эти задачи, таким образом, сформировались требования к новому протоколу: качество обслуживания, двусторонняя связь, эффективное использование полосы пропускания [2].
Впервые протокол MQTT был опубликован консорциумом OASIS (Organization for the Advancement of Structured Information Standards) в октябре 2014 г. Данный стандарт находится в открытом доступе [3].
В июне 2016 г. стандарт был признан Международной организацией по стандартизации (ISO). MQTT Version 3.1.1 был зарегистрирован техническим комитетом по информационным технологиям ISO (JTC1) под номером ISO/IEC 20922 [4].
Основные черты протокола MQTT:
Отличительной особенностью принципа "издатель-подписчик" от клиент-серверного подхода является то, что клиенты, посылающие сообщения (издатели, Publisher), и клиенты, принимающие сообщения (подписчики, Subscriber), как правило, разделены. Разделение может быть организовано в трех плоскостях:
Издатель и подписчик не передают друг другу сообщения напрямую, не устанавливают прямой контакт, могут не знать о существовании друг друга. Координирует и управляет передачей сообщений от издателя к подписчику и от подписчика к издателю брокер (Broker). Распараллеливание операций на брокере является второй важной особенностью принципа взаимодействия "издатель-подписчик".
MQTT-клиент – это устройство, оснащенное микроконтроллером, поддерживающим стек TCP/IP. Клиентские библиотеки MQTT доступны для большого числа языков программирования, например Android, Arduino, C, C++, C#, Go, iOS, Java, JavaScript, NET [5].
Брокер является основным элементом системы "издатель-подписчик". Он отвечает за прием всех сообщений, их фильтрацию, принятие решения о том, кому интересны эти сообщения, и, в конечном итоге, за пересылку сообщений всем клиентам-подписчикам.
Среди серверных реализаций брокера можно выделить IBM WebSphere MQ [6]; открытое ПО Mosquitto[7]; решение, основанное на облачном сервисе Eurotech Everywhere Device Cloud [8]; легко масштабируемый и высокопроизводительный открытый сервер emqttd, последняя версия (0,17) позволяет обслуживать 1,3 миллиона соединений [9]; брокер HiveMQ [10], обеспечивающий корпоративную безопасность и максимальную масштабируемость.
Упрощенный процесс обмена информацией можно описать следующим образом:
Таким образом, множество подписчиков может быть подписано на разнообразные темы и в зависимости от этих подписок получать необходимую им информацию, не общаясь с издателем напрямую. На рис. 1 изображена схема передачи информации по принципу "издатель-подписчик".
На рис. 2 представлен общий формат сообщений прокола MQTT. Сообщение состоит из двух заголовков:
В данной статье приведено подробное описание заголовка фиксированной длины, так как ключевые особенности протокола MQTT реализуются именно с помощью полей этого заголовка. Первый байт заголовка включает четыре поля, три из которых являются специальными флагами (DUP, QoS Level, RETAIN), четвертое указывает тип сообщения. Второй байт служит для указания оставшейся длины сообщения, которая складывается из размера заголовка переменной длины (если он есть) и размера полезной нагрузки.
Тип сообщения. Значение этого поля определяет тип сообщения. В табл. 1 приведены типы сообщений, их числовые значения, направления передачи и краткое описание.
Специальный флаг DUP. DUPlicate – дублирование сообщения. Этот флаг указывает получателю, что полученное им сообщение передается повторно и, возможно, уже было получено им ранее. Этот флаг играет важную роль при передаче информации по ненадежным каналам, где возможна потеря сигнала.
Специальный флаг QoS. Как отмечалось выше, основной отличительной чертой протокола MQTT является возможность использования различных уровней обслуживания, которые задаются значением данного флага. Это делает протокол MQTT более гибким, в отличие от протокола CoAP (Constrained Application Protocol), сообщения которого могут подтверждаться или обрабатываться без подтверждения.
QoS 0: At most once – не более одного. Издатель публикует сообщение (PUBLISH) на брокере, а брокер публикует его для подписчика. Однако издатель не требует, чтобы это сообщение было гарантированно передано подписчику. Иными словами, подписчик может и не получить это сообщение, но это не отслеживается издателем. Описанный сценарий (см. рис. 3) используется для тех случаев, когда потери данных не критичны. Например, при постоянном мониторинге температуры, когда потеря единичного измерения не играет существенной роли в общей картине.
QoS 1: At least once – хотя бы один. Издатель публикует сообщение на брокере (PUBLISH). Брокер сохраняет это сообщение и публикует его для подписчика. Только после того, как сообщение будет опубликовано для подписчика, брокер отсылает подтверждение публикации издателю (PUBACK). Сценарий такого взаимодействия приведен на рис. 4. То есть до тех пор, пока издатель не получит подтверждение публикации подписчику, данная публикация будет посылаться брокеру и далее подписчику. Таким образом, подписчик должен получить данное сообщение как минимум один раз.
QoS 2: Exactly one – гарантированно один. Уровень QoS обеспечивает высшую гарантию доставки сообщений за счет использования дополнительных процедур подтверждения и завершения публикации (PUBREC, PUBREL, PUBCOMP). Сценарий представлен на рис. 5 и применим для ситуаций, когда нужно исключить любые потери и дублирование данных от датчиков. Например, когда от полученного сообщения срабатывает сигнализация, вызов экстренных служб.
Специальный флаг RETAIN. Данный флаг служит для индикации сохранения последнего принятого брокером сообщения. То есть флаг RETAIN=1 в сообщении PUBLISH от издателя сообщает брокеру о том, что сообщение по этой теме нужно сохранить и, когда новый подписчик присоединится к теме, отправить ему это сообщение.
На рис. 6 приведен сценарий, описанный выше.
Рассмотрим более детально процесс установления соединения, посылки и приема сообщений (см. рис. 7).
Установление соединения начинается с передачи от клиента брокеру сообщения CONNECT, в котором указываются:
Брокер в ответ посылает клиенту сообщение CONACK, состоящее из:
После того, как клиент MQTT подключен к брокеру, он может публиковать сообщения. Публикация происходит путем отправки брокеру от клиента сообщения PUBLISH, где указываются:
Таким образом, после получения сообщения PUBLISH брокер отправляет подтверждение приема публикации (если это задано QoS) и пересылает полученное сообщение всем клиентам, которые подписаны на данную тему.
Чтобы получать сообщения с необходимыми данными, MQTT-клиент должен сначала подписаться на их получение с помощью сообщения SUBSCRIBE. Данное сообщение состоит из двух частей:
Стоит отметить, что в протоколе MQTT принята иерархическая структура построения тем, поэтому для удобства применяются т.н. wildcard-символы, благодаря которым подписчик может подписаться на все подтемы данной темы (символ #) либо темы определенного уровня (символ +).
В ответ на сообщение SUBSCRIBE брокер отправляет клиенту подтверждение SUBACK, в котором сообщает о результате подписки (успешная или нет).
Также клиент может отписаться от темы, которая больше не представляет для него интереса, отправив брокеру сообщение UNSUBSCRIBE, в котором будет указана данная тема.
Брокер подтверждает отказ от информации по этой теме сообщением UNSUBACK.
Проиллюстрируем работу протокола. В качестве примера рассмотрим спортивные приложения, устанавливаемые на смартфон. Практически все эти приложения, помимо сбора статистических данных, также позволяют динамически отслеживать местоположение спортсмена. Эта функция особенно востребована на массовых спортивных мероприятиях, таких как марафон, дистанции триатлона или велосипедные соревнования.
Для реализации такой функции необходимы как минимум три типа клиентов и один брокер, обслуживающий этих клиентов с использованием протокола MQTT.
Клиенты:
На рис. 8 изображена упрощенная схема обмена сообщениями протокола MQTT между участниками с указанием тем. На ней бегун (издатель) с установленным приложением навигации публикует на брокер информацию о своем текущем местоположении ("марафон/спортсмены/имя/GPS").
Аналитическое приложение, которое подписано на темы с местоположением конкретного бегуна и остальных участников с помощью рассмотренных выше wildcard-символов ("марафон/спортсмены/+/GPS"), использует эти данные для анализа времени, скорости, пройденного расстояния, а проанализированные данные публикует в соответствующие темы на брокере ("мара-фон/спортсмены/имя/дистанция_вре мя"). Болельщик может таким образом узнать точное местоположение бегуна и время прибытия в ту или иную точку с помощью приложения мониторинга, которое подписано на темы с местоположением, уже проанализированными данными ("марафон/спортсмены/#") и в виде графического интерфейса представляет эту информацию пользователю.
Минимальный объем служебной информации, наличие классов обслуживания и иерархическая структура тем являются неоспоримыми достоинствами протокола MQTT, что подтверждается большим разнообразием как клиентского, так и серверного ПО, в том числе открытого ПО. В то же время архитектура "издатель-подписчик" выдвигает требования к новому сетевому объекту – брокеру, который по сути своей обеспечивает маршрутизацию пользовательской информации. Таким образом, мы наблюдаем сдвиг парадигмы от маршрутизации на транспортном уровне к маршрутизации на прикладном.
Литература
Опубликовано: Журнал "Технологии и средства связи" #5, 2016
Посещений: 47787
Автор
| |||
Автор
| |||
В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
