MQTT

MQTT(Message Queuing Telemetry Transport) ist ein einfaches und weit verbreitetes Messaging-Protokoll, das für eingeschränkte Geräte konzipiert ist. AWS IoT Core Die Unterstützung für MQTT basiert auf der MQTTv3.1.1-Spezifikation und der MQTT v5.0-Spezifikation, mit einigen Unterschieden, wie unter dokumentiert. AWS IoT Unterschiede zu den MQTT Spezifikationen Als neueste Version des Standards bietet MQTT 5 mehrere wichtige Funktionen, die ein MQTT basiertes System robuster machen, darunter neue Skalierbarkeitsverbesserungen, verbesserte Fehlerberichterstattung mit Antworten auf Ursachencodes, Timer für den Ablauf von Nachrichten und Sitzungen sowie benutzerdefinierte Kopfzeilen für Benutzernachrichten. Weitere Informationen zu den von MQTT 5 AWS IoT Core unterstützten Funktionen finden Sie unter MQTT5 unterstützte Funktionen. AWS IoT Core unterstützt auch die MQTT versionsübergreifende Kommunikation (MQTT3 und MQTT 5). Ein Herausgeber von MQTT 3 kann eine MQTT 3-Nachricht an einen MQTT 5-Abonnenten senden, der dann eine MQTT 5-Veröffentlichungsnachricht erhält, und umgekehrt.

AWS IoT Core unterstützt Geräteverbindungen, die das MQTT Protokoll und das MQTT WSS Over-Protokoll verwenden und die durch eine Client-ID identifiziert werden. AWS IoT Gerät SDKs unterstützen beide Protokolle und sind die empfohlenen Verbindungsmethoden für Geräte zu AWS IoT Core Das AWS IoT Gerät SDKs unterstützt die Funktionen, die Geräte und Clients benötigen, um eine Verbindung zu AWS IoT Diensten herzustellen und auf sie zuzugreifen. Das Gerät SDKs unterstützt die Authentifizierungsprotokolle, die für die AWS IoT Dienste erforderlich sind, und die Verbindungs-ID-Anforderungen, die für MQTT das Protokoll und MQTT andere WSS Protokolle erforderlich sind. Informationen darüber, wie Sie AWS IoT mithilfe des AWS Geräts eine Verbindung herstellen können, SDKs sowie Links zu Beispielen AWS IoT in den unterstützten Sprachen finden Sie unterVerbindung herstellen MQTT mit dem Gerät AWS IoT SDKs. Weitere Informationen zu Authentifizierungsmethoden und den Portzuordnungen für MQTT Nachrichten finden Sie unter. Protokolle, Port-Zuweisungen und Authentifizierung

Wir empfehlen zwar, das AWS IoT Gerät für die Verbindung SDKs zu verwenden AWS IoT, sie sind jedoch nicht erforderlich. Wenn Sie das AWS IoT Gerät jedoch nicht verwendenSDKs, müssen Sie für die erforderliche Verbindungs- und Kommunikationssicherheit sorgen. Die Clients müssen die TLSErweiterung Server Name Indication (SNI) in der Verbindungsanforderung senden. Verbindungsversuche, die das nicht enthalten, SNI werden abgelehnt. Weitere Informationen finden Sie unter Transportsicherheit in AWS IoT. Clients, die IAM Benutzer und AWS Anmeldeinformationen zur Authentifizierung von Clients verwenden, müssen die richtige Signature Version 4-Authentifizierung bereitstellen.

Verbindung herstellen MQTT mit dem Gerät AWS IoT SDKs

Dieser Abschnitt enthält Links zum AWS IoT Gerät SDKs und zum Quellcode von Beispielprogrammen, die veranschaulichen, wie ein Gerät angeschlossen wird AWS IoT. Die hier verlinkten Beispiel-Apps zeigen, wie Sie AWS IoT mithilfe des MQTT Protokolls und MQTT darüber eine Verbindung herstellen könnenWSS.

Anmerkung

Das AWS IoT Gerät SDKs hat einen MQTT 5-Client veröffentlicht.

C++

Geräte mit dem AWS IoT SDK C++-Gerät verbinden

• Quellcode einer Beispiel-App, die ein MQTT Verbindungsbeispiel in C++ zeigt

• AWS IoT C++-Gerät SDK v2 aktiviert GitHub

Python

Geräte mit dem AWS IoT Device SDK for Python verbinden

• Quellcode einer Beispiel-App, die ein MQTT Verbindungsbeispiel in Python zeigt

• AWS IoT Gerät SDK für Python v2 auf GitHub

JavaScript

Verwenden Sie das AWS IoT Gerät SDK JavaScript zum Anschließen von Geräten

• Quellcode einer Beispiel-App, die ein MQTT Verbindungsbeispiel in zeigt JavaScript

• AWS IoT Gerät SDK für JavaScript v2 an GitHub

Java

Geräte mit dem AWS IoT Gerät SDK für Java verbinden

Anmerkung

Das AWS IoT Gerät SDK für Java v2 unterstützt jetzt die Android-Entwicklung. Weitere Informationen finden Sie unter AWS IoT Gerät SDK für Android.

• Quellcode einer Beispiel-App, die ein MQTT Verbindungsbeispiel in Java zeigt

• AWS IoT Gerät SDK für Java v2 an GitHub

Embedded C

Geräte mit dem AWS IoT Gerät SDK für Embedded C verbinden

Wichtig

Dies SDK ist für erfahrene Entwickler eingebetteter Software vorgesehen.

• Quellcode einer Beispiel-App, die ein MQTT Verbindungsbeispiel in Embedded C zeigt

• AWS IoT Gerät SDK für Embedded C ein GitHub

MQTTOptionen für Servicequalität (QoS)

AWS IoT und das AWS IoT Gerät SDKs unterstützt die MQTTQuality of Service (QoS) -Stufen 0 und 1. Das MQTT Protokoll definiert eine dritte Ebene von QoS, Ebene2, unterstützt AWS IoT diese jedoch nicht. Nur das MQTT Protokoll unterstützt die QoS-Funktion. HTTPSunterstützt QoS, indem ein Abfragezeichenfolgenparameter übergeben ?qos=qos wird, dessen Wert 0 oder 1 sein kann.

Die Tabelle beschreibt, wie sich jede QoS-Stufe auf Meldungen auswirkt, die an und von Message Broker veröffentlicht werden.

Mit einem QoS-Level von ...	Die Meldung ist …	Kommentare
QoS Stufe 0	Null oder mehr Mal gesendet	Diese Stufe sollte für Meldungen verwendet werden, die über zuverlässige Kommunikationsverbindungen gesendet werden oder die problemlos übersehen werden können.
QoS Stufe 1	Mindestens einmal gesendet und dann wiederholt, bis eine PUBACK Antwort eingeht.	Die Meldung gilt erst dann als vollständig, wenn der Absender eine PUBACK Antwort erhält, die auf eine erfolgreiche Zustellung hinweist.

MQTTpersistente Sitzungen

Persistente Sitzungen speichern Abonnements und Meldungen eines Kunden mit einer Quality of Service (QoS) von 1, sofern diese nicht vom Kunden bestätigt wurden. Wenn das Gerät wieder eine Verbindung zu einer dauerhaften Sitzung herstellt, wird die Sitzung wieder aufgenommen, Abonnements werden wieder hergestellt und unbestätigte abonnierte Meldungen, die vor der Wiederverbindung empfangen und gespeichert wurden, werden an den Client gesendet.

Die Verarbeitung der gespeicherten Nachrichten wird in CloudWatch und CloudWatch Logs aufgezeichnet. Informationen zu den in Logs geschriebenen Einträgen CloudWatch und CloudWatch Logs finden Sie unter Message Broker-Metriken undProtokolleintrag in der Warteschlange.

Erstellen einer persistenten Sitzung

In MQTT 3 erstellen Sie eine MQTT persistente Sitzung, indem Sie eine CONNECT Nachricht senden und das cleanSession Kennzeichen auf setzen0. Wenn für den Client, der die CONNECT-Meldung versendet, keine Sitzung vorhanden ist, wird eine neue persistente Sitzung erstellt. Wenn für den Client bereits eine Sitzung existiert, nimmt der Client die bestehende Sitzung wieder auf. Um eine saubere Sitzung zu erstellen, senden Sie eine CONNECT Meldung und setzen das cleanSession Flag auf 1. Der Broker speichert dann keinen Sitzungsstatus, wenn der Client die Verbindung trennt.

In MQTT 5 behandeln Sie persistente Sitzungen, indem Sie das Clean Start Flag und setzenSession Expiry Interval. Clean Start steuert den Beginn der Verbindungssitzung und das Ende der vorherigen Sitzung. Wenn Sie Clean Start = 1 setzen, wird eine neue Sitzung erstellt und eine vorherige Sitzung wird beendet, falls sie existiert. Wenn Sie Clean Start = 0 setzen, nimmt die Verbindungssitzung eine vorherige Sitzung wieder auf, falls sie existiert. Das Sitzungsablaufintervall bestimmt das Ende der Verbindungssitzung. Das Sitzungsablaufintervall gibt die Zeit in Sekunden (4-Byte-Ganzzahl) an, für die eine Sitzung nach der Trennung bestehen bleibt. Einstellung Session Expiry interval = 0 bewirkt, dass die Sitzung sofort nach der Trennung beendet wird. Wenn das Sitzungsablaufintervall in der CONNECT Nachricht nicht angegeben ist, ist der Standardwert 0.

MQTT5 Clean Start und Ablauf der Sitzung

Eigenschaftenwert	Beschreibung
Clean Start= 1	Erzeugt eine neue Sitzung und beendet eine vorherige Sitzung, falls eine existiert.
Clean Start= 0	Nimmt eine Sitzung wieder auf, falls eine vorherige Sitzung existiert.
Session Expiry Interval> 0	Hält eine Sitzung aufrecht.
Session Expiry interval= 0	Behält eine Sitzung nicht bei.

Wenn Sie in MQTT 5 Clean Start = 1 und Session Expiry Interval = setzen0, entspricht dies einer Sitzung mit MQTT 3 fehlerfreien Sitzungen. Wenn Sie Clean Start = 0 und Session Expiry Interval > setzen0, entspricht dies einer persistenten Sitzung mit MQTT 3 Personen.

Anmerkung

MQTTVersionsübergreifende (MQTT3 und MQTT 5) persistente Sitzungen werden nicht unterstützt. Eine persistente Sitzung mit MQTT 3 kann nicht als eine Sitzung mit MQTT 5 wiederaufgenommen werden und umgekehrt.

Operationen während einer persistenten Sitzung

Clients müssen das sessionPresent-Attribut in der Connection Acknowledged (CONNACK)-Meldung nutzen, um festzustellen, ob eine persistente Sitzung vorhanden ist. Wenn sessionPresent auf 1 gesetzt ist, liegt eine persistente Sitzung vor und alle gespeicherten Meldungen für den Client werden an den Client zugestellt, nachdem der Client CONNACK empfangen hat, wie unter Meldungsverkehr nach Wiederverbindung mit einer persistenten Sitzung beschrieben. Wenn sessionPresent auf 1 gesetzt ist, muss der Client kein erneutes Abonnement abschließen. Wenn sessionPresent auf 0 gesetzt ist, ist keine persistente Sitzung vorhanden, und der Client muss die Themenfilter erneut abonnieren.

Nachdem der Client der persistenten Sitzung beigetreten ist, kann er weiterhin Meldungen veröffentlichen und Themenfilter ohne zusätzliche Flags für jede Maßnahme abonnieren.

Meldungsverkehr nach Wiederverbindung zu einer persistenten Sitzung

Eine persistente Sitzung stellt eine laufende Verbindung zwischen einem Client und einem MQTT Message Broker dar. Wenn ein Client eine Verbindung mit dem Message Broker über eine persistente Sitzung herstellt, speichert der Message Broker alle Abonnements, die der Client während der Verbindung erstellt. Wenn der Client getrennt wird, speichert der Message Broker unbestätigte QoS 1-Meldungen und neue QoS 1-Meldungen, die zu Themen veröffentlicht wurden, die der Client abonniert hat. Meldungen werden gemäß dem Kontolimit gespeichert. Meldungen, die das Limit überschreiten werden gelöscht. Weitere Informationen zu persistenten Nachrichtenlimits finden Sie unter AWS IoT Core Endpunkte und Kontingente. Wenn der Client die Verbindung zur persistenten Sitzung wiederherstellt, werden alle Abonnements reaktiviert und alle gespeicherten Meldungen werden bei einer maximalen Rate von 10 Meldungen pro Sekunde an den Client gesendet. In MQTT 5 gilt: Wenn ein ausgehender QoS1-Dienst mit dem Nachrichtenablaufintervall abläuft, wenn ein Client offline ist, empfängt der Client nach der Wiederaufnahme der Verbindung die abgelaufene Nachricht nicht.

Nach der Wiederverbindung werden die gespeicherten Meldungen an den Client gesendet, und zwar mit einer Geschwindigkeit, die auf 10 gespeicherte Meldungen pro Sekunde begrenzt ist, zusammen mit dem aktuellen Meldungsverkehr, bis das Publish requests per second per connection-Limit erreicht ist. Da die Zustellungsrate der gespeicherten Meldungen begrenzt ist, dauert es mehrere Sekunden, bis alle gespeicherten Meldungen zugestellt werden, wenn in einer Sitzung nach der Wiederverbindung mehr als 10 gespeicherte Meldungen zugestellt werden müssen.

Eine persistente Sitzung wird beendet.

Dauerhafte Sitzungen können wie folgt enden:

• Die Ablaufzeit der persistenten Sitzung ist abgelaufen. Der Timer für den Ablauf einer persistenten Sitzung wird gestartet, wenn der Message Broker feststellt, dass ein Client die Verbindung getrennt hat, entweder weil der Client die Verbindung getrennt hat oder weil die Verbindung das Timeout überschritten hat.

• Der Client sendet eine CONNECT Nachricht, die das cleanSession Flag auf 1 setzt.

In MQTT 3 ist der Standardwert für die Ablaufzeit persistenter Sitzungen eine Stunde. Dies gilt für alle Sitzungen im Konto.

In MQTT 5 können Sie das Sitzungsablaufintervall für jede Sitzung CONNECT und jedes DISCONNECT Paket festlegen.

Für das Sitzungsablaufintervall für DISCONNECT ein Paket:

• Wenn die aktuelle Sitzung ein Sitzungsablaufintervall von 0 hat, können Sie das Sitzungsablaufintervall für das DISCONNECT Paket nicht auf mehr als 0 setzen.

• Wenn die aktuelle Sitzung ein Sitzungsablaufintervall von mehr als 0 hat und Sie das Sitzungsablaufintervall für das DISCONNECT Paket auf 0 setzen, wird die Sitzung am beendetDISCONNECT.

• Andernfalls aktualisiert das auf dem DISCONNECT Paket angegebene Sitzungsablaufintervall das Sitzungsablaufintervall der aktuellen Sitzung.

Anmerkung

Die gespeicherten Meldungen, die darauf warten, am Ende einer Sitzung an den Client gesendet zu werden, werden verworfen. Sie werden jedoch weiterhin zum Standardnachrichtentarif in Rechnung gestellt, obwohl sie nicht gesendet werden konnten. Weitere Informationen zu Preisen erhalten Sie unter AWS IoT Core Preise. Sie können das Ablaufzeitintervall konfigurieren.

Wiederverbindung nach Ablauf einer persistenten Sitzung

Wenn ein Client vor Ablauf nicht wieder eine Verbindung zu seiner persistenten Sitzung herstellt, wird die Sitzung beendet und die gespeicherten Meldungen werden verworfen. Wenn ein Client nach Ablauf der Sitzung wieder eine Verbindung herstellt und das cleanSession-Flag auf 0 setzt, erstellt der Dienst eine neue persistente Sitzung. Alle Abonnements oder Meldungen aus der vorherigen Sitzung sind für diese Sitzung nicht verfügbar, da sie beim Ablauf der vorherigen Sitzung verworfen wurden.

Gebühren für Meldungen während einer dauerhaften Sitzung

Nachrichten werden Ihnen in Rechnung gestellt AWS-Konto , wenn der Message Broker eine Nachricht an einen Client oder eine persistente Offline-Sitzung sendet. Wenn ein Offline-Gerät mit einer dauerhaften Sitzung erneut eine Verbindung herstellt und seine Sitzung wieder aufnimmt, werden die gespeicherten Meldungen an das Gerät übermittelt und Ihrem Konto erneut belastet. Weitere Informationen zu den Preisen für Meldungen finden Sie unter AWS IoT Core Preise – Meldungsübermittlung.

Die standardmäßige Ablaufzeit einer persistenten Sitzung von einer Stunde kann erhöht werden, indem das standardmäßige Verfahren zum Erhöhen von Limits verwendet wird. Beachten Sie, dass durch eine Verlängerung der Sitzungsablaufzeit Ihre Meldungsgebühren steigen können, da durch die zusätzliche Zeit mehr Meldungen für das Offline-Gerät gespeichert werden können und diese zusätzlichen Meldungen Ihrem Konto zum Standardnachrichtentarif in Rechnung gestellt würden. Bei der Ablaufzeit der Sitzung handelt es sich um einen ungefähren Wert, und eine Sitzung kann bis zu 30 Minuten länger als das Kontolimit andauern. Eine Sitzung darf das Kontolimit jedoch nicht unterschreiten. Weitere Informationen zu Sitzungslimits finden Sie unter AWS -Service Quotas.

