Il existe de nombreux clients et serveurs MQTT dans des langages et pour des systèmes d’exploitation variés : c’est une excellente solution pour faire communiquer des appareils utilisant des technologies différentes. Et bien sûr, il existe des clients JavaScript  pour les applications web.

A notre avis les principales forces de MQTT sont :

• Il est agnostique quant aux informations qu’il permet de faire transiter, c’est uniquement un protocole de transport pour les objets connectés. La taille maximale du payload d’un message est de 256Mo
• Sa légèreté : n’augmente que légèrement la consommation de bande passante
• Il permet de contrôler facilement la fiabilité de transmission des informations
• Il constitue une abstraction pour la gestion du réseau : pour des connexions instables, la gestion des déconnexions/reconnexions est simplifiée
• Il permet à de nombreux clients de recevoir ou de diffuser une information
• Le chiffrement via TLS/SSL
• La possibilité de gérer quels clients ont le droit d’accéder à une information ou de la publier

Quel est le principe de fonctionnement ?

MQTT permet à des clients de publier et/ou de s’abonner à des informations. L’ensemble des clients communiquent avec un broker : un programme en charge de réceptionner les informations publiées et de les retransmettre aux clients abonnés :

Les clients peuvent publier ou s’abonner à des « topics » MQTT, par exemple  « /data/A » ce qui permet d’identifier les informations simplement. Les clients peuvent s’abonner à plusieurs topics.

Il faut faire fonctionner un broker, l’ensemble des informations transitent par lui. La communication entre clients n’est jamais directe ce qui peut être un inconvénient pour certain projets.

Pourquoi gérer la Qualité de service alors que MQTT utilise TCP ?

Pour chaque topic, MQTT permet de gérer la QoS désirée, les messages seront délivrés :

• QoS 0 : Une fois au plus
• QoS 1 : Une fois au moins
• QoS 2 : Exactement une seule fois

TCP assure la fiabilité des transmissions sur le réseau. Mais MQTT permet en plus de gérer les pertes de connexion, lors d’une reconnexion, en QoS 1 et QoS 2, les informations non transmises sont retransmises.

En QoS 1, les messages sont acquittés par le receveur, si cet acquittement n’arrive pas le message est retransmis :

En QoS 2, l’acquittement est lui même validé afin de garantir que le message n’arrive qu’une seule fois :

En QoS 0 par contre, les informations sont simplement transmises et validées uniquement par TCP :

Utiliser MQTT pour un système embarqué sous Linux

Il existe beaucoup de clients et de broker MQTT.  Et faire un choix n’est pas aisé. Wikipedia présente les fonctionnalitées implémentées par ces logiciels, c’est un bon point de départ.

Dans notre cas, nous cherchions une librairie utilisable dans un programme en C embarqué sous Linux. Ainsi qu’un broker fonctionnant sur un appareil embarqué lui aussi sous Linux. L’objectif est de faire transiter des flux d’informations découpés en paquets de  1/10 de seconde sur une dizaine de topics.

• Le broker
  Le broker de référence sous Linux s’appelle Mosquitto, développé  sous licence Eclipse Public License 1.0 par la fondation Apache. Il est disponible dans Buildroot, c’est donc assez naturellement que nous l’avons  évalué puis sélectionné.
• Le client
  Pour se linker avec un programme en C sous Linux, nous avons considéré deux candidats: la librairie cliente en C de Mosquitto et libPaho en C. Elles sont toutes les deux maintenues par la fondation Apache et publiées sous Eclipse Public License 1.0. Après les avoir évaluées , nous avons opté pour Paho.mqtt.c, pour la clarté de sa documentation et son intégration à Buildroot (ce n’est pas le cas de la librairie cliente de Mosquitto).

En résumé

MQTT est une excellente solution pour assurer la communication entre appareils et son adoption devrait être de plus en plus large à l’avenir. Dans le cadre d’un logiciel écrit en langage C, il simplifie beaucoup la gestion du réseau, notamment les cas de connexion/reconnexion.