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
Le MQTT
AWS IoT Core prend en charge les connexions de périphériques qui utilisent le protocole MQTT et le protocole MQTT over WSS 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. Les SDK pour AWS IoT appareils prennent en charge les fonctions nécessaires aux appareils et aux clients pour se connecter aux AWS IoT services et y accéder. Les SDK pour appareils prennent en charge les protocoles d'authentification requis par les AWS IoT services et les exigences en matière d'ID de connexion requises par le protocole MQTT et les protocoles MQTT over WSS. Pour plus d'informations sur la façon de se connecter à AWS IoT l'aide des kits SDK du AWS périphérique et pour obtenir des liens vers des exemples de AWS IoT langues prises en charge, consultezConnexion à MQTT à l'aide des SDK du AWS IoT périphérique. Pour plus d’informations sur les méthodes d’authentification et de mappage de ports pour les messages MQTT, consultez Protocols, port mappings, and authentication (Protocoles, mappages de ports et authentification).
Bien que nous vous recommandions d'utiliser les SDK de l' AWS IoT appareil pour vous y connecter AWS IoT, ils ne sont pas obligatoires. Si vous n'utilisez pas les SDK de l' AWS IoT appareil, vous devez toutefois fournir la sécurité de connexion et de communication nécessaire. Les clients doivent envoyer l’extension TLS SNI (Server Name Indication)
Dans cette rubrique :
- Connexion à MQTT à l'aide des SDK du AWS IoT périphérique
- Options de qualité de service (QoS) MQTT
- Sessions permanentes MQTT
- MQTT a retenu les messages
- Messages MQTT Last Will and Testament (LWT)
- Utilisation de ConnectAttributes
- Fonctionnalités prises en charge par MQTT 5
- Propriétés MQTT 5
- Codes de motif MQTT
- AWS IoT différences par rapport aux spécifications MQTT
Connexion à MQTT à l'aide des SDK du AWS IoT périphérique
Cette section contient des liens vers les kits SDK du AWS IoT périphérique et vers le code source d'exemples de programmes illustrant comment connecter un appareil à AWS IoT. Les exemples d'applications liés ici montrent comment se connecter à AWS IoT l'aide du protocole MQTT et de MQTT via WSS.
Note
Les SDK du AWS IoT périphérique ont publié un client MQTT 5.
Options de qualité de service (QoS) MQTT
AWS IoT et les SDK pour AWS IoT appareils prennent en charge les niveaux de qualité de service (QoS) MQTT0
1
Le protocole MQTT définit un troisième niveau de QoS, le 2
niveau, AWS IoT mais ne le supporte pas. Seul le protocole MQTT prend en charge la fonctionnalité QoS. HTTPS prend 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 |
Sessions permanentes MQTT
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 permanente MQTT en envoyant un message CONNECT
et en définissant l’indicateur cleanSession
sur 0
. 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 permanentes en définissant l’indicateur Clean Start
et Session 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 message CONNECT, la valeur par défaut est 0.
Démarrage propre MQTT 5 et expiration de session | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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. |
Dans MQTT 5, si vous définissez Clean Start
= 1
et Session
Expiry Interval
=0
, cela équivaut à une session propre de MQTT 3. Si vous définissez Clean Start
= 0
et Session Expiry Interval
>0
, cela équivaut à une session permanente MQTT 3.
Note
Les sessions permanentes de plusieurs versions MQTT (MQTT 3 et MQTT 5) ne sont pas prises en charge. Une session permanente MQTT 3 ne peut pas être reprise en tant que session 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 permanente représente une connexion continue entre un client et un agent de messages MQTT. 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 l’intervalle d’expiration des messages expire alors qu’un client est hors ligne, une fois la connexion rétablie, le client ne recevra pas le message expiré.
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 permanentes 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 sur les paquets CONNECT et DISCONNECT.
Pour l’intervalle d’expiration de session sur le paquet DISCONNECT :
-
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 paquet DISCONNECT.
-
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 paquet DISCONNECT, la session sera terminée sur DISCONNECT.
-
Sinon, l’intervalle d’expiration de session sur le paquet DISCONNECT 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.
MQTT a retenu les messages
AWS IoT Core supporte l'indicateur RETAIN décrit dans le protocole MQTT. Lorsqu'un client définit l'indicateur RETAIN sur un message MQTT 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 retenus au format MQTT
-
En tant que message de configuration initiale
Les messages retenus au format MQTT sont envoyés à un client une fois que celui-ci s’est abonné à une rubrique. 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'indicateur RETAIN activé. 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 définir l’indicateur RETAIN sur les messages d’état actuel afin que AWS IoT Core les enregistre. 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 retenus au format MQTT dans AWS IoT Core
AWS IoT Core enregistre les messages MQTT avec l'indicateur RETAIN activé. Ces messages retenus sont envoyés à tous les clients abonnés au sujet, sous la forme d’un message MQTT normal, et ils sont également stockés pour être envoyés aux nouveaux abonnés à la rubrique.
Les messages retenus au format MQTT nécessitent des actions 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 retenu lorsqu’il publie un message MQTT. Les clients peuvent définir l’indicateur RETAIN lorsqu’ils publient un message à l’aide d’un SDK des appareils. Les applications et les services peuvent définir l’indicateur RETAIN lorsqu’ils utilisent l’
Publish
action pour publier un message MQTT.Un seul message par nom de rubrique est retenu. Un nouveau message dont l’indicateur RETAIN est défini et publié dans une rubrique remplace tout message retenu existant qui a été envoyé au sujet précédemment.
REMARQUE : Vous ne pouvez pas publier dans une rubrique réservée lorsque l’indicateur RETAIN est activé.
-
Abonnement à un sujet de message retenu
Les clients s’abonnent aux rubriques de message retenus comme ils le feraient pour n’importe quel autre rubrique de message MQTT. L’indicateur RETAIN est activé pour les messages retenus reçus en vous abonnant à un sujet de message retenu.
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.
REMARQUE : Pour recevoir un message retenu lors de l’abonnement, le filtre de rubrique de la demande d’abonnement doit correspondre exactement à la rubrique du message retenu.
L’indicateur RETAIN est activé pour les messages retenus reçus lors de l’abonnement à une rubrique de message retenu. 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
.Aucun client n’est empêché de publier des messages dans une rubrique de message retenu sans définir l’indicateur RETAIN. 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 retenu est défini et que le message retenu expire, un nouvel abonné qui s’abonne à cette rubrique ne recevra pas le message retenu 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
Les messages MQTT Will
créés lorsqu’un appareil se connecte peuvent être retenus en définissant l’indicateur Will Retain
dans le champConnect Flag bits
. -
Supprimer un message retenu
Les appareils, les applications et les services peuvent supprimer un message retenu en publiant un message avec l’indicateur RETAIN activé et une charge utile de message vide (0 octet) dans le nom du sujet du message retenu à 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 de test MQTT
La page du client de test MQTT de la console AWS IoT permet de s’abonner et de publier sur des sujets MQTT. L’option de publication vous permet de définir l’indicateur RETAIN 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 l'option RETAIN définie et à des charges utiles supérieures à 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’indicateur RETAIN activé par un client, à l’aide de la console AWS IoT
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, à l'aide de AWS IoT la console ou par appel GetRetainedMessage
entraîne des frais de messagerie en plus des frais d'utilisation habituels de l'API. Les frais supplémentaires sont décrits dans la section AWS IoT Core
Tarification - Messagerie
Les messages MQTT Will publiés
Pour plus d’informations sur les coûts de messagerie, consultez la section AWS IoT Core Tarification - Messagerie
Comparaison des messages MQTT retenus et des sessions permanentes MQTT
Les messages retenus et les sessions permanentes sont des fonctionnalités standard de 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 un QOS = 1 et auxquels vous êtes abonné avec un QOS =1 alors que l’appareil était déconnecté sont envoyés après la reconnexion de l’appareil. |
Expiration de session/données |
Dans MQTT 3, les messages retenus n’expirent pas. Ils sont stockés jusqu’à ce qu’ils soient remplacés ou supprimés. Dans MQTT 5, les messages retenus 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 un QOS = 1 et auxquels vous avez souscrit 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 Sessions permanentes MQTT. |
Pour plus d'informations sur les sessions permanentes, consultez Sessions permanentes MQTT.
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 retenus, AWS IoT Core renvoie une réponse limitée aux messages publiés avec l’option RETAIN définie et à des charges utiles supérieures à 0 octet jusqu’à ce que certains messages retenus soient supprimés et que le nombre de messages retenus tombe en dessous de la limite.
MQTT a conservé les messages 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. MQTT ne 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. |
Messages MQTT Last Will and Testament (LWT)
Last Will and Testament (LWT) est une fonctionnalité de MQTT. Grâce LWT, les clients peuvent spécifier un message que l’agent publiera sur un rubrique défini par le client et enverra à tous les clients abonnés au rubrique en cas de déconnexion non initiée. Le message spécifié par les clients est appelé message LWT ou message Will, et la rubrique définie par les clients est appelé rubrique Will. Vous pouvez spécifier un message LWT lorsqu’un appareil se connecte à l’agent. 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 de l’agent avec une déconnexion initiée par le client à l’aide du message MQTT DISCONNECT, l’agent ne publiera pas les messages LWT enregistrés. Dans tous les autres cas, les messages LWT seront envoyés. Pour une liste complète des scénarios de déconnexion dans lesquels l’agent enverra les messages LWT, consultez la section Événements de connexion/déconnexion.
Utilisation de ConnectAttributes
ConnectAttributes
vous permettent de spécifier les attributs que vous souhaitez utiliser dans votre message de connexion dans vos politiques IAM telles que PersistentConnect
et LastWill
. 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 politique IAM si vous souhaitez en avoir une.
Pour des exemples ConnectAttributes
, consultez la section Exemples de politiques de connexion.
Fonctionnalités prises en charge par MQTT 5
AWS IoT Core le support de MQTT 5 est basé sur la spécification MQTT v5.0
AWS IoT Core prend en charge les fonctionnalités MQTT 5 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 des messages MQTT 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 à la rubrique MQTT 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 client AWS IoT MQTT 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 plus d’informations, consultez Sessions permanentes MQTT.
Code de motif sur tous les ACK
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 Codes de motif MQTT. Pour une liste complète des codes de motif MQTT, consultez 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é ait un MEI mis à jour de 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 la communication entre versions, le comportement d’expiration du message est déterminé par la version MQTT du message de publication entrant. Par exemple, un message d’expiration envoyé par une session connectée via MQTT5 peut expirer pour les appareils abonnés à des sessions MQTT3. 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. |
Autres fonctionnalités de MQTT 5
Déconnexion du serveur
Lorsqu’une déconnexion se produit, le serveur peut envoyer au client de manière proactive 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.
Propriétés MQTT 5
Les propriétés MQTT 5 sont des ajouts importants à la norme MQTT pour prendre en charge les nouvelles fonctionnalités de MQTT 5 telles que l’expiration de session et le modèle de requête/réponse. Dans AWS IoT Core, vous pouvez créer des règles qui peuvent transférer les propriétés des messages sortants ou utiliser HTTP Publish pour publier des messages MQTT avec certaines des nouvelles propriétés.
Le tableau suivant répertorie toutes les propriétés MQTT 5 prises AWS IoT Core en charge.
Propriété | Description | Type d’entrée | Paquets |
---|---|---|---|
Indicateur de format de charge utile | Valeur booléenne indiquant si la charge utile est formatée en UTF-8. | Octet | PUBLIER, CONNECTER |
Type de contenu | Chaîne UTF-8 qui décrit le contenu de la charge utile. | Chaîne UTF-8 | PUBLIER, CONNECTER |
Rubrique de réponse | Chaîne UTF-8 qui décrit la rubrique dans laquelle le récepteur doit effectuer la publication dans le cadre du flux demande-réponse. La rubrique ne doit pas avoir de caractères génériques. | Chaîne UTF-8 | PUBLIER, CONNECTER |
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 | PUBLIER, CONNECTER |
Propriétés de l’utilisateur | Une paire de chaînes UTF-8. 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. | Paire de chaînes UTF-8 | CONNECTER, PUBLIER, Will Properties, S’ABONNER, SE DÉCONNECTER, SE DÉSABONNER |
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 | PUBLIER, CONNECTER |
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 le CONNACK. |
Entier de 4 octets | CONNECTER, CONNECTER, DÉCONNECTER |
Identifiant client attribué | Un identifiant 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. | Chaîne UTF-8 | 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 qui peuvent être envoyés sans recevoir de PUBACK. | Entier de 2 octets | CONNECTER, CONNECTER |
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 | CONNECTER, CONNECTER |
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 | CONNECTER, CONNECTER |
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 |
Codes de motif MQTT
MQTT 5 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 motif pris en charge par MQTT 5, consultez les spécifications du MQTT 5
Codes de motif CONNACK | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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. |
Codes de motif PUBACK | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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é | Le PUBLISH n’est 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. |
Code de motif de déconnexion | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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é de PUBACK ou de PUBCOMP. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
148 | 0x94 | Alias de rubrique invalide | Le client ou le serveur a reçu un paquet PUBLISH contenant un alias de rubrique supérieur à l’alias de rubrique maximal qu’il a envoyé dans le paquet CONNECT ou CONNACK. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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é. |
Codes de motif SUBACK | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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. |
Codes de motif UNSUBACK | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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 aux spécifications MQTT
L’implémentation de l’agent 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 : PUBREC, PUBREL et PUBCOMP.
-
AWS IoT ne prend pas en charge les paquets suivants pour MQTT 5 : PUBREC, PUBREL, PUBCOMP et AUTH.
-
AWS IoT ne prend pas en charge la redirection du serveur MQTT 5.
-
AWS IoT prend en charge les niveaux de qualité de service (QoS) MQTT 0 et 1 uniquement. AWS IoT ne prend pas en charge la publication ou l'abonnement avec QoS de niveau 2. Lorsque QoS 2 est requis, l’agent de messages , n’envoie pas de PUBACK ou de 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 ce cas, l'indicateur DUP n'est pas défini.
-
Lorsqu'il répond à une demande de connexion, l'agent de messages envoie un message CONNACK. 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 message CONNACK soit reçu sur son appareil par l’agent de messages AWS IoT .
-
Lorsqu'un client s'abonne à une rubrique, il peut y avoir un délai entre le moment où l'agent de messages envoie un 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 de client est transmis depuis le client à l'agent de messages dans le cadre de la charge utile MQTT. 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é.
-
À de rares occasions, l'agent de messages peut renvoyer le même message PUBLISH logique avec un ID 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.
-
L’agent de messages ne garantit pas l’ordre dans lequel les messages et les 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.
-
L'indicateur MQTT DUP n'est pas pris en charge.