Machine-to-Machine-Kommunikation (M2M) mit MQTT

MQTT steht für Message Queuing Telemetry Transport und dieses Protokoll ist bereits Anfang des Jahrtausends entwickelt worden von IBM und Eurotech. Spannend ist, dass es ein wenig in der Versenkung untergegangen ist, und erst mit der IOT ein Revival erlebt hat. Alles eigentlich perfekt ist für Machine-to-Machine-Kommunikation. Denn auch bei hohen Latenzen und geringe Bandbreiten lassen sich damit hervorragend in Netzwerken Informationen transportieren. Und dabei wird das Publish/ Subscribe-Model bei der Kommunikation verwendet. Bei dem Publish/Subscribe-Model sende das Endgerät an eine Zentraleinheit eine Information, und Empfänger können sich an der zentralen Einheit registrieren um diese Information abzuholen. Dabei gibt es auch drei unterschiedliche "Quality of Services", die in drei Level unterteilt sind 0, 1 und 2, die ich aber gleich in Ruhe erläutern möchte, wenn wir uns erstmal das Prinzip des Publish und Subscribe angesehen haben. Bei Publish und Subscribe müssen wir uns bitte folgendes Szenario vorstellen. Wir haben unterschiedliche Endgeräte. Ich nehme hier einfach mal ein Thermostat als Beispiel. Meine Zielsetzung soll es sein, dass dieses Thermostat entsprechend eine Information an eine Alarmsirene durchreichen soll, und dies würde im Regelfall ja eine direkte Kommunikation sein. Würde ich aber gleichzeitig in Applikationssicht zum Beispiel diese Information benötigen, müsste das Thermostat die Information schon an zwei Endgeräte senden. Das ist natürlich etwas suboptimal, weil wir davon ausgehen müssen dass wir komplexe Strukturen haben, wo durchaus eine Information an ganz viele Empfänger gesendet werden müssen. Und bei schlechten Latenzen oder gar schlechten Brandbreiten ist das sicherlich nicht die beste Wahl. Stattdessen arbeitet MQTT mit einem sogenannten Brocker. Diese Brocker hat deutlich mehr Rechenpower und ist auch relativ gut bestückt was die Bandbreite im Netz angeht. Und die Idee ist es nun, dass ein Endgerät ein sogenanntes Publish durchführt. Bei dem Publish wird eine bestimmte Information versendet. Im Falle dieses Temperaturmessers ist es ein Topic, also ein Inhaltstyp der Temperatur ist, und die Information, die veröffentlicht wird, also die weitergegeben werden soll ist die Eigenschaft "temp" mit 27 Grad. Diese Information wird es aber eben nicht an alle möglichen Geräte im System weitergeleitet, sondern einfach nur einmal an die Brocker geleitet. Bei dem Brocker wiederum kann sich nun die Alarmsirene registrieren und dies macht es durch diese Subscribe Mechanismen. Bei dem Subscribe-Mechanismus registriert sich diese Riene exakt bei dem Topic, das jetzt im dem Fall von dem Temperaturmesser gesendet wurde. Durch diese Registrierung wird also die Information über das Endgerät an den Brocker zu der Alarmsirene durchgereicht. Spannend ist es zum Beispiel auch, dass jetzt hier die Information eben nicht noch zusätzlich zur Applikationsschicht durchgereicht wird, weil die sich gar nicht dafür interessiert. Stellen wir uns jetzt nochmal vor, dass wir eine Machine haben die als Topic Auslastung hat, und als Information "load": "70%" sendet. Und hier ist es tatsächlich sehr spannend, dass wir tatsächlich in der Lage sind dann auch in der Applikationsschicht die Auslastung anzufragen und auf diese Art und Weise wunderbar diese Informationen zu erhalten. Es wäre übrigens auch überhaupt gar kein Problem, dass ein Gerät mehrere Subscription benutzen kann, das heißt ich wähle auch in Applikationsschicht durchaus in der Lage gleichzeitig die Temperatur anzuzeigen beispielsweise auch visuellen Alarm zu realisieren. Spannend ist also, dass die Empfänger wirklich nur die Daten bekommen an diese sich explizit subscriben, aber die Endgeräte alle Informationen an den Brocker schicken. Und da haben wir gerade darüber gesprochen, dass es ein Quality of Service gibt. Bei dem Quality of Service kann ich eigentlich bestimmen wie oft so eine Information an den Brocker gehen soll. Ich kann das einmal mit Level 0 machen, das ist nicht eigentlich anderes als ein Fire und Forget, das heißt, ich sende die Information einmal und hoffe dass sie beim Brocker ankommt. Sollte ich logischerweise nicht machen mit irgendwelchen Informationen die kritisch sind. Level 1 hingegen sagt at least once und das bedeutet das die Information durchaus mehrfach zum Brocker geschickt wird um sicherzugehen, dass das ganze auch wirklich funktioniert. Der Brocker müsste dann natürlich dafür sorgen die Eindeutigkeit einer Nachricht dementsprechend zu verarbeiten, das heißt die Information dann nicht auch zwingend mehrfach an die Subscriber durchzusetzen. Zu guter Letzt gibt es noch exactly once, das heißt hier ist der Aufwand relativ hoch, weil ich sicherstelle, dass die Information hundertprozentig und garantiert nur einmal beim Brocker ankommt, was dafür sorgt, dass der Brocker die Gewährleistung hat die Information, die es verbreiten soll, auf jeden Fall zu besitzen.