Das MQTT Protokoll – Hintergründe (Teil 1)

Internet of things: Viele haben schon mal was davon gehört, aber nur wenige können so richtig beschreiben was es überhaupt ist… dieses „Internet of things“? Wikipedia beschreibt es folgendermaßen:

The Internet of Things refers to the interconnection of uniquely identifiable embedded computing like devices within the existing Internetinfrastructure. 

Oder wie ich es einfach gerne bezeichne: die Vernetzung von physischen Geräten über das Internet. Im Zeitalter der Digitalsierung sind dabei nicht nur Computer, Smartphones oder Tablets gemeint. Der Trend geht dazu alles miteinander zu vernetzen und kommunzieren zu lassen. Sei es das Auto, die Smartwatch, die Brille, der Fernseher oder gar der Kühlschrank dessen Inhalt ich von der Arbeit aus mit der Smartphone überprüfen lassen kann. Immer mehr Geräte finden ihren Weg ins Netz. Technisch gesehen wäre die Vernetzung dieser riesigen Anzahl an Geräten durch IPv6 möglich, allerdings sollte man sich viel mehr die Frage stellen: Auf welche Art und Weise sollen diese Geräte kommunizieren? Diese Frage ist vor allem dann wichtig, wenn man davon ausgeht, dass nicht jedes angeschlossene Gerät über die Non-Plus-Ultra Hardware verfügt oder nur eine Datenübertragung über den Mobilfunk ermöglicht. Eine ähnliche Frage stellte sich uns vor einigen Monaten als wir mit der Entwicklung des Forschungsprojektes IMPROVE begonnen haben. IMPROVE verfolgt das Ziel zu erforschen, wie man mit moderner Informationstechnologie den Energieverbrauch von Elektrofahrzeugen senken kann. Neben dem Backend und einer iOS Applikation, besteht unsere Aufgabe darin, die Software einer OnBoard Communication Unit zu entwickeln, welche im fahrenden Betrieb Informationen über das Fahreug sammelt und an das Backend und den mobilen Client sendet. Nach einem Gespräch mit einem der führenden OBCU-Herstellern Deutschlands, wurden wir auf das MQTT Protokoll aufmerksam.

MQTT (Message Queue Telemetry Protocol): MQTT ist ein auf TCP basierendes, schlankes und leichtgewichtiges Kommunikations-Protokoll, welches bereits 1999 von den beiden IT Unternehmen IBM und Arcom entwickelt wurde. In einem gemeinsamen Projekt sollte ein System entworfen werden, mit dem es möglich sein sollte Ölpipelines zu überwachen. Aufgrund von instablien bzw. schwach ausgeprägten mobilen Netzen, wurde ein Protokoll entwickelt, das eine effiziente Datenübertragung und sichere Zustellung der Daten ermöglicht. Da diese Anforderungen, auch heutzutage noch aktuell sind wurde der Source Code 2010 unter einer freien Lizenz veröffentlicht.

Topologie: Der Aufbau eines solchen MQTT-Netzes ist relativ simpel und auch schnell beschrieben. Da dieses Protokoll auf dem Publish/Subscribe Prinzip basiert, gibt es einen oder meherer Publisher und Subscriber, sowie eine zentrale Anlaufstelle – „Broker“ genannt. Die Publish- und Subscriber-Clients kommunizieren also nicht auf direkten Weg untereinandern sondern über den Broker. Die Nachrichten welche über diesen Kanal laufen, sind so genannten Topics zugeordnet. Nach dem sich ein Subscriber erfolgreich am Broker angemeldet hat, teilt er diesem mit welche Topics er abonieren möchte, um in Zukunft mit den jeweiligen Nachrichten versorgt zu werden. Beim Publisher funktioniert dies umgekehrt. Sendet er eine Nachricht raus, teilt er dem Broker mit, zu welchem Topic diese gehört. Die Hauptaufgabe des Brokers besteht also darin, Nachrichten anzunehmen und diese entstprechend an die Clients weiterzuleiten.

Topics: Topics sind einfache Zeichenketten welche eine Art Nachrichten-Hierarchie abbilden und mit einer einfachen URL vergleichbar sind.

FlotteHN/Fahrzeug1/Kilometerstand
FlotteHN/Fahrzeug1/Durschnittsgeschwindigkeit
FlotteHN/Fahrzeug2/Kilometerstand
FlotteHN/Fahrzeug2/Durschnittsgeschwindigkeit

In diesem Beispiel hätten wir also zwei Flotten-Fahrzeuge, welche in regelmäßigen Zeitabständen den Kilometerstand und die Durchschnittsgeschwindigkeit unter diesen Topics auf dem Broker veröffentlichen. Wenn nun ein oder mehrere Subscribe-Clients über den Kilometerstandes von Fahrzeug-1 informiert werden möchten, müssen sie das erste Topic abonnieren. Durch den Einsatz von Wildcards wird dieses Konzept erst so richtig interessant. Dabei kommen die ‚+‘ und ‚#‘ Operatoren zum Einsatz und können innerhalb eines Topics eingesetzt werden. Während man mittels des ‚+‘ Operators immer nur eine Ebene überspringen kann, erlaubt der ‚#‘ Operator beliebig viele. Ein Anwendungsbeispiel wäre eine Software welche die Kilometerstände aller Flotten-Fahrzeuge überwacht. Diese müsste demnach folgendes Topic abonieren:

