MQTT
| Модель TCP/IP (RFC 1122) |
|---|
| Прикладний рівень |
| Транспортний рівень |
| Мережевий рівень |
| Канальний рівень |

MQTT (англ. Message Queue Telemetry Transport) — спрощений мережевий протокол, що працює на TCP/IP. Використовується для обміну повідомленнями між пристроями за принципом видавець-підписник.
Приклад використання: на комп'ютері запускається програма-брокер, яка починає слухати порт 1883 для незашифрованих з'єднань або порт 8883 для зашифрованих. Основне завдання брокера — організовувати списки підписників на топіки. Наприклад, хтось надсилає брокеру побажання підписатися на топік temperature1/roof. Брокер запам'ятовує, що такий-то IP та порт підписався. Якщо від когось надійде повідомлення з топіком temperature1/roof, то брокер передасть це повідомлення всім, хто був підписаний на топік.
Перша версія протоколу була розроблена доктором Енді Станфорд-Кларком (IBM) та Арлен Ніппер (Arcom) 1999 року і опублікована під роялті-фрі ліцензією. Специфікація MQTT 3.1.1 була стандартизована консорціумом OASIS 2014 року.[1]
Подальшим розвитком MQTT стала розробка версії цього протоколу для сенсорних мереж MQTT-SN[2] на основі UDP або Bluetooth.

- Простий у використанні. Протокол є програмним блоком без зайвої функціональності, що може бути легко вбудований в будь-яку складну систему;
- Зручний для більшості рішень з датчиками. Дає можливість пристроям виходити на зв'язок і публікувати повідомлення, які не були заздалегідь відомі або визначені;
- Легкий у адмініструванні;
- Низьке навантаження на канал зв'язку;
- Робота в умовах постійної втрати зв'язку або інших проблем на лінії;
- Немає обмежень на формат переданого контенту.
MQTT визначає методи (так звані «дієслова»), щоб вказати бажану дію, яка повинна виконуватися на ідентифікованому ресурсі. Чим є цей ресурс, будь то вже наявні дані або дані, що генеруються динамічно, залежить від реалізації сервера. Часто ресурс відповідає файлу або результату виконання якогось файлу, розміщеного на сервері.
Connect. З'єднати: Чекає встановлення з'єднання з сервером.
Disconnect. Роз'єднати: Чекає доки клієнт MQTT закінчить будь-яку роботу, що має зробити, і доки роз'єднається TCP/IP сесія.
Subscribe. Підписатися: Чекає на завершення методу Subscribe чи UnSubscribe.
UnSubscribe. Відписатися: просить сервер відписати клієнта від одної або кількох тем.
Publish. Публікувати: одразу повертається в потік виконання додатку (англ. application thread) після того, як передасть запит клієнту MQTT.
При відправленні повідомлення можна обирати три рівні якості доставки[4]:
- 0 — повідомлення доставляється без підтвердження. Надійність доставки контролюється на рівні TCP/IP, але можуть бути інші проблеми, окрім каналу зв'язку. Наприклад, отримувач бачить повідомлення, але зайнятий і не може його обробити. Або проблеми з автентифікацією. В простих системах такого немає, і QoS=0 достатній.
- 1 — повідомлення доставляється з підтвердженням. Отримувач у відповідь на PUBLISH повинен надіслати підтвердження PUBACK з кодом помилки (або успіху). Якщо відправник не дочекається такого PUBACK, то періодично повторюватиме відправлення зі встановленим прапорцем DUP=1.
Цей режим практичний, коли розмір повідомлень малий і потрібна просунута перевірка доставки. При великих повідомленнях може трапитися така річ, що датчик надіслав свої дані брокеру, брокер відповів PUBACK і продублював повідомлення всім підписникам. Але припустимо, датчик чомусь не отримав назад PUBACK. Він повторно надсилає дані брокеру з прапорцем DUP, а брокер знову змушений дублювати їх усім підписникам. Отже, якщо одна ланка передачі зазбоїть, то мережа постійно генеруватиме багато повідомлень PUBLISH, а кожен PUBLISH може тягнути аж до 256 МБ трафіку. Цей недолік усувається при QoS=2. - 2 — повідомлення доставляється з підтвердженням підтвердження.
датчик ⇒ PUBLISH ⇒ брокер
датчик ⇐ PUBREC ⇐ брокер
датчик ⇒ PUBREL ⇒ брокер
датчик ⇐ PUBCOMP ⇐ брокер
Якщо датчик ще не отримав PUBREC, то він буде періодично повторювати PUBLISH, але якщо отримав, то ні. В цілому, датчик повинен обрати QoS=2, якщо його повідомлення важке.
У комбінації з протоколом DDS (Data Distribution Service) MQTT може бути використаний для Інтернету речей (IoT)[5].
Перспективним напрямом реалізації брокерського механізму MQTT є забезпечення централізованого мультимережного менеджменту у бортових мережах транспортних засобів[6], а також мережі солдат[6].
- ↑ docs.oasis-open.org. Архів оригіналу за 20 лютого 2018. Процитовано 28 березня 2017.
- ↑ Специфікація MQTT-SN ver. 1.2 [Архівовано 11 травня 2021 у Wayback Machine.]
- ↑ What is MQTT? Definition and Details. www.paessler.com (англ.). Архів оригіналу за 9 червня 2020. Процитовано 9 червня 2020.
- ↑ Архівована копія. Архів оригіналу за 10 жовтня 2017. Процитовано 9 жовтня 2017.
{{cite web}}: Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (посилання) - ↑ David Barnett. Comparison of MQTT and DDS as M2M Protocols for the Internet of Things. Published on May 29, 2013. — [Архівовано 29 вересня 2020 у Wayback Machine.]
- 1 2 Слюсар В. І. Концепція архітектури транспортних засобів як мережі мереж.//Збірник матеріалів ХІІ науково-практичної конференції «Пріоритетні напрямки розвитку телекомунікаційних систем та мереж спеціального призначення. Застосування підрозділів, комплексів, засобів зв'язку та автоматизації в операції Об'єднаних сил» (14 — 15 листопада 2019 р.). — Київ. — С. 218—219 [Архівовано 1 січня 2020 у Wayback Machine.]
- Bryan Boyd et al. Building Real-time Mobile Solutions with MQTT and IBM MessageSight. IBM Redbooks, 2014
- Jeff Mesnil. Mobile and Web Messaging. O'Reilly Media, Inc., 2014 ISBN 978-1-4919-4480-6 — II. MQTT
- mqtt.org — офіційний сайт MQTT
- MQTT вікі-спільнота на GitHub
- Основи MQTT на HiveMQ [Архівовано 28 січня 2017 у Wayback Machine.].
- Is Exactly-Once Delivery Possible with MQTT [Архівовано 21 березня 2017 у Wayback Machine.]
- Is your personal information available via public MQTT brokers?
- http://www.steves-internet-guide.com/understanding-mqtt-topics/ [Архівовано 7 листопада 2017 у Wayback Machine.]