Qt MQTT Übersicht

Qt MQTT ermöglicht es Ihnen, Anwendungen und Geräte zu erstellen, die über das MQTT-Protokoll (MQ Telemetry Transport) kommunizieren können. Es entspricht vollständig der MQTT-Protokollspezifikation.

Veröffentlichen und Abonnieren

MQTT ist ein Protokoll für die Maschine-zu-Maschine-Kommunikation, das nach dem Publish-and-Subscribe-Modell funktioniert. Ein MQTT-Client ist ein Programm oder Gerät, das MQTT nutzt, um eine Netzwerkverbindung zu einem MQTT-Server, auch Broker genannt, herzustellen. Sobald eine Verbindung hergestellt ist, kann der Client Nachrichten an den Broker senden. Andere Clients können Benachrichtigungen zu bestimmten Themen abonnieren, die vom Client gesendet werden.

Wenn beispielsweise Client 2 Nachrichten zum Thema A abonniert, erhält er eine Benachrichtigung, sobald Client 1 eine Nachricht zu diesem Thema sendet. Wenn Client 3 die Themen A und B abonniert, erhält er Benachrichtigungen über Nachrichten zu beiden Themen.

Qt MQTT ist eine Client-Lösung, die keinen Broker enthält. Sie eignet sich besonders für die Entwicklung von Telemetrieanwendungen für eingebettete Geräte. Da „ Qt MQTT “ jedoch keine externen Abhängigkeiten aufweist, können die implementierten Clients auf allen unterstützten Qt-Plattformen ausgeführt werden.

Themen

Themen werden in einer hierarchischen Baumstruktur gespeichert. Der Standard legt weder fest, wie der Baum aufgebaut sein soll, noch stellt er vordefinierte Hierarchiesätze bereit. Sie können die Hierarchie frei nach den Anforderungen Ihres Projekts gestalten. Im Folgenden finden Sie ein Beispiel für eine Themenhierarchie, wobei „aktiv“ alle aktiven Sensoren bezeichnet, während „Haus“ und „Garage“ einzelne Sensoren sind:

sensors/active
sensors/house/temperature
sensors/house/bedroom/light
sensors/house/livingroom/light
sensors/garage/temperature
sensors/garage/light

Themen abonnieren mit Platzhaltern

