Qt MQTT Présentation

Qt MQTT vous permet de créer des applications et des appareils capables de communiquer via le protocole MQTT (MQ Telemetry Transport). Il est entièrement conforme à la spécification du protocole MQTT.

Publication et abonnement

MQTT est un protocole de connectivité de machine à machine qui fonctionne selon le modèle « publication-abonnement ». Un client MQTT est un programme ou un appareil qui utilise MQTT pour établir une connexion réseau avec un serveur MQTT, également appelé « courtier ». Une fois la connexion établie, le client peut envoyer des messages au courtier. Les autres clients peuvent s'abonner aux notifications relatives à des sujets spécifiques envoyées par le client.

Par exemple, si le Client 2 s’abonne aux messages sur le sujet A, il reçoit une notification lorsque le Client 1 envoie un message sur ce sujet. Si le Client 3 s’abonne aux sujets A et B, il reçoit des notifications concernant les messages sur ces deux sujets.

Qt MQTT est une solution client qui n’inclut pas de broker. Elle est particulièrement adaptée au développement d’applications de télémétrie pour les appareils embarqués. Cependant, Qt MQTT ne présente aucune dépendance externe ; les clients implémentés peuvent donc être exécutés sur toutes les plateformes Qt prises en charge.

Sujets

Les sujets sont stockés dans une structure arborescente hiérarchique. La norme ne précise pas comment l’arborescence doit être conçue, ni ne fournit d’ensembles hiérarchiques prédéfinis. Vous pouvez concevoir librement la hiérarchie en fonction des besoins de votre projet. Voici un exemple de hiérarchie de sujets, où « actif » désigne tous les capteurs actifs, tandis que « maison » et « garage » sont des capteurs individuels :

sensors/active
sensors/house/temperature
sensors/house/bedroom/light
sensors/house/livingroom/light
sensors/garage/temperature
sensors/garage/light

S'abonner à des sujets à l'aide de caractères génériques

