Немного теории (MQTT)

Чем дальше в лес , тем тяжелее с него выбраться...
Изучая протокол MQTT, а также консоль IBM Bluemix (с их Watson IoT Platform) наткнулся на ещё один очень интересный сервис NODE-RED. Поэтому с целью "ничего не забыть и не упустить в дальнейшем" небольшой теоретический отступ.

http://www.sast.in.ua/2016/05/mqtt.html
Протокол MQTT, важные моменты (материалы позаимствованы с блога Андрея Зубинского):
Основа стандарта протокола MQTT – описание форматов пакетов и обмена ими, на которые отображены все механизмы MQTT.

Ключевые элементы коммуникационной системы, описываемой протоколом MQTT – клиент (client) и сервер (server, в ранних редакциях стандарта MQTT – broker).
Каждый клиент MQTT обязан иметь уникальный идентификатор ClientId, представленный UTF-8 строкой с числом символов от 1 до 23. В строке ClientId допускается использование только символов [a-z, A-Z, 0-9].
  «Издатель» (Pub, Publisher) «публикует» данные и метаинформацию (формирует описанные метаинформацией «каналы»), «подписчик» (Sub, Subscriber) «подписывается» на «каналы», определённые метаинформацией. Если для подписки на метаинформацию данные от «издателя» есть, «подписчик» их получает. Если таких данных нет – ничего не происходит вообще, никто не запрещает «подписываться» на несуществующие «каналы», никаких ограничений нет.
Иерархия формируется соединением топиков с помощью символа «/», например строка: room1/north_wall/temperature
Wildcards - позволяют задавать одним символом множество каналов сразу. При «публикации» данных в метаинформации они недопустимы (метаинформация о публикуемых данных должна быть точно определена, чтобы до данных можно было «добраться»)
В метаинформации о подписке возможны всего два символа wildcards – «#» и «+». Первый обозначает «всю под-иерархию топиков», второй «весь только один уровень иерархии».  К примеру в MQTT-системе опубликованы следующие пять иерархий топиков:
L0
L0/L1
L0/L1/L2
L0/L1/L2/L3.1
L0/L1/L2/L3.2
L0/L1/L2/L3/L4
Использование «#», например, L0/L1/L2/# , формирует сразу четыре канала транспорта данных:
L0/L1/L2
L0/L1/L2/L3.1
L0/L1/L2/L3.2
L0/L1/L2/L3/L4
В свою очередь, L0/L1/L2/+ задаёт только три канала:
L0/L1/L2/L3.1
L0/L1/L2/L3.2
L0/L1/L2/L3
Описание подписки на множественные каналы может содержать любые правильно описанные комбинации wildcards, использование повторяющихся неразделённых «/» символов wildcards стандартом запрещено.
Топик, состоящий из одного wildcard символа «#» не просто разрешён стандартом и логично описывается фразой «подписываюсь на всё», он используется в том числе для связи серверов MQTT между собой.
Класс топиков, начинающихся с символа «$». Это топики системной информации и управления сервером MQTT, стандарт строго ограничивает их применения – сервер должен препятствовать использованию таких топиков клиентами для обмена информацией.


Каждый пакет содержит три флага (команды):
- флаг признака повторной отправки (DUP),
- двухбитовый флаг «качества обслуживания» механизмов доставки (QoS, Quality of Service)
- флаг признака «актуальной до обновления публикации» (RET, Retain).

QoS, «качество обслуживания» MQTT, определяет степень доверия к работе механизма транспорта.
Основной уровень степени доверия – QoS 0, «at most onсe delivery», лучше всего объяснить военным термином «выстрелил и забыл». Клиент или сервер «выстреливает» Pub-команду (пакет) и забывает об этом, никаких дополнительных проверок, ничего вообще. Основным уровнем его можно считать потому, что протокол требует канала с гарантированной доставкой данных с сохранением порядка и проч.
Уровень степени доверия «с подтверждением», QoS 1, «at least once delivery» требует подтверждения получения передачей специального пакета каждого получения Pub-команды (пакета).
И, наконец, самый высокий уровень степени доверия – QoS 2, «exactly once delivery», с двойным подтверждением от обеих сторон симметричного pub-канала (ещё раз напоминаю, что и клиент, и сервер, передают/принимают Publish-пакеты).
Кажущаяся избыточность уровней качества обслуживания связана с тем, что в MQTT каждый Pub-пакет имеет собственный идентификатор (назначаемый отправляющей стороной) и за ним скрыт временный ресурс клиента или сервера – собственно данные. Пакет с определённым идентификатором может быть как подтверждённо доставлен, так и подтверждённо могут быть освобождены данные, передаваемые этим пакетом и представляющие собой ресурс, в терминах MQTT это две разные операции.


Флаг DUP, обозначающий повторную отправку пакета, интуитивно понятен, как и понятно, что при QoS 0, «выстрелил и забыл», никаких повторных отправок быть не может.

Флаг RET, актуальной до обновления публикации, как раз относится к публикуемым данным, как к ресурсу. Если этот флаг установлен в 1, сервер MQTT будет «удерживать» полученные данные и публиковать их любым новым клиентам, подписавшимся на топик этих данных. Для «неудерживаемых» (RET=0) данных новые подписчики не получат ничего вообще до очередной публикации



MQTT – сервер (server, broker). Одним из наиболее используемых серверов является Mosquitto. Данный сервер присутствует в репозитории rasbian, поэтому с его установкой проблем не возникло, стоит  только отметить, что после установки сервер запускается автоматически.
Документация по работе с Mosquitto:

on
Мітки: ,

Немає коментарів:

Дописати коментар

Підписатися на: Дописати коментарі (Atom)