Nachdem wir nun in dem vorherigen Beitrag auf die MQTT Basics eingegangen sind und das Protokoll erklärt haben, gehen wir nun ein wenig in die Tiefe. Wer ganz tiefes Wissen erlange möchte, wie z.B. wie sieht der Header aus, sollte sich nen Buch kaufen. 🙂 Nein, wir bleiben bei den 3 wichtigsten Features die MQTT noch mit an Board hat. Zunächst schauen wir auf QoS – Quality of Service und beleuchten die 3 Modis die es gibt. Danach schauen wir uns kurz Retained Messages und den letzten Willen an. Mit diesen 3 Features können wir wunderbar unsere Umgebung steuern und ein wenig managen wann wen welche Nachricht erreicht.

QoS – Quality of Service

QoS ist sozusagen die Dienstgüte der Kommunikation. Der Client besagt mit dem Flag von QoS dem Broker wie wichtig ihm die Nachricht und wie dringend diese umbedingt bei Ihm ankommen soll. Wir brauchen die Quality of Service teilweise, da wir hier über ein limitiertes Netzwerk reden. Nicht immer kann der Client einen Broker erreichen, muss aber trotzdem gewährleisten das eine Nachricht ankommt, dann ist dieser mit einer QoS Regel genau an der richtigen Adresse. Also es gibt genau 3 QoS Regeln.


QoS 0 – Höchstens einmal
QoS 1 – Mindestens einmal
QoS 2 – Genau einmal


QoS 0 -> Das ist das Standardlevel bei MQTT und sendet nur genau einmal ein Paket zum Broker, dabei ist egal ob es ankommt oder eben nicht. Der Client will auch gar nicht wissen ob etwas angekommen ist, geschweige denn das irgendwas weitergeleitet wird. Häufig sagt man hier auch fire and forget, absenden und nicht weiter drüber nachdenken. Meiner Meinung nach sollte das auch der Grundsatz sein mit der Programmierung von diesem Protokoll, wir halten den Traffic damit gering und können ja trotzdem hin und wieder ein QoS 1 oder 2 senden.

QoS 1 -> Hier sind wir jetzt schon bei einer Kommunikation zwischen Client und Broker. Der Client sendet seine Nachricht mit einem QoS Level von 1 und wenn der Broker diese erreicht, bestätigt dieser das Empfangen von dem Paket. Wenn der Client jetzt auch noch das Bestätigungspaket vom Broker erhält, ist dieser zufrieden. Kommt aber nach einer gewissen Timeout kein Bestätigungspaket vom Broker zurück, sendet der Client das Paket erneut mit der QoS 1. So können wir gewährleisten das dass Paket beim Broker früher oder später mindestens einmal ankommt. Eine Sache ist noch wichtig. Bei dieser Art von QoS kann es natürlich auch vorkommen das der Client das Paket ein paar mal sendet und auch beim Broker ankommt, aber dieser niemals eine Bestätigung vom Broker erhält da z.B. die Netzabdeckung in Empfangsrichtung schlecht ist oder gar einfach die Pakete verloren gehen.

QoS 2 -> Das QoS Level 2 ist die höchste Form von Quality bei MQTT. Hierbei wird sichergestellt das eine Nachricht genau nur einmal beim Broker angekommen ist und auch bestätigt ist. Hier wird nicht nur der Empfang vom Broker bestätigt, sondern dann bestätigt auch noch der Client das die Bestätigungsnachricht bei Ihm angekommen ist und keine weiteren Versuche vom Senden vorgenommen werden. Der Broker sendet noch einmal zurück das er die Kommunikation nun beendet. Also zusammen gefasst, werden für eine Nachricht insgesamt 4 Pakete hin und her gesendet, was natürlich das Datenaufkommen im Netzwerk erhöht, wir uns aber sicher sein können das eine Nachricht nur genau einmal beim Broker angekommen ist.

Letztendlich kann man gut zusammenfassend sagen, das generell eine QoS von 0 die beste Wahl ist, aber im Use-Case eine QoS 1 oder 2 manchmal Sinnvoll sein kann. 

MQTT – Retained Messages

Soo, kommen wir nun zu den Retained Messages. Eine zum Broker versendete Nachricht kann als retained markiert werden, um diese auf dem Broker vorzuhalten für neue Subscriber. Eine Retained Message kann als eine Art Willkommensnachricht gesehen werden, denn wenn ein neuer Subscriber ein Topic wo eine Retained Nachricht hinterlegt ist abboniert, bekommt er genau diese Nachricht zugestellt. Das gilt für jeden neuen Subscriber, welcher das Thema abboniert. Man könnte dies beispielsweise für eine Statusmeldung benutzen, damit der Subscriber sofort einen aktuellen oder vorgehaltenen Status bekommt. Entweder wird eine Retained Message gelöscht, indem ein Client eine weitere Retained Message in dem Topic sendet, welche leer ist oder eine Retained Message wird aktualisiert mit einem neuen Inhalt. Wichtig, niemand besagt dem Empfänger von wann diese Retained Message ist, diese kann auch zum Zeitpunkt des Abbonieren schon ziemlich alt sein. Nochmal zum Abschluss, wenn diese Nachricht gelöscht werden soll, muss eine „leere“ Nachricht mit dem Retained Flag in diesem Topic an den Broker gesendet werden. Danach wird niemand mehr mit einer Retained Message belästigt. 🙂

MQTT – Last Will (Letzter Wille und Testament)

Als letzten wichtigen Punkt gibt es noch den Letzten Willen oder auch Last Will and Testament oder nur Wills. Dies ist eine Nachricht, welche der Client beim Verbinden mit dem Broker als letzten Willen hinterlegt, für den Fall der Fälle das die Verbindung abbricht. Dies gilt aber auch wirklich nur für den Fall das die Verbindung verloren geht und nicht für einen geplanten Disconnect. Im Bereich von IoT kommt es z.B. mal vor das eine Batterie leer ist und das System einfach nicht ordnungsgemäß heruntergefahren werden kann. Oder die Verbindung zum Broker reißt einfach ab, durch ein Funkloch in der Gegend. Genau dann kommt der letzte Wille zum Tragen. Das Topic und die Message kann vom Client festgelegt werden, welche gesendet werden soll wenn die Verbindung abbricht. Natürlich erreicht diese Nachricht nur die Subscriber, welche das Thema abonniert haben in welchem der „The Last Will“ gesendet wird.

Das waren nun die wichtigsten zusätzlichen Features von MQTT, mit welchen man in Kombination mit Sicherheit eine tolle und gesicherte Kommunikation sicherstellen kann. Ich werde in Zukunft mal auf ein paar Beispiele eingehen, um das ganze am lebenden Herzen zu präsentieren.

Ansichten: 16.594