MQTT (Message Queuing Telemetry Transport) constitue un protocole de communication conçu spécifiquement pour l'IoT, initialement développé par IBM. Ce protocole se distingue par son architecture légère basée sur le modèle publish/subscribe, le rendant particulièrement adapté aux environnements contraints en bande passante et aux connexions réseau instables.

Les domaines d'application principaux incluent la messagerie instantanée, les communications machine-à-machine (M2M), ainsi que la collecte de données provenant de capteurs distants. Sa conception repose sur cinq piliers fondamentaux : l'open source, la fiabilité, la légèreté, la simplicité et l'efficacité.

2. Caractéristiques essentielles du protocole MQTT

Le protocole MQTT présente plusieurs avantages techniques significatifs qui expliquent son adoption massive dans l'écosystème IoT :

• Overhead minimal : La taille minimale des messages atteint seulement 2 octets, permettant une transmission efficace même sur des connexions limitées.
• Compatibilité multiplateforme : Des implémentations existent pour de nombreux langages (C, Java, Python, Ruby) avec des bibliothèques cleintes matures et faciles à intégrer.
• Modèle publish/subscribe : Cette architecture découple les producteurs et consommateurs de messages, simplifiant considérablement le développement d'applications distribuées.
• Niveaux de qualité de service (QoS) : Trois niveaux de livraison garantissent la réception des messages selon les besoins applicatifs (au plus une fois, au moins une fois, exactement une fois).
• Conservation des messages : Les messages retainus permettent aux nouveaux clients de recevoir immédiatement le dernier état pertinent lors de leur connexion.

3. Principaux serveurs MQTT du marché

EMQX (anciennement EMQ)

EMQX représente une solution MQTT écrite en Erlang, offrant une architecture distribuée hautement évolutive capable de gérer des millions de connexions simultanées. Ce serveur supporte nativement les protocoles CoAP et LwM2M, ce qui en fait une plateforme універсаlle pour les déploiements IoT industriels et les applications 5G. Le projet maintient une communauté active sur GitHub avec des milliers de contributeurs.

Mosca

Cette implémentation entièrement développée en Node.js séduit les développeurs par sa simplicité d'installation et son intégration naturelle dans les environnements JavaScript. Elle convient parfaitement aux prototypes et aux projets de petite envergure nécessitant un broker MQTT rapide à déployer.

VerneMQ

Tout comme EMQX, VerneMQ exploite la puissance du langage Erlang pour offrir des performances élevées et une tolérance aux pannes. Ce broker met l'accent sur la flexibilité de configuration et la sécurité des communications.

Mosquitto

Développé par la Eclipse Foundation en C, Mosquitto incarne la référence open source pour les implémentations MQTT. Sa légèreté en fait le choix privilégié pour les dispositifs contraints comme les microcontrôleurs, les capteurs basse consommation et les appareils mobiles. Andy Stanford-Clark, l'un des créateurs du protocole, l'utilise d'ailleurs pour son système domotique personnel.

D'autres solutions méritent attention : HiveMQ (édition communautaire disponible), Apache ActiveMQ Artemis, RabbitMQ (avec plugin MQTT), et IBM MessageSight pour les environnements enterprise.

4. Résolution du problème « X.service is not a native service » avec systemctl pour EMQ

Lors de la tentative d'activation du démarrage automatique d'EMQ avec systemctl, l'erreur suivante peut apparaître :

admin@serveur:~# systemctl enable emqx
Executing: /lib/systemd/systemd-sysv-install enable emqx
emqx.service is not a native service, redirecting to systemd-sysv-install.
admin@serveur:~# systemctl list-unit-files | grep emq
emqx.service                               generated

Cette situation indique que le service EMQ n'est pas registered en tant qu'unité native systemd mais fonctionne via un script d'initialisation SysV. Le système de gestion redirige automatiquement vers le mécanisme SysV traditionnel.

Comprendre l'origine du problème

La documentation systemd précise que ce comportement se produit lorsqu'une unité est un script SysV init.d. Dans ce cas, systemctl délègue la gestion à des outils comme chkconfig, update-rc.d ou équivalents selon la distribution Linux utilisée.

Il est probable qu'une configuration d'autostart ait déjà été appliquée précédemment via update-rc.d, ce qui explique l'état « generated » plutôt que « enabled » ou « disabled ».

Méthodes de diagnostic et de résolutino

Pour vérifier la présence du service dans les niveaux d'exécution, examinez le répertoire /etc/rc3.d/ (niveau 3, mode texte multiutilisateur) :

admin@serveur:~# ll /etc/rc3.d/
rwxrwxrwx  1 root root   14 Jul  5  2021 S01emqx -> ../init.d/emqx

La présence d'un lien symbolique dans ce répertoire confirme l'intégration au système d'initialisation. Si l'utilitaire chkconfig est installé sur votre système, vous pouvez l'utiliser pour gérer le service :

# Activation du service au démarrage
chkconfig emqx on

# Vérification de l'état
chkconfig --list emqx

# Désactivation du service
chkconfig emqx off

Pour les distributions utilisant update-rc.d (principalement Debian et Ubuntu), les commandes suivantes s'appliquent :

# Ajout aux niveaux d'exécution par défaut
update-rc.d emqx defaults

# Suppression complète du service au démarrage
update-rc.d emqx remove

Fonctionnement de update-rc.d

Ce script Perl gère automatiquement les liens symboliques dans les répertoires /etc/rcN.d/ (où N varie de 0 à 6 selon le niveau d'exécution). Les scripts réels résident dans /etc/init.d/ tandis que les liens dans les répertoires rcN.d déterminent l'ordre de démarrage et les conditions d'activation des services.

Le préfixe « S » indique un service à démarrer (Start), suivi d'un numéro déterminant la séquence de lancement, puis du nom du service. Cette organisation garantit le bon ordre de dépendance entre les services système.