Verwirrung über den Client-Server-Verbindungsaufbau in MQTT

Gemäß den Spezifikationen sollte immer der Client die Verbindung zu einem Server herstellen.

Klient:

Ein Programm oder Gerät, das MQTT verwendet. Ein Client stellt immer die Netzwerkverbindung zum Server her . Es kann

• Veröffentlichen Sie Anwendungsnachrichten, an denen andere Clients interessiert sein könnten.

• Abonnieren Sie, um Anwendungsnachrichten anzufordern, die Sie erhalten möchten.

• Abbestellen, um eine Anforderung für Anwendungsnachrichten zu entfernen.

• Trennen Sie die Verbindung zum Server.

Wenn dieser Client eine Anwendungsnachricht abonniert, sollte der Server diese Nachrichten an diesen bestimmten Client weiterleiten.

Server:

Ein Programm oder Gerät, das als Vermittler zwischen Clients, die Anwendungsnachrichten veröffentlichen, und Clients, die Abonnements abgeschlossen haben, fungiert. Ein Server

• Akzeptiert Netzwerkverbindungen von Clients.

• Akzeptiert von Clients veröffentlichte Anwendungsnachrichten.

• Verarbeitet Abonnement- und Abbestellungsanforderungen von Clients.

• Leitet Anwendungsnachrichten weiter, die mit Client-Abonnements übereinstimmen .

Bedeutet dies, dass ein Client, der ein Abonnement abschließt, mit dem Server verbunden bleibt, solange das Abonnement gültig ist, obwohl die meiste Zeit kein Datenfluss stattfindet?

Ich komme zu diesem Schluss, weil, wenn der Client nach dem Abonnement die Verbindung trennt, ein Server keine Nachrichten an ihn weiterleiten kann, weil es der Client ist, der die Verbindung herstellen soll. Aber es wird nicht wissen, wann es wieder hergestellt werden soll.

Bedeutet dies, dass ein Client, der ein Abonnement abschließt, mit dem Server verbunden bleibt, solange das Abonnement gültig ist, auch wenn die meiste Zeit kein Datenfluss stattfindet?

Ja, sobald die Verbindung hergestellt ist, wartet der Client auf Nachrichten. Er sendet jedoch auch regelmäßig PING-Nachrichten an den Server, basierend auf dem Keepalive-Wert. Wenn der Server keine PING-Nachricht empfängt, werden Sie möglicherweise getrennt.

Wenn der Client nach dem Abonnement die Verbindung trennt, kann ein Server keine Nachrichten an ihn weiterleiten, da der Client die Verbindung herstellen soll.

Wenn die Verbindung zum Client getrennt wird, werden keine Nachrichten empfangen. Es gibt jedoch Funktionen in MQTT, die dies umgehen.

Wenn der Client eine Verbindung zum Server herstellt und das Flag 'Clean session' auf false gesetzt ist, speichert der Server das Abonnement für diese Client-ID. Sobald der Client erneut eine Verbindung herstellt, muss er nicht erneut abonniert werden, da sich der Server daran erinnert hat.

Darüber hinaus können Sie mit QoS Level 1 oder 2 abonnieren. Mit diesen QoS Levels speichert der Server Nachrichten und wartet, bis der Client die Verbindung wiederherstellt, bevor er sie weiterleitet. Selbst wenn der Client die Verbindung trennt und wieder herstellt, werden auf diese Weise alle veröffentlichten Nachrichten empfangen.

Diese Site verfügt über einige gute Ressourcen, die das MQTT-Protokoll erläutern.

Bedeutet dies, dass ein Client, der ein Abonnement abschließt, mit dem Server verbunden bleibt, solange das Abonnement gültig ist, auch wenn die meiste Zeit kein Datenfluss stattfindet?

Ja, Ihr Client wartet auf Nachrichten.

... Wenn der Client nach dem Abonnement die Verbindung trennt, kann ein Server keine Nachrichten weiterleiten

Sie müssen die Trennung verwalten (insbesondere bei batteriebetriebenen Geräten). Dies kann mit der Funktion " Last Will and Testament " von MQTT erfolgen: Wenn ein Gerät die Verbindung trennt, wird eine letzte Nachricht gesendet.

Sie sollten Verbindung und Sitzung unterscheiden.

Alles wird durch die Sitzung definiert. Wenn die MQTT-Verbindung zum ersten Mal für den Broker autorisiert wird, erstellt der Broker eine Sitzung für diese Verbindung, in der Regel basierend auf den Verbindungsparametern für die Client-ID.

Im MQTT 3.1.1-Protokoll (Standardeinstellung derzeit bei den meisten Clients / Brokern) können Sie während der Verbindung das Flag clean = true oder clean = false angeben. Wenn clean = true, erstellt der Broker automatisch eine neue Sitzung und schließt diese, wenn die Verbindung unterbrochen / geschlossen wird. Wenn clean = false, behält der Broker die Sitzung bei und überträgt die Ereignisse (in eine Art Sitzungsspeicher), auch wenn der Client nicht verbunden ist. Es hängt von der Broker-Implementierung ab, ob eine saubere = falsche Sitzung überhaupt zulässig ist und wie hoch die maximale Anzahl dieser Sitzungen ist.

Im MQTT 5.0-Protokoll (sehr frisch, aber perspektivisch) ist es möglich, die Sitzung ttl vom Client aus anzugeben oder sie sogar zu ändern, nachdem die Verbindung hergestellt wurde. Dies ist äußerst nützlich für instabile WAN-Verbindungen (meistens IoT) oder zustandsbehaftete Verbindungen, wie Sie beschrieben haben.

Das AFAIK-Protokoll MQTT 5.0 aus Client-Sicht kann derzeit in Python mit gmqtt und in Javascript mit mqtt.js verwendet werden .