MQTT für Dummies

In unseren Projekten beschäftigen wir uns aktuell mit verschiedenen Kommunikationsprotokollen wie beispielsweise Http, MQTT oder Coap. Gerade im Bereich IoT ist MQTT ein Protokoll, das sich in den letzten Jahren etabliert hat. MQTT wird unter anderem zur Anbindung von IoT-Devices an Backend-Plattformen wie ThingWorx verwendet. Auch im Bereich Connected Car findet MQTT Einsatz. Ein Beispiel hierfür ist das Joynr-Framework der BMW CarIT.

Da wir in unserem Tagesgeschäft mit MQTT konfrontiert werden, haben wir eine Zusammenfassung mit den wichtigsten Punkten zum Protokoll erstellt, welche wir im Rahmen dieses Artikels vorstellen möchten.

Das MQTT-Protokoll folgt den Regeln einer Publish-Subscribe-Kommunikation. Es gibt zwei verschiedene Teilnehmer: Einen Broker, und „n“ Clients, wobei die Clients als Publisher und Subscriber nicht direkt miteinander kommunizieren, sondern Nachrichen „publishen“ (veröffentlichen) und „subscriben“ (abonnieren). Die Aufgabe des Brokers ist hier die Nachrichtenverwaltung und -verteilung.

MQTT Kommunikationsparadigma
MQTT Kommunikationsparadigma (Quelle)

Vorteil dieses Kommunikationsparadigmas: Entkopplung von Publisher und Subscriber (in Anlehnung an HiveMQ)

  • Space decoupling: Publisher und Subscriber müssen sich nicht kennen (IP-Adresse o.Ä.)
  • Time decoupling: Publisher und Subscriber müssen nicht zeitgleich ausgeführt werden
  • Synchronization decoupling: Operationen auf den ausführenden Computern blockieren nicht für die Zeit der Nachrichtenübermittlung (Asynchrones Messaging)

 

Nachfolgend werden die einzelnen Komponenten von MQTT sowie deren technische Details erläutert.

MQTT Clients

Der Client ist, wie man sich ganz typisch vorstellt, der „Endnutzer“ der Kommunikation und derjenige, der Nachrichten aktiv sendet. Ein Client kann zu einem Zeitpunkt Nachrichten eines Topics empfangen (Subscriber) als auch Nachrichten in dem gleichen Topic veröffentlichen (Publisher). Jeder Client identifiziert sich durch eine Client ID, die auch seine Session komplett identifiziert, denn MQTT ist für die Client-Seite komplett stateless.

MQTT Topics

Die Kommunikation von MQTT stützt sich auf ein sogenanntes „Topic“-Prinzip:

  • Jede Nachricht wir einem Topic zugeordnet. Das heißt, jede valide MQTT-Nachricht enthält eine Payload mit einem zugehörigen Topic.
  • Topics sind von der Funktions- und Schreibsyntax Ordnern in einem Filesystem sehr ähnlich. So hieße ein valides topic z.Bsp „5OG/Zimmer5/Temperatursensor/Temperatur“
  • Topics müssen von den Clients abboniert werden, um Nachrichten zu empfangen. Schließt sich nun ein neuer Client dem Netz an und schickt dem Broker eine Subscription zum Topic „5OG/Zimmer5/Temperatursensor/Temperatur“, wird der Broker alle Nachrichten mit diesem Topic an den Subscriber weiterleiten – doch Vorsicht – nur zu exakt diesem Topic, und nicht zu „5OG/Zimmer5/Temperatursensor“. Es gibt auch die Möglichkeit, gewählte Topics wieder zu „unsubscriben“ und deren entsprechende Nachrichten nicht mehr zu erhalten.

 

