MQTT (Message Queue Telemetry Transport) ist ein offenes Nachrichtenprotokoll für Machine-to-Machine-Kommunikation (M2M), das die Übertragung von Telemetriedaten in Form von Nachrichten zwischen Geräten ermöglicht, trotz hoher Verzögerungen oder beschränkter Netzwerke.
Entsprechende Geräte reichen von Sensoren und Aktoren, Mobiltelefonen, Eingebetteten Systemen in Fahrzeugen oder Laptops bis zu voll entwickelten Rechnern. [Wikipedia]
Die unten aufgeführten Informationen über die Spezifikation stammen unter anderem aus der aktuellen MQTT Spezifikation der IBM.
OSI
Innerhalb des OSI-Modells ist MQTT wie folgt angesiedelt:
Die MQTT-Spezifikation unterscheidet TCP/IP-basierte und Nicht-TCP/IP-Netzwerk. Standardmäßig verwendet MQTT das TCP Protokoll/Verbindung (Port 1883 und 8883 für eine SSL-Verbidung). Bei MQTT-SN (MQTT for Sensor Networks) wird statt TCP das UDP Protokoll verwendet.
MQTT Paket Struktur
Fixed header ist immer vorhanden, wobei ‚variable header‘ und ‚payload‘ nicht immer vorkommen.
Fixed header
Der ‚fixed‘ Header eine MQTT Nachricht hat eine Länge von zwei byte und ist wie folgt unterteilt:
Auflistung der ‚Message Types‘ – byte 1, bits 7-4:
Für eine detaillierte Beschreibung verweise ich auf die Spezifikation Kapitel 3.
Auflistung von byte 1, bits 3-1:
RETAIN
Wenn ein subscriber sich für eine topic registriert, so bekommt er die Daten erst wenn der publisher neue Daten zur Verfügung stellt. Sollten die Daten z.B. einmal am Tag übertragen werden, so wird der subscriber erst einmal so lange warten müssen, bis der neue Datensatz eintrifft. Um diesen Umstand entgegen zu wirken, kann der publisher dafür sorge tragen, dass neue subscriber den letzten Datensatz (obwohl vielleicht veraltet) erhalten. Hierfür muss der RETAIN flag auf den Wert 1 gesetzt werden.
Quality of Service (QoS)
QoS oder Dienstgüte bezeichnet die Güte eines Kommunikationsdienstes aus der Sicht der Anwender. Das heißt, wie stark die Güte des Dienstes mit deren Anforderungen übereinstimmt. Formal ist QoS eine Menge von Qualitätsanforderungen an das gemeinsame Verhalten beziehungsweise Zusammenspiel von mehreren Objekten.
Standard IEEE 802.1p
- Ein Anwender möchte zuverlässig mit dem gewünschten Ziel verbunden werden und nach Ende der Kommunikation zuverlässig getrennt werden.
- Der Verbindungsaufbau soll rasch erfolgen.
- Probleme beim Verbindungsaufbau (z. B. Ziel-Teilnehmer nicht erreichbar) sollen dem Anwender schnellstmöglich mitgeteilt werden.
- Eine Kommunikationsverbindung soll stabil bestehen bleiben.
- Die Kommunikationsteilnehmer wollen sich verstehen können.
- Die Informationen sollen vollständig und ohne Fehler übertragen werden.
- Es sollen keine Informationen anderer Kommunikationsteilnehmer und keine Störungen übertragen werden.
- Die Kommunikation soll möglichst originalgetreu vor sich gehen.
- Es sollen keine langen Wartezeiten während der Kommunikation bestehen.
Die Abrechnung der Kommunikation soll dem korrekten Zeit- und Datenumfang entsprechen. [Wikipedia]
Im Kontext von MQTT werden folgende drei QoS Stufen voneinander unterschieden:
Anbei die Darstellung der QoS Varrianten als Sequenzdiagramm für ein besseres Verständnis:
Duplicate delivery (DUP)
Dieser Flag wird immer dann gesetzt, wenn der Client oder der Server folgende Kommandos erneut senden möchten:
- PUBLISH
- PUBREL
- SUBSCRIBE
- UNSUBSCRIBE
DUP kann bei QoS > 0 gesetzt werden.
Variable header
Zusätzlich zum fixed header können MQTT Nachrichten einen variablen Header beinhalten.
Message identifiers
Der variable header der folgenden ‚Message Types‘ wird durch ‚Message identifiers‘ beschrieben:
- PUBLISH
- PUBACK
- PUBREC
- PUBREL
- PUBCOMP
- SUBSCRIBE
- SUBACK
- UNSUBSCRIBE
- UNSUBACK
Payload
die folgenden MQTT Kommandos haben einen payload:
