MQTT - AWS IoT Core

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(Message Queuing Telemetry Transport) est un protocole de messagerie léger et largement adopté, conçu pour les appareils limités. AWS IoT Core le support de MQTT est basé sur les spécifications MQTT v3.1.1 et MQTTv5.0, avec quelques différences, comme indiqué dans. AWS IoT différences par rapport MQTT aux spécifications En tant que dernière version de la norme, la version MQTT 5 introduit plusieurs fonctionnalités clés qui renforcent la robustesse d'un système MQTT basé, notamment de nouvelles améliorations en termes d'évolutivité, un meilleur signalement des erreurs avec les réponses au code de motif, les délais d'expiration des messages et des sessions, et des en-têtes de message utilisateur personnalisés. Pour plus d'informations sur les MQTT 5 fonctionnalités prises AWS IoT Core en charge, voir MQTT5 fonctionnalités prises en charge. AWS IoT Core prend également en charge MQTT la communication entre versions (MQTT3 et MQTT 5). Un éditeur MQTT 3 peut envoyer un message MQTT 3 à un abonné MQTT 5 qui recevra un message MQTT 5 publications, et vice versa.

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 la demande de connexion. Les tentatives de connexion qui n'incluent pas le SNI sont refusées. Pour plus d'informations, voir Sécurité du transport dans AWS IoT. Les clients qui utilisent IAM des utilisateurs et des AWS informations d'identification pour authentifier les clients doivent fournir l'authentification Signature Version 4 correcte.

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.

C++

Utilisation du périphérique AWS IoT C++ SDK pour connecter des périphériques

Python

Utilisation du AWS IoT Device SDK for Python pour connecter des appareils

JavaScript

Utilisation de l' AWS IoT appareil SDK pour JavaScript connecter des appareils

Java

Utilisation de AWS IoT Device SDK for Java pour connecter des appareils

Note

The AWS IoT Device SDK for Java v2 prend désormais en charge le développement Android. Pour plus d'informations, consultez la section AWS IoT Appareil SDK pour Android.

Embedded C

Utilisation du AWS IoT Device SDK for Embedded C pour connecter des appareils

Important

Il SDK est destiné à être utilisé par des développeurs de logiciels embarqués expérimentés.

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) et. 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 PUBACK soit reçue

Le message n’est pas considéré comme complet tant que l’expéditeur n’a pas reçu de réponse PUBACK indiquant que la livraison a été réussie.

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.

MQTT5 Démarrage correct 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.

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’indicateur cleanSession sur 1.

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. Vous pouvez configurer l’intervalle d’expiration.

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.

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'Publishaction 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 et GetRetainedMessage.

    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 le Connect 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 Publishentraî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 GetRetainedMessageentraî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 publiés lorsqu'un appareil se déconnecte de façon inattendue entraîneront-ils des frais de messagerie décrits dans la section AWS IoT Core Tarification - Messagerie.

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

ConnectAttributesvous 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 message LastWillTopic 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 avec quelques différences, comme indiqué dansAWS IoT différences par rapport MQTT aux spécifications.

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 un ShareName 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.
sports/tennis sports/#
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.
$share/consumer/sports/tennis $share/consumer/sports/#
Flux d’abonnements non partagés Flux d’abonnements partagés
Abonnements réguliers pour MQTT 3 et MQTT 5 pouces AWS IoT Core.
Abonnements partagés pour MQTT 3 et MQTT 5 pouces AWS IoT Core.

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.

    Abonnements partagés contenant des caractères génériques. AWS IoT Core

    Dans cet exemple, trois abonnements partagés correspondent au MQTT sujet de publicationsports/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, consultezTest des abonnements partagés dans le MQTT client. Pour plus d'informations sur les abonnements partagés, consultez la section Abonnements partagés de la spécification MQTTv5 .0.

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.

CONNACKCodes de raison
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.
PUBACKCodes de raison
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.
DISCONNECTCodes de raison
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é.
SUBACKCodes de raison
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.
UNSUBACKCodes de raison
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 et MQTTv5.0, mais elle diffère des spécifications de la manière suivante :

  • 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 rubrique sensor/# reçoit les messages publiés dans les rubriques sensor/, sensor/temperature, sensor/temperature/room1, mais pas les messages publiés dans sensor. 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.