Es existiert auch ein Mechanismus, mit dem sich das Ordnersystem der Topics gruppieren lässt: sogenannte Single-Level-Wildcards(+) und Multi-Level-Wildcards(#)

  • Die Single-level-Wildcard ersetzt ein Element eines Topics durch eine Wildcard, sprich: Ein Subscriber zum topic „5OG/+/Temperatursensor/Temperatur“ würde alle Nachrichten erhalten, die den drei angegebenen Leveln entsprechen, ungeachtet der Wildcard. Nachrichten zu beispielsweise „5OG/Zimmer2/Temperatursensor/Temperatur“ oder „5OG/Flur/Temperatursensor/Temperatur“ würden jetzt empfangen werden.
  • Die Multi-level-Wildcard ersetzt die ganze folgende Baumstruktur. Eine Subscription zum Topic „5OG/#“ würde absolut alle Nachrichten empfangen, die mit „5OG/“ beginnen, auch z.Bsp „5OG/Flur/Tischkicker/Schummelmodul/Status“
  • Wildcards lassen sich beliebig kombinieren, beispielsweise „+/+/Temperatursensor/#“ für alle Temperatursensor-Daten aus allen Stöcken und Zimmern.

 

MQTT QoS

Nachrichten werden mit einer „Quality of Service“ verschickt, die drei Werte anbietet:

  • 0: „Fire-and-forget“ – das Paket wird genau einmal verschickt. Kommt an, unter Umständen auch vielleicht mal nicht, analog dem UDP-Protokoll. Enorm schnell.
  • 1: „Acknowledgement“ – der Empfänger bestätigt dem Sender, das Paket erhalten zu haben. Es ist möglich dass ein Paket mehrmals ankommt. Immer noch schnell.
  • 2: „Synchronisiert“ – das Paket erreicht garantiert das Ziel, und zwar garantiert nur ein mal, jedoch erzeugt diese Variante etwas mehr Verkehr.

 

MQTT Broker

Das „Backend“ für MQTT, genannt Broker, verwaltet und administriert jeglichen Datenverkehr. Zu seinen Aufgaben zählen die Speicherung, Verwaltung und Verteilung aller Informationen zu Topics, deren Abonnenten, Clients und deren IDs, Retained Messages, etc.  Die Bandbreite des Brokers sollte trotz des sehr schmalen Protokolls bei einer sehr hohen Anzahl an Clients entsprechend dimensioniert sein. Dennoch ist die Netzwerkauslastung von MQTT-Kommunikation generell gering.

Der Broker stellt die zentrale Vermittlungsplattform des MQTT Nachrichtenaustauschs dar. Das heißt bei einem Ausfall des Brokers bricht die ganze Kommunikation zusammen, da Clients untereinander nicht kommunizieren können. Glücklicherweise gibt es die Möglichkeit verschiedene Broker zu „bridgen“, sprich miteinander zu verbinden, um ein redundantes System aufzubauen, sofern fail-safety notwendig ist. Die meisten öffentlichen Broker-Implementationen wie z.Bsp. Mosquitto verfügen bereits über fertige Implementationen zur Überbrückung. Diese Brückenmechanik kann auch eingesetzt werden, um „Brokernetze“ zu bauen – die konfigurierbar Informationen und Nachrichten zu verschiedenen Topics austauschen und an ihre entsprechenden Clients weiterreichen.

MQTT Architektur (Quelle)
MQTT Architektur (Quelle)

Extras

Es werden generell alle Nachrichten direkt empfangen und verteilt, mit der Ausnahme von eigens gekennzeichneten „Retained Messages“. Diese werden auf dem Broker gespeichert und mit dem Topic verknüpft. Jedem neuen Abonnent des Topics wird diese Nachricht nach erfolgreichem Verbingungsaufbau automatisch zugestellt. Zu jedem Topic kann nur eine Retained Message gespeichert werden. Bereits gespeicherte Retained Messages werden von Neuen überschrieben. Das ermöglicht beispielsweise das Persistieren und zeitversetzte Empfangen von Nachrichten, auch wenn sie nicht regelmäßig gesendet werden.

Zu guter Letzt bietet MQTT noch eine Art Ausfallsicherung an – der „Last-Will“ – ein konfigurierbares Paket, das vom Broker gesendet wird, sobald ein Client eine Verbindung unsauber abbricht, durch Netzwerkfehler oder ähnliches. Eine Will-Nachricht kann z.Bsp. an „5OG/Zimmer5/Temperatursensor/Status“ mit der Payload „unreachable“ oder „0“ gesendet werden – damit werden Abonnenten benachrichtigt, dass der Client unerwartet nicht mehr erreichbar ist.

So entsteht eine verschachtelte Kommunikation mit sehr gezieltem Datenverkehr, und der Network-Code für Clients ist sehr schlank und simpel zu implementieren.

 

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*Pflichtfelder

*