© Excellent backgrounds/Shutterstock.com
MQTT: Schnelleinstieg in das schlanke IoT-Protokoll mit Java

IoT-Allrounder


Das schlanke und leichtgewichtige Kommunikationsprotokoll MQTT hat sich als wichtigstes Internet-of-Things-(IoT-)Standardprotokoll durchgesetzt. Die Anwendungsfälle für MQTT reichen von industriellen Anwendungen über Connected Cars bis zu Home Automation und Do-it-yourself-(DIY-)Projekten. Grund genug, das IoT-Allrounder-­Protokoll aus der Java-Perspektive zu betrachten und zu erforschen, welche Möglichkeiten sich mit dem Einsatz von MQTT in Java-Applikationen ergeben.

Das Protokoll MQTT wurde 1999 als ein M2M-Kommunikationsprotokoll für SCADA-Systeme mit minimalem Protokolloverhead entwickelt. Es bietet vernetzten Geräten eine Möglichkeit, bandbreiten- und batterieschonend miteinander zu kommunizieren. Das Protokoll MQTT zeichnet sich außerdem durch seine außerordentliche Leichtgewichtigkeit aus und ist clientseitig sehr einfach zu implementieren.

Seit 2010 ist die Protokollspezifikation in Version 3.1 lizenzfrei verfügbar und seit 2014 auch die aktuellste Version 3.1.1, die erstmals bei dem Standardisierungsgremium OASIS spezifiziert wurde [1]. Das Protokoll schlägt mit einem ereignisgesteuerten Push-Ansatz einen anderen Weg ein als beispielsweise HTTP, das auf Request/Response basiert.

Warum MQTT?

MQTT ist besonders geeignet für eine zuverlässige Nachrichtenübertragung in unzuverlässigen und instabilen Netzwerken, wie etwa bei Mobilfunknetzwerken. Folgende Aspekte machen MQTT zu einem optimalen Protokoll für das Internet der Dinge und die mobile Kommunikation:

  • MQTT ist komplett datenagnostisch. Es ist daher geeignet, Daten jeder Art zu übertragen, egal ob es sich um Text oder binärkodierte Inhalte handelt.

  • MQTT ist einfach. Die Konzepte sind leicht zu erlernen und eigene Clientimplementierungen problemlos zu realisieren.

  • MQTT erfindet das Rad nicht neu. Es baut auf TCP auf, und die Übertragung kann jederzeit mittels SSL/TLS verschlüsselt werden.

  • MQTT ermöglicht echte Push-Kommunikation: Anders als bei anderen Protokollen gibt es bei MQTT kein Polling. Nachrichten werden sofort verteilt, wenn ein Ereignis auftritt. Das schont Bandbreite und CPU, da MQTT-Clientanwendungen reagieren können, sobald eine Nachricht ankommt, anstatt beim Server nach neuen Nachrichten zu fragen.

Publish/Subscribe

MQTT implementiert das Publish/Subscribe-Pattern (Abb. 1). Das bedeutet, dass jede Kommunikation über einen zentralen Verteiler, den so genannten MQTT Message Broker, stattfindet. Jede Nachricht, die ein Client sendet, enthält ein so genanntes Topic und die tatsächlichen Nutzdaten.

obermaier_mqtt1.tif_fmt1.jpgAbb. 1: Das Publish/Subscribe-Pattern

Ein Topic ist ein Text, der Trennzeichen enthalten kann, und er kann, ähnlich dem POSIX-Dateisystem­pfad, eine Hierarchie abbilden. Die Struktur heimautomatisierung/peters_haus/wohnzimmer/gluehbirne/1 wäre beispielsweise ein gutes Topic für Nachrichten von Glühbirne 1 im Wohnzimmer von Peters Haus. Jeder MQTT-Client, der Nachrichten für dieses Topic empfangen möchte, abonniert es beim Message Broker. Da die interessierten Clients beim Eintreffen neuer Nachrichten durch den Broker benachrichtigt werden, anstatt selbst beim Server nach Änderungen zu fragen, wird eine hocheffiziente Kommunikation zwischen den Teilnehmern gewährleistet. Somit ist eine echte Push-Kommunikation möglich. Entscheidend ist, dass die Teilnehmer der Kommunikation nichts voneinander wissen, da jeder Client nur den Message Broker kennt, nicht jedoch die anderen Teilnehmer.

Protokollfeatures

MQTT besitzt neben dem reinen Publish/Subscribe eine Reihe von bemerkenswerten Protokollfeatures, die im Kontext des IoT und von Mobile optimal sind.

  • Quality of Service: Um sicherzustellen, dass eine gesendete Nachricht beim Empfänger ankommt, definiert MQTT drei verschiedene Quality-of-Service-Levels (QoS), mit denen eine Nachricht gesendet werden kann: at most once (0), at least once (1) und exactly once (2).

  • Retained Messages: Die letzte gesendete Nachricht eines Topics kann am Broker hinterlegt werden. Jeder neue Subscriber auf diesem Topic erhält automatisch die zuletzt gesendete Nachricht.

  • Last Will and Testament (LWT): Ein Client kann eine MQTT-Nachricht als „letzten Willen“ beim Verbindungsaufbau am Broker hinterlegen. Wenn der Broker feststellt, dass dieser Client nicht mehr verbunden ist und der Client sich vorher nicht abgemeldet hat, wird dieser letzte Wille an alle Subscriber versendet. Der Broker ist also verantwortlich dafür, den letzten Willen des Clients auszuführen.

  • Persistent Sessions: In Anwendungsfällen, bei denen mit häufigen Verbindungs...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang