Partager via

Fonctionnalités MQTT prises en charge par la fonctionnalité répartiteur MQTT d’Azure Event Grid

  • Article

MQTT est un protocole de transport de messagerie publication-abonnement conçu pour les environnements contraints. Il est efficace, évolutif et fiable, ce qui en a fait la référence pour la communication dans les scénarios IoT. Le répartiteur MQTT prend en charge les clients qui publient et s’abonnent à des messages via MQTT v3.1.1, MQTT v3.1.1 sur WebSockets, MQTT v5 et MQTT v5 sur WebSockets. Le répartiteur MQTT prend également en charge la communication entre les différentes versions MQTT (MQTT 3.1.1 et MQTT 5).

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.
  • Des clients de communication plus transparents par le biais de 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 1.2 ou TLS 1.3. Sans cette étape, la connexion échoue.

Lors de la connexion au répartiteur MQTT, utilisez les ports suivants pendant la communication sur MQTT :

  • MQTT v3.1.1 et MQTT v5 sur le port TCP 8883
  • MQTT v3.1.1 sur WebSocket et MQTTv5 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 pour chacune de ses sessions.
  • Le champ Nom d’utilisateur est obligatoire si vous n’avez pas sélectionné de valeur dans alternativeAuthenticationNameSources lors de la création de l’espace de noms. Dans ce cas, vous devez fournir le nom d’authentification de votre client dans le champ Nom d’utilisateur. Ce nom doit correspondre au nom d’authentification fourni et à la valeur dans le champ de certificat du client qui a été 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 aux clients MQTT de votre application d’avoir une implémentation plus évolutive et plus fiable en se connectant au répartiteur MQTT avec plusieurs sessions actives en même temps.

Configuration de l’espace de noms

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

  • Accédez à votre espace de noms dans le Portail Azure.
  • Sous Configuration, remplacez la valeur du nombre maximal de sessions de clients par nom d’authentification par le nombre souhaité de sessions par client.
  • Sélectionnez Appliquer.

Notes

Pour la configuration d’Azure CLI, mettez à jour la propriété MaxClientSessionsPerAuthenticationName 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 indiquer le nom d’authentification de votre client.
  • Indiquez la propriété ClientID dans le paquet CONNECT pour indiquer le nom de session, car il existe une ou plusieurs valeurs pour l’ID client pour chaque nom d’utilisateur.

Par exemple, les combinaisons suivantes de Username et ClientIds dans le paquet CONNECT permettent au client "Mgmt-application" de se connecter au répartiteur MQTT sur trois sessions indépendantes :

  • Première session :
    • Nom d’utilisateur : Mgmt-application
    • ClientId : Mgmt-Session1
  • Deuxième session :
    • Nom d’utilisateur : Mgmt-application
    • ClientId : Mgmt-Session2
  • Troisième session :
    • Nom d’utilisateur : Mgmt-application
    • ClientId : Mgmt-Session3

Diagramme d’un exemple multisession.

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

Gestion des 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à au client A, la demande de connexion du client B est rejetée. Cela dit, si le même client tente de se reconnecter avec les mêmes noms de session et le même nom d'authentification, il est en mesure de reprendre la 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 alors que le client B est supprimé, le client A ne peut pas se connecter à la session 123 tant qu’il n’aura pas expiré.
  • 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. Si le client A se connecte à une session persistante 123 mais qu’il est ensuite déconnecté, 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

La fonctionnalité répartiteur MQTT d’Azure Event Grid prend en charge les fonctionnalités MQTT suivantes :

Quality of service (QoS)

Le répartiteur MQTT prend en charge QoS 0 et 1, qui définissent la garantie de remise des messages sur les paquets PUBLISH et SUBSCRIBE entre les clients et le répartiteur MQTT. QoS 0 garantit une livraison au plus une fois ; les messages avec QoS 0 ne sont pas reconnus par l’abonné et ne sont pas retransmis par l’éditeur. QoS 1 garantit une livraison au moins une fois ; les messages sont reconnus par l’abonné et sont retransmis par l’éditeur s’ils n’ont pas été reconnus. QoS permet à vos clients de contrôler l’efficacité et la fiabilité de la communication.

Sessions persistantes

Le répartiteur MQTT prend en charge les sessions persistantes pour MQTT v3.1.1 de sorte que le répartiteur MQTT conserve les informations d’une session client en cas de déconnexion pour garantir la fiabilité de la communication. Ces informations incluent les abonnements du client et les messages QoS 1 manqués/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. Clean Start est une fonctionnalité qui permet à un client de démarrer une nouvelle session avec le répartiteur MQTT, en ignorant toutes les données de session précédentes. Session Expiry permet à un client d’informer le répartiteur MQTT lorsqu’une session inactive est considérée comme expirée et automatiquement supprimée. Dans le paquet CONNECT, un client peut définir l’indicateur de démarrage propre sur vraie et/ou sur un intervalle d’expiration de session court pour des raisons de sécurité ou pour éviter les conflits de données potentiels qui ont pu se produire au cours de la session précédente. Un client peut également définir un démarrage propre sur false et/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 comme valeur maximale pour la propriété 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 1 heure et peut être étendue jusqu’à 8 heures. Procédez comme suit pour configurer l’intervalle d’expiration de session maximal dans le Portail Azure :

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

Capture d’écran dela configuration de l’intervalle d’expiration de session maximal.

Dépassement de capacité de session