Wenn Clients Themen abonnieren, können sie das Rautezeichen (#) und das Pluszeichen (+) als Platzhalter verwenden. Das Rautezeichen gibt an, dass der Client Benachrichtigungen zu allen Nachrichten eines Themas und dessen Unterthemen erhalten möchte. Wenn ein Client beispielsweise „sensors/house/#“ abonniert, erhält er alle Nachrichten zum „house“-Sensor.

Das Pluszeichen gibt an, dass ein Zweig im Baum bei der Suche nach einem passenden Unterthema übersprungen werden kann. Wenn sich ein Client beispielsweise bei „sensors/+/temperature“ abonniert, erhält er Nachrichten zur Temperatur, unabhängig davon, welcher Sensor sie gesendet hat. Sie können mehrere Pluszeichen verwenden, um mehrere Zweige zu überspringen. So könnte beispielsweise „house/+/+/temperature“ verwendet werden, um Nachrichten zur Temperatur aller Räume in allen Wohnungen eines Hauses zu erhalten.

Gemeinsame Abonnements

Gemeinsame Abonnements beschreiben eine Gruppe von Abonnenten für einen Themenfilter. Anstatt dass alle Abonnenten eine Nachricht erhalten, erhält nur ein Abonnent die Nachricht. Dies ermöglicht einen Lastausgleich auf mehrere Clients. Das Format eines gemeinsamen Abonnements lautet:

$share/{sharename}/{topicfilter}

Wenn beispielsweise Client 1 und Client 2 sich ein Abonnement für das Thema „sensors/house/temperature“ teilen sollen, lautet der zu abonnierende Themenfilter:

$share/poolAB/sensors/house/temperature

Es ist nicht festgelegt, in welcher Reihenfolge die Nachrichten vom Server verteilt werden. Dies ist eine serverspezifische Option.

Um festzustellen, ob ein Server gemeinsame Abonnements unterstützt, siehe auch „ QMqttServerConnectionProperties::sharedSubscriptionSupported “ ().

Themen-Aliase

Die Strukturierung von Themen in einer Baumstruktur hilft dabei, Datenkanäle zu trennen und eine logische Reihenfolge der Informationen zu gewährleisten. Dies kann jedoch dazu führen, dass bei der Veröffentlichung von Nachrichten sehr lange Themennamen verwendet werden, wodurch sich die Größe jeder Nachricht erhöht.

Um dies zu umgehen, wurden in der Protokollversion MQTT 5.0 Themenaliase eingeführt. Anstelle der Themenzeichenfolge wird ein ganzzahliger Wert gesendet. Um eine anfängliche Zuordnung zwischen Client und Server herzustellen, müssen sowohl die Themenzeichenfolge als auch der Alias Teil einer Nachricht sein. Danach wird nur noch die ID mit einem leeren Thema verwendet.

Diese Zuordnung kann jederzeit geändert werden, indem ein Themenalias mit einer anderen Themenzeichenfolge verwendet wird. Beachten Sie, dass diese Zuordnung nicht unbedingt für andere Verbindungen gilt, wie beispielsweise Verbindungen vom Server zu anderen Clients. Jede Verbindung muss diese Zuordnung manuell erstellen.

Qt MQTT bietet einen automatisierten Mechanismus zur Reduzierung der Datenraten. Nachdem QMqttClient eine Verbindung hergestellt hat, werden Informationen zu den vom Server unterstützten Themenaliasen gespeichert. Anschließend werden die Themenaliase in der Reihenfolge verwendet, in der die Nachrichten veröffentlicht werden, bis alle verfügbaren Aliase im Einsatz sind. Ein Benutzer kann diese Zuordnung jederzeit ändern, indem er während der Veröffentlichung QMqttPublishProperties::setTopicAlias() verwendet.

Wenn QMqttClient ein Thema abonniert, kann der Server je nach dem vom Client festgelegten Wert für QMqttConnectionProperties::maximumTopicAlias() ebenfalls Themenaliasse verwenden. Der Client ordnet Themenaliasse automatisch zu und leitet Nachrichten transparent an den Benutzer weiter, einschließlich der vollständigen Themenzeichenfolge.

Sicherheit

Die Verbindungen zwischen den Clients und dem Broker werden durch ein integriertes Authentifizierungssystem gesichert, das Benutzernamen und Passwörter verwendet. Nachrichten werden auf der Transportschicht mittels SSL/TLS verschlüsselt. Die standardisierte Portnummer für verschlüsselte MQTT-Nachrichten lautet 8883.

Dienstgüte

Die folgenden Quality-of-Service-Stufen (QoS) für Nachrichten sind definiert:

• „Höchstens einmal“ (0) bedeutet, dass Nachrichten nach bestem Bemühen der Betriebsumgebung zugestellt werden und daher Nachrichtenverlust auftreten kann. Diese Stufe könnte beispielsweise bei Umgebungssensordaten verwendet werden, bei denen es keine Rolle spielt, wenn ein einzelner Messwert verloren geht, da der nächste kurz darauf veröffentlicht wird.
• „Mindestens einmal“ (1) bedeutet, dass die Zustellung der Nachrichten gewährleistet ist, es jedoch zu Duplikaten kommen kann.
• „Genau einmal“ (2) bedeutet, dass Nachrichten garantiert genau einmal ankommen. Diese Stufe könnte beispielsweise bei Abrechnungssystemen verwendet werden, bei denen doppelte oder verlorene Nachrichten zu falschen Abrechnungen führen könnten.

Will-Nachrichten

Eine „Will-Nachricht“, auch „Testament“ genannt, ist eine vom Client gesendete und am Broker-Standort gespeicherte Nachricht. Wenn die Verbindung zwischen Client und Broker unerwartet unterbrochen wird, wird die „Will-Nachricht“ an alle Abonnenten des „Will-Themas“ weitergeleitet.

Will-Nachrichten müssen bei der Verbindungsherstellung angegeben werden. Daher ist es zwingend erforderlich, sie vor dem Aufruf von ` QMqttClient::connectToHost()` oder ` QMqttClient::connectToHostEncrypted()` festzulegen. Eine Will-Nachricht verfügt über alle Eigenschaften einer regulären Nachricht sowie über ein Will-Thema, eine QoS-Stufe, ein Retain-Flag und eine Nachrichtennutzlast.

Wenn der Client die Verbindung zum Broker auf reguläre Weise durch Aufruf von ` QMqttClient::disconnectFromHost()` trennt, verwirft der Broker die „Will“-Nachricht. Bei Bedarf ist der Client dafür verantwortlich, alle erforderlichen Nachrichten vor dem Trennen der Verbindung zu versenden.

Zurückbehaltene Nachrichten

Zurückbehaltene Nachrichten werden auf der Broker-Seite gespeichert. Wenn sich zukünftige Clients verbinden, erhalten sie diese Nachrichten. Ein typischer Anwendungsfall ist die Speicherung des aktuellen Zustands des Publishers in einer zurückbehaltenen Nachricht. Abonnenten erhalten sofort eine Nachricht über den Status.

Ein Broker kann nur die letzte für ein bestimmtes Thema gesendete gespeicherte Nachricht speichern. Wenn ein Client eine gespeicherte Nachricht mit der QoS-Stufe Null veröffentlicht, müssen alle zuvor für dieses Thema beim Broker gespeicherten Nachrichten verworfen werden. Der Broker sollte die letzte Nachricht speichern, kann sie jedoch auch verwerfen. Dies hängt von der Implementierung des Brokers ab.