Dans la deuxième partie de notre voyage dans le nuage, je vous avais parlé de la transmission des paquets IP entre sockets selon le protocole TCP classique. Les sockets représentent les interfaces de connexion des utilisateurs du réseau, chaque socket étant identifié par une adresse IP et un numéro de port. Avec TCP, l’arrivée à bon port des paquets est garantie par certains mécanismes inhérents au protocole. Il y a tellement de langages qui offrent des bibliothèques de programmation par socket qu’il est relativement aisé d’écrire un protocole pour des tâches que l’on souhaite déclencher au moyen d’octets de commande, comme « ON », « RED » ou encore « 3 », ces octets de commande étant transmis en tant que données utiles TCP/IP.

Une application IdO type comprend plusieurs capteurs qui mesurent des grandeurs environnementales et fournissent des entrées aux abonnés d’un réseau domotique. Certains nœuds délivrent de l’information, d’autres consomment des données qui seront ensuite traitées ou affichées sur un écran. Tous ces nœuds ne sont pas en ligne en permanence, mais heureusement ce cas peut être traité par MQTT. MQTT est un protocole de messagerie qui a été conçu au tournant du siècle et qui s’exécute au-dessus du protocole TCP/IP. Au lieu d’utiliser une connexion directe entre les émetteurs de messages et leurs destinataires, il recourt à un courtier (broker) pour distribuer les messages aux seuls clients intéressés, autrement dit aux clients abonnés à un sujet particulier.

Les émetteurs de message (p. ex. des capteurs) et les clients (p. ex. une appli pour smartphone) sont tous abonnés au service du courtier. Le courtier s’occupent également des adresses IP, l’utilisateur/concepteur n’a donc plus à se soucier de leur représentation en longues suites cryptiques. Le message qu’un client envoie contient un champ « Sujet » qui est décrit au moyen de chaînes de caractères faciles à retenir. Par exemple :
Building / Office / Temperature
Building / Kitchen / Temperature
Un client (p. ex. un smartphone) peut s’abonner à un sujet spécifique, l’emploi des caractères de remplacement étant permis :
Building / + / Temperature
MQTT offre également pour les messages un service appelé Quality of Service (QoS) et qui possèdent plusieurs niveaux de qualité. Le niveau 0 n’envoie un message qu’une seule fois (il se peut qu’il ne soit pas reçu). Le niveau 1 garantit que le message aura été reçu au moins une fois (plusieurs copies du message peuvent être reçues). Quant au niveau 2, il garantit que le message est bien reçu, et une seule fois. La fonction Last Will and Testament (LWT) est également utile : chaque client a la possibilité de composer un message exprimant ses dernières volontés. Si le client en question est déconnecté de façon impromptue, le courtier envoie alors ce « dernier » message aux clients abonnés au même sujet que le disparu. Le courtier peut aussi stocker les retained messages (messages retenus), par définition les derniers messages envoyés sur un sujet donné. Lorsqu’un nouveau client s’abonne au dit sujet, le courtier lui envoie le message retenu correspondant. Cette fonction est utile lorsqu’on travaille avec des capteurs qui n’envoient que sporadiquement des données puisqu’elle garantit que la dernière valeur mesurée sera toujours disponible.

Vous ne perdrez pas votre temps à apprendre les dessous du protocole MQTT. Le code source est ouvert, et MQTT est utilisé par de nombreux acteurs bien connus de l’IdO. Je reviendrai plus en détail sur MQTT lors de la prochaine étape de notre voyage !    [HM]

Le site officiel de MQTT  | L’essentiel sur MQTT :