FlotteHN/+/Kilometerstand

Eine weitere Software, welche alle Informationen eines bestimmten Fahrzeuges benötigt um diese auszuwerten, würde folgendes Topic wählen:

FlotteHN/Fahrzeug1/#

Quality of Service: Da MQTT auf dem TCP Protokoll basiert, kommt es von Haus aus mit einer großen Zuverlässigkeit in Sachen Datenaustausch. Allerdings kann es gerade im mobilen Bereich, zu Verbindungsengpässen oder gar Ausfällen kommen. Zu diesem Zweck wurde das Protokoll um den Quality of Service Mechanismus erweitert, welcher das Übertragen von Nachrichten garantiert. Dabei unterscheidet MQTT in drei Servicequalitäten:

  • QoS = 0: fire and forget
  • QoS = 1: Nachricht kommt mindestens einmal an
  • QoS = 2: Nachricht kommt genau einmal an

Je nach Einsatzgebiet oder Gewichtung der zu versendeten Nachricht, kann der MQTT-Client selbst entscheiden welcher QoS für ihn am geeignetsten ist. Um bei unserem Beispiel mit den Flotten-Fahrzeugen zu bleiben: Nehmen wir an, das Fahrzeug sendet im Sekunden-Takt seine Position an den Broker. Hier wäre es angebracht die Nachricht mit einem Wert von 0 zu versenden, da eine einzelne verloren gegangene Geo-Position verkraftbar ist (da in einer Sekunde bereits die nächste folgt) und dadurch nicht unnötiger Rückkopplungs-Overhead entsteht. Die Servicequalität von 2 wird beim subscriben eines Clients am Broker eingesetzt. Hier ist es wichtig, dass die Abonierung nur ein einziges mal ankommt und der Client sich nicht versehentlich doppelt registiert, wenn z. B. die Rückantwort des Servers verloren ging.

Quelle: Christian Götz (HiveMQ)

Quelle: Christian Götz (HiveMQ) 

Last Will and Testament: Was sich auf den ersten Blick etwas seltsam im Zusammenhang mit der Software Entwicklung und einer Protokoll-Beschreibung anhört, stellt auf den zweiten Blick ein mächtiges Werkzeug von MQTT dar. Hiermit können MQTT-Clients bei der Verbindung zum Broker ein “letztes Testament” abgeben. Dieses beschreibt im übertragenen Sinne, was passieren soll, wenn die Verbindung zum Client unerwartet abbricht. Damit ist es möglich, sofort reagieren zu können sobald ein Client die Verbindung verliert um beispielsweise andere Clients über den aktuellen Status zu informieren.

Retained Messages: Eine retained Message ist eine Nachricht welche von einem Publish-Client an den Broker gesendet wurde. Der Broker speichert diese Nachricht und leitet sie umgehend an jeden Subscribe-Client, der sich neu verbindet. Ein Use-Case hierfür wäre der Transport einer Ware von A nach B. Jedes mal wenn die Ware einen Zwischenstop in einem Lager macht, wird der momentane Aufenthaltsort an den Broker gesendet. Wenn ein neuer Subscriber online kommt, müsste dieser im Normalfall warten bis die Ware die nächsten Zwischenstation erreicht hat. Aufgrund der zuletzt auf dem Broker gepseicherten Nachricht (retained Message) wird er allerdings sofort über den zuletzt bekannten Aufenthaltsort informiert.

Fazit: Mein persönliches Fazit nach mehreren Monaten Entwicklung mit MQTT ist – Es macht einfach Spaß! Es ist leicht zu implementieren, kommt hervorragend mit eingeschränkten Ressourcen aus und überträgt Daten auf effiziente Art und Weise. Und dadurch dass es seit 2010 frei für Jedermann (und Frau) zur Verfügung steht, hat sich ein richtiges Ökosystem an Broker und Client Implementierungen in den gängigsten Programmiersprachen etabliert. Gerade im M2M Bereich macht ein Paradigmenwechseln von einfachen Polling zu einer ergeignisgesteuerten Publish/Subscribe Architektur Sinn.

Im nächsten Teil dieses Blog-Artikel werde ich anhand der Paho-Client-Library und einigen Code-Beispielen zeigen, wie leicht MQTT einzusetzen ist.

Lesen Sie in unserem aktuellen Blogartikel den Vergleich MQTT vs. AMQP

hier entlang…

Bewerte diesen Beitrag
0 Kommentare

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

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

  Newsletter abonnieren (Jederzeit wieder abbestellbar)