MQTT und Message Brokers

Wie funktioniert das Publish/Subscribe-Modell?

Publisher, Subscriber und Broker

Stell dir vor, du abonnierst einen Nachrichten-Newsletter zu einem bestimmten Thema, zum Beispiel "Technik-Neuheiten". Die herausgebende Instanz des Newsletters (Publisher) veröffentlicht regelmäßig neue Artikel (Nachrichten). Du als abonnierende Person (Subscriber) erhältst diese Artikel automatisch, weil du dein Interesse an diesem Thema bekundet hast. Die Plattform, die den Newsletter versendet und verwaltet (der Broker), sorgt dafür, dass die richtigen Artikel an die richtigen Abonnierenden gelangen. In MQTT funktioniert es ganz ähnlich:

• Publisher: Geräte oder Anwendungen, die Nachrichten (Daten) zu einem bestimmten Thema senden. Ein Temperatursensor wäre ein Publisher, der aktuelle Temperaturwerte sendet.
• Subscriber: Geräte oder Anwendungen, die Nachrichten zu bestimmten Themen empfangen möchten, die sie zuvor abonniert haben. Eine Heizungssteuerung wäre ein Subscriber, der Temperaturwerte empfängt.
• Broker: Ein zentraler Server, der Nachrichten von Publishern entgegennimmt und an alle Subscriber weiterleitet, die das entsprechende Thema abonniert haben. Er ist die Kommunikationsdrehscheibe.

Topics: Die Adressierung von Nachrichten

Topics sind in MQTT wie Kanäle oder Adressen, die festlegen, wohin eine Nachricht gesendet wird und von wo sie empfangen werden kann. Sie sind hierarchisch aufgebaut, ähnlich wie Ordnerstrukturen auf deinem Computer, und verwenden Schrägstriche (/) zur Trennung der Ebenen. Diese Struktur ermöglicht eine sehr flexible und gezielte Nachrichtenverteilung.

• Ein Sensor in einem Gebäude könnte beispielsweise Nachrichten zum Topic gebaeude/etage1/raum101/temperatur veröffentlichen.
• Eine Anwendung, die die Temperatur nur in Raum 101 überwachen möchte, abonniert genau dieses Topic.
• Eine andere Anwendung, die alle Temperaturdaten der ersten Etage benötigt, könnte das Topic gebaeude/etage1/+/temperatur abonnieren, wobei + ein Platzhalter für eine einzelne Ebene ist.
• Um alle Daten aus dem gesamten Gebäude zu erhalten, kann gebaeude/# abonniert werden, wobei # ein Platzhalter für mehrere Ebenen am Ende eines Topics ist.

Was ist MQTT und warum ist es wichtig?

MQTT: Das Kommunikationsprotokoll für das Internet der Dinge

MQTT steht für Message Queuing Telemetry Transport. Es ist ein leichtgewichtiges und effizientes Nachrichtenprotokoll, das speziell für die Kommunikation zwischen Geräten im Internet der Dinge (IoT) und in Machine-to-Machine (M2M) Szenarien entwickelt wurde. Seine Hauptmerkmale sind:

• Geringer Ressourcenverbrauch: Es benötigt wenig Bandbreite und Rechenleistung, ideal für kleine Geräte mit begrenzten Ressourcen (z.B. Sensoren mit Batteriebetrieb).
• Zuverlässigkeit: Es bietet Mechanismen, um Nachrichten auch über unzuverlässige Netzwerkverbindungen (z.B. Mobilfunk) sicher zuzustellen.
• Asynchrone Kommunikation: Die sendende und die empfangende Instanz müssen nicht gleichzeitig online sein.

Stell dir vor, du möchtest, dass dein Smartphone (Subscriber) die Daten von verschiedenen Sensoren (Publisher) in deinem Smart-Home-System empfängt, um die Temperatur zu regeln oder das Licht zu steuern. MQTT sorgt dafür, dass diese Kommunikation reibungslos und effizient funktioniert, selbst wenn die Internetverbindung der Sensoren gelegentlich schwach ist.

Quality of Service (QoS) – Die Zuverlässigkeit deiner Nachrichten

MQTT bietet drei Stufen der Nachrichtenübermittlungssicherheit, die als Quality of Service (QoS) bezeichnet werden. Diese Stufen ermöglichen es, die Zuverlässigkeit der Nachrichtenübermittlung an die spezifischen Anforderungen der Anwendung anzupassen:

• QoS 0 (At most once – Höchstens einmal): Die Nachricht wird ohne Bestätigung gesendet. Dies ist die schnellste, aber unzuverlässigste Stufe. Es gibt keine Garantie, dass die Nachricht ankommt. Beispiel: Ein Sensor sendet alle paar Sekunden die aktuelle Raumtemperatur. Geht ein Wert verloren, ist das meist unkritisch, da bald ein neuer Wert folgt.
• QoS 1 (At least once – Mindestens einmal): Der Broker garantiert, dass die Nachricht mindestens einmal beim Subscriber ankommt. Der Publisher sendet die Nachricht so lange, bis er eine Bestätigung (PUBACK) erhält. Es kann zu Duplikaten kommen, wenn die Bestätigung verloren geht und der Publisher die Nachricht erneut sendet. Beispiel: Ein Befehl zum Einschalten einer Lampe. Es ist wichtig, dass der Befehl ankommt. Kommt er doppelt an, bleibt die Lampe einfach an.
• QoS 2 (Exactly once – Genau einmal): Dies ist die sicherste, aber auch ressourcenintensivste Stufe. Durch einen vierstufigen Handshake zwischen Publisher, Broker und Subscriber wird sichergestellt, dass die Nachricht exakt einmal zugestellt und verarbeitet wird. Beispiel: Eine kritische Alarmmeldung eines Rauchmelders, die exakt einmal verarbeitet werden muss, um Fehlalarme oder das Verpassen eines echten Alarms zu vermeiden.

Retained Messages – Die letzte wichtige Nachricht nicht verpassen

Retained Messages sind eine spezielle Art von MQTT-Nachrichten. Wenn ein Publisher eine Nachricht mit dem "Retained"-Flag sendet, speichert der Broker diese Nachricht für das betreffende Topic. Sobald ein neuer Subscriber dieses Topic abonniert, erhält er sofort die zuletzt gespeicherte Retained Message. Das ist besonders nützlich, um neuen Teilnehmenden im Netzwerk sofort den aktuellen Status eines Geräts oder Sensors mitzuteilen, ohne dass sie auf die nächste reguläre Nachricht warten müssen.

• Beispiel: Ein Temperatursensor sendet jede Minute die aktuelle Temperatur als Retained Message. Wenn eine neue Wetterstation online geht und das Temperatur-Topic abonniert, erhält sie sofort den letzten bekannten Temperaturwert, anstatt eine Minute auf die nächste Messung warten zu müssen.

Wie unterscheidet sich MQTT vom Client-Server-Modell?

MQTT: Entkopplung durch Publish/Subscribe

Im traditionellen Client-Server-Modell baut ein Client eine direkte Verbindung zu einem Server auf, um eine Anfrage zu stellen und eine Antwort zu erhalten (z.B. ein Webbrowser, der eine Webseite von einem Webserver anfordert). Die Kommunikation ist direkt und synchron. Das Publish/Subscribe-Modell von MQTT hingegen ermöglicht eine entkoppelte Kommunikation:

• Publisher und Subscriber müssen sich nicht direkt kennen. Sie kommunizieren ausschließlich über den Broker und die Topics.
• Zeitliche Entkopplung: Publisher und Subscriber müssen nicht gleichzeitig online sein. Der Broker kann Nachrichten zwischenspeichern (abhängig von QoS und Konfiguration).
• Räumliche Entkopplung: Publisher und Subscriber müssen nicht wissen, wo sich der jeweils andere im Netzwerk befindet.

Diese Entkopplung macht MQTT sehr flexibel und skalierbar, besonders in Szenarien mit vielen Geräten (Viele-zu-Viele-Kommunikation), wie sie im IoT typisch sind. Stell dir ein Smart-Home-System mit Dutzenden von Sensoren (Licht, Temperatur, Bewegung) und Aktoren (Lampen, Heizung, Alarmanlage) vor. Mit MQTT können neue Geräte einfach hinzugefügt oder entfernt werden, ohne die Konfiguration der bestehenden Geräte ändern zu müssen. Jeder Sensor publiziert seine Daten, und jede Steuerungseinheit abonniert nur die für sie relevanten Daten.

Client-Server: Direkte Kommunikation

