Fonctionnalités MQTT prises en charge par l’agent MQTT Azure Event Grid

Message Queuing Telemetry Transport (MQTT) est un protocole de transport de messagerie de publication-abonnement conçu pour les environnements contraints. MQTT est efficace, évolutif et fiable, ce qui le rend populaire pour la communication dans les scénarios IoT (Internet des objets). L’agent MQTT prend en charge les clients qui publient et s’abonnent aux messages sur MQTT v3.1.1, MQTT v3.1.1 sur WebSocket, MQTT v5 et MQTT v5 sur WebSocket. L’agent MQTT prend également en charge la communication entre les versions de MQTT (MQTT 3.1.1 et MQTT 5).

L’agent MQTT dans Azure Event Grid prend également en charge les appareils et services qui envoient des messages MQTT via HTTPS, ce qui simplifie l’intégration avec les clients non-MQTT. Event Grid vous permet d’envoyer des messages MQTT au cloud pour l’analyse des données, le stockage et les visualisations, entre autres cas d’usage. Cette fonctionnalité est actuellement en préversion.

MQTT v5 a introduit de nombreuses améliorations par rapport à MQTT v3.1.1, pour fournir une communication plus fluide, plus transparente et plus efficace. Cela a ajouté :

• De meilleurs rapports d’erreurs.
• Communication plus transparente avec les clients via des fonctionnalités telles que les propriétés utilisateur et le type de contenu.
• Plus de contrôle pour les clients sur la communication par le biais de fonctionnalités telles que le message et l’expiration de session.
• Modèles importants standard tels que le modèle requête-réponse.

Flux de connexion

Vos clients MQTT doivent se connecter via TLS (Transport Layer Security) 1.2 ou TLS 1.3. Sans cette étape, la connexion échoue.

Lorsque vous vous connectez au répartiteur MQTT, utilisez les ports suivants lors de la communication sur MQTT :

• MQTT v3.1.1 et MQTT v5 sur le port TCP 8883
• MQTT v3.1.1 sur WebSocket et MQTT v5 sur WebSocket sur le port TCP 443

Le paquet CONNECT doit inclure les propriétés suivantes :

• Le champ ClientId est obligatoire et doit inclure le nom de session du client. Le nom de session doit être unique dans l’espace de noms. Vous pouvez utiliser le nom d’authentification du client comme nom de session si chaque client utilise une session par client. Si un client utilise plusieurs sessions, il doit utiliser des valeurs différentes pour ClientId chacune de ses sessions.
• Le champ Username est obligatoire si vous n’avez pas sélectionné de valeur dans l’espace de noms lors de la création de l’espace alternativeAuthenticationNameSources de noms. Dans ce cas, vous devez fournir le nom d’authentification de votre client dans le champ Username. Ce nom doit correspondre au nom d’authentification fourni et à la valeur dans le champ de certificat du client spécifié lors de la création de la ressource cliente.

En savoir plus sur l’authentification du client.

Prise en charge multisession

La prise en charge multisession permet à vos clients MQTT d’application d’avoir une implémentation plus évolutive et fiable en se connectant au répartiteur MQTT avec plusieurs sessions actives en même temps.

Configuration de l’espace de noms

Avant que vous utilisiez cette fonctionnalité, vous devez configurer l’espace de noms pour autoriser plusieurs sessions par client. Pour configurer plusieurs sessions par client dans le Portail Azure, procédez comme suit :

1. Accédez à votre espace de noms dans le Portail Azure.
2. Sous Configuration, remplacez la valeur de sessions clientes maximales par nom d’authentification par nom d’authentification par le nombre de sessions par client souhaité.
3. Sélectionnez Appliquer.

Remarque

Pour la configuration d’Azure CLI, mettez à jour la MaxClientSessionsPerAuthenticationName propriété dans la charge utile de l’espace de noms avec la valeur souhaitée.

Flux de connexion

Les paquets CONNECT de chaque session doivent inclure les propriétés suivantes :

• Indiquez la propriété Username dans le paquet CONNECT pour signer votre nom d’authentification client.
• Indiquez la propriété ClientID dans le paquet CONNECT pour signer le nom de session, par exemple s’il existe une ou plusieurs valeurs pour l’ID client pour chaque nom d’utilisateur.

Par exemple, les combinaisons suivantes de Username et ClientId dans le paquet CONNECT permettent au client Mgmt-application de se connecter à l’agent MQTT via trois sessions indépendantes :

• Première session :
  • Username: Mgmt-application
  • ClientId: Mgmt-Session1
• Deuxième session :
  • Username: Mgmt-application
  • ClientId: Mgmt-Session2
• Troisième session :
  • Username: Mgmt-application
  • ClientId: Mgmt-Session3

Pour plus d’informations, consultez Établir plusieurs sessions pour un seul client.

Gérer les sessions

• Si un client tente de reprendre la session active d’un autre client en présentant son nom de session avec une authentification différente, sa demande de connexion est rejetée avec une erreur non autorisée. Par exemple, si le client B tente de se connecter à la session 123 affectée à ce moment-là pour le client A, la demande de connexion du client B est rejetée. Toutefois, si le même client tente de se reconnecter avec les mêmes noms de session et le même nom d’authentification, il peut prendre en charge sa session existante.
• Si une ressource cliente est supprimée sans mettre fin à sa session, les autres clients ne peuvent pas utiliser son nom de session tant que la session n’a pas expiré. Par exemple, si le client B crée une session avec le nom de session 123 , puis que le client B est supprimé, le client A ne peut pas se connecter à la session 123 tant qu’il n’expire pas.
• La limite du nombre de sessions par client s’applique aux sessions en ligne et hors connexion à tout moment. Par exemple, considérez un espace de noms avec le nombre maximal de sessions clientes par nom d’authentification défini sur 1. Le client A se connecte à une session permanente 123, puis se déconnecte. Le client A ne peut pas se connecter à une nouvelle session 456, car sa session 123 est toujours active même si elle est hors connexion. Par conséquent, nous recommandons que le même client se reconnecte toujours avec les mêmes noms de session statiques plutôt que de générer un nouveau nom de session à chaque reconnexion.

Fonctionnalités MQTT

L’agent MQTT Event Grid prend en charge les fonctionnalités MQTT suivantes.

Qualité de service

L’agent MQTT prend en charge les niveaux de qualité de service (QoS) 0 et 1, qui définissent la garantie de remise de messages sur les paquets PUBLISH et SUBSCRIBE entre les clients et L’agent MQTT.

• QoS 0 garantit au maximum une remise : l’abonné ne reconnaît pas les messages avec QoS 0 et l’éditeur ne les retransmet pas.
• QoS 1 garantit au moins une remise : l’abonné reconnaît les messages et le serveur de publication les retransmet s’ils n’ont pas été reconnus.

QoS permet à vos clients de contrôler l’efficacité et la fiabilité de la communication.

Sessions persistantes

L’agent MQTT prend en charge les sessions persistantes pour MQTT v3.1.1 afin que L’agent MQTT conserve des informations sur la session d’un client lorsqu’il est déconnecté pour garantir la fiabilité de la communication. Ces informations incluent les abonnements du client ou les messages QoS 1 manqués ou non connus. Les clients peuvent configurer une session persistante en définissant l’indicateur cleanSession dans le paquet CONNECT sur false.

Nettoyage du démarrage et de l’expiration de la session

MQTT v5 a introduit les fonctionnalités de démarrage propre et d’expiration de session comme une amélioration par rapport à MQTT v3.1.1 dans la gestion de la persistance de session. Le démarrage propre permet à un client de démarrer une nouvelle session avec l’agent MQTT après avoir ignoré les données de session précédentes. L’expiration de session permet à un client d’informer l’agent MQTT lorsqu’une session inactive est considérée comme expirée et supprimée automatiquement.

