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 durch eine Client-ID identifiziert werden. AWS IoT Geräte-SDKs unterstützen beide Protokolle und sind die empfohlenen Verbindungsmethoden für Geräte zu AWS IoT Core Die AWS IoT Geräte-SDKs unterstützen die Funktionen, die Geräte und Clients benötigen, um sich mit Diensten zu verbinden und auf sie zuzugreifen. AWS IoT Die Geräte-SDKs unterstützen 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 der AWS Geräte-SDKs eine Verbindung herstellen können, sowie Links zu Beispielen AWS IoT in den unterstützten Sprachen finden Sie unter. Verbindung mit MQTT mithilfe der Geräte-SDKs herstellen AWS IoT Weitere Informationen zu Authentifizierung und Portzuordnungen für MQTT-Meldungen unter Protokolle, Port-Zuweisungen und Authentifizierung.

Wir empfehlen zwar, die AWS IoT Geräte-SDKs für die Verbindung zu verwenden AWS IoT, diese sind jedoch nicht erforderlich. Wenn Sie die AWS IoT Geräte-SDKs jedoch nicht verwenden, 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.

Verbindung mit MQTT mithilfe der Geräte-SDKs herstellen AWS IoT

Dieser Abschnitt enthält Links zu den AWS IoT Geräte-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 über WSS eine Verbindung herstellen können.

MQTT QoS-(Quality of Service)-Optionen

AWS IoT und die AWS IoT Device SDKs unterstützen die MQTT Quality of Service (QoS) -Levels und. 0 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.

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 Logs aufgezeichnet. CloudWatch 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

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.

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.

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 QoS1-Verbindung mit dem Meldungsablaufintervall abläuft, während ein Client offline ist, empfängt der Client nach der Wiederaufnahme der Verbindung die abgelaufene Meldung 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:

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:

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 von ihm veröffentlichte MQTT-Nachricht setzt, 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.

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

AWS IoT Core speichert MQTT-Nachrichten mit gesetztem RETAIN-Flag. 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.

Abrechnung und gespeicherte Meldungen

Beim Veröffentlichen von Meldungen, bei denen das RETAIN-Flag gesetzt ist, von einem Client aus, über die AWS IoT Konsole oder per Anruf Publish fallen zusätzliche Gebühren für Meldungsübermittlung an, die unter AWS IoT Core Preise – Meldungsübermittlung beschrieben sind.

Beim 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.

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

In MQTT gespeicherte 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.

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.

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:

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.

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

Geteilte Abonnements

AWS IoT Core unterstützt Shared Subscriptions sowohl für MQTT 3 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 Meldungen, die zu diesem Thema veröffentlicht wurden, nach dem Zufallsprinzip. Mit geteilten Abonnements können MQTT-Meldungen 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}

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:

sports/tennis
sports/#

$share/consumer/sports/tennis
$share/consumer/sports/#

Es werden nicht gemeinsam genutzte Abonnements angeboten.	Ablauf geteilter Abonnements

Wichtige Hinweise zur Verwendung von geteilten Abonnements

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 von gemeinsamen Abonnements mit dem AWS IoT MQTT-Client in der AWS IoT Konsole finden Sie unter. Testen von geteilten Abonnements im MQTT-Client Weitere Informationen zu Shared Subscriptions finden Sie unter Shared Subscriptions in der MQTTv5.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 Persistente MQTT-Sitzungen.

Ursachencode auf allen 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.

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 gebührenpflichtige Datendienste gesenkt werden. 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 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 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, 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 wird das Verhalten des Meldungsablaufs durch die MQTT-Version der eingehenden Veröffentlichungsnachricht bestimmt. Beispielsweise kann eine Meldung mit Ablauf der Nachricht, die von einer über MQTT5 verbundenen Sitzung gesendet wurde, für Geräte, die mit MQTT3-Sitzungen abonniert wurden, ablaufen. In der folgenden Tabelle ist aufgeführt, wie der Ablauf von Meldungen die folgenden Arten von Veröffentlichungsnachrichten unterstützt:

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 das Request/Response-Muster. In können Sie Regeln erstellen AWS IoT Core, die die Eigenschaften ausgehender 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

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.

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: