Mit dem Gerät eine Verbindung mit MQTT herstellen AWS IoT SDKs MQTT QoS-(Quality of Service)-Optionen Persistente MQTT-Sitzungen Beibehaltene MQTT-Meldungen MQTT-Meldungen des letzten Willens und Testaments (LWT)ConnectAttributes verwenden Von MQTT 5 unterstützte Funktionen MQTT 5 Eigenschaften MQTT-Ursachencodes AWS IoT Unterschiede zu den MQTT-Spezifikationen Verwaltung von MQTT-Verbindungen

MQTT

MQTT (Message Queuing Telemetry Transport) ist ein einfaches, weit verbreitetes Messaging-Protokoll, das für eingeschränkte Geräte konzipiert ist. AWS IoT Core Unterstützung für MQTT basiert auf der MQTT-Spezifikation v3.1.1 und v5.0, mit einigen Unterschieden, wie in AWS IoT Unterschiede zu den MQTT-Spezifikationen dokumentiert. MQTT 5, die neueste Version des Standards, führt mehrere wichtige Funktionen ein, die ein MQTT-basiertes System robuster machen. Dazu gehören Verbesserungen der Skalierbarkeit, eine verbesserte Fehlerberichterstattung mit Reason-Code-Antworten, Timer für den Ablauf von Meldungen und Sitzungen sowie benutzerdefinierte Header für Benutzermeldungen. Weitere Informationen zu den Funktionen, die MQTT 5 AWS IoT Core unterstützen, finden Sie unter Von MQTT 5 unterstützte Funktionen. AWS IoT Core unterstützt auch die Kommunikation zwischen MQTT-Versionen (MQTT 3 und MQTT 5). Ein MQTT-3-Publisher kann eine MQTT-3-Meldung an einen MQTT-5-Subscriber senden, der eine MQTT-5-Publish-Meldung erhält, und umgekehrt.

AWS IoT Core unterstützt Geräteverbindungen, die das MQTT-Protokoll und das MQTT-over-WSS-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 Diensten herzustellen und auf sie zuzugreifen AWS IoT . 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 das MQTT-Protokoll und die Protokolle MQTT over WSS 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 unter. Mit dem Gerät eine Verbindung mit MQTT herstellen AWS IoT SDKs Weitere Informationen zu Authentifizierung und Portzuordnungen für MQTT-Meldungen unter Protokolle, Port-Zuweisungen und Authentifizierung.

Wir empfehlen zwar, das AWS IoT Gerät SDKs für die Verbindung zu verwenden AWS IoT, sie sind jedoch nicht erforderlich. Wenn Sie das AWS IoT Gerät jedoch nicht verwenden SDKs, müssen Sie für die erforderliche Verbindungs- und Kommunikationssicherheit sorgen. Clients müssen auch die Server Name Indication (SNI)-TLS-Erweiterung in der Verbindungsanforderung senden. Verbindungsversuche, die das SNI nicht enthalten, 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.

Nachdem Ihre Clients verbunden sind, können Sie ihre MQTT-Clientverbindungen mithilfe von überwachen und verwalten. APIs Weitere Informationen finden Sie unter Verwaltung von MQTT-Verbindungen.

In diesem Thema:

Mit dem Gerät eine Verbindung mit MQTT herstellen AWS IoT SDKs
MQTT QoS-(Quality of Service)-Optionen
Persistente MQTT-Sitzungen
Beibehaltene MQTT-Meldungen
MQTT-Meldungen des letzten Willens und Testaments (LWT)
ConnectAttributes verwenden
Von MQTT 5 unterstützte Funktionen
MQTT 5 Eigenschaften
MQTT-Ursachencodes
AWS IoT Unterschiede zu den MQTT-Spezifikationen
Verwaltung von MQTT-Verbindungen

Mit dem Gerät eine Verbindung mit MQTT herstellen 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 AWS IoT wird. Die hier verlinkten Beispiel-Apps zeigen, wie Sie AWS IoT mithilfe des MQTT-Protokolls und MQTT über WSS eine Verbindung herstellen können.

Anmerkung

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

MQTT QoS-(Quality of Service)-Optionen

AWS IoT und das AWS IoT Gerät SDKs unterstützt die MQTT Quality of Service (QoS) -Levels 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. HTTPS unterstützt QoS, indem es einen Abfragezeichenfolge-Parameter ?qos=qos übergibt, sein Wert kann 0 oder 1 sein.

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.

Persistente MQTT-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 Metriken und Protokollen aufgezeichnet. CloudWatch Informationen zu den Einträgen, in die geschrieben wurde, CloudWatch und zu den CloudWatch Protokollen finden Sie unter Message Broker-Metriken undProtokolleintrag in der Warteschlange.

Erstellen einer persistenten Sitzung

Erstellen Sie in MQTT 3 eine persistente MQTT-Sitzung, indem Sie eine CONNECTMeldung versenden und das cleanSession Flag auf 0 festlegen. 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 Session Expiry Interval festlegen. 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 nicht in der CONNECT-Meldung angegeben ist, ist der Standardwert 0.

MQTT 5 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 = 0 setzen, entspricht dies einer sauberen MQTT-3-Sitzung. Wenn Sie Clean Start = 0 und Session Expiry Interval >0 setzen, entspricht dies einer persistenten MQTT-3-Sitzung.

Anmerkung

MQTT-übergreifende (MQTT 3 und MQTT 5) persistente Sitzungen werden nicht unterstützt. Eine persistente MQTT 3-Sitzung kann nicht als MQTT 5-Sitzung wieder aufgenommen 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 fortlaufende 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. Wenn in MQTT 5 eine ausgehende QoS 1-Verbindung 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.