Lorsque les clients s’abonnent à des sujets, ils peuvent utiliser le signe dièse (#) et le signe plus (+) comme caractères génériques. Le signe dièse indique que le client souhaite recevoir des notifications concernant tous les messages d’un sujet et de ses sous-sujets. Par exemple, si un client s’abonne à « sensors/house/# », il reçoit tous les messages relatifs au capteur « house ».

Le signe « plus » indique qu’une branche de l’arborescence peut être ignorée lors de la recherche d’un sous-thème correspondant. Par exemple, si un client s’abonne à sensors/+/temperature, il reçoit les messages relatifs à la température, quel que soit le capteur qui les a envoyés. Vous pouvez utiliser plusieurs signes « plus » pour ignorer plusieurs branches. Par exemple, « house/+/+/temperature » pourrait être utilisé pour recevoir les messages relatifs à la température de toutes les pièces de tous les appartements d’une maison.

Abonnements partagés

Les abonnements partagés désignent un ensemble d’abonnés à un filtre de sujet. Au lieu que tous les abonnés reçoivent un message, un seul abonné le reçoit. Cela permet d’assurer l’équilibrage de charge entre plusieurs clients. Le format d’un abonnement partagé est le suivant :

$share/{sharename}/{topicfilter}

Par exemple, si le client 1 et le client 2 doivent partager un abonnement au sujet « sensors/house/temperature », le filtre de sujet auquel s’abonner est :

$share/poolAB/sensors/house/temperature

L’ordre dans lequel les messages sont distribués par le serveur n’est pas défini. Il s’agit d’une option propre au serveur.

Pour savoir si un serveur prend en charge les abonnements partagés, consultez également QMqttServerConnectionProperties::sharedSubscriptionSupported().

Alias de sujets

La structuration des sujets en arborescence permet de séparer les canaux de données et d’établir un ordre logique des informations. Cependant, cela peut entraîner l’utilisation de noms de sujets très longs lors de la publication des messages, ce qui augmente la taille de chaque message.

La version 5.0 du protocole MQTT a introduit les alias de sujets pour contourner ce problème. Au lieu de la chaîne de caractères du sujet, c’est une valeur entière qui est envoyée. Pour créer un mappage initial entre le client et le serveur, la chaîne de caractères du sujet et l’alias doivent tous deux figurer dans un message. Par la suite, seul l’identifiant, accompagné d’un sujet vide, est utilisé.

Ce mappage peut être modifié à tout moment en associant un alias de sujet à une autre chaîne de sujet. Notez que ce mappage ne s’applique pas nécessairement à d’autres connexions, telles que celles établies par le serveur vers d’autres clients. Chaque connexion doit créer ce mappage manuellement.

Qt MQTT fournit un mécanisme automatisé permettant de réduire les débits de données. Une fois qu’ QMqttClient a établi une connexion, les informations relatives aux alias de sujet pris en charge par le serveur sont stockées. Par la suite, les alias de sujet sont utilisés dans l’ordre de publication des messages, jusqu’à ce que tous les alias disponibles soient utilisés. Un utilisateur peut à tout moment modifier ce mappage en utilisant QMqttPublishProperties::setTopicAlias() lors de la publication.

Lorsque QMqttClient s’abonne à un sujet, le serveur peut également utiliser des alias de sujet, en fonction de la valeur de QMqttConnectionProperties::maximumTopicAlias() définie par le client. Le client mappe automatiquement les alias de sujet et transfère de manière transparente les messages à l’utilisateur en incluant la chaîne complète du sujet.

Sécurité

Les connexions entre les clients et le broker sont sécurisées par un système d’authentification intégré qui utilise des noms d’utilisateur et des mots de passe. Les messages sont chiffrés à l’aide du protocole SSL/TLS au niveau de la couche de transport. Le numéro de port standardisé pour les messages MQTT chiffrés est le 8883.

Qualité de service

Les niveaux de qualité de service (QoS) suivants sont définis pour les messages :

• «Au plus une fois» (0) signifie que les messages sont transmis dans la mesure des capacités de l’environnement d’exploitation, et que des pertes de messages peuvent donc se produire. Ce niveau peut être utilisé, par exemple, avec des données de capteurs d’ambiance, pour lesquelles la perte d’une lecture individuelle n’a pas d’importance, car la suivante sera publiée peu après.
• «Au moins une fois» (1) signifie que l’arrivée des messages est garantie, mais que des doublons peuvent survenir.
• Exactement une fois (2) signifie que les messages sont garantis d’arriver exactement une fois. Ce niveau pourrait être utilisé, par exemple, avec des systèmes de facturation où des messages en double ou perdus pourraient entraîner l’application de frais incorrects.

Messages « Will »

Un « message testamentaire » ( Will Message), également appelé « testament », est un message envoyé par un client et stocké chez le courtier. Si la connexion entre le client et le courtier est interrompue de manière inattendue, le message testamentaire sera transmis à tout abonné du sujet testamentaire (Will Topic).

Les messages « Will » doivent être spécifiés lors de la phase de connexion. Il est donc obligatoire de les définir avant d’appeler QMqttClient::connectToHost() ou QMqttClient::connectToHostEncrypted(). Un message « Will » possède toutes les propriétés d’un message standard, ainsi qu’un sujet « Will », un niveau de qualité de service (QoS), un indicateur de conservation et une charge utile.

Si le client se déconnecte du courtier de manière normale en appelant QMqttClient::disconnectFromHost(), le courtier supprimera le message « Will ». Si nécessaire, il incombe au client d’envoyer tous les messages requis avant de se déconnecter.

Messages conservés

Les messages conservés sont stockés côté broker. Lorsque de futurs clients se connecteront, ils recevront ces messages. Un cas d’utilisation typique consiste à stocker l’état de santé actuel de l’éditeur dans un message conservé. Les abonnés recevront instantanément un message concernant cet état.

Un broker ne peut stocker que le dernier message conservé envoyé pour un sujet donné. Si un client publie un message conservé avec un niveau de qualité de service (QoS) égal à zéro, tout message précédemment conservé pour ce sujet au niveau du broker doit être supprimé. Le broker est censé stocker le dernier message, mais peut également le supprimer. Cela dépend de l’implémentation du broker.