Перейти до вмісту

MQTT

Очікує на перевірку
Матеріал з Вікіпедії — вільної енциклопедії.
Приклад організації MQTT-зв'язку (QoS 0).

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.

В 2019 OASIS офіційно реалізував стандарт MQTT 5.0[3].

Можливості

[ред. | ред. код]
MQTT Broker
  • Простий у використанні. Протокол є програмним блоком без зайвої функціональності, що може бути легко вбудований в будь-яку складну систему;
  • Зручний для більшості рішень з датчиками. Дає можливість пристроям виходити на зв'язок і публікувати повідомлення, які не були заздалегідь відомі або визначені;
  • Легкий у адмініструванні;
  • Низьке навантаження на канал зв'язку;
  • Робота в умовах постійної втрати зв'язку або інших проблем на лінії;
  • Немає обмежень на формат переданого контенту.

Мет��ди MQTT

[ред. | ред. код]

MQTT визначає методи (так звані «дієслова»), щоб вказати бажану дію, яка повинна виконуватися на ідентифікованому ресурсі. Чим є цей ресурс, будь то вже наявні дані або дані, що генеруються динамічно, залежить від реалізації сервера. Часто ресурс відповідає файлу або результату виконання якогось файлу, розміщеного на сервері.

Connect. З'єднати: Чекає встановлення з'єднання з сервером.

Disconnect. Роз'єднати: Чекає доки клієнт MQTT закінчить будь-яку роботу, що має зробити, і доки роз'єднається TCP/IP сесія.

Subscribe. Підписатися: Чекає на завершення методу Subscribe чи UnSubscribe.

UnSubscribe. Відписатися: просить сервер відписати клієнта від одної або кількох тем.

Publish. Публікувати: одразу повертається в потік виконання додатку (англ. application thread) після того, як передасть запит клієнту MQTT.

Quality of Service

[ред. | ред. код]

При відправленні повідомлення можна обирати три рівні якості доставки[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].

Див. також

[ред. | ред. код]

Примітки

[ред. | ред. код]
  1. docs.oasis-open.org. Архів оригіналу за 20 лютого 2018. Процитовано 28 березня 2017.
  2. Специфікація MQTT-SN ver. 1.2 [Архівовано 11 травня 2021 у Wayback Machine.]
  3. What is MQTT? Definition and Details. www.paessler.com (англ.). Архів оригіналу за 9 червня 2020. Процитовано 9 червня 2020.
  4. Архівована копія. Архів оригіналу за 10 жовтня 2017. Процитовано 9 жовтня 2017.{{cite web}}: Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (посилання)
  5. David Barnett. Comparison of MQTT and DDS as M2M Protocols for the Internet of Things. Published on May 29, 2013.  [Архівовано 29 вересня 2020 у Wayback Machine.]
  6. 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

Посилання

[ред. | ред. код]