Bei geteilten Abonnenten werden Nachrichten in die Warteschlange gestellt, wenn mindestens ein Abonnent einer Gruppe eine persistente Sitzung verwendet und keine Abonnenten online sind, um die QoS 1-Nachricht zu empfangen. Das Löschen von Nachrichten aus der Warteschlange erfolgt mit einer maximalen Geschwindigkeit von 20 Nachrichten pro Sekunde pro aktivem Abonnenten in einer Gruppe. Weitere Informationen finden Sie unter Nachrichtenwarteschlange für gemeinsame Abonnements.

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.
Sie trennen den Client manuell und löschen die Sitzung mithilfe der DeleteConnection API. Weitere Informationen finden Sie unter Verwaltung von MQTT-Verbindungen.

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

In MQTT 5 können Sie das Sitzungsablaufintervall für jede Sitzung in den Paketen CONNECT und DISCONNECT festlegen.

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

Wenn die aktuelle Sitzung ein Sitzungsablaufintervall von 0 hat, können Sie das Sitzungsablaufintervall für das DISCONNECT-Paket nicht auf einen Wert über 0 setzen.
Wenn die aktuelle Sitzung ein Sitzungsablaufintervall von mehr als 0 hat und Sie das Sitzungsablaufintervall im DISCONNECT-Paket auf 0 setzen, wird die Sitzung auf DISCONNECT beendet.
Andernfalls aktualisiert das Sitzungsablaufintervall für das DISCONNECT-Paket 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.

Beibehaltene MQTT-Meldungen

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 gespeicherten MQTT-Meldungen

Als erste Konfigurationsnachricht

In MQTT gespeicherte Meldungen werden an einen Client gesendet, nachdem der Client ein Thema abonniert hat. Wenn Sie möchten, dass alle Clients, die ein Thema abonnieren, die beibehaltene MQTT-Nachricht direkt nach ihrem Abonnement erhalten, können Sie eine Konfigurationsnachricht mit gesetztem RETAIN Flag 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:

Häufige Aufgaben mit MQTT-Aufbewahrungsnachrichten in AWS IoT Core
Abrechnung und gespeicherte Meldungen
Vergleich von beibehaltenen MQTT-Meldungen und persistenten MQTT-Sitzungen
MQTT hat Nachrichten und Device Shadows gespeichert AWS IoT

Häufige Aufgaben mit MQTT-Aufbewahrungsnachrichten in AWS IoT Core

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

Archivierte MQTT-Meldungen erfordern spezifische Richtlinienaktionen, um Clients den Zugriff auf sie 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 Meldung beibehalten wird, wenn er eine MQTT-Meldung veröffentlicht. Clients können das RETAIN Flag setzen, wenn sie eine Nachricht veröffentlichen, indem sie ein Geräte-SDK verwenden. 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 Meldung mit gesetztem RETAIN-Flag, die zu einem Thema veröffentlicht wurde, ersetzt alle vorhandenen beibehaltenen Meldungen, die zuvor an das Thema gesendet wurden.

Anmerkung
Sie können nicht in einem reservierten Thema veröffentlichen, wenn das RETAIN Kennzeichen gesetzt ist.
Abonnieren eines beibehaltenen Meldungsthemas

Kunden abonnieren Themen für beibehaltene Meldungen wie jedes andere MQTT-Meldungsthema. Für zurückbehaltene Nachrichten, die Sie erhalten haben, indem Sie ein Thema abonniert haben, ist dieses 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.

Anmerkung
Um bei einem Abonnement eine beibehaltene 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.

Wenn bei MQTT 5 für eine beibehaltene Meldung das Meldungsablaufintervall festgelegt ist und die beibehaltene Meldung abläuft, erhält ein neuer Abonnent, der dieses Thema abonniert, die beibehaltene Meldung bei erfolgreichem Abonnement nicht.
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

MQTT-Will-Meldungen, die erstellt werden, wenn ein Gerät eine Verbindung herstellt, können beibehalten werden, indem das Will Retain Flag im Connect Flag bits Feld gesetzt wird.
Löschen einer beibehaltenen Nachricht

Geräte, Anwendungen und Dienste können eine beibehaltene Nachricht löschen, indem sie eine Nachricht veröffentlichen, bei der das RETAIN Kennzeichen gesetzt ist und eine leere Nachrichten-Payload (0 Byte) zum Themennamen der zu löschenden Nachricht hinzugefügt wird. 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 MQTT-Testclient
  
  Auf der MQTT-Testclient-Seite in der AWS IoT Konsole können MQTT-Themen abonniert und veröffentlicht werden. Mit der Veröffentlichungsoption können Sie das RETAIN-Flag für die von Ihnen veröffentlichten Meldungen setzen, um zu simulieren, wie sich Ihre Geräte verhalten könnten. Sie können den MQTT-Testclient auch verwenden, um Nachrichten von verbundenen Clients zu überwachen, die Sie über die Client-Verbindungsschnittstelle verwalten. Weitere Informationen zur Verwaltung von Client-Verbindungen finden Sie unterVerwaltung von MQTT-Verbindungen.
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 eine gedrosselte Antwort auf Nachrichten AWS IoT Core zurückgegeben, die mit aktiviertem RETAIN und Payloads von mehr als 0 Byte veröffentlicht wurden, 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 gesetztem Kennzeichen auf einem Client, über die AWS IoT Konsole oder per 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.

