Abonnementkennung und Abonnementoptionen – Neue Funktionen von MQTT 5.0

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. Heute diskutieren wir weiter: Abonnementkennung und Abonnementoptionen.

Abonnement-ID

Der Client kann beim Abonnieren eine Abonnementkennung angeben. Der Broker erstellt und speichert die Zuordnungsbeziehung zwischen diesem Abonnement und der Abonnementkennung, wenn das Abonnement erfolgreich erstellt oder geändert wird. Der Broker gibt die mit diesem PUBLISH-Paket und dem PUBLISH-Paket verknüpfte Subskriptionskennung an den Client zurück, wenn es erforderlich ist, PUBLISH-Pakete, die mit dieser Subskription übereinstimmen, an diesen Client weiterzuleiten.

Daher kann der Client die Zuordnung zwischen dem Abonnement-Identifizierer und dem Nachrichtenverarbeitungsprogramm zum direkten Ausrichten von Nachrichten an das entsprechende Nachrichtenverarbeitungsprogramm durch den Abonnement-Identifizierer herstellen, wenn er ein PUBLISH-Paket empfängt. Es ist viel schneller, als das Nachrichtenverarbeitungsprogramm durch Topic-Matching zu finden.

image20200723152010505.png

Da das SUBSCRIBE-Paket unterstützt, dass viele Subskriptionen enthalten sind, können mehrere Subskriptionen mit einer Subskriptionskennung verknüpft werden. Auch wenn Sie sich separat anmelden, kann diese Situation eintreten. Benutzer müssen sich darüber im Klaren sein, dass das Ergebnis bei dieser Verwendung auftreten kann, obwohl diese Situation vorkommen darf. Gemäß der tatsächlichen Abonnementsituation des Clients kann das PUBLISH-Paket, das der Client schließlich empfangen hat, mehrere Abonnementidentifizierer enthalten, und diese Abonnementidentifizierer können vollständig unterschiedlich oder gleich sein. Im Folgenden sind einige häufige Situationen aufgeführt:

  1. Der Client abonniert das Thema a und die Abonnementkennung als 1 angibt, das Thema abonniert b und spezifiziert die Subskriptionskennung als 2. Aufgrund der Verwendung unterschiedlicher Subskriptionskennungen werden die Nachrichten des Themas a und b werden an verschiedene Nachrichtenverarbeitungsprogramme geleitet.
  2. Der Client abonniert das Thema a und die Abonnementkennung als 1 angibt, das Thema abonniert b und spezifiziert die Subskriptionskennung als 1. Da die gleiche Subskriptionskennung verwendet wird, werden die Nachrichten des Themas a und b werden an dasselbe Nachrichtenverarbeitungsprogramm geleitet.
  3. Der Client abonniert das Thema a/+ und die Abonnementkennung als 1 angibt, das Thema abonniert a/b und spezifiziert die Subskriptionskennung als 1. Das PUBLISH-Themenpaket a/b zwei identische Subskriptionsidentifizierer tragen wird, wird das entsprechende Nachrichtenverarbeitungsprogramm zweimal getriggert.
  4. Der Client abonniert das Thema a/+ und die Abonnementkennung als 1 angibt, das Thema abonniert a/b und spezifiziert die Subskriptionskennung als 2. Das PUBLISH-Themenpaket a/b zwei unterschiedliche Subskriptionsidentifikatoren trägt, löst eine Nachricht zwei unterschiedliche Nachrichtenverarbeitungsprogramme aus.

image20200723152040226.png

Die Situation, dass das PUBLISH-Paket mehrere Abonnement-IDs trägt, ist in Ordnung, wenn die Nachrichtenrate niedrig ist, aber es kann einige Leistungsprobleme verursachen, wenn die Nachrichtenrate hoch ist. Daher haben wir vorgeschlagen, dass Sie versuchen sicherzustellen, dass dies absichtlich geschieht.

Abonnementoptionen

In MQTT v5 können Sie mehr Abonnementoptionen verwenden, um das Serververhalten zu ändern.

image20200723161859058.png

QoS

Bitte beziehen Sie sich auf MQTT-Dienstqualität.

Kein Lokal

Wenn Sie in MQTT v3.1.1 das von Ihnen veröffentlichte Thema abonnieren, erhalten Sie alle Nachrichten, die Sie veröffentlicht haben.

Wenn Sie diese Option jedoch in MQTT v5 beim Abonnieren auf 1 setzen, leitet der Server die von Ihnen veröffentlichte Nachricht nicht an Sie weiter.

Als Veröffentlichung beibehalten

Diese Option wird verwendet, um anzugeben, ob der Server die RETAIN-Markierung beibehält, wenn er Nachrichten an den Client weiterleitet, und diese Option wirkt sich nicht auf die RETAIN-Markierung in der aufbewahrten Nachricht aus. Wenn die Option Retain As Publish auf 0 gesetzt ist, wird der Client daher anhand der RETAIN-Markierung in der Nachricht direkt unterscheiden, ob es sich um eine normal weitergeleitete Nachricht oder eine zurückbehaltene Nachricht handelt, anstatt zu beurteilen, ob diese Nachricht die erste ist, die nach dem Abonnement empfangen wird (Die weitergeleitete Nachricht kann vor der zurückbehaltenen Nachricht gesendet werden, was von der spezifischen Implementierung verschiedener Broker abhängt).

Handhabung beibehalten

Diese Option wird verwendet, um anzugeben, ob der Server die zurückbehaltene Nachricht an den Client weiterleitet, wenn ein Abonnement eingerichtet wird.

  • Retain Handling ist gleich 0solange der Client sich erfolgreich anmeldet, sendet der Server die zurückbehaltene Nachricht.
  • Retain Handling ist gleich 1, wenn der Client sich erfolgreich anmeldet und dieses Abonnement vorher nicht existiert, sendet der Server die zurückbehaltene Nachricht. Schließlich initiiert der Client manchmal das Abonnement neu, nur um die QoS zu ändern, aber das bedeutet nicht, dass er die reservierten Nachrichten erneut empfangen möchte.
  • Retain Handling ist gleich 2sendet der Server die gespeicherte Nachricht nicht, selbst wenn der Client erfolgreich abonniert wurde.

Ursprünglich erschienen bei

Similar Posts

Leave a Reply

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