Dans le paquet CONNECT, un client peut définir l’indicateur Clean Start sur true. Un client peut également définir un intervalle d’expiration de session court pour des raisons de sécurité ou pour éviter les conflits de données potentiels qui peuvent se produire pendant la session précédente. Un client peut également définir l’indicateur Clean Start sur false ou un intervalle d’expiration de session long pour garantir la fiabilité et l’efficacité des sessions persistantes.

Configuration de l’intervalle d’expiration de session maximal

Vous pouvez configurer l’intervalle maximal d’expiration de session autorisé pour tous vos clients qui se connectent à l’espace de noms Event Grid. Pour les clients MQTT v3.1.1, la limite configurée est appliquée comme intervalle d’expiration de session par défaut pour toutes les sessions persistantes. Pour les clients MQTT v5, la limite configurée est appliquée en tant que valeur maximale pour la propriété d’intervalle d’expiration de session dans le paquet CONNECT. Toute valeur qui dépasse la limite est ajustée. La valeur par défaut de cette propriété d’espace de noms est d’une heure et peut s’étendre jusqu’à huit heures. Pour configurer l’intervalle maximal d’expiration de session dans le Portail Azure, procédez comme suit :

1. Accédez à votre espace de noms dans le Portail Azure.
2. Sous Configuration, remplacez la valeur de l’intervalle d’expiration maximal de session en heures par la limite souhaitée.
3. Sélectionnez Appliquer.

Dépassement de capacité de session

L’agent MQTT conserve une file d’attente de messages pour chaque session MQTT active qui n’est pas connectée, tant que le client ne se connecte pas à nouveau avec l’agent MQTT pour recevoir les messages dans la file d’attente. Si un client ne se connecte pas pour recevoir les messages QoS 1 mis en file d’attente, la file d’attente de session accumule les messages jusqu’à ce qu’elle atteigne sa limite de 100 messages ou 1 Mo. Une fois la file d’attente atteinte sa limite pendant la durée de vie de la session, la session est arrêtée.

Dernières volontés et messages testament

Dernières volontés et testament (LWT) avertit vos clients MQTT des déconnexions abruptes d’autres clients MQTT. Vous pouvez utiliser LWT pour garantir un flux de communication prévisible et fiable entre les clients MQTT lors de déconnexions inattendues. Cette fonctionnalité est utile pour les scénarios où la communication en temps réel, la fiabilité du système et les actions coordonnées sont essentielles. Les clients qui collaborent pour effectuer des tâches complexes peuvent réagir aux messages LWT les uns des autres en ajustant leur comportement, en redistribuant des tâches ou en prenant certaines responsabilités pour maintenir les performances et la stabilité du système.

Pour utiliser LWT, un client peut spécifier le message Will, la rubrique Will et le reste des propriétés Will dans le paquet CONNECT pendant la connexion. Lorsque le client se déconnecte brusquement, l’agent MQTT publie le message Will sur tous les clients abonnés à la rubrique Will. Pour réduire le bruit des déconnexions fluctuantes, le client peut définir l’intervalle de retard sur une valeur supérieure à zéro. Dans ce cas, si le client se déconnecte brusquement, mais restaure la connexion avant l’expiration de l’intervalle de retard, le message Will n’est pas publié.

Propriétés de l’utilisateur

L’agent MQTT prend en charge les propriétés utilisateur sur les paquets PUBLISH MQTT v5 que vous pouvez utiliser pour ajouter des paires clé / valeur personnalisées dans l’en-tête de message pour fournir plus de contexte sur le message. Les cas d’usage des propriétés utilisateur sont polyvalents. Vous pouvez utiliser cette fonctionnalité pour inclure l’objectif ou l’origine du message afin que le destinataire puisse gérer le message sans analyser la charge utile, ce qui enregistre les ressources informatiques. Par exemple, un message avec une propriété utilisateur qui indique son objectif en tant qu’« avertissement » peut déclencher une logique de gestion différente de celle d’une avec l’objectif de « information ».