Le répartiteur MQTT gère une file d’attente de messages pour chaque session MQTT active qui n’est pas connectée, jusqu’à ce que le client se reconnecte au répartiteur MQTT pour recevoir les messages dans la file d’attente. Si un client ne se connecte pas pour recevoir les messages QOS1 mis en file d’attente, la file d’attente de session commence à accumuler les messages jusqu’à ce qu’elle atteigne sa limite : 100 messages ou 1 Mo. Une fois que la file d’attente a atteint sa limite pendant la durée de vie de la session, la session est arrêtée.

Messages LWT (Last Will and Testament, Dernières volontés et 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 en cas de déconnexions inattendues, ce qui 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 à leurs messages LWT respectifs en ajustant leur comportement, en redistribuant des tâches ou en prenant certaines responsabilités pour maintenir le niveau de performance 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 est déconnecté brusquement, le répartiteur MQTT publie le message Will à tous les clients abonnés à la rubrique Will. Pour réduire le bruit des déconnexions fluctuantes, le client peut définir un intervalle de retard supérieur à zéro. Dans ce cas, si le client se déconnecte brusquement mais rétablit la connexion avant l'expiration de l'intervalle de délai, le message d'erreur n'est pas publié.

Propriétés de l’utilisateur

Le répartiteur MQTT prend en charge les propriétés utilisateur sur les paquets PUBLISH MQTT v5 qui vous permettent d’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 récepteur puisse gérer le message sans analyser la charge utile, ce qui permet d’économiser des ressources informatiques. Par exemple, un message avec une propriété utilisateur indiquant son objectif en tant qu’« avertissement » peut déclencher une logique de gestion différente de celle dont l’objectif est l’« information ».

Modèle requête-réponse

MQTTv5 a introduit des champs dans l’en-tête de paquet MQTT PUBLISH qui fournissent le contexte pour le message de réponse dans le modèle requête-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 requête-réponse standard utilisé dans les scénarios de commande et de contrôle.

Diagramme de l’exemple de modèle de requête-réponse.

Intervalle d’expiration du message :

Dans MQTT v5, l’intervalle d’expiration des messages permet aux messages d’avoir une durée de vie configurable. L’intervalle d’expiration du message est défini comme l’intervalle de temps entre le moment où un message est publié sur le répartiteur MQTT et le moment où Le répartiteur MQTT doit ignorer le message non remis. Cette fonctionnalité est utile dans les scénarios où les messages ne sont valides que pendant un certain laps de temps, 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, le répartiteur MQTT peut supprimer automatiquement les messages obsolètes, garantissant que seules les informations pertinentes soient 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é. Le répartiteur MQTT gère un mappage entre l’alias de la 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. Le répartiteur MQTT prend en charge jusqu’à 10 alias de rubrique. Un client peut utiliser un champ Alias de rubrique dans le paquet PUBLISH pour remplacer le nom complet de la rubrique par l’alias correspondant.

Diagramme de l’exemple d’alias de rubrique.

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. Le contrôle de flux peut être configuré en définissant les paramètres Maximum Packet Size et Receive Maximum dans le paquet CONNECT. Le paramètre Receive Maximum permet au client de limiter le nombre de messages envoyés par le répartiteur au nombre de messages que le client est en mesure de gérer. Le paramètre Maximum Packet Size définit la taille maximale des paquets que le client peut recevoir. Le répartiteur MQTT a une limite de taille de message de 512 Kio. Cette fonctionnalité garantit la fiabilité et la stabilité de la communication pour les appareils limités avec une vitesse de traitement ou des capacités de stockage limitées.

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

Pour MQTT v5, le répartiteur MQTT est en mesure d’envoyer des accusés de réception négatifs(Negative ACKnowledgments/NACK) 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. Le répartiteur MQTT utilise les codes de raison définis dans les Spécifications MQTT v5.

Limites actuelles

Le répartiteur MQTT ajoutera d’autres 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 le répartiteur MQTT et les spécifications MQTT :

Limites actuelles MQTT v5

MQTT v5 diffère actuellement de la spécification MQTT v5 des manières suivantes :

  • Les abonnements partagés ne sont pas encore pris en charge.
  • L’indicateur RETAIN n’est pas encore pris en charge.
  • L’intervalle de retard maximal est de 300.
  • La qualité de service maximale est 1.
  • La taille maximale du paquet est de 512 KiB
  • L’ordre des messages n’est pas garanti.
  • Les identificateurs d’abonnement ne sont pas pris en charge.
  • Les identificateurs client attribués ne sont pas encore 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 affecter et utiliser des alias de rubrique dans la limite définie.
  • CONNACK ne retourne pas la propriété Response Information même si la requête CONNECT contient la propriété Request Response Information.
  • Les propriétés utilisateur sur les paquets CONNECT, SUBSCRIBE, DISCONNECT, PUBACK, AUTH ne sont pas utilisées par le service et 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 PUBACK d’un client avec un code de réponse non réussi, la connexion est arrêtée.
  • La valeur Keep Alive Maximum est de 1160 secondes.

Limitations actuelles de MQTTv3.1.1

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

  • QoS2 et l’indicateur de RETAIN ne sont pas encore pris en charge. Une demande de publication avec un indicateur RETAIN ou avec une QoS2 échoue et ferme la connexion.
  • L’ordre des messages n’est pas garanti.
  • La valeur Keep Alive Maximum est de 1160 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.

Étapes suivantes :

En savoir plus sur MQTT :

En savoir plus sur le répartiteur MQTT :