MQTTgespeicherte Nachrichten

AWS IoT Core unterstützt das im MQTT Protokoll beschriebene RETAIN Flag. Wenn ein Client das RETAIN Flag für eine MQTT Nachricht setzt, die er veröffentlicht, wird die Nachricht AWS IoT Core gespeichert. Sie kann dann an neue Abonnenten gesendet, durch Aufrufen des GetRetainedMessageVorgangs abgerufen und in der AWS IoT Konsole angezeigt werden.

Beispiele für die Verwendung von MQTT gespeicherten Nachrichten

• Als erste Konfigurationsnachricht

  MQTTgespeicherte Nachrichten werden an einen Client gesendet, nachdem der Client ein Thema abonniert hat. Wenn Sie möchten, dass alle Clients, die ein Thema abonnieren, die MQTT beibehaltene Nachricht direkt nach ihrem Abonnement erhalten, können Sie eine Konfigurationsnachricht mit gesetzter RETAIN Markierung veröffentlichen. Abonnierende Clients erhalten außerdem Updates für diese Konfiguration, wenn eine neue Konfigurationsnachricht veröffentlicht wird.

• Als letzte bekannte Zustandsmeldung

  Geräte können Nachrichten mit dem aktuellen Status RETAIN kennzeichnen, sodass sie gespeichert AWS IoT Core werden. Wenn Anwendungen eine Verbindung herstellen oder erneut eine Verbindung herstellen, können sie dieses Thema abonnieren und sofort nach dem Abonnieren des beibehaltenen Nachrichtenthemas den zuletzt gemeldeten Status abrufen. Auf diese Weise können sie vermeiden, dass sie bis zur nächsten Meldung vom Gerät warten müssen, um den aktuellen Status zu sehen.

In diesem Abschnitt:

• Allgemeine Aufgaben mit MQTT gespeicherten Nachrichten in AWS IoT Core
• Abrechnung und gespeicherte Meldungen
• Vergleich von MQTT gespeicherten Nachrichten und dauerhaften Sitzungen MQTT
• MQTTBeibehaltene Nachrichten und Device Shadows AWS IoT

Allgemeine Aufgaben mit MQTT gespeicherten Nachrichten in AWS IoT Core

AWS IoT Core speichert MQTT Nachrichten mit RETAIN gesetzter Markierung. Diese gespeicherten Nachrichten werden als normale MQTT Nachricht an alle Clients gesendet, die das Thema abonniert haben, und sie werden auch gespeichert, um an neue Abonnenten des Themas gesendet zu werden.

MQTTFür gespeicherte Nachrichten sind spezifische Richtlinienmaßnahmen erforderlich, um Clients den Zugriff auf diese Nachrichten zu autorisieren. Beispiele für die Verwendung von Richtlinien für gespeicherte Meldungen finden Sie unter Beispielrichtlinien für beibehaltene Nachrichten.

In diesem Abschnitt werden allgemeine Vorgänge beschrieben, bei denen gespeicherte Meldungen verwendet werden.

• Erstellen einer beibehaltenen Nachricht

  Der Client bestimmt, ob eine Nachricht aufbewahrt wird, wenn er eine MQTT Nachricht veröffentlicht. Clients können das RETAIN Kennzeichen setzen, wenn sie eine Nachricht veröffentlichen, indem sie ein Gerät verwendenSDK. Anwendungen und Dienste können das RETAIN Kennzeichen setzen, wenn sie die PublishAktion zum Veröffentlichen einer MQTT Nachricht verwenden.

  Pro Themenname wird nur eine Meldung beibehalten. Eine neue Nachricht mit festgelegtem RETAIN Kennzeichen, die zu einem Thema veröffentlicht wurde, ersetzt alle vorhandenen beibehaltenen Nachrichten, die zuvor an das Thema gesendet wurden.

  NOTE: Sie können nicht zu einem reservierten Thema veröffentlichen, wenn das RETAIN Kennzeichen gesetzt ist.

• Abonnieren eines beibehaltenen Meldungsthemas

  Kunden abonnieren beibehaltene Nachrichtenthemen wie jedes andere MQTT Nachrichtenthema. Bei gespeicherten Nachrichten, die durch das Abonnieren eines beibehaltenen Nachrichtenthemas empfangen wurden, ist das RETAIN Kennzeichen gesetzt.

  Aufbewahrte Nachrichten werden gelöscht, AWS IoT Core sobald ein Client eine beibehaltene Nachricht mit einer 0-Byte-Nachrichtennutzlast zum Thema der beibehaltenen Nachricht veröffentlicht. Clients, die das beibehaltene Meldungsthema abonniert haben, erhalten auch die 0-Byte-Nachricht.

  Wenn Sie einen Wildcard-Themenfilter abonnieren, der ein aufbewahrtes Meldungsthema enthält, kann der Client nachfolgende Meldungen empfangen, die zum Thema der beibehaltenen Meldung veröffentlicht wurden, aber die beibehaltene Meldung wird beim Abonnement nicht zugestellt.

  NOTE: Um bei einem Abonnement eine gespeicherte Nachricht zu erhalten, muss der Themenfilter in der Abonnementanforderung exakt dem Thema der beibehaltenen Nachricht entsprechen.

  Bei gespeicherten Nachrichten, die beim Abonnieren eines Themas für eine beibehaltene Nachricht empfangen wurden, ist die RETAIN Markierung gesetzt. Bei gespeicherten Meldungen, die nach dem Abonnement von einem abonnierten Client empfangen werden, ist dies nicht der Fall.

• Eine beibehaltene Meldung wird abgerufen.

  Aufbewahrte Meldungen werden automatisch an Clients zugestellt, wenn sie das Thema mit der gespeicherten Meldung abonnieren. Damit ein Kunde die beibehaltene Meldung nach dem Abonnement erhalten kann, muss er den genauen Themennamen der gespeicherten Meldung abonnieren. Wenn Sie einen Wildcard-Themenfilter abonnieren, der ein aufbewahrtes Meldungsthema enthält, kann der Client nachfolgende Meldungen empfangen, die zum Thema der beibehaltenen Meldung veröffentlicht wurden, aber die beibehaltene Meldung wird beim Abonnement nicht zugestellt.

  Dienste und Apps können gespeicherte Meldungen auflisten und abrufen, indem sie ListRetainedMessagesund GetRetainedMessageaufrufen.

  Ein Client kann nicht daran gehindert werden, Nachrichten zu einem beibehaltenen Nachrichtenthema zu veröffentlichen, ohne die RETAIN Markierung zu setzen. Dies kann zu unerwarteten Ergebnissen führen, z. B. dass die gespeicherte Meldung nicht mit der Meldung übereinstimmt, die durch das Abonnieren des Themas empfangen wurde.

  Bei einem Wert von MQTT 5 erhält ein neuer Abonnent, der dieses Thema abonniert hat, die beibehaltene Nachricht nach erfolgreichem Abonnement nicht, wenn für eine beibehaltene Nachricht das Nachrichtenablaufintervall festgelegt ist und die beibehaltene Nachricht abläuft.

• Themen der beibehaltenen Meldungen auflisten

  Sie können die gespeicherten Meldungen auflisten, indem Sie ListRetainedMessages telefonisch abrufen, und die gespeicherten Meldungen können in der AWS IoT Konsole eingesehen werden.

• Details zu gespeicherten Meldungen abrufen

  Sie können die gespeicherten Meldungsdetails telefonisch unter GetRetainedMessage abrufen, und sie können in der AWS IoT Konsole angezeigt werden.

• Beibehaltung einer Willensnachricht

  MQTTKönnen Nachrichten, die erstellt werden, wenn ein Gerät eine Verbindung herstellt, beibehalten werden, indem die Will Retain Markierung im Connect Flag bits Feld gesetzt wird.

• Löschen einer beibehaltenen Nachricht

  Geräte, Anwendungen und Dienste können eine gespeicherte Nachricht löschen, indem sie eine Nachricht mit gesetzter RETAIN Markierung und einer leeren (0 Byte) Nachrichten-Payload zum Themennamen der gespeicherten Nachricht veröffentlichen, die gelöscht werden soll. Solche Nachrichten löschen die gespeicherte Nachricht von AWS IoT Core, werden an Clients gesendet, die das Thema abonniert haben, aber sie werden nicht von gespeichert. AWS IoT Core

  Beibehaltene Meldungen können auch interaktiv gelöscht werden, indem Sie in der AWS IoT Konsole auf die gespeicherte Meldung zugreifen. Archivierte Meldungen, die mithilfe der AWS IoT Konsole gelöscht werden, senden auch eine 0-Byte-Meldung an Clients, die das Thema der gespeicherten Meldung abonniert haben.

  Aufbewahrte Meldungen können nicht wiederhergestellt werden, nachdem sie gelöscht wurden. Ein Client müsste eine neue beibehaltene Meldung veröffentlichen, um die gelöschte Meldung zu ersetzen.