Modèle requête-réponse

MQTT v5 a introduit des champs dans l’en-tête de paquet MQTT PUBLISH qui fournissent un contexte pour le message de réponse dans le modèle de demande-réponse. Ces champs incluent une rubrique de réponse et un ID de corrélation que le répondeur peut utiliser dans la réponse sans configuration préalable. Les informations de réponse permettent une communication plus efficace pour le modèle de demande-réponse standard utilisé dans les scénarios de commande et de contrôle.

Intervalle d’expiration du message

Dans MQTT v5, l’intervalle d’expiration du message permet aux messages d’avoir une durée de vie configurable. L’intervalle d’expiration du message est défini comme intervalle de temps entre le moment où un message est publié sur L’agent MQTT et l’heure à laquelle l’agent doit ignorer le message non remis. Cette fonctionnalité est utile dans les scénarios où les messages sont valides pour une certaine durée, comme les commandes sensibles au temps, la diffusion en continu de données en temps réel ou les alertes de sécurité. En définissant un intervalle d’expiration de message, l’agent MQTT peut supprimer automatiquement les messages obsolètes. Cette étape garantit que seules les informations pertinentes sont disponibles pour les abonnés. Si l’intervalle d’expiration d’un message est défini sur zéro, cela signifie que le message ne doit jamais expirer.

Alias de rubrique

Dans MQTT v5, les alias de rubrique permettent à un client d’utiliser un alias plus court à la place du nom complet de la rubrique dans le message publié. L’agent MQTT gère un mappage entre l’alias de rubrique et le nom réel de la rubrique. Cette fonctionnalité peut économiser la bande passante réseau et réduire la taille de l’en-tête de message, en particulier pour les rubriques avec des noms longs. Il est utile dans les scénarios où la même rubrique est publiée à plusieurs reprises dans plusieurs messages, par exemple dans des réseaux de capteurs. L’agent MQTT prend en charge jusqu’à 10 alias de rubrique. Un client peut utiliser un Topic Alias champ dans le paquet PUBLISH pour remplacer le nom complet de la rubrique par l’alias correspondant.

Contrôle de flux

Dans MQTT v5, le contrôle de flux fait référence au mécanisme de gestion de la vitesse et de la taille des messages qu’un client peut gérer. Pour configurer le contrôle de flux, définissez les paramètres et Maximum Packet Size les Receive Maximum paramètres dans le paquet CONNECT. Le Receive Maximum paramètre permet au client de limiter le nombre de messages envoyés par l’agent au nombre de messages que le client peut gérer. Le Maximum Packet Size paramètre définit la taille maximale des paquets que le client peut recevoir. L’agent MQTT a une limite de taille de message de 512 Kib. Cette fonctionnalité garantit la fiabilité et la stabilité de la communication pour les appareils limités avec une vitesse de traitement ou des fonctionnalités de stockage limitées.

Accusés de réception négatifs et paquet de déconnexion initié par le serveur

Pour MQTT v5, l’agent MQTT peut envoyer des accusés de réception négatifs et des paquets de déconnexion initiés par le serveur qui fournissent au client plus d’informations sur les échecs de remise de messages ou de connexion. Ces fonctionnalités aident le client à diagnostiquer la raison d’un échec et à prendre les mesures d’atténuation appropriées. L’agent MQTT utilise les codes de raison définis dans la spécification MQTT v5.

Classement des messages

MQTT v5 garantit la remise de messages dans chaque rubrique et chaque client lorsque qoS niveau 1 est utilisé, ce qui est essentiel pour les flux de travail qui nécessitent l’intégrité de la séquence. Il est idéal pour les scénarios tels que la télémétrie, l’exécution des commandes et les données de série chronologique.

Toutefois, il ne garantit pas l’ordre entre différentes rubriques ou lorsque les messages sont envoyés avec différents niveaux qoS. Pour en savoir plus, contactez-nous à l’adresse askmqtt@microsoft.com.

