Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
MQTT
MQTT
AWS IoT Core prend en charge les connexions de périphériques qui utilisent le MQTT WSS protocole et le MQTT surprotocole et qui sont identifiées par un identifiant client. Les AWS IoT Appareil SDKs prennent en charge les deux protocoles et sont les méthodes recommandées pour connecter les appareils AWS IoT Core. L' AWS IoT appareil SDKs prend en charge les fonctions nécessaires aux appareils et aux clients pour se connecter aux AWS IoT services et y accéder. L'appareil SDKs prend en charge les protocoles d'authentification requis par les AWS IoT services et les exigences d'identification de connexion requises par le MQTT protocole et MQTT WSS les protocoles supplémentaires. Pour plus d'informations sur la façon de se connecter AWS IoT à l' AWS appareil SDKs et pour obtenir des liens vers des exemples de AWS IoT langues prises en charge, consultezConnexion à l'MQTTutilisation de l' AWS IoT appareil SDKs. Pour plus d'informations sur les méthodes d'authentification et les mappages de ports pour les MQTT messages, consultezProtocols, port mappings, and authentication (Protocoles, mappages de ports et authentification).
Bien que nous vous recommandions d'utiliser l' AWS IoT appareil SDKs pour vous y connecter AWS IoT, ils ne sont pas obligatoires. Si vous n'utilisez pas l' AWS IoT appareilSDKs, vous devez toutefois fournir la sécurité de connexion et de communication nécessaire. Les clients doivent envoyer l'TLSextension Server Name Indication (SNI)
Dans cette rubrique :
- Connexion à l'MQTTutilisation de l' AWS IoT appareil SDKs
- MQTTOptions de qualité de service (QoS)
- MQTTsessions persistantes
- MQTTmessages conservés
- MQTTMessages du dernier testament (LWT)
- En utilisant connectAttributes
- MQTT5 fonctionnalités prises en charge
- MQTT5 propriétés
- MQTTcodes de raison
- AWS IoT différences par rapport MQTT aux spécifications
Connexion à l'MQTTutilisation de l' AWS IoT appareil SDKs
Cette section contient des liens vers le AWS IoT périphérique SDKs et vers le code source d'exemples de programmes illustrant comment connecter un appareil à celui-ci AWS IoT. Les exemples d'applications liés ici montrent comment se connecter à AWS IoT l'aide du MQTT protocole et MQTT plus encoreWSS.
Note
The AWS IoT Device SDKs a publié un client MQTT 5.
MQTTOptions de qualité de service (QoS)
AWS IoT et l' AWS IoT appareil SDKs prend en charge les niveaux 0
de MQTT qualité de service (QoS)1
Le MQTT protocole définit un troisième niveau de QoS, le niveau 12
, mais AWS IoT ne le prend pas en charge. Seul le MQTT protocole prend en charge la fonctionnalité QoS. HTTPSprend en charge la QoS en transmettant un paramètre de chaîne de requête ?qos=qos
dont la valeur peut être 0 ou 1.
Ce tableau décrit comment chaque niveau de QoS affecte les messages publiés par et vers l’agent de messages.
Avec un niveau de QoS de... |
Le message est… |
Commentaires |
---|---|---|
QoS niveau 0 |
Envoyé zéro fois ou plus |
Ce niveau doit être utilisé pour les messages envoyés via des liens de communication fiables ou qui peuvent être manqués sans problème. |
QoS niveau 1 |
Envoyé au moins une fois, puis à plusieurs reprises jusqu’à ce qu’une réponse |
Le message n’est pas considéré comme complet tant que l’expéditeur n’a pas reçu de réponse |
MQTTsessions persistantes
Les sessions permanentes stockent les abonnements et les messages d’un client, avec une qualité de service (QoS) de 1, qui n’ont pas été reconnus par le client. Lorsque l’appareil se reconnecte à une session permanente, la session reprend, les abonnements sont rétablis et les messages d’abonnement reçus et stockés sans accusé de réception avant la reconnexion sont envoyés au client.
Le traitement des messages enregistrés est enregistré dans CloudWatch et CloudWatch Logs. Pour plus d'informations sur les entrées écrites dans CloudWatch et les CloudWatch journaux, reportez-vous aux Métriques d'agent de messages sections etEntrée de journal en file d'attente.
Création d’une session permanente
Dans MQTT 3, vous créez une session MQTT persistante en envoyant un CONNECT
message et en réglant le cleanSession
drapeau sur0
. Si aucune session n’existe pour le client qui envoie le message CONNECT
, une nouvelle session permanente est créée. Si une session existe déjà pour le client, celui-ci la reprend. Pour créer une session propre, vous envoyez un message CONNECT
et vous définissez l’indicateur cleanSession
sur 1
, et l’agent ne stockera aucun état de session lorsque le client se déconnecte.
Dans MQTT 5, vous gérez les sessions persistantes en réglant le Clean Start
drapeau etSession Expiry Interval
. Le démarrage propre contrôle le début de la session de connexion et la fin de la session précédente. Lorsque vous définissez Clean
Start
=1
, une nouvelle session est créée et une session précédente est interrompue si elle existe. Lorsque vous définissez Clean Start
=0
, la session de connexion reprend une session précédente si elle existe. L’intervalle d’expiration de session contrôle la fin de la session de connexion. L’intervalle d’expiration de session indique le temps, en secondes (entier de 4 octets), pendant lequel une session persistera après la déconnexion. Le paramètre Session Expiry interval
= 0
entraîne la fin de la session immédiatement après la déconnexion. Si l'intervalle d'expiration de session n'est pas spécifié dans le CONNECT message, la valeur par défaut est 0.
Valeur de la propriété | Description |
---|---|
Clean Start = 1 |
Crée une nouvelle session et met fin à une session précédente s’il en existe une. |
Clean Start = 0 |
Reprend une session s’il en existe une précédente. |
Session Expiry Interval > 0 |
Maintient une session. |
Session Expiry interval = 0 |
Ne fait pas perdurer une session. |
En MQTT 5, si vous définissez Clean Start
= 1
et Session
Expiry Interval
=0
, cela équivaut à une session nettoyée à MQTT 3 reprises. Si vous définissez Clean Start
= 0
et Session Expiry Interval
>0
, cela équivaut à une session persistante de MQTT 3.
Note
Les sessions persistantes entre MQTT versions (MQTT3 et MQTT 5) ne sont pas prises en charge. Une session persistante de MQTT 3 points ne peut pas être reprise en tant que session de MQTT 5, et vice versa.
Opérations au cours d’une session permanente
Les clients utilisent l’attribut sessionPresent
dans le message de connexion reconnue (CONNACK
), afin de déterminer si une session permanente est présente. Si sessionPresent
est 1
, une session permanente est présente et tous les messages stockés pour le client sont remis au client une fois que celui-ci a reçu CONNACK
, comme décrit dans Trafic de messages après reconnexion à une session permanente. Si sessionPresent
est 1
, le client n’a pas besoin de se réabonner. Toutefois, si sessionPresent
est défini sur 0
, aucune session permanente n’est présente et le client doit se réabonner à ses filtres de rubrique.
Une fois que le client rejoint la session permanente, il peut publier des messages et à s’abonner aux filtres de rubrique sans aucun indicateur supplémentaire sur chaque opération.
Trafic de messages après reconnexion à une session permanente
Une session persistante représente une connexion permanente entre un client et un courtier de MQTT messages. Lorsqu’un client se connecte à l’agent de messages à l’aide d’une session permanente, ce dernier enregistre tous les abonnements souscrits par le client pendant la connexion. Lorsque le client se déconnecte, le courtier de messages conserve les messages d'une QoS 1 et les nouveaux messages d'une QoS 1 publiés sur les rubriques auxquelles le client s'est abonné. Les messages sont stockés conformément à la limite du compte. Les messages dépassant cette limite seront supprimés. Pour plus d’informations sur les limites de messages permanents, veuilelz consulter AWS IoT Core quotas de point de terminaison. Lorsque le client se reconnecte à sa session permanente, tous les abonnements sont réactivés et tous les messages stockés sont envoyés au client à un rythme maximum de 10 messages par seconde. Dans MQTT 5, si un QoS1 sortant avec un intervalle d'expiration des messages expire alors qu'un client est hors ligne, le client ne recevra pas le message expiré une fois la connexion rétablie.
Après la reconnexion, les messages stockés sont envoyés au client, à un débit limité à 10 messages stockés par seconde, ainsi que tout le trafic de messages en cours jusqu’à ce que la limite Publish
requests per second per connection
soit atteinte. Le taux de livraison des messages stockés étant limité, la remise de tous les messages stockés prendra plusieurs secondes si une session comporte plus de 10 messages stockés à remettre après la reconnexion.
Fin d’une session permanente
Les sessions permanentes peuvent prendre fin de différentes manières :
-
Le délai d’expiration de la session permanente est expiré. Le délai d’expiration de session permanente démarre lorsque l’agent de messages détecte qu’un client s’est déconnecté, soit en raison de la déconnexion du client, soit en raison de l’expiration du délai de connexion.
-
Le client envoie un message
CONNECT
qui définit l’indicateurcleanSession
sur1
.
Dans MQTT 3, la valeur par défaut du délai d'expiration des sessions persistantes est d'une heure, et cela s'applique à toutes les sessions du compte.
Dans MQTT 5, vous pouvez définir l'intervalle d'expiration de session pour chaque session ouverte CONNECT et pour chaque DISCONNECT paquet.
Pour l'intervalle d'expiration de session sur le DISCONNECT paquet :
-
Si la session en cours a un intervalle d'expiration de session de 0, vous ne pouvez pas définir un intervalle d'expiration de session supérieur à 0 sur le DISCONNECT paquet.
-
Si la session en cours a un intervalle d'expiration de session supérieur à 0 et que vous définissez l'intervalle d'expiration de session sur 0 sur le DISCONNECT paquet, la session sera terminée leDISCONNECT.
-
Sinon, l'intervalle d'expiration de session sur le DISCONNECT paquet mettra à jour l'intervalle d'expiration de session de la session en cours.
Note
Les messages stockés en attente d’être envoyés au client à la fin d’une session sont supprimés ; cependant, ils sont toujours facturés au tarif de messagerie standard, même s’ils n’ont pas pu être envoyés. Pour plus d’informations sur la tarification des messages, consultez AWS IoT Core
Tarification
Reconnexion après expiration d’une session permanente
Si un client ne se reconnecte pas à sa session permanente avant son expiration, celle-ci se termine et les messages enregistrés sont supprimés. Lorsqu’un client se reconnecte après l’expiration de la session et définit un indicateur cleanSession
sur 0
, le service crée une nouvelle session persistante. Les abonnements ou messages de la session précédente ne sont pas disponibles pour cette session car ils ont été supprimés à l’expiration de la session précédente.
Frais liés aux messages de session persistants
Les messages vous sont facturés Compte AWS lorsque le courtier de messages envoie un message à un client ou lors d'une session permanente hors ligne. Lorsqu’un appareil hors ligne doté d’une session permanente se reconnecte et reprend sa session, les messages enregistrés sont transmis à l’appareil et débités de nouveau sur votre compte. Pour plus d’informations sur la tarification des messages, consultez la section AWS IoT Core Tarification - Messagerie
Le délai d’expiration des sessions permanentes par défaut d’une heure peut être augmenté en utilisant le processus d’augmentation de limite standard. Notez que l’augmentation du délai d’expiration de la session peut augmenter le coût de vos messages, car ce délai supplémentaire pourrait permettre de stocker davantage de messages sur l’appareil hors ligne et ces messages supplémentaires seraient débités de votre compte au tarif de messagerie standard. L’heure d’expiration de la session est approximative et une session peut persister jusqu’à 30 minutes de plus que la limite du compte ; toutefois, une session ne sera pas inférieure à la limite du compte. Pour de plus amples informations sur les limites de sessions, veuillez consulter AWS Service Quotas.
MQTTmessages conservés
AWS IoT Core supporte le RETAIN drapeau décrit dans le MQTT protocole. Lorsqu'un client place l'RETAINindicateur sur un MQTT message qu'il publie, il AWS IoT Core enregistre le message. Il peut ensuite être envoyé aux nouveaux abonnés, récupéré en appelant l’opération GetRetainedMessage
et visualisé dans la AWS IoT console
Exemples d'utilisation de messages MQTT conservés
-
En tant que message de configuration initiale
MQTTles messages conservés sont envoyés à un client une fois que celui-ci s'est abonné à un sujet. Si vous souhaitez que tous les clients abonnés à un sujet reçoivent le message MQTT conservé juste après leur inscription, vous pouvez publier un message de configuration avec l'RETAINindicateur défini. Les clients abonnés reçoivent également des mises à jour de cette configuration chaque fois qu’un nouveau message de configuration est publié.
-
En tant que dernier message d’état connu
Les appareils peuvent placer l'RETAINindicateur sur les messages d'état actuel afin de AWS IoT Core les enregistrer. Lorsque les applications se connectent ou se reconnectent, elles peuvent s'abonner à cette rubrique et obtenir le dernier état signalé juste après s'être abonnées à la rubrique de message conservée. De cette façon, ils peuvent éviter d’avoir à attendre le prochain message de l’appareil pour voir l’état actuel.
Dans cette section :
Tâches courantes avec des messages MQTT conservés dans AWS IoT Core
AWS IoT Core enregistre MQTT les messages avec le RETAIN drapeau défini. Ces messages conservés sont envoyés à tous les clients abonnés au sujet, sous forme de MQTT message normal, et ils sont également stockés pour être envoyés aux nouveaux abonnés au sujet.
MQTTles messages conservés nécessitent des mesures politiques spécifiques pour autoriser les clients à y accéder. Pour des exemples d’utilisation des politiques relatives aux messages retenus, consultez Exemples de stratégies de messages conservés.
Cette section décrit les opérations courantes impliquant les messages retenus.
-
Création d’un message retenu
Le client détermine si un message est conservé lorsqu'il publie un MQTT message. Les clients peuvent définir l'RETAINindicateur lorsqu'ils publient un message à l'aide d'un appareil SDK. Les applications et les services peuvent définir l'RETAINindicateur lorsqu'ils utilisent l'
Publish
action pour publier un MQTT message.Un seul message par nom de rubrique est retenu. Un nouveau message dont l'RETAINindicateur est défini comme publié dans un sujet remplace tout message conservé existant qui a été envoyé au sujet plus tôt.
NOTE: vous ne pouvez pas publier dans un sujet réservé lorsque le RETAIN drapeau est activé.
-
Abonnement à un sujet de message retenu
Les clients s'abonnent aux sujets de message conservés comme à n'importe quel autre sujet de MQTT message. L'RETAINindicateur est activé pour les messages conservés reçus en vous abonnant à un sujet de message conservé.
Les messages conservés sont supprimés AWS IoT Core lorsqu'un client publie un message conservé avec une charge utile de 0 octet dans le sujet du message conservé. Les clients qui se sont abonnés à la rubrique du message retenu recevront également le message de 0 octet.
L’abonnement à un filtre de rubrique générique qui inclut un sujet de message retenu permet au client de recevoir les messages suivants publiés dans le sujet du message retenu, mais il ne transmet pas le message retenu lors de l’abonnement.
NOTE: pour recevoir un message conservé lors de l'abonnement, le filtre de sujet de la demande d'abonnement doit correspondre exactement au sujet du message conservé.
L'RETAINindicateur est activé pour les messages conservés reçus lors de l'inscription à un sujet de message conservé. Les messages retenus qui sont reçus par un client abonné après son abonnement ne le sont pas.
-
Récupération d’un message retenu
Les messages retenus sont remis automatiquement aux clients lorsqu’ils s’abonnent à la rubrique contenant le message retenu. Pour qu’un client reçoive le message retenu lors de son abonnement, il doit s’abonner au nom exact de rubrique du message retenu. L’abonnement à un filtre de rubrique générique qui inclut une rubrique de message retenu permet au client de recevoir les messages suivants publiés dans la rubrique du message retenu, mais il ne transmet pas le message retenu lors de l’abonnement.
Les services et applications peuvent répertorier et récupérer les messages retenus en appelant
ListRetainedMessages
etGetRetainedMessage
.Il n'est pas interdit à un client de publier des messages dans un sujet de message conservé sans définir l'RETAINindicateur. Cela peut entraîner des résultats inattendus, tels que le message retenu ne correspondant pas au message reçu en vous abonnant à la rubrique.
Avec MQTT 5, si l'intervalle d'expiration d'un message conservé est défini et que le message conservé expire, un nouvel abonné abonné à cette rubrique ne recevra pas le message conservé une fois son abonnement réussi.
-
Répertorier les sujets des messages retenus
Vous pouvez répertorier les messages retenus en appelant
ListRetainedMessages
et les messages retenus peuvent être consultés dans la AWS IoT console. -
Obtenir les détails des messages retenus
Vous pouvez obtenir les détails des messages retenus en appelant
GetRetainedMessage
et ils peuvent être consultés dans la AWS IoT console. -
Retenir un message volontaire
MQTTLes messages
créés lors de la connexion d'un appareil pourront-ils être conservés en plaçant le Will Retain
drapeau dans leConnect Flag bits
champ. -
Supprimer un message retenu
Les appareils, les applications et les services peuvent supprimer un message conservé en publiant un message avec l'RETAINindicateur défini et une charge utile de message vide (0 octet) dans le nom du sujet du message conservé à supprimer. Ces messages suppriment le message conservé de AWS IoT Core, sont envoyés aux clients abonnés au sujet, mais ils ne sont pas conservés par AWS IoT Core.
Les messages retenus peuvent également être supprimés de manière interactive en accédant au message retenu dans la AWS IoT console.
Les messages retenus supprimés à l’aide de la AWS IoT console envoient également un message de 0 octet aux clients abonnés au sujet du message retenu. Les messages retenus ne peuvent pas être restaurés après leur suppression. Un client devra publier un nouveau message retenu pour remplacer le message supprimé.
-
Débogage et résolution des problèmes liés aux messages retenus
La AWS IoT console
fournit plusieurs outils pour vous aider à résoudre les problèmes liés aux messages retenus : -
La page des messages retenus
La page Messages retenus de la console AWS IoT fournit une liste paginée des messages retenus qui ont été stockés par votre compte dans la région actuelle. À partir de cette page, vous pouvez :
-
Consultez les détails de chaque message retenu, tels que la charge utile du message, la QoS, l’heure à laquelle il a été reçu.
-
Mettez à jour le contenu d’un message retenu.
-
Supprimez un message retenu.
-
-
Le client MQTT de test
La page client de MQTT test de la AWS IoT console permet de s'abonner à des MQTT rubriques et de publier des articles. L'option de publication vous permet de définir le RETAIN drapeau sur les messages que vous publiez afin de simuler le comportement de vos appareils.
Certains résultats inattendus peuvent être le résultat de ces aspects de la manière dont les messages conservés sont implémentés dans AWS IoT Core.
-
Limit es de messages retenues
Lorsqu'un compte a stocké le nombre maximum de messages conservés, AWS IoT Core renvoie une réponse limitée aux messages publiés avec un paramètre RETAIN défini et à une charge utile supérieure à 0 octet, jusqu'à ce que certains messages conservés soient supprimés et que le nombre de messages conservés tombe en dessous de la limite.
-
Ordre de distribution des messages retenus
La séquence d’envoi des messages retenus et des messages souscrits n’est pas garantie.
-
Facturation et messages retenus
La publication de messages avec l'RETAINindicateur défini par un client, à l'aide de AWS IoT
la console ou par appel Publish
entraîne des frais de messagerie supplémentaires décrits dans la section AWS IoT Core Tarification - Messagerie
La récupération des messages conservés par un client, en utilisant AWS IoT la console ou en appelant GetRetainedMessage
entraîne des frais de messagerie en plus des frais API d'utilisation normaux. Les frais supplémentaires sont décrits dans la section AWS IoT Core
Tarification - Messagerie
MQTTLes messages
Pour plus d’informations sur les coûts de messagerie, consultez la section AWS IoT Core Tarification - Messagerie
Comparaison des messages MQTT conservés et des sessions MQTT persistantes
Les messages conservés et les sessions persistantes sont des fonctionnalités standard MQTT qui permettent aux appareils de recevoir des messages publiés alors qu'ils étaient hors ligne. Les messages retenus peuvent être publiés à partir de sessions permanentes. Cette section décrit les principaux aspects de ces fonctionnalités et explique comment elles fonctionnent ensemble.
Messages retenus |
Sessions persistantes |
|
---|---|---|
Fonctions principales |
Les messages retenus peuvent être utilisés pour configurer ou notifier de grands groupes d’appareils après leur connexion. Les messages retenus peuvent également être utilisés lorsque vous souhaitez que les appareils ne reçoivent que le dernier message publié dans une rubrique après une reconnexion. |
Les sessions permanentes sont utiles pour les appareils dotés d’une connectivité intermittente et susceptibles de manquer plusieurs messages importants. Les appareils peuvent se connecter à une session permanente pour recevoir les messages envoyés lorsqu’ils sont hors ligne. |
Exemples |
Les messages retenus peuvent fournir aux appareils des informations de configuration relatives à leur environnement lorsqu’ils se connectent. La configuration initiale peut inclure une liste d’autres rubriques de message auxquels il doit s’abonner ou des informations sur la façon dont il doit configurer son fuseau horaire local. |
Les appareils qui se connectent via un réseau cellulaire à connectivité intermittente peuvent utiliser des sessions permanentes pour éviter de manquer des messages importants envoyés alors qu’un appareil n’est pas couvert par le réseau ou doit éteindre sa radio cellulaire. |
Messages reçus lors de l’inscription initiale à une rubrique |
Une fois que vous vous êtes abonné à une rubrique contenant un message retenu, le message retenu le plus récent est reçu. |
Une fois que vous vous êtes abonné à une rubrique sans qu’un message soit retenu, aucun message n’est reçu tant qu’un message n’est pas publié dans la rubrique. |
Rubriques souscrites après reconnexion |
En l’absence de session permanente, le client doit s’abonner aux rubriques après s’être reconnecté. |
Les rubriques auxquelles vous êtes abonné sont restaurées après la reconnexion. |
Messages reçus après la reconnexion |
Une fois que vous vous êtes abonné à une rubrique contenant un message retenu, le message retenu le plus récent est reçu. |
Tous les messages publiés avec a QOS = 1 et auxquels vous êtes abonné avec a QOS = 1 alors que l'appareil était déconnecté sont envoyés après la reconnexion de l'appareil. |
Expiration de session/données |
En MQTT 3, les messages conservés n'expirent pas. Ils sont stockés jusqu’à ce qu’ils soient remplacés ou supprimés. Dans MQTT 5, les messages conservés expirent après l'intervalle d'expiration des messages que vous avez défini. Pour plus d’informations, consultez Expiration de messages. |
Les sessions permanentes expirent si le client ne se reconnecte pas dans le délai imparti. Après l'expiration d'une session permanente, les abonnements du client et les messages enregistrés publiés avec a QOS = 1 et auxquels on s'est abonné avec un QOS = 1 alors que l'appareil était déconnecté sont supprimés. Les messages expirés ne seront pas remis. Pour de amples informations sur l’expiration des sessions permanentes, veuillez consulter MQTTsessions persistantes. |
Pour plus d'informations sur les sessions permanentes, consultez MQTTsessions persistantes.
Avec les messages retenus, le client de publication détermine si un message doit être retenu et remis à un appareil après sa connexion, qu’il ait déjà eu une session ou non. Le choix de stocker un message est fait par le diffuseur de publication et le message stocké est remis à tous les clients actuels et futurs qui s’abonnent avec un abonnement QoS 0 ou QoS 1. Les messages retenus ne contiennent qu’un seul message à la fois sur une rubrique donnée.
Lorsqu'un compte a stocké le nombre maximum de messages conservés, AWS IoT Core renvoie une réponse limitée aux messages publiés avec un paramètre RETAIN défini et à une charge utile supérieure à 0 octet, jusqu'à ce que certains messages conservés soient supprimés et que le nombre de messages conservés tombe en dessous de la limite.
MQTTmessages conservés et AWS IoT Device Shadows
Les messages retenus et les Device Shadows retiennent les données d’un appareil, mais ils se comportent différemment et répondent à des objectifs différents. Cette section décrit leurs similitudes et leurs différences.
Messages retenus |
Device Shadows |
|
---|---|---|
La charge utile des messages possède une structure ou un schéma prédéfini |
Tel que défini par l’implémentation. MQTTne spécifie pas de structure ou de schéma pour la charge utile de ses messages. |
AWS IoT prend en charge une structure de données spécifique. |
La mise à jour de la charge utile des messages génère des messages d’événement |
La publication d’un message retenu envoie le message aux clients abonnés, mais ne génère pas de messages de mise à jour supplémentaires. |
La mise à jour d’un Device Shadow génère des messages de mise à jour décrivant le changement. |
Les mises à jour des messages sont numérotées |
Les messages retenus ne sont pas numérotés automatiquement. | Les documents Device Shadow sont dotés de numéros de version et d’horodatage automatiques. |
La charge utile du message est attachée à une ressource d’objet |
Les messages retenus ne sont pas attachés à une ressource d’objet. |
Les Device Shadows sont attachés à une ressource d’objets. |
Mise à jour des éléments individuels de la charge utile du message |
Les éléments individuels du message ne peuvent pas être modifiés sans mettre à jour l’intégralité de la charge utile du message. |
Les éléments individuels d’un document Device Shadow peuvent être mis à jour sans qu’il soit nécessaire de mettre à jour l’intégralité du document Device Shadow. |
Le client reçoit les données des messages lors de l’abonnement |
Le client reçoit automatiquement un message retenu après s’être abonné à une rubrique contenant un message retenu. |
Les clients peuvent s’abonner aux mises à jour de Device Shadow, mais ils doivent demander délibérément l’état actuel. |
Indexation et consultabilité |
Les messages retenus ne sont pas indexés pour la recherche. |
L’indexation de flotte indexe les données Device Shadow à des fins de recherche et d’agrégation. |
MQTTMessages du dernier testament (LWT)
Last Will and Testament (LWT) est une fonctionnalité deMQTT. Les clients peuvent ainsi spécifier un message que le courtier publiera sur un sujet défini par le client et enverra à tous les clients abonnés au sujet en cas de déconnexion non initiée. LWT Le message spécifié par les clients est appelé LWT message ou message testamentaire, et le sujet défini par les clients est appelé sujet testamentaire. Vous pouvez spécifier un LWT message lorsqu'un appareil se connecte au broker. Ces messages peuvent être retenus en plaçant l’indicateur Will
Retain
dans le champ Connect Flag bits
pendant la connexion. Par exemple, si l’indicateur Will Retain
est défini sur 1
, un message Will sera stocké dans l’agent dans le rubrique Will associée. Pour plus d’informations, consultez Messages volontaires
L’agent retiendra les messages Will jusqu’à ce qu’une déconnexion non initiée se produise. Lorsque cela se produit, le courtier publiera les messages à tous les clients abonnés à la rubrique Will pour notifier la déconnexion. Si le client se déconnecte du courtier avec une déconnexion initiée par le client à l'aide du MQTT DISCONNECT message, le courtier ne publiera pas les messages stockés. LWT Dans tous les autres cas, les LWT messages seront envoyés. Pour une liste complète des scénarios de déconnexion dans lesquels le courtier enverra les LWT messages, consultez la section Événements de connexion/déconnexion.
En utilisant connectAttributes
ConnectAttributes
vous permettent de spécifier les attributs que vous souhaitez utiliser dans votre message de connexion dans vos IAM politiques, tels que PersistentConnect
etLastWill
. Grâce à ConnectAttributes
, vous pouvez ainsi créer des politiques qui n’autorisent pas les appareils à accéder aux nouvelles fonctionnalités par défaut, ce qui peut être utile si un appareil est compromis.
connectAttributes
prend en charge les fonctions suivantes :
PersistentConnect
-
Utilisez la fonctionnalité
PersistentConnect
pour enregistrer tous les abonnements effectués par le client pendant la connexion lorsque la connexion entre le client et le courtier est interrompue. LastWill
-
Utilisez la fonctionnalité
LastWill
pour publier un messageLastWillTopic
lorsqu’un client se déconnecte de manière inattendue.
Par défaut, votre politique prévoit une connexion non permanente et aucun attribut n’est transmis pour cette connexion. Vous devez spécifier une connexion permanente dans votre IAM politique si vous souhaitez en avoir une.
Pour des exemples ConnectAttributes
, consultez la section Exemples de politiques de connexion.
MQTT5 fonctionnalités prises en charge
AWS IoT Core le support pour MQTT 5 est basé sur la spécification MQTT v5.0
AWS IoT Core prend en charge les MQTT 5 fonctionnalités suivantes :
Abonnements partagés
AWS IoT Core prend en charge les abonnements partagés pour MQTT 3 et MQTT 5. Les abonnements partagés permettent à plusieurs clients de partager un abonnement à une rubrique et un seul client recevra les messages publiés sur cette rubrique selon une distribution aléatoire. Les abonnements partagés peuvent équilibrer efficacement la charge MQTT des messages entre un certain nombre d'abonnés. Supposons, par exemple, que 1000 appareils publient sur le même rubrique et que 10 applications principales traitent ces messages. Dans ce cas, les applications principales peuvent s’abonner à la même rubrique et chacune recevra aléatoirement des messages publiés par les appareils sur le rubrique partagé. Cela revient à « partager » efficacement la charge de ces messages. Les abonnements partagés permettent également une meilleure résilience. Lorsqu’une application principale se déconnecte, l’agent répartit la charge entre les abonnés restants du groupe.
Pour utiliser les abonnements partagés, les clients s’abonnent au filtre de rubrique d’un abonnement partagé comme suit :
$share/{ShareName}/{TopicFilter}
-
$share
est une chaîne littérale indiquant le filtre de rubrique d’un abonnement partagé, qui doit commencer par$share
. -
{ShareName}
est une chaîne de caractères qui indique le nom partagé utilisé par un groupe d’abonnés. Le filtre de rubrique d’un abonnement partagé doit contenir unShareName
et être suivi du caractère/
. Le{ShareName}
ne doit pas inclure les caractères suivants :/
,+
, ou#
. La taille maximale de{ShareName}
est de 128 octets. -
{TopicFilter}
suit la même syntaxe de filtre de rubrique qu’un abonnement non partagé. La taille maximale de{TopicFilter}
est de 256 octets. -
Les deux barres obliques requises (
/
) car les$share/{ShareName}/{TopicFilter}
ne sont pas incluses dans le nombre maximum de barres obliques dans la rubrique et dans la limite du filtre de rubrique.
Les abonnements identiques {ShareName}/{TopicFilter}
appartiennent au même groupe d’abonnements partagés. Vous pouvez créer plusieurs groupes d’abonnements partagés et ne pas dépasser la limite d’abonnements partagés par groupe. Pour plus d’informations, veuillez consulter la rubrique Points de terminaison et quotas AWS IoT Core depuis la Référence générale AWS .
Les tableaux suivants comparent les abonnements non partagés et les abonnements partagés :
Abonnement | Description | Exemples de filtres de rubrique |
---|---|---|
Abonnements non partagés | Chaque client crée un abonnement distinct pour recevoir les messages publiés. Lorsqu’un message est publié dans une rubrique, tous les abonnés à ce rubrique reçoivent une copie du message. |
|
Abonnements partagés | Plusieurs clients peuvent partager un abonnement à un rubrique et un seul client recevra les messages publiés sur ce rubrique de manière aléatoire. |
|
Flux d’abonnements non partagés | Flux d’abonnements partagés |
---|---|
|
|
Remarques importantes concernant l’utilisation des abonnements partagés
-
Lorsqu’une tentative de publication auprès d’un abonné QoS0 échoue, aucune nouvelle tentative n’a lieu et le message est supprimé.
-
Lorsqu’une tentative de publication à destination d’un abonné QoS1 avec une session propre échoue, le message est envoyé à un autre abonné du groupe pour plusieurs tentatives de nouvelle tentative. Les messages qui ne parviennent pas à être remis après toutes les tentatives seront supprimés.
-
Lorsqu’une tentative de publication auprès d’un abonné QoS1 avec des sessions permanentes échoue parce que l’abonné est hors ligne, les messages ne sont pas mis en file d’attente et sont envoyés à un autre abonné du groupe. Les messages qui ne parviennent pas à être remis après toutes les tentatives seront supprimés.
-
Les abonnements partagés ne reçoivent pas de messages retenus.
-
Lorsque les abonnements partagés contiennent des caractères génériques (# ou +), plusieurs abonnements partagés peuvent correspondre à un rubrique. Dans ce cas, l’agent de messages copie le message de publication et l’envoie à un client aléatoire dans chaque abonnement partagé correspondant. Le comportement des caractères génériques des abonnements partagés peut être expliqué dans le schéma suivant.
Dans cet exemple, trois abonnements partagés correspondent au MQTT sujet de publication
sports/tennis
. L’agent de messages copie le message publié et l’envoie à un client aléatoire dans chaque groupe correspondant.Le client 1 et le client 2 partagent l’abonnement :
$share/consumer1/sports/tennis
Le client 3 et le client 4 partagent l’abonnement :
$share/consumer1/sports/#
Le client 5 et le client 6 partagent l’abonnement :
$share/consumer2/sports/tennis
Pour plus d’informations sur les limites des abonnements partagés, consultez la section AWS IoT Core Points de terminaison et quotas de la AWS référence générale. Pour tester les abonnements partagés à l'aide du AWS IoT MQTT client dans la AWS IoT console
Démarrage correct et expiration de session
Vous pouvez utiliser Clean Start et Session Expiration pour gérer vos sessions permanentes avec plus de flexibilité. Un indicateur Clean Start indique si la session doit démarrer sans utiliser une session existante. Un intervalle d’expiration de session indique la durée pendant laquelle la session doit être retenue après une déconnexion. L’intervalle d’expiration des sessions peut être modifié lors de la déconnexion. Pour de plus amples informations, veuillez consulter MQTTsessions persistantes.
Code de raison sur tous ACKs
Vous pouvez déboguer ou traiter les messages d’erreur plus facilement à l’aide des codes de motif. Les codes de motif sont renvoyés par l’agent de messages en fonction du type d’interaction avec l’agent (s’abonner, publier, accuser réception). Pour plus d'informations, consultez la section Codes de MQTT motif. Pour une liste complète des codes de MQTT raison, voir la spécification MQTT v5
Alias de rubrique
Vous pouvez remplacer le nom d’une rubrique par un alias de rubrique, qui est un entier de deux octets. L'utilisation d'alias de rubrique permet d'optimiser la transmission des noms de rubriques afin de réduire potentiellement les coûts de données sur les services de données mesurés. AWS IoT Core a une limite par défaut de 8 alias de rubrique. Pour plus d’informations, veuillez consulter la rubrique Points de terminaison et quotas AWS IoT Core depuis la Référence générale AWS .
Expiration du message
Vous pouvez ajouter des valeurs d’expiration aux messages publiés. Ces valeurs représentent l’intervalle d’expiration des messages en secondes. Si un message n’a pas été envoyé aux abonnés dans cet intervalle, il expirera et sera supprimé. Si vous ne définissez pas la valeur d’expiration du message, celui-ci n’expirera pas.
À l’aller, l’abonné recevra un message indiquant le temps restant dans l’intervalle d’expiration. Par exemple, si un message de publication entrant expire 30 secondes et qu’il est acheminé vers l’abonné au bout de 20 secondes, le champ d’expiration du message sera mis à jour à 10. Il est possible que le message reçu par l'abonné soit actualisé à MEI 0. En effet, dès que le temps restant est inférieur ou égal à 999 ms, il sera mis à jour à 0.
Dans AWS IoT Core, l'intervalle d'expiration minimal des messages est de 1. Si l’intervalle est défini sur 0 du côté client, il sera ajusté à 1. L’intervalle d’expiration maximal des messages est de 604 800 (7 jours). Toute valeur supérieure à cette valeur sera ajustée à la valeur maximale.
Dans les communications entre versions, le comportement relatif à l'expiration du message est déterminé par la MQTT version du message de publication entrant. Par exemple, un message expirant envoyé par une session connectée via MQTT5 peut expirer pour les appareils abonnés à des MQTT3 sessions. Le tableau ci-dessous indique comment l’expiration des messages prend en charge les types de messages de publication suivants :
Publier un type de message | Intervalle d’expiration des messages |
---|---|
Publier régulièrement | Si un serveur ne parvient pas à délivrer le message dans le délai spécifié, le message expiré sera supprimé et l’abonné ne le recevra pas. Cela inclut les situations telles que lorsqu’un appareil ne publie pas ses messages QoS 1. |
Conserver | Si un message retenu expire et qu’un nouveau client s’abonne à la rubrique, le client ne recevra pas le message lors de son inscription. |
Dernier testament | L’intervalle entre les derniers messages testamentaires commence une fois que le client se déconnecte et que le serveur tente de transmettre le dernier testament à ses abonnés. |
Messages mis en file d’attente | Si un QoS1 sortant avec intervalle d’expiration des messages expire lorsqu’un client est hors ligne, le client ne recevra pas le message expiré après la reprise de la session permanente. |
MQTT5 autres fonctionnalités
Déconnexion du serveur
Lorsqu'une déconnexion se produit, le serveur peut envoyer de manière proactive au client un message DISCONNECT pour notifier la fermeture de la connexion avec un code de motif de déconnexion.
Requête/réponse
Les éditeurs peuvent demander qu’une réponse soit envoyée par le destinataire à un rubrique spécifié par le diffuseur de publication lors de la réception.
Taille maximale du paquet
Le client et le serveur peuvent spécifier indépendamment la taille de paquet maximale qu’ils prennent en charge.
Format de charge utile et type de contenu
Vous pouvez spécifier le format de charge utile (binaire, texte) et le type de contenu lorsqu’un message est publié. Ils sont transmis au destinataire du message.
MQTT5 propriétés
MQTTLes 5 propriétés sont des ajouts importants à la MQTT norme pour prendre en charge les MQTT 5 nouvelles fonctionnalités telles que l'expiration de session et le modèle Request/Response. Dans AWS IoT Core, vous pouvez créer des règles permettant de transférer les propriétés des messages sortants, ou utiliser HTTPPublier pour publier MQTT des messages contenant certaines des nouvelles propriétés.
Le tableau suivant répertorie les MQTT 5 propriétés prises en AWS IoT Core charge.
Propriété | Description | Type d’entrée | Paquets |
---|---|---|---|
Indicateur de format de charge utile | Valeur booléenne qui indique si la charge utile est formatée en -8. UTF | Octet | PUBLISH, CONNECT |
Type de contenu | Chaîne UTF -8 qui décrit le contenu de la charge utile. | UTF-8 cordes | PUBLISH, CONNECT |
Rubrique de réponse | Chaîne UTF -8 qui décrit le sujet sur lequel le destinataire doit publier dans le cadre du flux de demande-réponse. La rubrique ne doit pas avoir de caractères génériques. | UTF-8 cordes | PUBLISH, CONNECT |
Données de corrélation | Données binaires utilisées par l’expéditeur du message de demande pour identifier la demande à laquelle correspond le message de réponse. | Binaire | PUBLISH, CONNECT |
Propriétés de l’utilisateur | Une paire UTF de 8 cordes. Cette propriété peut apparaître plusieurs fois dans un même paquet. Les destinataires recevront les paires clé-valeur dans l’ordre dans lequel elles sont envoyées. | UTF-paire de 8 cordes | CONNECTPUBLISH, Propriétés testamentaires,SUBSCRIBE,DISCONNECT, UNSUBSCRIBE |
Intervalle d’expiration des messages | Entier de 4 octets qui représente l’intervalle d’expiration des messages en secondes. S’il est absent, le message n’expire jamais. | Entier de 4 octets | PUBLISH, CONNECT |
Intervalle d’expiration des sessions |
Un entier de 4 octets qui représente l'intervalle d'expiration de la session en secondes. AWS IoT Core prend en charge un maximum de 7 jours, avec un maximum d'une heure par défaut. Si la valeur que vous avez définie dépasse le maximum de votre compte, la valeur ajustée AWS IoT Core sera renvoyée dans leCONNACK. |
Entier de 4 octets | CONNECT, CONNACK, DISCONNECT |
Identifiant client attribué | ID client aléatoire généré AWS IoT Core lorsqu'aucun identifiant client n'est spécifié par les appareils. L’identifiant client aléatoire doit être un nouvel identifiant client qui n’est utilisé par aucune autre session actuellement gérée par le courtier. | UTF-8 cordes | CONNACK |
Serveur Keep Alive | Un entier de 2 octets qui représente la durée de rétention attribuée par le serveur. Le serveur déconnecte le client s’il est inactif pendant une durée supérieure à la durée de conservation. | Entier de 2 octets | CONNACK |
Demander des informations sur le problème | Valeur booléenne qui indique si la chaîne de motif ou les propriétés utilisateur sont envoyées en cas d’échec. | Octet | CONNECT |
Recevoir maximum | Un entier de 2 octets qui représente le nombre maximum de paquets PUBLISH QOS > 0 pouvant être envoyés sans recevoir dePUBACK. | Entier de 2 octets | CONNECT, CONNACK |
Alias maximal du rubrique | Cette valeur indique la valeur la plus élevée qui sera acceptée comme alias de rubrique. La valeur par défaut est 0. | Entier de 2 octets | CONNECT, CONNACK |
QoS maximale | La valeur maximale de QoS prise en charge. AWS IoT Core La valeur par défaut est 1. AWS IoT Core ne prend pas en charge QoS2. | Octet | CONNACK |
Retenir disponible |
Valeur booléenne qui indique si le courtier de AWS IoT Core messages prend en charge les messages conservés. La valeur par défaut est 1. |
Octet | CONNACK |
Taille maximale du paquet | Taille maximale des paquets qui AWS IoT Core acceptent et envoient. Ne peut pas dépasser 128 Ko. | Entier de 4 octets | CONNECT, CONNACK |
Abonnement Wildcard disponible |
Valeur booléenne qui indique si le courtier de AWS IoT Core messages prend en charge Wildcard Subscription Available. La valeur par défaut est 1. |
Octet | CONNACK |
Identifiant d’abonnement disponible |
Valeur booléenne qui indique si le courtier de AWS IoT Core messages prend en charge l'identifiant d'abonnement disponible. La valeur par défaut est 0. |
Octet | CONNACK |
MQTTcodes de raison
MQTT5 introduit un meilleur signalement des erreurs avec les réponses au code de raison. AWS IoT Core peut renvoyer des codes de motif, y compris, mais sans s'y limiter, les suivants regroupés par paquets. Pour une liste complète des codes de raison pris en charge par MQTT 5, consultez les spécifications MQTT 5
Valeur | Hex | Nom du code de motif | Description |
---|---|---|---|
0 | 0x00 | Réussite | La connexion est acceptée. |
128 | 0x80 | Erreur non spécifiée | Le serveur ne souhaite pas révéler le motif de l’échec, sinon aucun des autres codes de motif ne s’applique. |
133 | 0x85 | Identifiant du client non valide | L’identifiant du client est une chaîne valide mais n’est pas autorisé par le serveur. |
134 | 0x86 | Nom d’utilisateur ou mot de passe incorrect | Le serveur n’accepte pas le nom d’utilisateur ou le mot de passe spécifiés par le client. |
135 | 0x87 | Non autorisé | Le client n’est pas autorisé à se connecter. |
144 | 0x90 | Nom de la rubrique non valide | Le nom de la rubrique testamentaire est correctement formé mais n’est pas accepté par le serveur. |
151 | 0x97 | Quota dépassé | Une limite de mise en œuvre ou imposée par l’administration a été dépassée. |
155 | 0 x 9 B | QoS n’est pas pris en charge. | Le serveur ne prend pas en charge la QoS définie dans Will QoS. |
Valeur | Hex | Nom du code de motif | Description |
---|---|---|---|
0 | 0x00 | Réussite | Le message est accepté. La publication du message QoS 1 se poursuit. |
128 | 0x80 | Erreur non spécifiée | Le destinataire n’accepte pas la publication, mais soit ne souhaite pas en révéler la raison, soit elle ne correspond pas à l’une des autres valeurs. |
135 | 0x87 | Non autorisé | Ce n'PUBLISHest pas autorisé. |
144 | 0x90 | Nom de la rubrique non valide | Le nom de la rubrique n’est pas mal formé, mais il n’est pas accepté par le client ou le serveur. |
145 | 0x91 | Identifiant de paquet en cours d’utilisation | L’identifiant du paquet est déjà utilisé. Cela peut indiquer une incompatibilité de l’état de session entre le client et le serveur. |
151 | 0x97 | Quota dépassé | Une limite de mise en œuvre ou imposée par l’administration a été dépassée. |
Valeur | Hex | Nom du code de motif | Description |
---|---|---|---|
129 | 0x81 | Paquet incorrect | Le paquet reçu n’est pas conforme à cette spécification. |
130 | 0x82 | Erreur de protocole | Un paquet inattendu ou en panne a été reçu. |
135 | 0x87 | Non autorisé | La demande n'est pas autorisée. |
139 | 0 x 8 B | Arrêt du serveur | Le serveur est en train de s’arrêter. |
141 | 0 x 8D | Délai d’expiration de Keep Alive | La connexion est fermée car aucun paquet n’a été reçu pendant 1,5 fois la durée de Keep Alive. |
142 | 0 x 8E | Session prise en charge | Une autre connexion utilisant le même ClientID s’est connectée, ce qui a entraîné la fermeture de cette connexion. |
143 | 0 x 8 F | Filtre de rubrique invalide | Le filtre de rubrique est correctement formé mais n’est pas accepté par le serveur. |
144 | 0x90 | Nom de la rubrique non valide | Le nom de la rubrique est correctement formé mais n’est pas accepté par ce client ou serveur. |
147 | 0x93 | Dépassement du maximum de réception | Le client ou le serveur a reçu une publication supérieure à la valeur maximale de réception pour laquelle il n'a pas envoyé PUBACK ouPUBCOMP. |
148 | 0x94 | Alias de rubrique invalide | Le client ou le serveur a reçu un PUBLISH paquet contenant un alias de sujet supérieur à l'alias de sujet maximal qu'il a envoyé dans le CONNACK paquet CONNECT ou. |
151 | 0x97 | Quota dépassé | Une limite de mise en œuvre ou imposée par l’administration a été dépassée. |
152 | 0x98 | Action administrative | La connexion est interrompue suite à une action administrative. |
155 | 0 x 9 B | QoS n’est pas pris en charge. | Le client a spécifié une QoS supérieure à la QoS spécifiée dans une QoS maximale dans le. CONNACK |
161 | 0 x A1 | Identifiants d’abonnement non pris en charge | Le serveur ne prend pas en charge les identifiants d’abonnement ; l’abonnement n’est pas accepté. |
Valeur | Hex | Nom du code de motif | Description |
---|---|---|---|
0 | 0x00 | QoS 0 accordé | L’abonnement est accepté et la QoS maximale envoyée sera de QoS 0. Il s’agit peut-être d’une QoS inférieure à celle demandée. |
1 | 0x01 | QoS 1 accordé | L’abonnement est accepté et la QoS maximale envoyée sera de QoS 1. Il s’agit peut-être d’une QoS inférieure à celle demandée. |
128 | 0x80 | Erreur non spécifiée | L’abonnement n’est pas accepté et le serveur ne souhaite pas en révéler le motif ou aucun des autres codes de motif ne s’applique. |
135 | 0x87 | Non autorisé | Le client n’est pas autorisé à souscrire cet abonnement. |
143 | 0 x 8 F | Filtre de rubrique invalide | Le filtre de rubrique est correctement formé mais n’est pas autorisé pour ce client. |
145 | 0x91 | Identifiant de paquet en cours d’utilisation | L’identifiant de paquet spécifié est déjà utilisé. |
151 | 0x97 | Quota dépassé | Une limite de mise en œuvre ou imposée par l’administration a été dépassée. |
Valeur | Hex | Nom du code de motif | Description |
---|---|---|---|
0 | 0x00 | Réussite | L'abonnement est supprimé. |
128 | 0x80 | Erreur non spécifiée | Le désabonnement n’a pas pu être effectué et le serveur ne souhaite pas en révéler le motif ou aucun des autres codes de motif ne s’applique. |
143 | 0 x 8 F | Filtre de rubrique invalide | Le filtre de rubrique est correctement formé mais n’est pas autorisé pour ce client. |
145 | 0x91 | Identifiant de paquet en cours d’utilisation | L’identifiant de paquet spécifié est déjà utilisé. |
AWS IoT différences par rapport MQTT aux spécifications
L'implémentation du courtier de messages est basée sur les spécifications MQTT v3.1.1
-
AWS IoT ne prend pas en charge les paquets suivants pour MQTT 3 : PUBRECPUBREL, etPUBCOMP.
-
AWS IoT ne prend pas en charge les paquets suivants pour MQTT 5 : PUBRECPUBREL,PUBCOMP, etAUTH.
-
AWS IoT ne prend pas en charge la redirection de MQTT 5 serveurs.
-
AWS IoT prend en charge les niveaux de MQTT qualité de service (QoS) 0 et 1 uniquement. AWS IoT ne prend pas en charge la publication ou l'abonnement avec QoS de niveau 2. Lorsque le niveau 2 de QoS est demandé, le courtier de messages n'envoie pas de « ou ». PUBACK SUBACK
-
En effet AWS IoT, l'abonnement à une rubrique dont le niveau de QoS est 0 signifie qu'un message est délivré zéro fois ou plus. Un message peut être remis plusieurs fois. Les messages remis plusieurs fois peuvent être envoyés avec un ID de paquet différent. Dans ces cas, le DUP drapeau n'est pas activé.
-
Lorsqu'il répond à une demande de connexion, le courtier de messages envoie un CONNACK message. Ce message contient un indicateur précisant si la connexion reprend une session précédente.
-
Avant d'envoyer des paquets de contrôle supplémentaires ou une demande de déconnexion, le client doit attendre que le CONNACK message soit reçu sur son appareil par le courtier de AWS IoT messages.
-
Lorsqu'un client s'abonne à un sujet, il peut y avoir un délai entre le moment où le courtier de messages envoie un message SUBACK et le moment où le client commence à recevoir de nouveaux messages correspondants.
-
Lorsqu’un client utilise le caractère générique
#
dans le filtre de rubrique pour s’abonner à une rubrique, toutes les chaînes situées à son niveau ou inférieur dans la hiérarchie des rubriques sont mises en correspondance. Cependant, la rubrique parent ne correspond pas. Par exemple, un abonnement à la rubriquesensor/#
reçoit les messages publiés dans les rubriquessensor/
,sensor/temperature
,sensor/temperature/room1
, mais pas les messages publiés danssensor
. Pour plus d’informations sur les caractères génériques, consultez Filtres de rubrique. -
L'agent de messages utilise l'ID de client pour identifier chaque client. L'ID client est transmis par le client au courtier de messages dans le cadre de la MQTT charge utile. Deux clients possédant le même ID de client ne peuvent pas être connectés simultanément à l’agent de messages. Lorsqu'un client se connecte à l'agent de messages à l'aide d'un ID de client qu'un autre client utilise, la nouvelle connexion client est acceptée et le client connecté précédemment est déconnecté.
-
Dans de rares cas, le courtier de messages peut renvoyer le même PUBLISH message logique avec un identifiant de paquet différent.
-
L’abonnement aux filtres de rubrique contenant un caractère générique ne permet pas de recevoir les messages retenus. Pour recevoir un message retenu, la demande d’abonnement doit contenir un filtre de rubrique correspondant exactement à la rubrique du message retenu.
-
Le courtier de messages ne garantit pas l'ordre dans lequel les messages ACK sont reçus.
-
AWS IoT peut avoir des limites différentes des spécifications. Pour plus d’informations veuillez consulter AWS IoT Core Limites et quotas de l’agent de messages et des protocoles dans le AWS IoT Guide de référence.
-
Le MQTT DUP drapeau n'est pas pris en charge.