Details zum MQTT-Treiber

Retain

Das Retain-Flag ist nur für die Veröffentlichung relevant. Für Subscription-Adressen wird es ignoriert. Wenn das Retain-Flag gesetzt ist, speichert der Broker den zuletzt veröffentlichten Wert für dieses Thema. Wenn ein Client dieses Thema abonniert, erhält er sofort diesen Wert. Der Anwendungsfall des Retain-Flags ist es, den Clients einen "letzten" Wert eines Themas zur Verfügung zu stellen, ohne dass ein Wert veröffentlicht werden muss.

Quality of Service

Es gibt 3 Stufen von QoS (0,1,2).

  • Der Wert 0 bedeutet "fire and forget". Das bedeutet, dass eine Nachricht, die mit QoS 0 veröffentlicht wird, nicht bestätigt oder erneut gesendet wird.
  • Der Wert 1 bedeutet "Übertragung der Nachricht mindestens einmal". Eine Nachricht mit QoS 1 wird vom Empfänger quittiert.

Erreicht die Bestätigung den Absender nicht, wird die Nachricht wiederholt. Dies kann jedoch auch zu doppelten Nachrichten führen.

Der Wert 2 bedeutet "genau einmal". In diesem Fall quittiert der Empfänger die Nachrichten, der Sender quittiert die Quittung und der Empfänger sendet schließlich eine vollständige Transaktion.

Dadurch kann der Empfänger doppelte Nachrichten herausfiltern. Der Preis für die höhere Zuverlässigkeit höherer QoS-Werte ist ein höherer Ressourcenverbrauch beim Broker und beim Client, eine höhere Netzlast und auch eine höhere Übertragungslatenzzeit.

Die QoS einer Nachricht vom Broker an einen abonnierenden Client wird durch die QoS der ursprünglichen Veröffentlichung und die QoS des Subscriptions bestimmt. Dies ist in der nachstehenden Tabelle zu sehen, in der die QoS des Subscriptions horizontal und die QoS der ursprünglichen Veröffentlichung vertikal dargestellt ist.
P\S 0 1 2
0 0 0 0
1 0 1 1

2 0 1 2

Persistent Session

Eine dauerhafte Sitzung speichert die Subscriptions und QoS-1- und QoS-2-Nachrichten, wenn der Client nicht verbunden ist. Dies kann zu einer Menge gepufferter Werte führen, die an den Client gesendet werden, wenn dieser die Verbindung wieder aufnimmt und die Sitzung fortsetzt.

Aus diesem Grund müssen persistente Sitzungen mit Vorsicht verwendet werden, da sie zu einem hohen Ressourcenverbrauch des Brokers führen können.

Der Anwendungsfall einer persistenten Sitzung besteht darin, die Lücke zu schließen, in der ein abonnierender Client nicht verfügbar ist, und keine Nachrichten verloren gehen sollen.

Debug-Flags

Um mögliche Fehlerquellen bei einem laufenden Treiber zu erkennen, stehen folgende Debug-Flags zur Verfügung.

Debug Level Beschreibung
25 Interne Datenbehandlung von MQTT-Nachrichten

Fehlermeldungen

Fehlercode Fehlermeldung
0 Unknown error
1 SocketConnectionRefusedError
2 SocketRemoteHostClosedError
3 SocketHostNotFoundError
4 SocketAccessError
5 SocketResourceError
6 SocketTimeoutError
7 SocketDatagramTooLargeError
8 SocketNetworkError
9 SocketAddressInUseError
10 SocketAddressNotAvailableError
11 SocketUnsupportedSocketOperationError
12 SocketUnfinishedSocketOperationError
13 SocketProxyAuthenticationRequiredError
14 SocketSslHandshakeFailedError
15 SocketProxyConnectionRefusedError
16 SocketProxyConnectionClosedError
17 SocketProxyConnectionTimeoutError
18 SocketProxyNotFoundError
19 SocketProxyProtocolError
20 SocketOperationError
21 SocketSslInternalError
22 SocketSslInvalidUserDataError
23 SocketTemporaryError
65536 MqttUnacceptableProtocolVersionError
65537 MqttIdentifierRejectedError
65538 MqttServerUnavailableError
65539 MqttBadUserNameOrPasswordError
65540 MqttNotAuthorizedError
65541 MqttNoPingResponse