Für Will-Meldungen, die veröffentlicht werden, wenn die Verbindung zu einem Gerät unerwartet unterbrochen wird, fallen Gebühren für die Meldungsübermittlung an, die unter AWS IoT Core Preise – Meldungsübermittlung beschrieben sind.

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

Vergleich von beibehaltenen MQTT-Meldungen und persistenten MQTT-Sitzungen

Aufbewahrte Meldungen und persistente Sitzungen sind Standardfunktionen von MQTT, die es Geräten ermöglichen, Meldungen 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 Meldungen, die mit QOS = 1 veröffentlicht und mit QOS =1 abonniert wurden, während das Gerät getrennt wurde, werden gesendet, nachdem das Gerät wieder eine Verbindung hergestellt hat.
Sitzungsablauf	In MQTT 3 laufen gespeicherte Meldungen nicht ab. Sie werden gespeichert, bis sie ersetzt oder gelöscht werden. In MQTT 5 laufen gespeicherte 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 Meldungen des Clients gelöscht, die mit einem QOS = 1 veröffentlicht und mit einem QOS =1 abonniert wurden, während das Gerät getrennt wurde. Abgelaufene Meldungen werden nicht zugestellt. Weitere Hinweise zum Ablauf von Sitzungen mit persistenten Sitzungen finden Sie unter Persistente MQTT-Sitzungen.

Informationen zu persistentem Speicher siehe Persistente MQTT-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 Nachricht zu speichern, wird vom Herausgeber getroffen, und die gespeicherte Nachricht wird an alle aktuellen und future Clients zugestellt, die QoS 0- oder QoS 1-Abonnements abonnieren. Bei gespeicherten Meldungen wird jeweils nur eine Meldung zu einem bestimmten Thema gespeichert.

Wenn ein Konto die maximale Anzahl an gespeicherten Meldungen gespeichert hat, wird AWS IoT Core eine gedrosselte Antwort auf Meldungen zurückgeben, bei denen RETAIN aktiviert war, und Nutzlasten von mehr als 0 Byte, bis einige beibehaltene Meldungen gelöscht wurden und die Anzahl der gespeicherten Meldungen unter den Grenzwert fällt.

MQTT hat Nachrichten und Device Shadows gespeichert 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. MQTT spezifiziert keine Struktur oder kein Schema für seine Meldungsnutzlast.	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 Client erhält automatisch eine gespeicherte Nachricht, nachdem er ein Thema mit einer gespeicherten Nachricht 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.

MQTT-Meldungen des letzten Willens und Testaments (LWT)

Last Will and Testament (LWT) ist ein Feature in MQTT. Mit LWT können Kunden eine Meldung angeben, die der Broker zu einem vom Kunden definierten Thema veröffentlicht und an alle Clients sendet, die das Thema abonniert haben, wenn eine uninitiierte Verbindungsunterbrechung auftritt. Die von den Clients angegebene Meldung wird als LWT-Meldung oder Will-Meldung bezeichnet, und das von den Clients definierte Thema wird Will-Thema genannt. Sie können eine LWT-Meldung 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.

Bei der Verwaltung von Client-Verbindungen können Sie steuern, ob LWT-Nachrichten veröffentlicht werden, wenn Sie die Verbindung zu einem Client trennen. Weitere Informationen finden Sie unter Verwaltung von MQTT-Verbindungen.

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 mithilfe der MQTT DISCONNECT-Meldung trennt, veröffentlicht der Broker die gespeicherten LWT-Meldungen nicht. In allen anderen Fällen werden die LWT-Meldungen versendet. Eine vollständige Liste der Verbindungsszenarien, in denen der Broker die LWT-Meldungen sendet, finden Sie unter Connect/Disconnect events.

ConnectAttributes verwenden

ConnectAttributes ermöglichen es Ihnen, in Ihren IAM-Richtlinien anzugeben, welche Attribute Sie in Ihrer Connect-Meldung verwenden möchten, z. B. PersistentConnect und LastWill 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.

Bei der Verwaltung von Clientverbindungen können Sie die Verbindungsattribute und die Sitzungskonfiguration für verbundene Clients einsehen. Weitere Informationen finden Sie unter Verwaltung von MQTT-Verbindungen.

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

Von MQTT 5 unterstützte Funktionen

AWS IoT Core Die Unterstützung für MQTT 5 basiert auf der MQTT v5.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
Aliase für Themen
Ablauf der Nachricht
Weitere Funktionen von MQTT 5

Geteilte Abonnements

AWS IoT Core unterstützt gemeinsame Abonnements sowohl für MQTT 3.1.1 als auch für MQTT 5. Geteilte Abonnements ermöglichen es mehreren Clients, ein Abonnement für ein Thema gemeinsam zu nutzen, und nur ein Client erhält Nachrichten, 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 Nachrichten empfangen, die von den Geräten zum 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. Wenn alle Abonnenten die Verbindung trennen, werden die Nachrichten in die Warteschlange gestellt.

Message Queuing-Funktionen sind für gemeinsame Abonnements sowohl für MQTT 3.1.1- als auch für MQTT 5-Verbindungen verfügbar, um die Zuverlässigkeit der Nachrichtenzustellung zu erhöhen.

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 vom / Zeichen enthalten. {ShareName} darf die folgenden Zeichen nicht enthalten: /,+ oder#. Die maximale Größe für {ShareName} beträgt 128 UTF-8-Zeichen.
{TopicFilter}folgt derselben Themenfiltersyntax wie ein Abonnement, das nicht gemeinsam genutzt wird. Die maximale Größe für {TopicFilter} beträgt 256 UTF-8-Zeichen.
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 haben, {ShareName}/{TopicFilter} gehören derselben gemeinsamen Abonnementgruppe an. Sie können mehrere gemeinsame Abonnementgruppen 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 gibt nicht gemeinsam genutzte Abonnements	Ablauf geteilter Abonnements

Wichtige Hinweise zur Verwendung von gemeinsamen Abonnements

Wenn die gemeinsame Abonnentengruppe aus Abonnenten einer dauerhaften Sitzung besteht, wenn alle Abonnenten in der gemeinsam genutzten Gruppe getrennt sind oder wenn Abonnenten das Limit für Veröffentlichungsanfragen pro Sekunde pro Verbindung überschreiten, werden alle nicht bestätigten QoS-1-Nachrichten und nicht zugestellten QoS-1-Nachrichten, die in einer gemeinsam genutzten Abonnementgruppe veröffentlicht wurden, in die Warteschlange gestellt. Weitere Informationen finden Sie unter Nachrichtenwarteschlange für gemeinsame Abonnements.
QoS 0-Nachrichten, die in einer gemeinsam genutzten Abonnementgruppe veröffentlicht wurden, werden bei einem Fehler gelöscht.
Geteilte Abonnements erhalten keine beibehaltenen Nachrichten, wenn sie Themenmuster als Teil einer gemeinsamen Abonnentengruppe abonnieren. Nachrichten, die zu Themen veröffentlicht wurden, die gemeinsame Abonnenten haben und bei denen die RETAIN Markierung gesetzt ist, werden an gemeinsame Abonnenten wie jede andere Veröffentlichungsnachricht zugestellt.
Wenn gemeinsame Abonnements Platzhalterzeichen (# oder +) enthalten, gibt es möglicherweise mehrere übereinstimmende gemeinsame Abonnements für ein Thema. In diesem Fall kopiert der Nachrichtenbroker 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-Thema zur Veröffentlichung. sports/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 Beschränkungen für gemeinsame Abonnements finden Sie unter AWS IoT Core Endpunkte und Kontingente in der AWS Allgemeinen Referenz. Informationen zum Testen gemeinsam genutzter Abonnements mit dem AWS IoT MQTT-Client in der AWS IoT Konsole finden Sie unter. Testen von geteilten Abonnements im MQTT-Client Mithilfe der Funktionen zur Verwaltung von Client-Verbindungen können Sie auch sehen, welche Themen verbundene Clients abonniert haben, einschließlich gemeinsamer Abonnements. Weitere Informationen finden Sie unter Verwaltung von MQTT-Verbindungen. Weitere Informationen zu gemeinsamen Abonnements finden Sie unter Gemeinsame Abonnements aus der MQTTv5 2.0-Spezifikation.

Nachrichtenwarteschlange für gemeinsame Abonnements

Um die Zuverlässigkeit der Nachrichtenzustellung zu erhöhen, enthalten gemeinsame Abonnements Nachrichtenwarteschlangenfunktionen, mit denen Nachrichten gespeichert werden, wenn keine Online-Abonnenten verfügbar sind. Wenn eine gemeinsam genutzte Abonnementgruppe mindestens ein Mitglied mit einer dauerhaften Sitzung enthält, ist die Warteschlangenfunktion für die Gruppe aktiviert. Beim Verteilen von Nachrichten werden Online-Mitglieder als Empfänger ausgewählt. QoS 1-Nachrichten werden in die Warteschlange gestellt, wenn keine Mitglieder online gefunden werden oder wenn Abonnenten das Publish requests per second per connectionLimit überschreiten. Nachrichten in der Warteschlange werden zugestellt, wenn entweder bestehende Mitglieder ihre ständigen Sitzungen wieder aufnehmen oder neue Mitglieder der Gruppe beitreten. Nachrichten in der Warteschlange werden mit bis zu 20 Nachrichten pro Sekunde pro aktivem Gruppenabonnenten zugestellt, zusammen mit allen anderen Nachrichten, die dem Abonnenten gemäß den Abonnements zugestellt werden.

Standardmäßig entspricht die Aufbewahrung von Nachrichten in der Warteschlange dem Kontingent. Persistent Session expiry period Wenn jedoch in der eingehenden Veröffentlichungsnachricht ein Nachrichtenablaufintervall (MEI) festgelegt ist, hat das MEI Vorrang. Wenn MEI vorhanden ist, bestimmt es den Aufbewahrungszeitraum für Nachrichten, unabhängig von der Ablaufzeit der persistenten Sitzung.

Die Anzahl der Nachrichtenwarteschlangen ist entsprechend dem Queued messages per second per accountKontingent begrenzt, und die Anzahl der Nachrichten ist durch das Maximum number of queued messages per shared subscription groupKontingent begrenzt.

Wenn diese Grenzwerte überschritten werden, werden nur die Nachrichten aufbewahrt, die sich bereits in der Warteschlange befanden, bevor das Limit erreicht wurde. Neue eingehende Nachrichten, die die Grenzwerte überschreiten würden, werden gelöscht. Das System ersetzt ältere Nachrichten in der Warteschlange nicht durch neuere.

Das Einreihen von Nachrichten in die Warteschlange wird in CloudWatch Metriken und CloudWatch Protokollen aufgezeichnet. Informationen zu den Einträgen, in die geschrieben wurde, CloudWatch und zu den CloudWatch Protokollen finden Sie unter Message Broker-Metriken undProtokolleintrag in der Warteschlange. Nachrichten in der Warteschlange werden weiterhin zum Standardnachrichtentarif abgerechnet. Weitere Informationen zu Preisen erhalten Sie unter AWS IoT Core Preise.

Sitzungslebenszyklus in einer gemeinsam genutzten Abonnementgruppe

Wenn eine saubere Sitzung eine Gruppe abonniert, wird sie zu einem Online-Mitglied der Gruppe. Wenn sie sich abmeldet oder die Verbindung trennt, verlässt die saubere Sitzung die Gruppe.

Wenn eine persistente Sitzung eine Gruppe abonniert, wird sie zu einem Online-Mitglied der Gruppe. Wenn die Verbindung getrennt wird, verbleibt sie weiterhin in der Gruppe, wird aber zu einem Offline-Mitglied der Gruppe. Wenn die Verbindung wieder hergestellt wird, wird sie wieder zu einem Online-Mitglied. Die persistente Sitzung verlässt die Gruppe, wenn sie sich explizit abmeldet oder wenn sie nach der Trennung abläuft.

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 Persistente MQTT-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 MQTT. Eine vollständige Liste der MQTT-Ursachencodes finden Sie in der MQTT v5-Spezifikation.

Aliase für Themen

Sie können einen Themennamen durch einen Themenalias ersetzen, bei dem es sich um eine Zwei-Byte-Ganzzahl handelt. Durch die Verwendung von Themenaliasnamen kann die Übertragung von Themennamen optimiert werden, wodurch die Datenkosten für Dienste mit gebührenpflichtigen Daten potenziell gesenkt werden können. AWS IoT Core hat eine Standardbeschränkung 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 Nachrichtenablaufintervall (MEI) 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 Meldung einen aktualisierten MEI von 0 hat. Dies liegt daran, dass sie auf 0 aktualisiert wird, sobald die verbleibende Zeit 999 ms oder weniger beträgt.

In AWS IoT Core ist der Mindest-MEI 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 wird das Verhalten des Meldungsablaufs durch die MQTT-Version der eingehenden Veröffentlichungsnachricht bestimmt. 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 angemeldet 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 eine ausgehende QoS 1-Verbindung mit Nachrichtenablaufintervall abläuft, während ein Client offline ist, empfängt der Client nach der Wiederaufnahme der persistenten Sitzung die abgelaufene Nachricht nicht.

Weitere Funktionen von MQTT 5

Verbindung zum Server trennen

Wenn eine Verbindung unterbrochen wird, kann der Server dem Client proaktiv eine DISCONNECT-Meldung senden, um den Verbindungsabbruch mit einem Ursachencode für die Trennung zu benachrichtigen.

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.

MQTT 5 Eigenschaften

MQTT 5-Eigenschaften sind wichtige Ergänzungen des MQTT-Standards zur Unterstützung neuer MQTT 5-Funktionen wie Session Expiry und Pattern. Request/Response In können Sie Regeln erstellen AWS IoT Core, die die Eigenschaften in ausgehenden Nachrichten weiterleiten können, oder HTTP Publish verwenden, um MQTT-Nachrichten mit einigen der neuen Eigenschaften zu veröffentlichen.

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

Property (Eigenschaft)	Description (Beschreibung)	Eingabetyp	packets
Nutzlastformatindikator Nutzlastnutzlast	Ein boolescher Wert, der angibt, ob die Payload als UTF-8 formatiert ist.	Byte	VERÖFFENTLICHEN, VERBINDEN
Inhaltstyp	Eine UTF-8-Zeichenfolge, die den Inhalt der Nutzlast beschreibt.	UTF-8-Zeichenfolge	VERÖFFENTLICHEN, VERBINDEN
Thema der Antwort	Eine UTF-8-Zeichenfolge, die das Thema beschreibt, zu dem der Empfänger im Rahmen des Anfrage-Antwort-Ablaufs etwas veröffentlichen sollte. Das Thema darf keine Platzhalterzeichen enthalten.	UTF-8-Zeichenfolge	VERÖFFENTLICHEN, VERBINDEN
Korrelationsdaten	Binärdaten, die vom Absender der Anforderungsnachricht verwendet werden, um zu identifizieren, für welche Anfrage die Antwortnachricht bestimmt ist.	Binär	VERÖFFENTLICHEN, VERBINDEN
Benutzereigenschaften	Ein UTF-8-Stringpaar. 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.	UTF-8-String-Paar	VERBINDEN, VERÖFFENTLICHEN, Will-Eigenschaften, ABONNIEREN, TRENNEN, ABBESTELLEN
Ablaufintervall für Meldungen	Eine 4-Byte-Ganzzahl, die das Nachrichtenablaufintervall in Sekunden darstellt. Wenn nicht vorhanden, läuft die Meldung nicht ab.	4-Byte-Ganzzahl	VERÖFFENTLICHEN, VERBINDEN
Ablaufintervall der Sitzung	Eine 4-Byte-Ganzzahl, die das Ablaufintervall der Sitzung in Sekunden darstellt. AWS IoT Core unterstützt ein Maximum von 7 Tagen, 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 im CONNACK zurückgegeben.	4-Byte-Ganzzahl	VERBINDEN, VERBINDEN, TRENNEN
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 im Falle eines Fehlers 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 dass ein PUBACK empfangen wird.	2-Byte-Ganzzahl	VERBINDEN, CONNACK
Thema Alias Maximum	Dieser Wert gibt den höchsten Wert an, der als Themen-Alias akzeptiert wird. Standard = 0.	2-Byte-Ganzzahl	VERBINDEN, CONNACK
Maximale QoS	Der maximale Wert von QoS, der AWS IoT Core unterstützt wird. Die Standardeinstellung ist 1. AWS IoT Core unterstützt QoS 2 nicht.	Byte	CONNACK
Beibehaltung verfügbar	Ein boolescher Wert, der angibt, ob der AWS IoT Core Message Broker gespeicherte 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	VERBINDEN, 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

MQTT-Ursachencodes

MQTT 5 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 MQTT 5-Spezifikationen.

CONNACK-Ursachencodes
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.

PUBACK-Ursachencodes
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.	Die Veröffentlichung 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.

Disconnect – Ursachencodes
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 weder PUBACK noch PUBCOMP gesendet hat.
148	0 x 94	Ungültiges Thema-Alias	Der Client oder Server hat ein PUBLISH-Paket erhalten, das einen Themen-Alias enthält, der größer ist als die maximale Anzahl an Themen-Alias, die er im CONNECT- oder CONNACK-Paket 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 QoS angegeben, die höher ist als die QoS, die in einem Maximum QoS im CONNACK angegeben ist.
161	0 x A1	Abonnement-Identifikatoren werden nicht unterstützt.	Der Server unterstützt keine Abonnement-IDs. Das Abonnement wird nicht akzeptiert.

SUBACK-Ursachencodes
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.

UNSUBACK-Ursachencodes
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 MQTT-Spezifikation v3.1.1 und der MQTT-Spezifikation v5.0, unterscheidet sich jedoch in folgenden Punkten von den Spezifikationen:

AWS IoT unterstützt die folgenden Pakete für MQTT 3 nicht: PUBREC, PUBREL und PUBCOMP.
AWS IoT unterstützt die folgenden Pakete für MQTT 5 nicht: PUBREC, PUBREL, PUBCOMP und AUTH.
AWS IoT unterstützt keine MQTT 5-Serverumleitung.
AWS IoT unterstützt nur die MQTT Quality of Service (QoS) Stufen 0 und 1. AWS IoT unterstützt das Veröffentlichen oder Abonnieren mit QoS Level 2 nicht. Bei Abfragen über QoS-Ebene 2 sendet der Message Broker kein PUBACK oder SUBACK.
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 diesem Fall wird das DUP-Flag nicht festgelegt.
Der Message Broker sendet als Antwort auf eine Verbindungsanfrage 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-Meldung vom Message Broker auf seinem Gerät empfangen wird. AWS IoT
Wenn ein Client ein Thema abonniert, kann es zwischen dem Zeitpunkt, an dem der Message Broker eine SUBACK-Meldung sendet, und den ersten eingehenden passenden Meldungen eine Verzögerung geben.
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 Filter für Themennamen.
Der Message Broker verwendet die Client-ID, um die einzelnen Clients zu identifizieren. Die Client-ID wird vom Client im Rahmen der MQTT-Nutzlast an den Message Broker übermittelt. 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. Sie können Clients auch manuell trennen mit. APIs Weitere Informationen finden Sie unter Verwaltung von MQTT-Verbindungen.
In seltenen Fällen kann der Message Broker die gleiche logische PUBLISH Meldung mit einer anderen Paket-ID erneut senden.
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.
Die Reihenfolge, in der Meldungen und ACK empfangen werden, kann vom Message Broker nicht garantiert 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.
Das MQTT DUP-Flag wird nicht unterstützt.

Verwaltung von MQTT-Verbindungen

AWS IoT Core unterstützt APIs Sie bei der Verwaltung von MQTT-Verbindungen, einschließlich der Möglichkeit, Clients zu trennen und ihre Sitzungen zu verwalten. Diese Funktionen geben Ihnen mehr Kontrolle über Ihre AWS IoT Kundenflotte und helfen Ihnen bei der Behebung von Verbindungsproblemen.

DeleteConnection API

Verwenden Sie die DeleteConnection API, um die Verbindung zu MQTT-Geräten zu trennen, AWS IoT Core indem Sie ihren Client IDs angeben. Wenn Sie die AWS IoT Core Verbindung zu einem Client trennen, wird der Client vom AWS IoT Core Message Broker getrennt und Sie können optional den Sitzungsstatus bereinigen und die Nachricht Last Will and Testament (LWT) unterdrücken.

AWS IoT Core Führt beim Aufrufen der DeleteConnection API mehrere Aktionen aus, um sicherzustellen, dass die Verbindung ordnungsgemäß unterbrochen wird. AWS IoT Core sendet zunächst eine MQTT-Verbindungsnachricht an den Client, um die MQTT-Sitzung zu beenden. Der Dienst schließt dann den zugrunde TCP/TLS liegenden Socket.

Der Message Broker sendet ein DISCONNECT Paket an das Gerät und veröffentlicht ein Lebenszyklusereignis mit dem Grund für die Unterbrechung der VerbindungAPI_INITIATED_DISCONNECT. Auf diese Weise können Sie feststellen, wann eine Verbindungsunterbrechung über die API und nicht durch den Client oder aufgrund von Netzwerkproblemen initiiert wurde. Sie können diese Ereignisse aus Gründen der Transparenz, Problembehandlung und Prüfung überwachen. Sie können beispielsweise AWS IoT Regeln verwenden, um diese Ereignisse zu verarbeiten, um nachzuverfolgen, wann und warum die Verbindung der Clients unterbrochen wurde.

Wenn Sie den cleanSession Parameter auf setzentrue, AWS IoT Core wird der Sitzungsstatus des Clients gelöscht, einschließlich aller Abonnements und Nachrichten in der Warteschlange. Wenn Sie eine Sitzung bereinigen, wird die persistente Sitzung beendet. Wenn es sich bei dem Client um eine persistente Sitzung handelte und der preventWillMessage Parameter auf gesetzt istfalse, sendet der Dienst die LWT-Nachricht, sofern verfügbar, was bei geplanten Wartungsarbeiten nützlich ist.

Wenn Sie die DeleteConnection API aufrufen, beginnt der Verbindungsabbruch sofort. Der genaue Zeitpunkt, zu dem der Client die Unterbrechung erkennt, kann jedoch je nach Netzwerkbedingungen und Client-Implementierung variieren. Die meisten Clients erkennen die Unterbrechung innerhalb weniger Sekunden. In einigen Fällen kann es jedoch bei schlechter Netzwerkkonnektivität länger dauern, bis der Client erkennt, dass die Verbindung unterbrochen wurde.

Anmerkung

Wird eine Unterbrechung erzwungen, muss sich ein Client erneut authentifizieren und mit einem neuen Sitzungsstatus erneut autorisieren. Der API-Aufruf selbst verhindert nicht die Wiederverbindung von Clients. Wenn dies gewünscht wird, müssen zusätzlich die Anmeldeinformationen oder die Richtlinie eines Kunden geändert werden, bevor der DeleteConnection API-Aufruf ausgeführt wird.

Informationen zu Preisen finden Sie unter AWS IoT Core -Preise.

Anwendungsfälle

Die DeleteConnection API ist nützlich, um sich schlecht benehmende Clients zu verwalten, die ein problematisches Verhalten zeigen oder übermäßig viele Ressourcen verbrauchen. Indem Sie eine Unterbrechung erzwingen, können Sie sicherstellen, dass die Clients ihre Verbindungen mit der richtigen Authentifizierung und Autorisierung wiederherstellen, was zur Lösung von Problemen mit dem Ressourcenverbrauch beitragen kann.

Szenarien mit Client-Umleitung profitieren ebenfalls von dieser API. Wenn Sie Clients zu anderen Endpunkten umleiten müssen oder AWS-Regionen können Sie sie programmgesteuert trennen und sie durch Ändern der DNS-Einstellungen erneut eine Verbindung zu einem anderen AWS IoT Core Endpunkt herstellen lassen. Diese API kann dabei helfen, festgefahrene Verbindungen zu lösen oder problematische Sitzungszustände zu löschen, die den normalen Betrieb möglicherweise verhindern.

API-Parameter

Die DeleteConnection API akzeptiert die folgenden Parameter:

clientId (erforderlich): Die eindeutige Kennung des MQTT-Clients, für den die Verbindung getrennt werden soll. Dies ist im URL-Pfad angegeben. Die Client-ID darf nicht mit einem Dollarzeichen ($) beginnen.

Anmerkung
Der MQTT-Client IDs kann Zeichen enthalten, die in HTTP-Anfragen nicht gültig sind. Wenn Sie die DeleteConnection API verwenden, müssen Sie alle Zeichen in der Client-ID, die in MQTT, aber nicht in HTTP gültig sind, URL-kodieren (prozentual kodieren). Dazu gehören Sonderzeichen wie Leerzeichen, Schrägstriche (/) und UTF-8-Zeichen. Ein Leerzeichen wird beispielsweise zu %20, ein Schrägstrich wird zu %2F und das UTF-8-Zeichen ü wird zu %C 3% BC. Durch die richtige Kodierung wird sichergestellt, dass die MQTT-Clients beim HTTP-basierten IDs API-Aufruf korrekt übertragen werden.
CleanSession (optional): Gibt an, ob der Sitzungsstatus des Clients beim Trennen der Verbindung entfernt werden soll. Legt fest, true dass alle Sitzungsinformationen, einschließlich Abonnements und Nachrichten in der Warteschlange, gelöscht werden. Wird auf gesetztfalse, um den Sitzungsstatus beizubehalten. Standardmäßig ist dies auf false (behält den Sitzungsstatus bei) gesetzt. Bei sauberen Sitzungen wird dieser Parameter ignoriert.
preventWillMessage (Optional): Steuert, ob AWS IoT Core die Nachricht Last Will and Testament (LWT) gesendet wird, falls diese beim Trennen der Verbindung verfügbar ist. Wird auf gesetzt, true um das Versenden der LWT-Nachricht zu verhindern. Wird auf gesetzt, um das false Versenden zu ermöglichen. Standardmäßig ist dies auf false (sendet LWT, falls verfügbar) gesetzt.

API-Syntax

Die DeleteConnection API verwendet das folgende HTTP-Anforderungsformat:


DELETE /connections/<clientId>?cleanSession=<cleanSession>&preventWillMessage=<preventWillMessage> HTTP/1.1

Beispielanfragen:


// Basic disconnect (preserves session, allows LWT message)
DELETE /connections/myDevice123 HTTP/1.1

// Disconnect and clear session
DELETE /connections/myDevice123?cleanSession=TRUE HTTP/1.1

// Disconnect, clear session, and prevent LWT message
DELETE /connections/myDevice123?cleanSession=TRUE&preventWillMessage=TRUE HTTP/1.1

Erfolgreiche Anfragen geben HTTP 200 OK ohne Antworttext zurück.

Anmerkung

Der Dienstname, der von AWS Signature Version 4 zum Signieren von Anfragen verwendet wird, lautet: iotdevicegateway. Sie können Ihren Endpunkt finden, indem Sie den Befehl verwenden. aws iot describe-endpoint --endpoint-type iot:Data-ATS

Erforderliche Berechtigungen

Um die DeleteConnection API verwenden zu können, benötigen Sie die folgende IAM-Berechtigung:


iot:DeleteConnection

Sie können diese Berechtigung IDs mithilfe ressourcenbasierter Richtlinien auf bestimmte Clients beschränken. Zum Beispiel:


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:DeleteConnection",
            "Resource": "arn:aws:iot:region:account:client/myDevice*"
        }
    ]
}

