MQTT Protocol

komunikačný protokol MQTT

MQTT Protokol

  • (slide)

  • Komunikačný protokol MQTT patrí medzi najčastejšie používané komunikačné protokoly vo svete IoT. Je veľmi jednoduchý binárny protokol, ktorý sa vyznačuje malou veľkosťou prenášaných paketov, napr. v porovnaní s protokolom HTTP. Rovnako je protokol veľmi jednoducho implementovateľný na strane klienta. Pri jeho vývoji bol kladený veľký dôraz na jednoduchosť použitia, vďaka čomu sa hodí aj na zariadenia s obmedzenými zdrojmi, akými sú napríklad mikorkontroléry. [MQTT 3.1.1 specification]

Vznik protokolu

The MQTT protocol was invented in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Cirrus Link). They needed a protocol for minimal battery loss and minimal bandwidth to connect with oil pipelines via satellite. The two inventors specified several requirements for the future protocol:

  • Simple implementation
  • Quality of Service data delivery
  • Lightweight and bandwidth efficient
  • Data agnostic
  • Continuous session awareness

These goals are still at the core of MQTT. However, the primary focus of the protocol has changed from proprietary embedded systems to open Internet of Things (IoT) use cases. This shift in focus has created a lot of confusion about what the acronym MQTT stands for. The short answer is that MQTT is no longer considered an acronym. MQTT is simply the name of the protocol.

Vzor Publish-Subscribe

  • The publish/subscribe pattern (also known as pub/sub) provides an alternative to a traditional client-server architecture. In the client-server model, a client communicates directly with an endpoint. The pub/sub model decouples the client that sends a message (the publisher) from the client or clients that receive the messages (the subscribers). The publishers and subscribers never contact each other directly. In fact, they are not even aware that the other exists. The connection between them is handled by a third component (the broker). The job of the broker is to filter all incoming messages and distribute them correctly to subscribers.

    Architektúra Publish-Subscribe

Poslanie správy

  • Posielať správy je možné okamžite, ako sa klient pripojí k broker-ovi. Každá správa musí obsahovať

    • tému (z angl. topic), vďaka ktorej bude broker vedieť správu poslať všetkým zainteresovaným klientom, a ** údaje (z angl. payload), ktoré reprezentujú samotné prenášané údaje.

  • Pri posielaní je možné okrem témy a samotných údajov pridať aj niekoľko ďalších atribútov. Pozrieme sa na ne podrobnejšie:

    • topic name

      • pravidla pre topiky

    • retain flag

    • payload

    • packet id

    • qos

      • At most once (QoS 0)
      • At least once (QoS 1)
      • Exactly once (QoS 2)

    • DUP flag

Ako organizovať témy

Wildcards

  • +
  • #

Témy začínajúce znakom $

Posledná vôľa

  • This message notifies other clients when a client disconnects ungracefully.

Porovnanie protokolov HTTP a MQTT

Režim práce Bridge

konfigurácia

# bridge from local mqtt broker to remote
connection CONN_NAME
address REMOTE_BROKER
remote_username REMOTE_USER
remote_password REMOTE_PASSWORD

toto pravidlo zabezpečí obojsmerné preposielanie správ, resp. odosielanie z lokálneho brokera na vzdialený, a sťahovanie zo vzdialeného na lokálny broker

topic # both 2


týmito pravidlami vieme filtrovať správy, ktoré sa majú odosielať z lokálneho na vzdialený

topic xiaomi out 2 gw/temp/ kpi/caprica/temp/


| pravidlo | lokálny broker | vzdialený broker |
| `xiaomi out 2 gw/temp/ kpi/caprica/temp/` | `gw/temp/xiaomi` | `kpi/caprica/temp/xiaomi` |

topic + out 2 gw/temp/ kpi/caprica/temp/ topic +/status out 2 gw/temp/ kpi/caprica/temp/ # topic # out 2 gw/temp/ kpi/caprica/temp/ ```