• Debuggen und Problembehandlung bei gespeicherten Meldungen

  Die AWS IoT Konsole bietet mehrere Tools, mit denen Sie Fehler bei gespeicherten Meldungen beheben können:

  • Die Seite „Zurückbehaltene Meldungen“

    Die Seite „Zurückbehaltene Meldungen“ in der AWS IoT Konsole enthält eine paginierte Liste der gespeicherten Meldungen, die von Ihrem Konto in der aktuellen Region gespeichert wurden. Auf dieser Seite können Sie:

    • Sehen Sie sich die Details jeder gespeicherten Meldung an, z. B. die Meldungsnutzlast, QoS und den Zeitpunkt, zu dem sie empfangen wurde.

    • Aktualisieren Sie den Inhalt einer gespeicherten Nachricht.

    • Löscht eine beibehaltene Nachricht.

  • Der MQTTTestclient

    Auf der MQTTTestclient-Seite in der AWS IoT Konsole können MQTT Themen abonniert und veröffentlicht werden. Mit der Veröffentlichungsoption können Sie die von Ihnen veröffentlichten Nachrichten RETAIN kennzeichnen, um zu simulieren, wie sich Ihre Geräte verhalten könnten.

  Einige unerwartete Ergebnisse können auf diese Aspekte der Implementierung von gespeicherten Nachrichten zurückzuführen sein AWS IoT Core.

  • Beibehaltene Meldungslimits

    Wenn ein Konto die maximale Anzahl an gespeicherten Nachrichten gespeichert hat, wird auf Nachrichten, die mit RETAIN festgelegten und nutzbaren Daten von mehr als 0 Byte veröffentlicht wurden, eine gedrosselte Antwort AWS IoT Core zurückgegeben, bis einige der gespeicherten Nachrichten gelöscht wurden und die Anzahl der gespeicherten Nachrichten unter den Grenzwert fällt.

  • Beibehaltene Reihenfolge der Meldungszustellung

    Die Reihenfolge zwischen beibehaltener und abonnierter Meldungszustellung kann nicht garantiert werden.

Abrechnung und gespeicherte Meldungen

Für das Veröffentlichen von Nachrichten mit RETAIN gesetzter Markierung auf einem Client, über die AWS IoT Konsole oder durch einen Anruf Publishfallen zusätzliche Gebühren für Nachrichtenübermittlung an, die unter Preise — Messaging beschrieben sind.AWS IoT Core

Für das Abrufen von gespeicherten Nachrichten durch einen Client, über die AWS IoT Konsole oder durch einen Anruf GetRetainedMessagefallen zusätzlich zu den normalen API Nutzungsgebühren Gebühren für Nachrichtenübermittlung an. Die zusätzlichen Gebühren sind unter AWS IoT Core Preise – Meldungsübermittlung beschrieben.

MQTTFallen für Nachrichten, die veröffentlicht werden, wenn die Verbindung zu einem Gerät unerwartet getrennt wird, Messaging-Gebühren an, die unter Preise — Messaging beschrieben sind?AWS IoT Core

Weitere Informationen zu den Messaging-Kosten finden Sie unter AWS IoT Core Preise – Meldungsübermittlung.

Vergleich von MQTT gespeicherten Nachrichten und dauerhaften Sitzungen MQTT

Beibehaltene Nachrichten und persistente Sitzungen sind StandardfunktionenMQTT, die es Geräten ermöglichen, Nachrichten zu empfangen, die veröffentlicht wurden, während sie offline waren. Aufbewahrte Meldungen können aus persistenten Sitzungen heraus veröffentlicht werden. In diesem Abschnitt werden die wichtigsten Aspekte dieser Funktionen und ihr Zusammenspiel beschrieben.

	Beibehaltene Meldungen	Persistente MQTT-Sitzungen
Schlüsselfunktionen	Aufbewahrte Meldungen können verwendet werden, um große Gruppen von Geräten zu konfigurieren oder zu benachrichtigen, nachdem sie eine Verbindung hergestellt haben. Aufbewahrte Meldungen können auch verwendet werden, wenn Geräte nach einer erneuten Verbindung nur die zuletzt zu einem Thema veröffentlichte Meldung empfangen sollen.	Dauerhafte Sitzungen sind nützlich für Geräte, deren Konnektivität unterbrochen ist und bei denen möglicherweise mehrere wichtige Meldungen übersehen werden. Geräte können sich mit einer dauerhaften Sitzung verbinden, um Meldungen zu empfangen, die gesendet werden, während sie offline sind.
Beispiele	Gespeicherte Meldungen können Geräten Konfigurationsinformationen über ihre Umgebung geben, wenn sie online gehen. Die Erstkonfiguration könnte eine Liste anderer Meldungsthemen enthalten, die das Gerät abonnieren sollte, oder Informationen darüber, wie es seine lokale Zeitzone konfigurieren sollte.	Geräte, die über ein Mobilfunknetz mit intermittierender Konnektivität eine Verbindung herstellen, könnten persistente Sitzungen verwenden, um zu verhindern, dass wichtige Meldungen verpasst werden, die gesendet werden, wenn ein Gerät nicht mit Netzempfang versorgt ist oder sein Mobilfunknetz ausgeschaltet werden muss.
Meldungen, die beim ersten Abonnement eines Themas eingegangen sind	Nach dem Abonnieren eines Themas mit einer beibehaltenen Meldung wird die neueste beibehaltene Meldung empfangen.	Nach dem Abonnieren eines Themas ohne beibehaltene Meldung wird keine Meldung empfangen, bis eine Meldung zu dem Thema veröffentlicht wird.
Abonnierte Themen nach dem erneuten Verbindungsaufbau	Ohne eine dauerhafte Sitzung muss der Client nach der Wiederverbindung Themen abonnieren.	Abonnierte Themen werden nach der Wiederverbindung wiederhergestellt.
Nach der Wiederverbindung empfangene Meldungen	Nach dem Abonnieren eines Themas mit einer beibehaltenen Meldung wird die neueste beibehaltene Meldung empfangen.	Alle Nachrichten, die mit a QOS = 1 veröffentlicht und mit a QOS = 1 abonniert wurden, während das Gerät getrennt war, werden gesendet, nachdem das Gerät wieder eine Verbindung hergestellt hat.
Sitzungsablauf	Bei MQTT 3 laufen gespeicherte Nachrichten nicht ab. Sie werden gespeichert, bis sie ersetzt oder gelöscht werden. In MQTT 5 Fällen laufen die gespeicherten Nachrichten nach dem von Ihnen festgelegten Nachrichtenablaufintervall ab. Weitere Informationen finden Sie unter Message templates (Meldungsvorlagen).	Persistente Sitzungen laufen ab, wenn der Client innerhalb des Timeout-Zeitraums keine erneute Verbindung herstellt. Nach Ablauf einer dauerhaften Sitzung werden die Abonnements und gespeicherten Nachrichten des Clients gelöscht, die mit a QOS = 1 veröffentlicht und mit a QOS = 1 abonniert wurden, während das Gerät getrennt war. Abgelaufene Meldungen werden nicht zugestellt. Weitere Hinweise zum Ablauf von Sitzungen mit persistenten Sitzungen finden Sie unter MQTTpersistente Sitzungen.

Informationen zu persistentem Speicher siehe MQTTpersistente Sitzungen.

Bei Retained Messages bestimmt der Publishing-Client, ob eine Meldung aufbewahrt und an ein Gerät gesendet werden soll, nachdem das Gerät eine Verbindung hergestellt hat, unabhängig davon, ob es eine vorherige Sitzung hatte oder nicht. Die Entscheidung, eine Meldung zu speichern, wird vom Herausgeber getroffen, und die gespeicherte Meldung wird an alle aktuellen und zukünftigen Clients zugestellt, die ein Abonnement für QoS 0 oder QoS 1 abgeschlossen haben. Bei gespeicherten Meldungen wird jeweils nur eine Meldung zu einem bestimmten Thema gespeichert.

Wenn ein Konto die maximale Anzahl an gespeicherten Nachrichten gespeichert hat, wird auf Nachrichten, die mit RETAIN festgelegten Payloads von mehr als 0 Byte veröffentlicht wurden, eine gedrosselte Antwort AWS IoT Core zurückgegeben, bis einige der gespeicherten Nachrichten gelöscht wurden und die Anzahl der gespeicherten Nachrichten unter den Grenzwert fällt.