Wichtige Überlegungen

Getrennte Clients können sofort versuchen, die Verbindung wiederherzustellen, sofern Sie keine zusätzliche Logik implementiert haben, um eine Wiederverbindung zu verhindern. Der Trennvorgang beendet nur die aktuelle Verbindung und verhindert nicht, dass eine Verbindung wieder hergestellt wird. Wenn Sie eine Wiederverbindung verhindern möchten, sollten Sie die Implementierung einer clientseitigen Logik oder die Deaktivierung der Anmeldeinformationen eines Geräts in Betracht ziehen.

Für die API gelten im Rahmen der standardmäßigen API-Ratenbegrenzung Ratenbegrenzungen. AWS IoT Core Achten Sie bei der Planung von Massentrennungen darauf, dass Sie diese Grenzwerte berücksichtigen und geeignete Wiederholungslogik und Batching-Strategien implementieren, um Drosselungen zu vermeiden. Weitere Informationen finden Sie unter AWS IoT Core -Endpunkte und -Kontingente.

Fehlermeldungen

Die DeleteConnection API kann die folgenden Fehlerantworten zurückgeben:

InvalidRequestException: Die Anforderung ist ungültig. Dies kann auftreten, wenn das Client-ID-Format ungültig ist, ein Dollarzeichen-Präfix ($) enthält oder wenn erforderliche Parameter fehlen.
ResourceNotFoundException: Die angegebene Client-ID existiert nicht oder ist derzeit nicht verbunden und es besteht keine permanente Sitzung.
UnauthorizedException: Sie sind zur Ausführung dieser Operation nicht autorisiert. Stellen Sie sicher, dass Sie über die erforderliche iot:DeleteConnection Berechtigung verfügen.
ForbiddenException: Der Anrufer ist nicht berechtigt, die Anfrage zu stellen. Dies kann auf unzureichende IAM-Berechtigungen oder ressourcenbasierte Richtlinieneinschränkungen zurückzuführen sein.
ThrottlingException: Die Rate überschreitet den Grenzwert. Reduzieren Sie die Häufigkeit Ihrer API-Aufrufe und implementieren Sie eine entsprechende Wiederholungslogik mit exponentiellem Backoff.
InternalFailureException: Ein unerwarteter Fehler ist aufgetreten. Versuchen Sie die Anfrage nach einer kurzen Verzögerung erneut.
ServiceUnavailableException: Der Service ist vorübergehend nicht verfügbar. Versuchen Sie die Anfrage nach einer kurzen Verzögerung erneut.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Gerätekommunikationsprotokolle