Das Client-Server-Modell ist wie ein direktes Telefongespräch: Die anfragende Instanz (Client) initiiert die Verbindung und stellt eine Anfrage an die antwortende Instanz (Server), die darauf reagiert. Diese direkte, oft synchrone Kommunikation eignet sich gut für Anwendungen, bei denen ein Client spezifische Informationen von einem bekannten Server benötigt. Ein klassisches Beispiel ist das Abrufen einer Webseite von einem Webserver mittels HTTP. Für IoT-Szenarien mit vielen dezentralen Geräten, die oft nur sporadisch Daten senden oder empfangen, ist dieses Modell jedoch weniger flexibel und kann bei vielen gleichzeitigen Anfragen den Server schnell überlasten.

Welche Rolle spielt der Message Broker in MQTT?

Nachrichten-Routing und Gewährleistung der Zustellung

Der Message Broker ist die zentrale Instanz in einer MQTT-Architektur. Seine Hauptaufgaben umfassen:

• Nachrichten-Routing: Er empfängt Nachrichten von Publishern und leitet sie an alle Subscriber weiter, die das entsprechende Topic abonniert haben. Er fungiert als intelligente Vermittlungsstelle.
• Gewährleistung der Quality of Service (QoS): Je nach dem von Publisher und Subscriber gewählten QoS-Level einer Nachricht kümmert sich der Broker um die notwendigen Bestätigungsmechanismen, das Zwischenspeichern und eventuelle Wiederholungsversuche, um die gewünschte Zustellsicherheit zu erreichen. Stell dir vor, ein Sensor sendet kritische Alarmdaten mit QoS 2. Der Broker managt den komplexen Bestätigungsprozess, damit diese Daten zuverlässig und genau einmal beim zuständigen Alarmsystem ankommen.

Management von Verbindungen und Entkopplung der Teilnehmenden

Weitere wichtige Funktionen des Brokers sind:

• Management von Client-Verbindungen: Der Broker verwaltet die aktiven Netzwerkverbindungen zu allen verbundenen Publishern und Subscribern (Clients). Er authentifiziert Clients, überwacht den Verbindungsstatus (z.B. durch Keep-Alive-Nachrichten) und verwaltet Client-Sessions.
• Entkopplung der Kommunikationsteilnehmenden: Wie bereits erwähnt, ermöglicht der Broker die Entkopplung. Publisher müssen nicht wissen, welche oder wie viele Subscriber ihre Nachrichten empfangen, und Subscriber müssen den Publisher nicht direkt kennen. Sie interagieren nur über den Broker und die definierten Topics. Stell dir ein großes Netzwerk von Wettersensoren (Publisher) und verschiedenen Anwendungen (Subscriber) vor, die Wetterdaten visualisieren oder Warnungen ausgeben. Der Broker leitet die Daten der Sensoren an alle interessierten Anwendungen weiter, ohne dass Sensoren und Anwendungen direkte Verbindungen zueinander aufbauen oder voneinander wissen müssen.
• Verwaltung von Retained Messages: Der Broker speichert die letzte Retained Message pro Topic und liefert sie an neue Subscriber aus.
• Zugriffskontrolle: Viele Broker bieten Mechanismen zur Zugriffskontrolle (Authorization), um festzulegen, welche Clients welche Topics publizieren oder abonnieren dürfen.

Lernziele

• die zentralen Funktionen eines Message Brokers innerhalb der MQTT-Architektur erklären, indem dessen Aufgaben wie Nachrichten-Routing, Management von Client-Verbindungen, Gewährleistung von Quality of Service und die Entkopplung von Sensoren/Aktoren und Anwendungen erläutert werden.
• die Bedeutung von Quality of Service (QoS) und Retained Messages in MQTT interpretieren, indem die verschiedenen QoS-Stufen (0, 1, 2) und die Funktion von Retained Messages hinsichtlich Zuverlässigkeit, Nachrichtenverlust und Aktualität der Daten analysiert werden.
• das MQTT Publish/Subscribe-Modell mit dem traditionellen Client-Server-Modell vergleichen, indem die Unterschiede in Bezug auf Kommunikationsmuster, Kopplungsgrad der Teilnehmer und Eignung für typische CPS-Szenarien (z.B. viele-zu-viele Kommunikation) dargestellt werden.
• das Publish/Subscribe-Kommunikationsmodell von MQTT erklären, indem die Rollen von Publisher, Subscriber und Broker sowie die Funktionsweise von Topics für die Nachrichtenverteilung im Kontext von Cyber-Physischen Systemen dargestellt werden.