MQTTBeibehaltene Nachrichten und Device Shadows AWS IoT

Sowohl bei gespeicherten Meldungen als auch bei Geräteschatten werden Daten von einem Gerät gespeichert, sie verhalten sich jedoch unterschiedlich und dienen unterschiedlichen Zwecken. In diesem Abschnitt werden ihre Ähnlichkeiten und Unterschiede beschrieben.

	Beibehaltene Meldungen	Geräteschatten
Die Meldungsnutzlast hat eine vordefinierte Struktur oder ein vordefiniertes Schema.	Wie in der Implementierung definiert. MQTTspezifiziert keine Struktur oder kein Schema für seine Nachrichtennutzdaten.	AWS IoT unterstützt eine bestimmte Datenstruktur.
Durch die Aktualisierung der Meldungsnutzlast werden Ereignismeldungen generiert.	Durch das Veröffentlichen einer gespeicherten Meldung wird die Meldung an abonnierte Clients gesendet, es werden jedoch keine zusätzlichen Aktualisierungsnachrichten generiert.	Beim Aktualisieren eines Geräteschattens werden Aktualisierungsmeldungen angezeigt, die die Änderung beschreiben.
Meldungsaktualisierungen sind nummeriert.	Aufbewahrte Meldungen werden nicht automatisch nummeriert.	Geräteschatten-Dokumente haben automatische Versionsnummern und Zeitstempel.
Die Meldungen-Payload ist an eine Ding-Ressource angehängt.	Beibehaltene Meldungen sind nicht an eine Ding-Ressource angehängt.	Geräteschatten sind an eine Ding-Ressource angehängt.
Einzelne Elemente der Meldungs-Payload werden aktualisiert.	Einzelne Elemente der Meldung können nicht geändert werden, ohne die gesamte Meldungsnutzlast zu aktualisieren.	Einzelne Elemente eines Geräteschatten-Dokuments können aktualisiert werden, ohne dass das gesamte Geräteschatten-Dokument aktualisiert werden muss.
Der Kunde erhält Meldungsdaten bei Abschluss des Abonnements.	Der Kunde erhält automatisch eine gespeicherte Nachricht, nachdem er ein Thema mit einer gespeicherten Meldung abonniert hat.	Clients können Geräteschatten-Updates abonnieren, müssen den aktuellen Status jedoch bewusst anfordern.
Indizierung und Durchsuchbarkeit	Zurückbehaltene Meldungen werden nicht für die Suche indexiert.	Flottenindizierung indexiert Geräteschatten-Daten für die Suche und Aggregation.

MQTTBotschaften des letzten Willens und des Testaments (LWT)

Der letzte Wille und das Testament (LWT) sind ein Feature inMQTT. Mit können Kunden eine Nachricht angebenLWT, die der Broker zu einem vom Kunden definierten Thema veröffentlicht und an alle Kunden sendet, die das Thema abonniert haben, wenn die Verbindung nicht initiiert wird. Die von den Clients angegebene Nachricht wird als LWT Nachricht oder Will-Nachricht bezeichnet, und das von den Clients definierte Thema wird Will-Thema genannt. Sie können eine LWT Nachricht angeben, wenn ein Gerät eine Verbindung zum Broker herstellt. Diese Meldungen können beibehalten werden, indem während der Verbindung die Will Retain Markierung im Connect Flag bits Feld gesetzt wird. Wenn die Will Retain Markierung beispielsweise auf 1 gesetzt ist, wird eine Will-Meldung im Broker im zugehörigen Testament-Thema gespeichert. Weitere Informationen finden Sie unter Meldungsvorlagen.

Der Broker speichert die Will-Meldungen, bis es zu einer uninitiierten Verbindungsunterbrechung kommt. In diesem Fall veröffentlicht der Broker die Meldungen an alle Clients, die das Will-Thema abonniert haben, um den Verbindungsabbruch zu melden. Wenn der Client die Verbindung zum Broker mit einer vom Client initiierten Verbindungsunterbrechung anhand der MQTT DISCONNECT Nachricht trennt, veröffentlicht der Broker die gespeicherten Nachrichten nicht. LWT In allen anderen Fällen werden die LWT Nachrichten versendet. Eine vollständige Liste der Verbindungsszenarien, in denen der Broker die LWT Nachrichten sendet, finden Sie unter Connect/Disconnect events.

Verwenden connectAttributes

ConnectAttributesermöglichen es Ihnen, in Ihren IAM Richtlinien anzugeben, welche Attribute Sie in Ihrer Verbindungsnachricht verwenden möchten, z. B. PersistentConnect undLastWill. Mit ConnectAttributes können Sie Richtlinien erstellen, die Geräten standardmäßig keinen Zugriff auf neue Funktionen gewähren. Dies kann hilfreich sein, wenn ein Gerät kompromittiert wurde.

connectAttributes unterstützt die folgenden Funktionen:

PersistentConnect

Verwenden Sie die PersistentConnect Funktion, um alle Abonnements zu speichern, die der Client während der Verbindung abschließt, wenn die Verbindung zwischen dem Client und dem Broker unterbrochen wird.

LastWill

Verwenden Sie die LastWill Funktion, um eine Meldung an LastWillTopic zu veröffentlichen, wenn ein Client unerwartet die Verbindung trennt.

Standardmäßig hat Ihre Richtlinie eine nicht persistente Verbindung, und für diese Verbindung werden keine Attribute übergeben. Sie müssen in Ihrer IAM Richtlinie eine persistente Verbindung angeben, wenn Sie eine haben möchten.

ConnectAttributesBeispiele finden Sie unter Beispiele für Connect-Richtlinien.

MQTT5 unterstützte Funktionen

AWS IoT Core Die Unterstützung für MQTT 5 basiert auf der MQTTv5.0-Spezifikation mit einigen Unterschieden, die unter dokumentiert sind. AWS IoT Unterschiede zu den MQTT Spezifikationen

AWS IoT Core unterstützt die folgenden MQTT 5 Funktionen:

• Geteilte Abonnements
• Clean Start und Ablauf der Sitzung
• Ursachencode für alle ACKs
• Themen-Aliase
• Ablauf der Nachricht
• Weitere MQTT 5 Funktionen

Geteilte Abonnements

AWS IoT Core unterstützt gemeinsame Abonnements für MQTT 3 und MQTT 5. Geteilte Abonnements ermöglichen es mehreren Clients, ein Abonnement für ein Thema gemeinsam zu nutzen, und nur ein Client erhält Meldungen, die zu diesem Thema veröffentlicht wurden, nach dem Zufallsprinzip. Mit geteilten Abonnements können MQTT Nachrichten effektiv auf mehrere Abonnenten verteilt werden. Nehmen wir zum Beispiel an, Sie haben 1.000 Geräte, die zum gleichen Thema veröffentlichen, und 10 Backend-Anwendungen, die diese Meldungen verarbeiten. In diesem Fall können die Backend-Anwendungen dasselbe Thema abonnieren und jede Anwendung würde nach dem Zufallsprinzip Meldungen empfangen, die von den Geräten zu dem gemeinsamen Thema veröffentlicht wurden. Auf diese Weise wird die Menge dieser Meldungen quasi „geteilt“. Geteilte Abonnements ermöglichen auch eine bessere Ausfallsicherheit. Wenn eine Back-End-Anwendung die Verbindung trennt, verteilt der Broker die Last auf die verbleibenden Abonnenten in der Gruppe.

Um gemeinsame Abonnements zu verwenden, abonnieren Kunden den Themenfilter eines gemeinsamen Abonnements wie folgt:

$share/{ShareName}/{TopicFilter}

• $share ist eine wörtliche Zeichenfolge, die den Themenfilter eines geteilten Abonnements angibt, der mit $share beginnen muss.

• {ShareName} ist eine Zeichenfolge zur Angabe des gemeinsamen Namens, der von einer Gruppe von Abonnenten verwendet wird. Der Themenfilter eines geteilten Abonnements muss ein ShareName und gefolgt von einem / Zeichen enthalten. {ShareName} darf die folgenden Zeichen nicht enthalten: /,+ oder#. Die maximale Hash-Schlüsselgröße für {ShareName} ist 128 Byte.

• {TopicFilter} folgt derselben Themenfiltersyntax wie ein Abonnement ohne gemeinsame Nutzung. Die maximale Hash-Schlüsselgröße für {TopicFilter} ist 256 Byte.

• Die beiden erforderlichen Schrägstriche (/) für $share/{ShareName}/{TopicFilter} sind nicht in den Grenzwerten „Maximale Anzahl von Schrägstrichen im Thema“ und „Themenfilter“ enthalten.

Abonnements, die dasselbe {ShareName}/{TopicFilter} haben, gehören derselben gemeinsamen Abonnementgruppe an. Sie können mehrere Gruppen gemeinsam genutzter Abonnements erstellen und dabei das Limit für gemeinsame Abonnements pro Gruppe nicht überschreiten. Weitere Informationen finden Sie unter AWS IoT Core -Endpunkte und -Kontingente in der AWS Allgemeinen Referenz.

In den folgenden Tabellen werden nicht gemeinsam genutzte Abonnements und geteilte Abonnements verglichen:

Abonnement	Beschreibung	Beispiele für Metrikfilter
Nicht gemeinsam genutzte Abonnements	Jeder Client erstellt ein separates Abonnement für den Empfang der veröffentlichten Meldungen. Wenn eine Meldung zu einem Thema veröffentlicht wird, erhalten alle Abonnenten dieses Themas eine Kopie der Nachricht.	sports/tennis sports/#
Geteilte Abonnements	Mehrere Kunden können sich ein Abonnement für ein Thema teilen, und nur ein Kunde erhält Meldungen, die zu diesem Thema veröffentlicht wurden, nach dem Zufallsprinzip.	$share/consumer/sports/tennis $share/consumer/sports/#

Es werden nicht gemeinsam genutzte Abonnements angeboten.	Ablauf geteilter Abonnements

Wichtige Hinweise zur Verwendung von geteilten Abonnements

• Wenn ein Veröffentlichungsversuch für einen QoS0-Abonnenten fehlschlägt, erfolgt kein erneuter Versuch, und die Meldung wird gelöscht.

• Wenn ein Veröffentlichungsversuch für einen QoS1-Abonnenten mit sauberer Sitzung fehlschlägt, wird die Meldung an einen anderen Abonnenten in der Gruppe für mehrere Wiederholungsversuche gesendet. Meldungen, die nach allen Wiederholungsversuchen nicht zugestellt werden können, werden verworfen.

• Wenn ein Veröffentlichungsversuch für einen QoS1-Abonnenten mit persistenten Sitzungen fehlschlägt, weil der Abonnent offline ist, werden die Meldungen nicht in die Warteschlange gestellt, sondern an einen anderen Abonnenten in der Gruppe weitergeleitet. Meldungen, die nach allen Wiederholungsversuchen nicht zugestellt werden können, werden verworfen.

• Geteilte Abonnements empfangen keine gespeicherten Meldungen.

• Wenn gemeinsame Abonnements Platzhalterzeichen (# oder +) enthalten, gibt es möglicherweise mehrere übereinstimmende gemeinsame Abonnements zu einem Thema. In diesem Fall kopiert der Message Broker die Veröffentlichungsnachricht und sendet sie in jedem passenden gemeinsamen Abonnement an einen zufälligen Client. Das Platzhalterverhalten von gemeinsamen Abonnements kann in der folgenden Abbildung erklärt werden.

  

  In diesem Beispiel gibt es drei passende gemeinsame Abonnements für das MQTT Veröffentlichungsthemasports/tennis. Der Message Broker kopiert die veröffentlichte Meldung und sendet die Meldung an einen zufälligen Client in jeder passenden Gruppe.

  Kunde 1 und Kunde 2 teilen sich das Abonnement: $share/consumer1/sports/tennis

  Kunde 3 und Kunde 4 teilen sich das Abonnement: $share/consumer1/sports/#

  Kunde 5 und Kunde 6 teilen sich das Abonnement: $share/consumer2/sports/tennis

Weitere Informationen zu den Limits für gemeinsame Abonnements finden Sie unter AWS IoT Core Endpunkte und Kontingente in der AWS Allgemeinen Referenz. Informationen zum Testen geteilter Abonnements mithilfe des AWS IoT MQTT Clients in der AWS IoT Konsole finden Sie unterGeteilte Abonnements im Client testen MQTT. Weitere Informationen zu gemeinsamen Abonnements finden Sie unter Gemeinsame Abonnements aus der MQTTv5 2.0-Spezifikation.

Clean Start und Ablauf der Sitzung

Sie können Clean Start und Session Expiry verwenden, um Ihre persistenten Sitzungen flexibler zu handhaben. Ein Clean Start-Flag gibt an, ob die Sitzung gestartet werden soll, ohne eine bestehende Sitzung zu verwenden. Ein Sitzungsablaufintervall gibt an, wie lange die Sitzung nach einer Unterbrechung beibehalten werden soll. Das Ablaufintervall für die Sitzung kann bei der Trennung geändert werden. Weitere Informationen finden Sie unter MQTTpersistente Sitzungen.

Ursachencode für alle ACKs

Mithilfe der Ursachencodes können Sie Fehlermeldungen einfacher debuggen oder verarbeiten. Ursachencodes werden vom Message Broker auf der Grundlage der Art der Interaktion mit dem Broker zurückgegeben (Abonnieren, Veröffentlichen, Bestätigen). Weitere Informationen finden Sie unter MQTTUrsachencodes. Eine vollständige Liste der MQTT Ursachencodes finden Sie in der MQTTv5-Spezifikation.

Themen-Aliase

Sie können einen Themennamen durch einen Themenalias ersetzen, bei dem es sich um eine Zwei-Byte-Ganzzahl handelt. Durch die Verwendung von Topic-Aliasnamen kann die Übertragung von Themennamen optimiert und so potenziell die Datenkosten für Datendienste gesenkt werden. AWS IoT Core hat ein Standardlimit von 8 Themenaliasnamen. Weitere Informationen finden Sie unter AWS IoT Core -Endpunkte und -Kontingente in der AWS Allgemeinen Referenz.

Ablauf der Nachricht

Sie können veröffentlichten Meldungen Werte für den Ablauf von Meldungen hinzufügen. Diese Werte stellen das Meldungsablaufintervall in Sekunden dar. Wenn die Meldungen innerhalb dieses Intervalls nicht an die Abonnenten gesendet wurden, läuft die Meldung ab und wird entfernt. Wenn Sie den Wert für das Verfallsdatum der Meldung nicht festlegen, läuft die Meldung nicht ab.

Beim ausgehenden Versand erhält der Abonnent eine Meldung mit der verbleibenden Restzeit des Ablaufintervalls. Wenn beispielsweise eine eingehende Veröffentlichungsnachricht einen Meldungsablauf von 30 Sekunden hat und sie nach 20 Sekunden an den Abonnenten weitergeleitet wird, wird das Feld für den Ablauf der Meldung auf 10 aktualisiert. Es ist möglich, dass die vom Abonnenten empfangene Nachricht auf 0 aktualisiert MEI wird. Dies liegt daran, dass sie auf 0 aktualisiert wird, sobald die verbleibende Zeit 999 ms oder weniger beträgt.

In AWS IoT Core, das Mindestablaufintervall für Nachrichten ist 1. Wenn das Intervall auf der Clientseite auf 0 gesetzt ist, wird es auf 1 eingestellt. Das maximale Verfallsintervall für Meldungen beträgt 604800 (7 Tage). Alle Werte, die über diesem Wert liegen, werden an den Maximalwert angepasst.

Bei der versionsübergreifenden Kommunikation hängt das Verhalten des Ablaufs der Nachricht von der MQTT Version der eingehenden Veröffentlichungsnachricht ab. Beispielsweise MQTT5 kann eine Nachricht mit Ablauf der Nachricht, die von einer Sitzung gesendet wurde, über die eine Verbindung hergestellt wurde, für Geräte, die über Sitzungen abonniert wurden, ablaufen. MQTT3 In der folgenden Tabelle ist aufgeführt, wie der Ablauf von Meldungen die folgenden Arten von Veröffentlichungsnachrichten unterstützt:

Veröffentlichen eines Meldungstyps	Ablaufintervall für Meldungen
Reguläres Veröffentlichen	Wenn ein Server die Meldung nicht innerhalb der angegebenen Zeit zustellt, wird die abgelaufene Meldung entfernt und der Abonnent erhält sie nicht. Dies schließt Situationen ein, z. B. wenn ein Gerät seine QoS 1-Meldungen nicht veröffentlicht.
Beibehalten	Wenn eine gespeicherte Meldung abläuft und ein neuer Kunde das Thema abonniert, erhält der Client die Meldung nach Abschluss des Abonnements nicht.
Letzter Wille	Das Intervall für Meldungen des letzten Willens beginnt, nachdem der Client die Verbindung getrennt hat und der Server versucht, seinen Abonnenten die letzte Willensnachricht zuzustellen.
In die Warteschlange eingestellte Meldungen	Wenn ein ausgehender QoS1-Dienst mit Meldungsablaufintervall abläuft, während ein Client offline ist, empfängt der Client nach der Wiederaufnahme der persistenten Sitzung die abgelaufene Meldung nicht.

Weitere MQTT 5 Funktionen

Verbindung zum Server trennen

Wenn eine Verbindung unterbrochen wird, kann der Server dem Client proaktiv eine Benachrichtigung über den Verbindungsabbruch mit einem DISCONNECT Ursachencode für die Unterbrechung senden.

Request Response (Antwort anfordern)

Verlage können verlangen, dass der Empfänger nach Erhalt eine Antwort auf ein vom Verlag spezifiziertes Thema sendet.

Maximale Teilegröße

Client und Server können unabhängig voneinander die maximale Paketgröße angeben, die sie unterstützen.

Payload-Format und Inhaltstyp

Sie können das Payload-Format (Binär, Text) und den Inhaltstyp angeben, wenn eine Meldung veröffentlicht wird. Diese werden an den Empfänger der Meldung weitergeleitet.

MQTT5 Eigenschaften

MQTT5 Eigenschaften sind wichtige Ergänzungen des MQTT Standards zur Unterstützung neuer MQTT 5 Funktionen wie Sitzungsablauf und Anforderungs-/Antwortmuster. In können Sie Regeln erstellen AWS IoT Core, mit denen die Eigenschaften ausgehender Nachrichten weitergeleitet werden können, oder HTTPVeröffentlichen verwenden, um MQTT Nachrichten mit einigen der neuen Eigenschaften zu veröffentlichen.

In der folgenden Tabelle sind alle MQTT 5 Eigenschaften aufgeführt, die AWS IoT Core unterstützt werden.

Property (Eigenschaft)	Description (Beschreibung)	Eingabetyp	packets
Nutzlastformatindikator Nutzlastnutzlast	Ein boolescher Wert, der angibt, ob die Payload als -8 formatiert ist. UTF	Byte	PUBLISH, CONNECT
Inhaltstyp	Eine Zeichenfolge mit UTF -8, die den Inhalt der Payload beschreibt.	UTF-8 Zeichenfolge	PUBLISH, CONNECT
Thema der Antwort	Eine Zeichenfolge von UTF -8, die das Thema beschreibt, zu dem der Empfänger im Rahmen des Anfrage-Antwort-Ablaufs veröffentlichen soll. Das Thema darf keine Platzhalterzeichen enthalten.	UTF-8 Zeichenfolge	PUBLISH, CONNECT
Korrelationsdaten	Binärdaten, die vom Absender der Anforderungsnachricht verwendet werden, um zu identifizieren, für welche Anfrage die Antwortnachricht bestimmt ist.	Binär	PUBLISH, CONNECT
Benutzereigenschaften	Ein Paar mit UTF -8 Zeichenketten. Diese Eigenschaft kann in einem Paket mehrfach vorkommen. Die Empfänger empfangen die Schlüssel-Wert-Paare in derselben Reihenfolge, in der sie gesendet wurden.	UTFPaar mit -8 Zeichenketten	CONNECT,PUBLISH, Will Properties,SUBSCRIBE, DISCONNECT UNSUBSCRIBE
Ablaufintervall für Meldungen	Eine 4-Byte-Ganzzahl, die das Verfallsintervall der Meldung in Sekunden darstellt. Wenn nicht vorhanden, läuft die Meldung nicht ab.	4-Byte-Ganzzahl	PUBLISH, CONNECT
Ablaufintervall der Sitzung	Eine 4-Byte-Ganzzahl, die das Sitzungsablaufintervall in Sekunden darstellt. AWS IoT Core unterstützt maximal 7 Tage, mit einem standardmäßigen Maximum von einer Stunde. Wenn der von Ihnen festgelegte Wert das Maximum Ihres Kontos überschreitet, AWS IoT Core wird der angepasste Wert in der zurückgegebenCONNACK.	4-Byte-Ganzzahl	CONNECT, CONNACK, DISCONNECT
Zugewiesene Client-ID	Eine zufällige Client-ID, die generiert wird AWS IoT Core , wenn eine Client-ID nicht von Geräten angegeben wird. Bei der zufälligen Client-ID muss es sich um eine neue Client-ID handeln, die von keiner anderen Sitzung verwendet wird, die derzeit vom Broker verwaltet wird.	UTF-8 Zeichenfolge	CONNACK
Server Keep Alive	Eine 2-Byte-Ganzzahl, die die vom Server zugewiesene Keep-Alive-Zeit darstellt. Der Server trennt die Verbindung zum Client, wenn der Client länger als die Keep-Alive-Zeit inaktiv ist.	2-Byte-Ganzzahl	CONNACK
Probleminformationen anfordern	Ein boolescher Wert, der angibt, ob die Ursachenzeichenfolge oder die Benutzereigenschaften bei Fehlern gesendet werden.	Byte	CONNECT
Maximal empfangen	Eine 2-Byte-Ganzzahl, die die maximale Anzahl von PUBLISH QOS > 0 Paketen darstellt, die gesendet werden können, ohne eine zu empfangen. PUBACK	2-Byte-Ganzzahl	CONNECT, CONNACK
Thema Alias Maximum	Dieser Wert gibt den höchsten Wert an, der als Themen-Alias akzeptiert wird. Standard = 0.	2-Byte-Ganzzahl	CONNECT, CONNACK
Maximale QoS	Der maximale Wert von QoS, der AWS IoT Core unterstützt wird. Der Standardwert lautet 1. AWS IoT Core unterstützt QoS2 nicht.	Byte	CONNACK
Beibehaltung verfügbar	Ein boolescher Wert, der angibt, ob der AWS IoT Core Message Broker beibehaltene Nachrichten unterstützt. Der Standardwert ist 1.	Byte	CONNACK
Maximale Teilegröße	Die maximale Paketgröße, die AWS IoT Core akzeptiert und gesendet wird. Kann 128 KB nicht überschreiten.	4-Byte-Ganzzahl	CONNECT, CONNACK
Wildcard-Abonnement verfügbar	Ein boolescher Wert, der angibt, ob der AWS IoT Core Message Broker Wildcard Subscription Available unterstützt. Der Standardwert ist 1.	Byte	CONNACK
Abonnement-ID verfügbar	Ein boolescher Wert, der angibt, ob der AWS IoT Core Message Broker Subscription Identifier Available unterstützt. Der Standardwert ist 0.	Byte	CONNACK

MQTTUrsachencodes

MQTT5 führt eine verbesserte Fehlerberichterstattung mit Antworten auf Ursachencodes ein. AWS IoT Core kann Ursachencodes zurückgeben, einschließlich, aber nicht beschränkt auf die folgenden, gruppiert nach Paketen. Eine vollständige Liste der von MQTT 5 unterstützten Ursachencodes finden Sie in den Spezifikationen für MQTT 5.

CONNACKUrsachencodes

Wert	HEX()	Name des Grundcodes	Beschreibung
0	0x00	Herzlichen Glückwunsch	Die Verbindung wurde akzeptiert.
128	0x80	Unbekannter Fehler	Der Server möchte den Grund für den Fehler nicht preisgeben, oder keiner der anderen Ursachencodes trifft zu.
133	0x85	Die Client-ID ist nicht gültig.	Die Client-ID ist eine gültige Zeichenfolge, die jedoch vom Server nicht zugelassen wird.
134	0x86	Falscher Benutzername oder falsches Passwort	Der Server akzeptiert den vom Client angegebenen Benutzernamen oder das Passwort nicht.
135	0x87	Nicht autorisiert.	Der Client ist nicht autorisiert, eine Verbindung herzustellen.
144	0x90	Themenname ungültig	Der Name des Will-Themas ist korrekt formatiert, wird aber vom Server nicht akzeptiert.
151	0 x 97	Kontingent überschritten	Ein von der Implementierung oder vom Administrator auferlegtes Limit wurde überschritten.
155	0 x 9 B	QoS nicht unterstützt	Der Server unterstützt die in Will QoS eingestellte QoS nicht.

PUBACKUrsachencodes

Wert	HEX()	Name des Grundcodes	Beschreibung
0	0x00	Herzlichen Glückwunsch	Die Meldung wurde akzeptiert. Die Veröffentlichung der QoS 1-Meldung wird fortgesetzt.
128	0x80	Unbekannter Fehler	Der Empfänger akzeptiert die Veröffentlichung nicht, möchte aber entweder den Grund nicht preisgeben, oder er entspricht keinem der anderen Werte.
135	0x87	Nicht autorisiert.	Das PUBLISH ist nicht autorisiert.
144	0x90	Themenname ungültig	Der Themenname ist nicht falsch formatiert, wird aber vom Client oder Server nicht akzeptiert.
145	0x91	Paket-ID wird verwendet.	Die Paket-ID wird bereits verwendet. Dies könnte auf eine Nichtübereinstimmung des Sitzungsstatus zwischen Client und Server hinweisen.
151	0 x 97	Kontingent überschritten	Ein von der Implementierung oder vom Administrator auferlegtes Limit wurde überschritten.

DISCONNECTUrsachencodes

Wert	HEX()	Name des Grundcodes	Beschreibung
129	0x81	Fehlerhaftes Paket	Das empfangene Paket entspricht nicht dieser Spezifikation.
130	0x82	Protokollfehler	Ein unerwartetes Paket oder ein Paket, das nicht in der richtigen Reihenfolge ist, wurde empfangen.
135	0x87	Nicht autorisiert.	Die Anfrage ist nicht autorisiert.
139	0x8B	Server wird heruntergefahren.	Der Server wird heruntergefahren.
141	0x8D	Keep Alive Timeout	Die Verbindung wurde geschlossen, weil seit dem 1,5-fachen der Keep-Alive-Zeit kein Paket mehr empfangen wurde.
142	0x8E	Sitzung übernommen	Eine andere Verbindung, die dieselbe Client-ID verwendet, hat eine Verbindung hergestellt, wodurch diese Verbindung geschlossen wurde.
143	0x8F	Ungültiger Themenfilter	Der Themenfilter ist korrekt formatiert, wird aber vom Server nicht akzeptiert.
144	0x90	Themenname ungültig	Der Themenname ist korrekt formatiert, wird aber von diesem Client oder Server nicht akzeptiert.
147	0 x 93	Empfangsmaximum überschritten	Der Client oder Server hat mehr als die Empfangsmaximum-Publikation erhalten, für die er PUBACK oder nicht gesendet hatPUBCOMP.
148	0 x 94	Ungültiges Thema-Alias	Der Client oder Server hat ein PUBLISH Paket empfangen, das einen Themen-Alias enthält, der größer ist als die maximale Anzahl an Themen-Alias, die er im CONNACK Paket CONNECT oder gesendet hat.
151	0 x 97	Kontingent überschritten	Ein von der Implementierung oder vom Administrator auferlegtes Limit wurde überschritten.
152	0x98	Administrative Maßnahmen	Die Verbindung wurde aufgrund einer Verwaltungsmaßnahme geschlossen.
155	0 x 9 B	QoS nicht unterstützt	Der Client hat eine höhere QoS als die QoS angegeben, die in einem Maximum QoS in der angegeben ist. CONNACK
161	0 x A1	Abonnement-Identifikatoren werden nicht unterstützt.	Der Server unterstützt keine Abonnement-IDs. Das Abonnement wird nicht akzeptiert.

SUBACKUrsachencodes

Wert	HEX()	Name des Grundcodes	Beschreibung
0	0x00	QoS gewährt 0	Das Abonnement wurde akzeptiert, und die maximale gesendete QoS beträgt QoS 0. Dies könnte eine niedrigere QoS sein als gewünscht.
1	0x01	QoS 1 gewährt 1	Das Abonnement wurde akzeptiert, und die maximale gesendete QoS beträgt QoS 1. Dies könnte eine niedrigere QoS sein als gewünscht.
128	0x80	Unbekannter Fehler	Das Abonnement wurde nicht akzeptiert, und der Server möchte den Grund entweder nicht preisgeben oder keiner der anderen Ursachencodes trifft zu.
135	0x87	Nicht autorisiert.	Der Kunde ist nicht berechtigt, dieses Abonnement abzuschließen.
143	0x8F	Ungültiger Themenfilter	Der Themenfilter ist korrekt formatiert, ist aber für diesen Client nicht zulässig.
145	0x91	Paket-ID wird verwendet.	Die angegebene Paket-ID wird bereits verwendet.
151	0 x 97	Kontingent überschritten	Ein von der Implementierung oder vom Administrator auferlegtes Limit wurde überschritten.

UNSUBACKUrsachencodes

Wert	HEX()	Name des Grundcodes	Beschreibung
0	0x00	Herzlichen Glückwunsch	Das Abonnement wird gelöscht.
128	0x80	Unbekannter Fehler	Die Abmeldung konnte nicht abgeschlossen werden, und der Server möchte den Grund entweder nicht preisgeben oder keiner der anderen Ursachencodes trifft zu.
143	0x8F	Ungültiger Themenfilter	Der Themenfilter ist korrekt formatiert, ist aber für diesen Client nicht zulässig.
145	0x91	Paket-ID wird verwendet.	Die angegebene Paket-ID wird bereits verwendet.

AWS IoT Unterschiede zu den MQTT Spezifikationen

Die Message Broker-Implementierung basiert auf der MQTTv3.1.1-Spezifikation und der MQTTv5.0-Spezifikation, unterscheidet sich jedoch in folgenden Punkten von den Spezifikationen:

• AWS IoT unterstützt die folgenden Pakete für MQTT 3 nicht:PUBREC, undPUBREL. PUBCOMP

• AWS IoT unterstützt die folgenden Pakete für MQTT 5 nicht: PUBRECPUBREL,PUBCOMP, undAUTH.

• AWS IoT unterstützt keine MQTT 5-Server-Umleitung.

• AWS IoT unterstützt nur die MQTT Quality-of-Service-Stufen (QoS) 0 und 1. AWS IoT unterstützt das Veröffentlichen oder Abonnieren mit QoS Level 2 nicht. Wenn QoS Level 2 angefordert wird, sendet der Message Broker kein PUBACK OderSUBACK.

• In AWS IoT bedeutet das Abonnieren eines Themas mit QoS-Stufe 0, dass eine Nachricht null Mal oder öfter zugestellt wird. Meldungen können mehr als einmal übertragen werden. Meldungen, die mehrmals übertragen werden, können mit unterschiedlicher Paket-ID gesendet werden. In diesen Fällen ist die DUP Markierung nicht gesetzt.

• Bei der Beantwortung einer Verbindungsanfrage sendet der Message Broker eine CONNACK Nachricht. Diese enthält ein Flag, das angibt, ob eine frühere Sitzung wieder aufgenommen wird.

• Bevor der Client zusätzliche Steuerpakete oder eine Anfrage zum Trennen der Verbindung sendet, muss er warten, bis die CONNACK Nachricht vom AWS IoT Message Broker auf seinem Gerät eingeht.

• Wenn ein Client ein Thema abonniert, kann es zu einer Verzögerung zwischen dem Zeitpunkt kommen, zu dem der Nachrichtenbroker eine Nachricht sendet, SUBACK und dem Zeitpunkt, zu dem der Client beginnt, neue passende Nachrichten zu empfangen.

• Wenn ein Client das Platzhalterzeichen # im Themenfilter verwendet, um ein Thema zu abonnieren, werden alle Zeichenfolgen auf und unter seiner Ebene in der Themenhierarchie abgeglichen. Das übergeordnete Thema stimmt jedoch nicht überein. Wenn Sie beispielsweise das Thema sensor/# abonnieren, erhalten Sie Meldungen, die für sensor/, sensor/temperature oder sensor/temperature/room1 veröffentlicht werden, nicht jedoch Meldungen, die für sensor veröffentlicht werden. Weitere Informationen zu Platzhaltern unter Themenfilter.

• Der Message Broker verwendet die Client-ID, um die einzelnen Clients zu identifizieren. Die Client-ID wird als Teil der MQTT Nutzlast vom Client an den Message Broker weitergegeben. Zwei Clients mit identischen Client-IDs können nicht gleichzeitig mit dem Message Broker verbunden sein. Stellt ein Client eine Verbindung zum Message Broker über eine Client-ID her, die bereits von einem anderen Client verwendet wird, wird die neue Client-Verbindung akzeptiert und die Verbindung des früher verbundenen Clients getrennt.

• In seltenen Fällen sendet der Message Broker möglicherweise dieselbe logische PUBLISH Nachricht erneut mit einer anderen Paket-ID.

• Wenn Sie Themenfilter abonnieren, die ein Platzhalterzeichen enthalten, können keine beibehaltenen Meldungen empfangen werden. Um eine gespeicherte Meldung zu erhalten, muss die Anforderung einen Themenfilter enthalten, der genau dem Thema der gespeicherten Meldung entspricht.

• Der Nachrichtenbroker garantiert nicht die Reihenfolge, in der Nachrichten empfangen ACK werden.

• AWS IoT kann Grenzwerte haben, die von den Spezifikationen abweichen. Weitere Informationen zu den Grenzwerten von AWS IoT Core Message Broker finden Sie im AWS IoT Referenzhandbuch.

• Die MQTT DUP Flagge wird nicht unterstützt.