Flusskontrolle – MQTT 5.0 Neue Funktionen

MQTT v5 bringt viele neue Funktionen, wir werden diese Funktionen auf leicht verständliche Weise zeigen und die Auswirkungen dieser Funktionen auf den Entwickler diskutieren. Bisher haben wir diese besprochen neue Funktionen von MQTT v5. Jetzt werden wir weiter diskutieren: Ablaufsteuerung.

Ablaufsteuerung

Normalerweise sind die Ressourcen des Servers festgelegt und begrenzt, während sich der Fluss des Clients jederzeit und überall ändern kann. Das normale Geschäft (Benutzer greifen zentral zu und viele Geräte starten neu) wird böswillig angegriffen, und die Netzwerkfluktuation wird dazu führen, dass der Datenfluss dramatisch ansteigt. Wenn der Server den Fluss nicht begrenzt, wird die Last stark ansteigen und dann dazu führen, dass die Reaktionsgeschwindigkeit abnimmt, andere Unternehmen beeinträchtigt und sogar einen Systemausfall verursacht.

image20200730133959150.png

Daher brauchen wir Flusskontrolle, es kann die Senderate zur Begrenzung des Senders oder die Empfangsrate zur Begrenzung des Empfängers sein, und das Endziel ist es, die Stabilität des Systems sicherzustellen. Die üblichen Flusssteuerungsalgorithmen sind das Gleitfenster-Zählverfahren, der Leaky-Bucket-Algorithmus und der Token-Bucket-Algorithmus.

MQTT v3 hat das Flusssteuerungsverhalten nicht standardisiert, was dazu führen wird, dass Client und Server es unterschiedlich implementieren und sich dann auf den Zugriff und die Verwaltung von Geräten auswirken. MQTT v5 hat jedoch bereits die Flusskontrollfunktion eingeführt, und darauf werden wir auch als nächstes eingehen.

Die Flusskontrolle in MQTT v5

In MQTT v5 hat der Absender eine anfängliche Sendequote. Jedes Mal, wenn es ein PUBLISH-Paket mit QoS größer 0 sendet, wird die Sendequote um eins reduziert. Immer wenn es jedoch ein Antwortpaket (PUBACK und PUBCOMP oder PUBREC) empfängt, wird die Sendequote um eins erhöht. Wenn der Empfänger nicht sofort antwortet, wird die Sendequote auf 0 reduziert und der Absender sollte das Senden aller PUBLISH-Pakete mit QoS über 0 einstellen, bis die Sendequote wiederhergestellt ist. Wir können es uns als eine Variante des Token-Bucket-Algorithmus vorstellen, der einzige Unterschied besteht darin, die Methode zum Erhöhen der Quote von einer festen Rate auf die tatsächlich empfangene Antwortpaketrate zu ändern.

Dieser Algorithmus kann die Ressourcen positiver und vollständiger nutzen, da er die Empfangsrate nicht begrenzt und die Senderate dann vollständig von der Antwortrate des Gegenübers und der Netzwerksituation abhängt. Wenn der Empfänger verfügbar ist und ein gutes Netz hat, wird der Sender eine relativ hohe Senderate haben. Andernfalls wird es auf eine relativ niedrige Senderate beschränkt.

Erhalten Sie das maximale Attribut

MQTT v5 hat ein Receive Maximum-Attribut zur Unterstützung der Flusskontrolle hinzugefügt. Es ist im CONNECT-Paket und im CONNACK-Paket vorhanden und gibt die größte Anzahl von PUBLISH-Paketen mit der QoS 1 und 2 an, die der Client und der Server bereit sind, gleichzeitig zu verarbeiten, dh die maximale Sendequote, die die Gegenseite verwenden kann.

image20200730173320715.png

Warum kein QoS 0?

Vielleicht stellen Sie bereits fest, dass an allen Stellen, an denen im vorherigen Artikel PUBLISH-Nachrichten erwähnt werden, Attribute verwendet werden: QoS ist größer als 0. Die Merkmale der QoS 0-Nachricht bestimmen, dass kein Antwortpaket vorhanden ist. Sie denken vielleicht, dass die QoS 0-Nachrichten nicht sehr wichtig sind und der Empfänger die QoS 0-Nachrichten durch die obligatorische Empfangsratenbegrenzung einschränken kann, oder es gibt andere Gründe. Alles in allem sehen wir schließlich, dass der Flusskontrollmechanismus von MQTT v5 vollständig auf das Antwortpaket angewiesen ist, was dazu führt, dass die Flusskontrolle nur in QoS 1, 2-Nachrichten existieren kann.

MQTT v5 bietet eine unvollkommene Lösung oder ist nur ein Vorschlag: Wenn die Sendequote auf 0 reduziert wird, kann der Absender wählen, ob er weiterhin PUBLISH-Pakete mit QoS 0 senden oder das Senden aussetzen möchte. Die Logik des Aussetzens des Sendens ist: Wenn die Antwortgeschwindigkeit des PUBLISH-Pakets mit QoS 1,2 langsam wird, bedeutet dies normalerweise, dass die Kaufkraft des Empfängers zurückgegangen ist. Wenn der Absender weiterhin QoS 0-Nachrichten sendet, verschlechtert sich die Situation.

Zusammenfassung

Obwohl der Flusssteuerungsmechanismus von MQTT v5 immer noch einige Mängel aufweist, empfehlen wir Benutzern dennoch, ihn zu verwenden. Der auf dem Antwortpaket basierende Sendequotenalgorithmus ermöglicht es dem Absender, die Ressourcennutzung zu maximieren. Receive Maximum ermöglicht es beiden Kommunikationsparteien, das Sendekontingent nicht im Voraus auszuhandeln, wodurch eine größere Transparenz und Flexibilität erreicht wird, was für den Zugriff auf Geräte verschiedener Anbieter sehr nützlich ist.

Ursprünglich erschienen bei https://www.emqx.com.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *