Qt MQTT Überblick

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

Veröffentlichen und Abonnieren

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

Wenn z. B. Client 2 Nachrichten zum Thema A abonniert hat, erhält er eine Benachrichtigung, wenn Client 1 eine Nachricht zu diesem Thema sendet. Wenn Client 3 die Themen A und B abonniert hat, erhält er Benachrichtigungen über Nachrichten zu diesen 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

Topics werden in einer hierarchischen Baumstruktur gespeichert. Der Standard gibt weder vor, wie der Baum aufgebaut sein soll, noch bietet er vordefinierte Hierarchiesätze. Sie können die Hierarchie frei gestalten, wie es für Ihr Projekt erforderlich ist. Im Folgenden finden Sie ein Beispiel für eine Themenhierarchie, wobei "aktiv" für alle aktiven Sensoren steht, 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

Abonnieren von Themen mit Platzhaltern

Wenn Kunden Themen abonnieren, können sie das Rautenzeichen (#) und das Pluszeichen (+) als Platzhalter verwenden. Das Rautenzeichen zeigt an, dass der Kunde Benachrichtigungen über alle Nachrichten zu einem Thema und seinen Unterthemen erhalten möchte. Wenn ein Client beispielsweise sensors/house/# abonniert, erhält er alle Nachrichten über den Haussensor.

Das Pluszeichen zeigt an, dass ein Zweig des Baums bei der Suche nach einem passenden Unterthema übersprungen werden kann. Wenn ein Client z. B. sensors/+/temperature abonniert hat, empfängt er Nachrichten zur Temperatur, unabhängig davon, welcher Sensor sie gesendet hat. Sie können mehrere Pluszeichen verwenden, um mehrere Zweige zu überspringen. Beispielsweise könnte house/+/+/temperature verwendet werden, um Nachrichten über die Temperatur aller Räume in allen Wohnungen eines Hauses zu empfangen.

Gemeinsame Abonnements

Gemeinsame Abonnements beschreiben einen Pool 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 mehreren Clients. Das Format eines gemeinsamen Abonnements ist:

$share/{sharename}/{topicfilter}

Wenn z. B. Client 1 und Client 2 ein gemeinsames Abonnement für das Thema Sensoren/Haus/Temperatur haben sollen, lautet der zu abonnierende Themenfilter:

$share/poolAB/sensors/house/temperature

Es ist nicht definiert, 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 einem Baum 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 Topic-Namen verwendet werden, wodurch die Größe der einzelnen Nachrichten zunimmt.

Mit der Protokollversion MQTT 5.0 wurden Topic-Aliase eingeführt, um dies zu umgehen. Anstelle des Topic-Strings wird ein Integer-Wert gesendet. Um eine erste Zuordnung zwischen dem Client und dem Server herzustellen, müssen sowohl der Topic-String 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 Topic-Alias mit einem anderen Topic-String verwendet wird. Beachten Sie, dass diese Zuordnung nicht notwendigerweise für andere Verbindungen gilt, z. B. für Verbindungen vom Server zu anderen Clients. Jede Verbindung muss diese Zuordnung manuell erstellen.

Qt MQTT bietet einen automatischen Mechanismus, um die Datenrate zu reduzieren. Nachdem QMqttClient eine Verbindung erstellt hat, werden Informationen über vom Server unterstützte Themen-Aliase gespeichert. Anschließend werden die Themen-Aliase in der Reihenfolge verwendet, in der die Nachrichten veröffentlicht werden, bis alle verfügbaren Aliase verwendet werden. Ein Benutzer kann diese Zuordnung jederzeit ändern, indem er QMqttPublishProperties::setTopicAlias() während der Veröffentlichung verwendet.

Wenn QMqttClient ein Thema abonniert, kann der Server auch Themen-Aliase verwenden, abhängig vom QMqttConnectionProperties::maximumTopicAlias() Wert, der vom Client gesetzt wurde. Der Client ordnet Themen-Aliase automatisch zu und leitet Nachrichten mit dem vollständigen Themenstring transparent an den Benutzer weiter.

Sicherheit

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

Qualität des Dienstes

Die folgenden Dienstgüteebenen (QoS) für Nachrichten sind definiert:

• Höchstens einmal (0) bedeutet, dass Nachrichten nach bestem Bemühen der Betriebsumgebung zugestellt werden und daher Nachrichtenverluste auftreten können. Diese Stufe könnte z. B. bei Umgebungssensordaten verwendet werden, bei denen es keine Rolle spielt, ob ein einzelner Messwert verloren geht, da der nächste kurz darauf veröffentlicht wird.
• Mindestens einmal (1) bedeutet, dass das Eintreffen von Nachrichten gewährleistet ist, es aber zu Duplikaten kommen kann.
• Exakt einmal (2) bedeutet, dass die Nachrichten genau einmal ankommen. Diese Stufe könnte z. B. bei Abrechnungssystemen verwendet werden, bei denen doppelte oder verlorene Nachrichten zu falschen Gebühren führen könnten.

Testamentsnachrichten

Eine Willensnachricht, auch Testament genannt, ist eine Nachricht, die von einem Kunden gesendet und beim Broker gespeichert wird. Wenn die Verbindung zwischen dem Kunden und dem Makler auf unerwartete Weise unterbrochen wird, wird die Testamentsnachricht an jeden Teilnehmer des Testaments-Themas weitergeleitet.

Will-Messages müssen in der Verbindungsphase festgelegt werden. Daher ist es zwingend erforderlich, sie vor dem Aufruf von QMqttClient::connectToHost() oder QMqttClient::connectToHostEncrypted() festzulegen. Eine Will-Nachricht hat alle Eigenschaften einer normalen Nachricht sowie ein Will-Topic, eine QoS-Stufe, ein Retained Flag und eine Nutzlast.

Wenn der Client die Verbindung zum Broker auf reguläre Weise durch Aufruf von QMqttClient::disconnectFromHost() trennt, verwirft der Broker die Will Message. Falls erforderlich, ist der Client dafür verantwortlich, alle erforderlichen Nachrichten zu senden, bevor er die Verbindung trennt.

Zurückgehaltene Nachrichten

Zurückbehaltene Nachrichten werden auf der Seite des Brokers gespeichert. Wenn sich künftige Clients verbinden, erhalten sie solche Nachrichten. Ein typischer Anwendungsfall ist die Speicherung des aktuellen Gesundheitszustands des Herausgebers in einer gespeicherten Nachricht. Die Abonnenten erhalten dann sofort eine Nachricht über den Status.

Ein Broker kann nur die letzte aufbewahrte Nachricht speichern, die für ein bestimmtes Thema gesendet wurde. Wenn ein Client eine aufbewahrte Nachricht mit dem QoS-Level Null veröffentlicht, muss jede zuvor aufbewahrte Nachricht für sein Thema beim Broker verworfen werden. Der Broker sollte die letzte Nachricht speichern, kann sie aber auch verwerfen. Dies hängt von der Implementierung des Brokers ab.