MQTT-Protokoll, Python paho-mqtt-client

[Dr.Doom]

Howdy!

Frage zum Konzept publizierender Clients.

Client (publish only) ----> Broker ----> Client (subscribe only)

Auf dem angehängten Bild sieht man einige Debug-Ausgaben.

Verbindungsaufbau klappt.
Das Veröffentlichen von Nachrichten im Sekundentakt klappt. Von den (x,y)-Ausgaben ist x der RC mit 0=alles ok.

Ich trenne den Client bei der 10. Veröffentlichung vom Netzwerk.

Der nur publizierende Client macht fröhlich weiter und publiziert und publiziert. Laut RC=0 ist alles ok.

Erst 15 Sekunden später merkt er, hoppla, da stimmt doch was nicht, und der Wiederverbindungszirkus springt an und wird erfolgreich abgeschlossen.

(1) Keepalive
Die 15 Sekunden zwischen dem Trennen und der Reaktion darauf haben irgendwie nichts mit dem konfigurierten Keepalive zu tun.
keepalive ist auf 6 Sekunden für die obige Ausgabe festgelegt.
keepalive = 1, 3, 10, 40 oder 120 [s] ... völlig egal, 15 Sekunden nach dem Trennen merkt der Client erst/schon, dass etwas nicht stimmt.

Weiss jemand, warum das so ist?


(2) Quality of Service
Auf den Seite der nur lesenden Clients, erkennt man sofort nach dem Trennen der Verbindung, dass die nun nicht mehr zum Broker gesendeten Daten fehlern (klar...).

Nach dem Wiederverbinden des publizierenden Clients, werden die ins Nirvana gesendeten Daten (war ja für ihn alles ok für 15 Sekunden...) nicht vom publizierenden Client "nachgeholt".
Die Aufrufe von "publish" wurden mit einem QoS von 1 (mindestens einmal) oder 2 (genau einmal) durchgeführt.

Client ID ist eindeutig, CleanSession ist False, QoS > 0...
Warum sind die Daten verloren gegangen trotz QoS=1 bzw. 2?


Gehört es zum Konzept von MQTT, dass "nur publizierende" Clients die Daten gar nicht puffern und nach dem Wiederverbinden die Daten nachtragen?

Jemand eine Ahnung, ob das paho-Modul was taugt...? :ugly:

[Sephiroth]

Gehört es zum Konzept von MQTT, dass "nur publizierende" Clients die Daten gar nicht puffern und nach dem Wiederverbinden die Daten nachtragen?

Nö, die müssen nicht bestätige Nachrichten erneut senden.

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718103
When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers [MQTT-4.4.0-1]. This is the only circumstance where a Client or Server is REQUIRED to redeliver messages.


Bei welchem Client trennst du denn die Verbindung - Sender oder Receiver? Du verwendet leider für beide den gleichen Begriff.

[Dr.Doom]

Bin leider nicht weiter zum MQTT-Spielen gekommen.
Gekappt wurde aber die Verbindung zwischen dem Publisher-Client und dem Broker. Der Subscriber-Client war zu jeder Zeit mit dem Broker verbunden.

Kollegen-Gerüchten zufolge soll der Thingsboard-Broker aber gar kein QoS-Level 2 unterstützten (noch nicht geprüft).
Vermutlich würde er auch gar keine "nachgeholten" QoS-1-Nachrichten, die während der Unterbrechung vom Publisher-Client gesammelt wurden, in den Anzeige-Widgets nachtragen (noch nicht geprüft).
Zumindest ist es das, was ich bei der Visualisierung direkt auf der Oberfläche vom THingsboard-Broker sehe - da ist eine Datenlücke während der Zeit, in der der Publisher-Client nicht verbunden ist.
Der Publisher zählt einfach eine Variable rauf und verschickt den aktuellen Zustand. In der Visualisierung werden die fehlenden Zustände nicht nachgetragen, sondern der Zähler ist nach der Datenlücke einfach höher -- als hätte man eine Weile nicht "zugehört".

[Dr.Doom]

Ich mach' das ganze nicht mehr mit Python und nutze die C-Lib von paho, die arbeitet nachvollziehbarer.