HTTPS veröffentlichen

MQTT

In diesem Thema:

Mit dem Gerät eine Verbindung mit MQTT herstellen AWS IoT SDKs

Anmerkung

Anmerkung

Wichtig

MQTT QoS-(Quality of Service)-Optionen

Persistente MQTT-Sitzungen

Erstellen einer persistenten Sitzung

Anmerkung

Operationen während einer persistenten Sitzung

Meldungsverkehr nach Wiederverbindung zu einer persistenten Sitzung

Eine persistente Sitzung wird beendet.

Anmerkung

Wiederverbindung nach Ablauf einer persistenten Sitzung

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

Beibehaltene MQTT-Meldungen

Beispiele für die Verwendung von gespeicherten MQTT-Meldungen

Als erste Konfigurationsnachricht

Als letzte bekannte Zustandsmeldung

In diesem Abschnitt:

Häufige Aufgaben mit MQTT-Aufbewahrungsnachrichten in AWS IoT Core

Erstellen einer beibehaltenen Nachricht

Anmerkung

Abonnieren eines beibehaltenen Meldungsthemas

Anmerkung

Eine beibehaltene Meldung wird abgerufen.

Themen der beibehaltenen Meldungen auflisten

Details zu gespeicherten Meldungen abrufen

Beibehaltung einer Willensnachricht

