для чего нужен протокол mqtt
Роль протокола MQTT в развитии промышленного интернета вещей
У нас часто проходят мероприятия, на которые мы приглашаем экспертов промышленной автоматизации. В 2016 году к нам приезжал Арлен Ниппер, который является одним создателей протокола MQTT. Хотим поделиться его докладом в русском переводе.
И такие же системы SCADA, системы автоматизации производства, системы контроля и управления производством становятся элементом IIoT-инфраструктуры.
Для чего нужна IIoT-инфраструктура? Пользователи стремятся получать все больше возможностей, тратя меньше ресурсов. Этого невозможно добиться без получения и использования производственных данных нижнего уровня.
Сначала везде внедрялись информационные технологии. Потом появилось «облака» и у всех появился доступ к Интернету. Теперь осталось только использовать «облако» для систем SCADA.
Поэтому мы занялись переписыванием старых протоколов с закрытым исходным кодом. Так на рынке появились Modbus, Allen-Bradley, DNP 3.0. А потом случилось дерегулирование деятельности телекоммуникационных компаний, в том числе AT&T. До этого системы управления производственными процессами, системы SCADA и т. д. работали на отличных условиях: AT&T получала большие субсидии и была готова тянуть свои телефонные линии куда бы мы ни пожелали. После дерегулирования цены взлетели, а качество рухнуло.
Мы стали использовать системы VSAT, но они работали медленно, с большой задержкой сигнала, а постоянный опрос устройств обходился очень дорого.
В результате совместного проекта Phillips 66 и IBM, в котором я принял участие 19 лет назад, появился сетевой протокол MQTT (MQ telemetry transport), который используется уже почти 20 лет. В далеком 1999 г. мы понятия не имели об Интернете вещей или «облаке», а просто искали пути решения проблемы. Но нам удалось создать протокол для критически важных систем контроля состояния трубопроводов в режиме реального времени. Сегодня протокол MQTT — один из самых используемых прикладных протоколов.
Собственно Интернет вещей задумывался как обычный Интернет людей, объединяющий пользователей через веб-браузеры, HTTP и т. д., но который должен был объединять «вещи». Потом мы создали Промышленный Интернет вещей для систем управления производством, не имеющий ничего общего с возможностью корректировать температуру термостата через телефон.
Чтобы заставить Промышленный Интернет вещей работать, необходимо:
1. «Отвязать» устройства от приложений и связать с инфраструктурой.
Допустим, я установил прекрасный компьютер Advantech UNO, разработал для него отличное приложение, к которому привязал компьютер через протокол. Это означает, что я жестко увязал возможности компьютера с возможностями приложения.
И даже если я нашел для какой-либо проблемы решение, завтра оно может не сработать. Например, чтобы воспользоваться намного большим объемом данных, мне придется менять код.
Именно поэтому устройства нужно привязывать не к приложению, а к инфраструктуре, а затем встраивать в нее приложения. В таком случае нас не будут ограничивать возможности приложений.
2. Создать более совершенное решение на уровне операционных технологий (ОТ), чем существующее.
Девятнадцать лет в IBM я разрабатывал эту технологию, но все попытки внедрения были неудачными, потому что мы пытались спускать IIoT-технологию от ИТ до производства.
Но IIoT-решение должно обеспечивать получение данных от «вещей» и оптимизацию на операционном уровне вне зависимости от того, для какого предприятия создается IIoT, — завода, фармацевтической компании, системы водоснабжения и водоотведения или нефтегазовых компаний. И сейчас в B & B я пытаюсь создать эффективное ОТ-решение, потому что Интернет вещей можно создать только снизу вверх.
Согласно исследованию 2016 года, MQTT — самый используемый протокол в Интернете вещей (HTTP занимает первое место, но не обеспечивает контроль в режиме реального времени, и мы его не учитываем).
На рынке предлагается множество серверов, поддерживающих протокол MQTT. 
MQTT Servers
При этом количество клиентских MQTT-технологий ограничено. 
MQTT Clients
Но в IIoT-решениях нужно применять технологии, известные вчерашним студентам инженерных и ИТ-специальностей. Так, выпускники по компьютерным специальностям, например, 2016 года, скорее всего, пользуются одноплатным Raspberry Pi, поддерживающим протокол MQTT, чтобы включать и выключать свет в комнате. При этом они могут не знать, что такое OPC UA, протоколы Modbus, Allen-Bradley или DMP 3.0. Открытость и доступность таких технологий приведет к появлению большого количества SRP-решений.
Точной инструкции по применению MQTT в критически важных системах управления производством в режиме реального времени не существует. Но мы разработали спецификацию Sparkplug MQTT, определяющую некоторые базовые правила для создания систем управления производством в режиме реального времени с использованием протокола MQTT:
Итак, мы должны «отвязать» устройства от приложений и предложить более совершенное ОТ-решение.
Мы стремимся обеспечить взаимодействие продуктов Advantech с «вещами» в IoT:
Наша MQTT-инфраструктура включает устройства, отслеживающие физические события и публикующие данные о таких событиях на защищенных брокерах сообщений. Линейка продуктов Advantech позволяет не только создавать Интернет вещей, но и использовать маршрутизаторы SmartFlex и eWorks, которые публикуют данные и предоставляют интерфейс для их мониторинга.
После того, как мы «отвязали» устройства от приложений, можно встроить в инфраструктуру устройства и модули доступа в Интернет и подписать их на данные, публикуемые в режиме реального времени через протокол MQTT. На этом этапе необходимо продемонстрировать пользователю, руководителю производства или менеджеру SCADA, что наше ОТ-решение лучше, быстрее, безопаснее и легче масштабируется, чем обычные системы SCADA.
Раньше несколько систем SCADA нельзя было подписать на один и тот же топик. Но если системы не привязаны к приложению, нам даже не придется определять, какая система SCADA должна получать информацию в первую или вторую очередь — все системы, программы и устройства могут иметь доступ к одним и тем же производственным данным в режиме реального времени.
И на этом этапе можно выбирать другие интересные решения и встраивать их в инфраструктуру, например, приложения для управления активами, оптимизации проектно-технических работ и т. д. 
Advantech Unique Energy/Environment Solution Topology
Налаженный поток данных позволяет приступить к созданию собственно Промышленного Интернета вещей, с которым мы уже знакомы, включая большие данные, облачные вычисления и т. д. Можно использовать Microsoft Azure, IBM Bluemix или AWS IoT, а также всем известные Hadoop и Big Data, Storm и Spark и различные инструменты визуализации и аналитики. Но оказаться на этом уровне невозможно, если устройства связаны с приложениями и не встроены в необходимую инфраструктуру.
MQTT: протокол передачи данных в интернете вещей
Существует много протоколов обмена информацией — от распространенного HTTP до редко встречающегося PeSIT. Несмотря на это, для интернета вещей разработали отдельный протокол — MQTT. Разберемся, где и как его применяют.
Схема работы и особенности протокола MQTT
MQTT — специализированный протокол публикации небольших наборов данных в интернете вещей. Основная сфера его применения — доставка небольших сообщений, например показателей сенсоров.
Сообщения в MQTT передают между тремя участниками — издателями, брокером и подписчиками:
Описание MQTT-протокола: издатели и подписчики (их еще называют MQTT-клиентами) не знают о существовании друг друга, они общаются только с MQTT-брокером
IoT-устройства (датчики) могут быть и издателями, и подписчиками. Подписка им нужна для получения команд телеуправления, обновления конфигурации устройств, версий прошивок. В этом случае сообщение через брокер отправляет системное ПО, а принимает IoT-устройство.
У MQTT-протокола несколько особенностей, посмотрим на основные:
MQTT для IoT хорошо подходит, так как адаптирован к особенностям устройств и каналов связи. Этот протокол минимально нагружает вычислительные мощности умных устройств и правильно доставляет сообщения в центральный узел в условиях нестабильного соединения.
Особенности доставки сообщений
У данных разная ценность и приоритет доставки, поэтому в MQTT предусмотрены флаги Quality of Service — QoS:
Чем хуже качество связи, тем сложнее обрабатывать QoS. Поэтому QoS 0 используют, когда данных много, они передаются регулярно и потеря одного или нескольких сообщений ни на что не влияет.
Например, сенсор передает данные о температуре оборудования раз в секунду, но для анализа используют только среднесуточные показатели — тогда потеря нескольких сообщений несущественна. Но при передаче финансовых данных потери недопустимы, иначе на счете клиента не сойдется баланс.
Применение протокола MQTT: мониторинг оборудования, сред и отправка важных данных
Посмотрим, где чаще всего применяют протокол MQTT:
На крупных предприятиях умные датчики устанавливают на станках, трансформаторах, кранах и погрузчиках. Они мониторят работу промышленных устройств и передают данные в центральную аналитическую систему.
Благодаря этому компании могут отслеживать работу оборудования в реальном времени, прогнозировать его износ и оценивать эффективность работы предприятия.
MQTT используют для анализа климатических показателей, сейсмической активности и устойчивости зданий. Это позволяет предсказывать природные катастрофы и катаклизмы, предотвращать разрушение построек.
Хотя протокол MQTT изначально создавали для интернета вещей, его используют в биллингах мобильных операторов и провайдеров. Им важно передавать информацию о движении денег на счетах клиентов, не теряя ее.
Как общаются машины — протокол MQTT
Протокол MQTT достаточно молод (стандартизирован только в 2016 году), но уже успел получить широкое распространение в промышленности и IoT. Он был специально разработан максимально компактным, для нестабильных интернет-каналов и маломощных устройств, и позволяет гарантированно доставлять сообщения в случае потери пакетов и обрывов связи.
Главные особенности протокола MQTT:
История протокола MQTT
MQTT был разработан компанией IBM в 1999 году, и поначалу использовался внутри компании, для своих решений.
В ноябре 2011 IBM совместно с компанией Eurotech объявили об участии в рабочей группе Eclipse M2M и передаче кода MQTT в проект Eclipse Paho.
В 2013 году консорциум OASIS (Organization for the Advancement of Structured Information Standards) начинает процесс стандартизации протокола MQTT. До этого момента спецификация протокола была опубликована под бесплатной лицензией, и такие компании, как Eurotech (ранее известный как Arcom), уже используют протокол в своих продуктах.
В октябре 2014 г. OASIS публикует первый официальный стандарт протокола MQTT.
В 2016 г. протокол был стандартизирован Международной организацией по стандартизации ISO и получил номер ISO/IEC 20922.
С 2014 года интерес к протоколу начинает стремительно расти и, судя по графику Google Trends, на сегодняшний день превышает интерес к Modbus.
Сравнительный график Google Trends
Основные понятия
MQTT имеет клиент-серверную архитектуру. Обмен сообщениями происходит через центральный сервер, называемый брокером. В обычных условиях клиенты не могут общаться напрямую друг с другом, и весь обмен данными происходит через брокера.
Клиенты могут выступать в роли поставщиков данных (Publisher) и в роли получателей данных (Subscriber). В русском переводе эти термины часто переводят как издатель и подписчик, но, чтобы избежать путаницы, мы будем использовать только оригинальную терминологию.
В протоколе MQTT клиенты обмениваются данными друг с другом, через центральный узел
На прикладном уровне протокол работает поверх TCP/IP и может легко связывать удаленные объекты напрямую по интернету, без необходимости использования VPN-тоннелей. Достаточно, чтобы брокер имел реальный IP-адрес и все клиенты могли к нему подключиться. При этом, клиенты могут находится за NAT. Так как в протоколе MQTT подключение инициируют клиенты, пробрасывать порты для установки соединения не требуется, в то время как в Modbus/TCP подключение инициирует сервер (master), что требует прямой сетевой доступности.
Стандартный порт MQTT-брокера для входящих TCP-соединений — 1883. При использовании защищенного SSL-подключения используется порт 8883.
Broker
Брокер — это центральный узел MQTT, обеспечивающий взаимодействие клиентов. Обмен данными между клиентами происходит только через брокера. В качестве брокера может выступать серверное ПО или контроллер. В его задачи входит получение данных от клиентов, обработка и сохранение данных, доставка данных клиентам, и контроль за доставкой сообщений.
Publisher/Subscriber
Для понимания разницы между Publisher и Subscriber разберем простой пример: датчик влажности измеряет влажность в помещении, и если она опустилась ниже определенного уровня, включается увлажнитель воздуха.
В данном случае датчик влажности выступает в роли Publisher: его задача сводится только к публикации данных в сторону брокера. Увлажнитель воздуха выступает в роли Subscriber: он подписывается на обновления данных о влажности и получает от брокера актуальные данные, при этом увлажнитель может сам решать, в какой момент включать увлажнение.
В этой схеме MQTT-клиенты, то есть датчик и увлажнитель, не знают о существовании друг друга, и не взаимодействуют напрямую. Брокер может получать данные из разных источников, проводить над ними манипуляции, например, рассчитывать среднее значение от нескольких датчиков, и уже обработанные данные возвращать подписчику.
Publisher посылает данные брокеру, Subscriber подписывается на обновления этих данных
При этом, асинхронность протокола MQTT предусматривает, что датчик и увлажнитель могут быть онлайн в разное время, терять пакеты, и быть недоступны. Брокер позаботится о том, чтобы сохранить в памяти последние данные, полученные от датчика, и обеспечить их доставку на увлажнитель.
Topic
Для идентификации сущностей в MQTT используются топики, в русском переводе их еще называют каналами. Топики состоят из UTF8-символов, и имеют древовидную структуру, похожую на файловую систему в UNIX. Это удобный механизм, позволяющий называть сущности в человекопонятном виде.
Пример топиков в MQTT
Такой подход позволяет наглядно видеть, какие данные передаются, и удобно разрабатывать и отлаживать код, без необходимости запоминать цифровой адрес размещения данных, как это сделано в Modbus.
Топики также предусматривают wildcard-синтаксис, хорошо знакомый тем, кто работал с файловой системой UNIX. Wildcard может быть одноуровневым и многоуровневым.
Одноуровневый wildcard обозначается символом «+«.
Например, чтобы получить данные с температурных датчиков во всех помещениях в доме, подписчику нужно подписаться на такой топик:
В результате он подпишется на получение данных с таких датчиков:
Многоуровневый wildcard обозначается символом «#«.
Пример получения данных со всех датчиков во всех комнатах в доме:
Подписка на такой топик позволит получать данные с таких датчиков:
Идентификация клиентов
Для контроля доступа в MQTT предусмотрена аутентификация клиентов, в отличие от протокола Modbus, который не имеет такой функции. Для контроля доступа используются такие поля:
ClientId — (обязательное поле) уникальный идентификатор клиента. Должен быть уникальным для каждого клиента. Текущая версия стандарта MQTT 3.1.1 позволяет использовать пустое поле ClientId, если не требуется сохранение состояния подключения.
Username — (опциональное поле) логин для аутентификации, в формате UTF-8. Может быть не уникальным. Например, группа клиентов может авторизовываться с одним и тем же логином/паролем.
Password — (опциональное поле) может посылаться только вместе с полем Username, при этом Username может передаваться без поля Password. Максимум 65535 байт. Важно знать, что имя и пароль передаются в открытом виде, поэтому, если данные передаются по публичным сетям, необходимо использовать SSL для шифрования подключения.
Структура пакета
Как уже говорилось выше, в протоколе MQTT подключение всегда инициируют клиенты, вне зависимости от того, являются ли они получателями (Subscriber) или поставщиками (Publisher) данных. Разберем пакет с установкой соединения, перехваченный с помощью программы Wireshark.
Пакет с опцией MQTT, переданный по нешифрованному каналу
В TCP заголовке видно, что пакет передан по порту 1883, то есть шифрование не используется, а значит в открытом виде доступны все данные, в том числе логин и пароль.
Заголовок
Тип сообщения — Connect (команда 0x0001), установка соединения с брокером. Основные команды: Connect, Disconnect, Publish, Subscribe, Unsubscribe. Есть также команды подтверждения получения, keep alive, и т.д.
Флаг DUP — означает, что сообщение передается повторно, используется только в типах сообщений PUBLISH, SUBSCRIBE, UNSUBSCRIBE, PUBREL, для случаев, когда брокер не получил подтверждения получения предыдущего сообщения.
Уровень QoS — флаг Quality of Service. Мы разберем эту тему подробнее дальше.
Retain — данные, опубликованные с флагом retain, сохраняются на брокере. При последующей подписке на этот топик, брокер сразу отправит сообщение с этим флагом. Используется только в сообщениях с типом Publish.
Использование на практике
Теперь, ознакомившись с теорией, попробуем поработать с MQTT на практике. Для этого будем использовать открытую программу Mosquitto, которая может работать как в режиме клиента, так и в режиме сервера (брокера). Работает на Windows, macOS, Linux. Программа очень удобна для отладки и изучения протокола MQTT, при этом также широко используется в промышленной эксплуатации. Мы будем использовать ее как клиент для отправки и получения данных с удаленного облачного брокера.
Множество облачных провайдеров предоставляют услуги MQTT-брокера, например Microsoft Azure IoT Hub, Amazon AWS IoT, и другие. В этом примере мы будем использовать сервис Cloudmqtt.com, так как у него самая простая регистрация, и бесплатного тарифа достаточно для обучения.
После регистрации, в личном кабинете доступны реквизиты для подключения к брокеру. Так как мы подключаемся к серверу через публичные сети интернета, разумно использовать SSL-порт, для шифрования трафика.
Реквизиты доступа к MQTT-брокеру в личном кабинете облачного провайдера
Гибкость протокола MQTT позволяет клиенту передавать данные, заранее не определенные на брокере. То есть нет необходимости предварительно создавать нужные топики, в которые сможет записать данные Publisher. Используя данные, полученные из личного кабинета, попробуем вручную составить запрос для публикации данных в топик habr/test/random и чтения из него.
mosquitto_sub — утилита-клиент subscriber
mosquitto_pub — утилита-клиент publisher
Для начала подключимся к брокеру как subscriber, и подпишемся на получение данных из топика
habr/test/random.
Видно, что подключение прошло успешно, и мы подписались на топик habr/test/random, и сейчас ожидаем данных в данном топике от брокера.
Так как используется SSL-подключение, для проверки сертификата необходимо указать путь, по которому программа будет искать корневые сертификаты шифрования. Так как у сервиса в нашем примере используется сертификат, выданный доверенным удостоверяющим центром, то мы указываем путь к системному хранилищу корневых сертификатов: —capath /etc/ssl/certs/
Теперь попробуем опубликовать данные в топик, не прерывая первую программу.
Видно, что данные были успешно приняты сервером и опубликованы в нужный топик. Одновременно с этим, в первом окне, в котором запущена программа mosquitto_sub, мы видим, как сообщение было получено, при этом даже юникод работает, видно сообщение на руском языке.
QoS и гарантия доставки
Однако пересылкой сообщения в реальном времени мало кого удивишь, ведь то же самое можно сделать даже банальной утилитой nc. Поэтому попробуем имитировать нестабильное соединение между подписчиком и отправителем. Представим, что оба клиента работают через GPRS, с огромной потерей пакетов, и даже успешная установка TCP-соединения происходит редко, при этом нужно, чтобы подписчик гарантированно получил сообщение отправителя. В данном случае на помощь приходят опции QoS.
По умолчанию для сообщений установлен флаг QoS в значение 0, что значит «Fire and forget»: Publisher публикует сообщение на брокере, но при этом не требует, чтобы сообщение было гарантированно доставлено подписчику. Это подходит для данных, потеря которых не критична, например, для регулярных измерений влажности или температуры.
QoS 1: At least once – хотя бы один. Этот флаг означает, что пока Publisher не получит подтверждения доставки подписчику, данная публикация будет посылаться брокеру, и далее подписчику. Таким образом, подписчик должен получить данное сообщение как минимум один раз.
QoS 2: Exactly once – гарантированно один. Флаг QoS, обеспечивающий высшую гарантию доставки сообщений за счет использования дополнительных процедур подтверждения и завершения публикации (PUBREC, PUBREL, PUBCOMP). Применим для ситуаций, когда нужно исключить любые потери и дублирование данных от датчиков. Например, когда от полученного сообщения срабатывает сигнализация, вызов экстренных служб.
Для симуляции плохой связи отключим оба клиента и попробуем отправить сообщение с наивысшим приоритетом QoS, а также добавим опцию Retain, чтобы отправленное сообщение сохранилось на брокере.
Теперь, спустя время, наш получатель наконец смог установить соединение с интернетом и подключился к брокеру:
В последнее время мне пришлось долго и муторно разбираться с протоколом MQTT (Mosquitto) и с тем, как его можно использовать с домашней автоматизацией. Поэтому пришлось разбираться с тем, как оно работает и зачем нужны все эти настройки.
Немного теории
Основные термины и понятия используемые в данном протоколе:
Разберем каждый термин по отдельности
Message
Сообщения (message) содержат в себе информацию, которую один участник сети на базе протокола MQTT хочет передать другим. Взаимодействие между участниками сети осуществляется через Брокера. То есть, если мне, как устройству, нужно передать сообщение о том что я что-то сделал или сообщить о том, как у меня дела, я передаю сообщение брокеру публикуя во всеуслышание что «я что-то сделал» или «как у меня дела».
Publish
Это процесс передачи сообщения брокеру.
То есть простым языком, я подошел к брокеру и сказал «мама я покакал». Брокер гипотетически должен услышать это сообщение и записать его к себе в блокнотик. Почему гипотетически? Потому что есть особенности протокола, которые мы разберем чуть ниже. Пока берем за данность, что я сказал что-то брокеру используя механизм Publish и он это услышал и записал.
Subscribe
Так как всеми сообщениями от всех устройств владеет исключительно брокер, то нам жеж нужно как то получить эти сообщения. Для этого мы подписываемся на рассылку от брокера для получения проходящих через него сообщений. Чтобы читать какие-то конкретные сообщения, нам необходимо определить на какую тему мы хотим получать эти сообщения, и для этого как раз используется механизм Topic
Topic
Это как раз таки Тема, по поводу которой мы хотим получать или как ни странно отправлять сообщения.
То есть формат общения между участниками выглядит примерно так.
Я как участник хочу сказать всем «мама я покакала»
для этого я создаю топик любого содержания, например: мое_тело/задница/
и сообщаю в этот топик сообщение «мама я покакала»
Брокер получит это сообщение, и передаст всем, кто подписался на тему (топик) мое_тело/задница/
То есть это такая вот упрощенная система смс рассылок с определенными темами.
Формат топика может быть разным и абсолютно любым. В принципе мы можем создать любой топик, и в него передавать сообщения любого содержания. Главное чтобы получатель был подписан на этот топик и знал что делать с информацией полученной из сообщений.
Что касается особенностей топиков, то их не так чтобы много.
Во первых они чувствительны к регистру. То есть топик «мое_тело/задница» и топик «Мое_Тело/Задница» это два разных топика.
Во вторых, топики не создаются не сервере администратором. Они создаются публикаторами и подписчиками которые на них подписаны. Брокер только занимается передачей сообщений и служебной информации.
Они позволяют выстраивать иерархию. Ну например:
У нас есть в гостиной и в спальне по два выключателя и один в гараже. Для этого мы формируем на выключателях в топики в виде:
Затем, что есть служебные топики, которые позволяют подписаться на группы топиков или сообщений.
Например если мы хотим читать вообще все сообщения мы подписываемся на топик #
Если мы хотим видеть то, что происходит в доме, то мы подписываемся на топик home/# и будем получать сообщения в топиках:
Но не будем видеть то что происходит в топике:
Если мы хотим видеть то, что происходит в гостиной, мы подписываемся на топик home/livingroom/# и будем получать сообщения только из топиков
В общем я думаю понятно что и как происходит с этими топиками.
Служебные сообщения
В качестве служебных сообщений используются в основном два типа сообщений
Last Will and Testament (LWT) которое сообщает что после этого сообщения считать меня мертвым.
Ну плюс еще используется Keep Alive сообщения, которые сообщают брокеру что «я все еще живой» и стандартно посылаются каждые 60 секунд. Если брокер не получил это сообщение от клиента, то он принудительно пингует его чтобы выяснить живой ли тот, и если выясняется что он неживой, то брокер публикует за клиента LWT сообщение, чтобы все узнали что тот скончался.
Соответственно получение брокером Birth Message от устройства, переводит устройство в понимании брокера в режим ONLINE, а после того как брокер получает от устройства LWT сообщение или когда сам принимает решения что тот скончался проверив устройство на доступность, то переводит статус устройства в режим OFFLINE.
QoS в принципе расшифровывается как Quality Of Service, то есть качество предоставляемой услуги. В разрезе MQTT оно имеет три значения 0,1 и 2
Если по простому, то эти варианты означают по факту определение того, надо ли нам как публикующему свое сообщение устройству, быть уверенным что оно получено.
QoS=0 означает что мы один раз публикуем сообщение «мама я покакала» и нам пофиг услышали нас или нет
QoS=1 означает что мы будем публиковать сообщение «мама я покакала» до посинения, до тех пор пока нам не скажут что нас услышали и можно заткнуться уже.
QoS=2 означает что мы один раз сказали «мама я покакала», получили от мамы подтверждение того что она нас услышала, сообщили маме что мы узнали о том что мама нас улышала, а мама подтвердила, что она поняла что мы узнали о том что она услышала :))))))
Я думаю первая буква М в протоколе, имеет отсылку в адрес Майкрософта, который по стопицот раз переспрашивает «действительно ли вы уверены что хотите закрыть это приложения?» :)))))))
Вот в общем то и все.
Retain
Этот параметр имеет всего два значения вкл и выкл. Означает он очень простой механизм.
Если у нас режим выключен, то когда я сообщаю всему миру «мама я покакала», то его слышат все кто подписан сейчас на топик в который я это сообщил. Но вновь подключившийся подписчик на наш веселый топик «мое_тело/задница» не узнает о том что все уже случилось и так и умрет в неведении наверное.
Если же мы включаем режим Retain, то брокер берет на себя обязательство, после того как мы сообщили миру об акте дефекации, сообщать каждому вновь подписавшемуся на этот топик сей удивительный и жизненно необходимый факт.