Identificateurs client attribués

MQTT v5 introduit la prise en charge des identificateurs clients attribués, ce qui permet au répartiteur MQTT de générer et de retourner un ID client unique lorsque le client n’en fournit pas un. La prise en charge du répartiteur MQTT pour cette fonctionnalité garantit l’intégration transparente des clients et réduit la nécessité pour les clients de gérer leurs propres identificateurs. Il est particulièrement utile dans les scénarios où l’approvisionnement du client est dynamique ou lorsque les appareils n’ont pas d’identité préconfigurée. Les ID client attribués peuvent être récupérés à partir de la réponse CONNACK et réutilisés pour les sessions futures afin de maintenir une identification cohérente.

Gérer les limites d’identificateur client et de session dans MQTT

• Les identificateurs clients affectés permettent aux clients de se connecter sans spécifier d’identificateurs prédéfinis, en activant des sessions temporaires ou persistantes.
• Les clients peuvent éviter d’être verrouillés à l’aide d’intervalles d’expiration de session courts pendant la première connexion et d’enregistrer l’identificateur du client affecté pour une utilisation ultérieure.
• Pour les mises à jour ou les réinitialisations du microprogramme, les clients doivent conserver leur identificateur de client connu ou utiliser des intervalles d’expiration de session modestes pour éviter les verrouillages prolongés.
• La configuration de l’espace de noms peut augmenter les limites de session par client pour réduire les interruptions pendant les mises à jour ou les restaurations.

Limites actuelles

L’agent MQTT ajoute plus de fonctionnalités MQTT v5 et MQTT v3.1.1 à l’avenir pour s’aligner davantage sur les spécifications MQTT. La liste suivante détaille les différences actuelles entre les fonctionnalités prises en charge par l’agent MQTT et les spécifications MQTT.

Limitations actuelles de MQTT v5

MQTT v5 diffère actuellement de la spécification MQTT v5 de la manière suivante :

• Les abonnements partagés ne sont pas encore pris en charge.
• L’intervalle maximal de délai est de 300.
• La qualité de service maximale est 1.
• La taille maximale des paquets est de 512 Kib.
• Les identificateurs d’abonnement ne sont pas pris en charge.
• La valeur maximale de l’alias de rubrique est 10. Le serveur n’affecte pas d’alias de rubrique pour les messages sortants pour le moment. Les clients peuvent attribuer et utiliser des alias de rubrique dans la limite définie.
• CONNACK ne retourne pas la Response Information propriété même si la requête CONNECT contient la Request Response Information propriété.
• Les propriétés utilisateur sur les paquets CONNECT, SUBSCRIBE, DISCONNECT, PUBACK et AUTH ne sont pas utilisées par le service. Elles ne sont donc pas prises en charge. Si l’une de ces requêtes inclut des propriétés utilisateur, la requête échoue.
• Si le serveur reçoit un paquet PUBACK d’un client avec un code de réponse non-succès, la connexion est arrêtée.
• Conserver la durée maximale de vie est de 1 160 secondes.

Limitations actuelles de MQTTv3.1.1

MQTT v5 diffère actuellement de la spécification MQTT v3.1.1 de la manière suivante :

• QoS 2 n’est pas pris en charge. Une demande de publication avec un RETAIN indicateur ou une QoS 2 échoue et ferme la connexion.
• Conserver la durée maximale de vie est de 1 160 secondes.

Exemples de code

Ce référentiel contient des exemples de code C#, C et Python qui montrent comment envoyer des données de télémétrie, envoyer des commandes et diffuser des alertes. Les certificats créés par le biais des exemples sont adaptés aux tests, mais ne sont pas adaptés aux environnements de production.

Contenu connexe

Pour en savoir plus sur MQTT, consultez la spécification MQTT v5. Pour en savoir plus sur l’agent MQTT, consultez :

• Authentification du client
• Établir plusieurs sessions pour un seul client