Löschen einer beibehaltenen Nachricht

Debuggen und Problembehandlung bei gespeicherten Meldungen

Die Seite „Zurückbehaltene Meldungen“

Der MQTT-Testclient

Beibehaltene Meldungslimits

Beibehaltene Reihenfolge der Meldungszustellung

Abrechnung und gespeicherte Meldungen

Vergleich von beibehaltenen MQTT-Meldungen und persistenten MQTT-Sitzungen

MQTT hat Nachrichten und Device Shadows gespeichert AWS IoT

MQTT-Meldungen des letzten Willens und Testaments (LWT)

ConnectAttributes verwenden

Von MQTT 5 unterstützte Funktionen

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

Geteilte Abonnements

Nachrichtenwarteschlange für gemeinsame Abonnements

Clean Start und Ablauf der Sitzung

Ursachencode für alle ACKs

Aliase für Themen

Ablauf der Nachricht

Weitere Funktionen von MQTT 5

MQTT 5 Eigenschaften

MQTT-Ursachencodes

AWS IoT Unterschiede zu den MQTT-Spezifikationen

Verwaltung von MQTT-Verbindungen

DeleteConnection API

Anmerkung

Anwendungsfälle

API-Parameter

Anmerkung

API-Syntax

Anmerkung

Erforderliche Berechtigungen

Wichtige Überlegungen

Fehlermeldungen