Cette rubrique décrit les concepts clés d’ApsaraMQ for MQTT et du protocole Message Queuing Telemetry Transport (MQTT). Les termes sont classés en quatre catégories : concepts fondamentaux du produit, réseau, protocole et terminologie spécifique aux solutions.
Concepts fondamentaux
Les termes suivants sont propres à ApsaraMQ for MQTT. Si vous maîtrisez déjà le protocole MQTT, commencez par cette section pour découvrir les spécificités de ce produit.
Instance
Une instance est une entité de service ApsaraMQ for MQTT que vous achetez. Chaque instance dispose d’une URL d’endpoint globalement unique. Pour commencer à utiliser ApsaraMQ for MQTT, créez une instance dans la région cible et connectez-vous via l’endpoint attribué. Pour obtenir des instructions de configuration, consultez la rubrique Prise en main d’ApsaraMQ for MQTT.
Broker ApsaraMQ for MQTT
Nœud serveur qui gère les interactions basées sur le protocole MQTT. Le broker achemine les messages entre les clients ApsaraMQ for MQTT et échange des messages avec ApsaraMQ for RocketMQ.
Client ApsaraMQ for MQTT
Nœud mobile qui se connecte à un broker ApsaraMQ for MQTT pour publier ou s’abonner à des messages.
Client ID
Identifiant globalement unique pour chaque connexion client. Si un client tente de se connecter avec un Client ID déjà utilisé, la connexion est rejetée.
Un Client ID utilise le format <GroupID>@@@<DeviceID> et doit respecter les exigences suivantes :
Longueur maximale : 64 caractères
Aucun caractère non imprimable autorisé
Pour la liste complète des contraintes, consultez la rubrique Limites.
Group ID
Identifiant qui représente une classe d’appareils partageant les mêmes fonctionnalités et la même logique. Par exemple, tous les capteurs de température d’un déploiement peuvent partager un seul Group ID. Créez les Group IDs dans la console ApsaraMQ for MQTT avant de connecter les clients.
Device ID
Identifiant unique que vous attribuez à chaque appareil individuel. Chaque Device ID doit être globalement unique. Par exemple, vous pouvez utiliser le numéro de série d’un capteur comme Device ID.
Message ID
Identifiant globalement unique qu’ApsaraMQ for MQTT attribue automatiquement à chaque message. Utilisez les Message IDs pour tracer les chemins de livraison et résoudre les problèmes. Pour plus de détails, consultez la rubrique Interroger les traces de messages.
Parent topic
Topic de premier niveau dans la hiérarchie des topics ApsaraMQ for MQTT. MQTT utilise un modèle de publication-abonnement où chaque message appartient à un topic. Vous devez créer les parent topics dans la console ApsaraMQ for MQTT avant de publier ou de vous abonner.
Subtopic
Topic de deuxième ou troisième niveau sous un parent topic. Contrairement aux parent topics, les subtopics n’ont pas besoin d’être créés dans la console. Spécifiez-les directement dans votre code en utilisant le format suivant :
<Parent topic>/<Level-2 topic>/<Level-3 topic>Par exemple : SendMessage/demo/producer
La longueur combinée du parent topic et de tous les niveaux de subtopics ne doit pas dépasser 64 caractères. Le dépassement de cette limite provoque des exceptions côté client.
Message P2P
Type de message point à point qu’ApsaraMQ for MQTT propose en tant qu’extension du protocole MQTT standard. Les messages P2P sont livrés directement à un client spécifique sans nécessiter d’abonnement correspondant côté destinataire. Pour plus de détails, consultez la rubrique Messagerie P2P (MQTT).
Rule
Ressource qui permet l’échange de données entre ApsaraMQ for MQTT et d’autres produits Alibaba Cloud. Trois types de rules sont disponibles :
| Type de rule | Description |
|---|---|
| Data inbound rule | Lit les données depuis un autre produit Alibaba Cloud et les pousse vers un client ApsaraMQ for MQTT via le protocole MQTT. Cela vous permet d’utiliser l’API du produit source pour envoyer des données aux clients MQTT. Consultez la rubrique Entrée de données depuis d’autres produits cloud. |
| Data outbound rule | Exporte les messages d’un client ApsaraMQ for MQTT vers un autre produit Alibaba Cloud. Cela vous permet d’utiliser l’API du produit de destination pour consommer les messages MQTT. Consultez la rubrique Sortie de données vers d’autres produits cloud. |
| Client online/offline notification rule | Exporte les événements de connexion et de déconnexion des clients vers un autre produit Alibaba Cloud pour la surveillance ou le traitement. Consultez la rubrique Sortie de données pour les événements de connexion et de déconnexion des clients ApsaraMQ for MQTT. |
Réseau
Endpoint
URL que les clients utilisent pour se connecter à une instance ApsaraMQ for MQTT. Deux types d’endpoints sont disponibles :
Endpoints publics : pour les terminaux mobiles et les appareils externes.
Endpoints internes : pour les services exécutés au sein de la même région Alibaba Cloud.
En plus du protocole MQTT standard sur le port 1883, ApsaraMQ for MQTT prend en charge le chiffrement SSL (Secure Sockets Layer) et les connexions WebSocket. Une URL d’endpoint est attribuée automatiquement lors de la création d’une instance. Pour plus de détails sur la configuration, consultez la rubrique Prise en main d’ApsaraMQ for MQTT.
Protocole
MQTT
Message Queuing Telemetry Transport (MQTT) est un protocole de messagerie standard de l’industrie pour les scénarios d’Internet des objets (IoT) et d’Internet mobile. Ce protocole convient à la transmission de données entre terminaux mobiles. ApsaraMQ for MQTT prend en charge ce protocole par défaut.
QoS
Le Quality of Service (QoS) détermine la garantie de livraison pour chaque message. Le QoS est défini indépendamment côté émetteur et côté consommateur :
QoS côté émetteur : contrôle la fiabilité de la livraison de l’émetteur vers le broker ApsaraMQ for MQTT.
QoS côté consommateur : contrôle la fiabilité de la livraison du broker vers le consommateur.
Trois niveaux de QoS sont disponibles :
| Niveau | Garantie | Cas d’utilisation typique |
|---|---|---|
| QoS 0 | Livraison au plus une fois. Les messages peuvent être perdus. | Données haute fréquence où une perte occasionnelle est acceptable, comme les relevés périodiques de capteurs où la lecture suivante remplace celle perdue. |
| QoS 1 | Livraison au moins une fois. Les messages sont garantis d’arriver, mais peuvent être dupliqués. | Données où les doublons occasionnels sont acceptables, comme les mises à jour d’état des appareils. Gérez les doublons au niveau de l’application si nécessaire. |
| QoS 2 | Livraison exactement une fois. Les messages arrivent une seule et unique fois. | Données qui ne doivent ni être perdues ni dupliquées, comme les événements de facturation ou les alertes de sécurité. |
cleanSession
L’indicateur cleanSession du protocole MQTT contrôle si un client consommateur conserve son état de session entre les connexions. Ce paramètre est indépendant de la configuration de l’émetteur.
Les appareils IoT se déconnectent fréquemment en raison de l’instabilité du réseau ou des contraintes énergétiques. Sans sessions persistantes, un client qui se reconnecte perdrait ses abonnements et manquerait tous les messages envoyés pendant son indisponibilité. L’indicateur cleanSession répond à ce problème en proposant deux modes :
**
cleanSession=true** : le broker ignore tout état de session précédent lorsque le client se reconnecte. Le client repart de zéro, sans abonnements ni messages hors ligne mis en file d’attente.**
cleanSession=false** : le broker conserve les abonnements du client et met en file d’attente les messages envoyés pendant que le client était hors ligne. Le client doit traiter ces messages mis en file d’attente après la reconnexion.
Utilisation conjointe de QoS et de cleanSession
La combinaison du QoS côté consommateur et de cleanSession détermine le comportement de livraison des messages :
| Niveau de QoS | cleanSession=true | cleanSession=false |
|---|---|---|
| QoS 0 | Aucun message hors ligne. Une seule tentative d’envoi pour les messages en ligne. | Les messages hors ligne sont disponibles. Une seule tentative d’envoi pour les messages en ligne. |
| QoS 1 | Aucun message hors ligne. La livraison des messages en ligne est garantie. | Les messages hors ligne sont disponibles. La livraison de tous les messages est garantie. |
| QoS 2 | Aucun message hors ligne. La livraison des messages en ligne est garantie et ils sont reçus une seule fois. | Non pris en charge. |
Gardez à l’esprit les règles suivantes :
L’indicateur
cleanSessiondoit rester identique pour chaque connexion d’un client donné. Le modifier entre les connexions peut entraîner une mauvaise interprétation des messages hors ligne.ApsaraMQ for MQTT ne prend pas en charge
cleanSession=falsepour les messages QoS 2. Si un client s’abonne avec QoS 2, le paramètrecleanSession=falsen’a aucun effet.Pour les messages P2P, le comportement de
cleanSessionest déterminé par la configuration du client récepteur.Seuls les SDK côté client prennent en charge la configuration de QoS et de cleanSession ; les SDK côté serveur ne la prennent pas en charge.
Solutions
Les termes suivants s’appliquent à des architectures de solutions spécifiques construites sur ApsaraMQ for MQTT.
Real-Time Communication (RTC)
Méthode de communication réseau pour la voix et la vidéo. Les cas d’utilisation courants incluent les appels vocaux, les appels vidéo et les visioconférences.
Serveur RTC
Service de canal multimédia audio et vidéo fourni par Alibaba Cloud Real-Time Communication (RTC).
Serveur de gestion des services audio et vidéo
Nœud de gestion dans un système RTC, également appelé service de gestion audio et vidéo, qui contrôle le cycle de vie de toutes les sessions RTC. Vous devez construire et déployer ce service vous-même, généralement sur l’infrastructure Alibaba Cloud.
Application audio et vidéo mobile
Application finale dans un système RTC, également appelée application terminal. Les utilisateurs interagissent avec cette application pour lancer ou rejoindre des appels audio et vidéo.
Smart AP
Appareil réseau, tel qu’un routeur intelligent, qui prend en charge la programmation applicative. Les Smart AP gèrent à la fois l’accès à Internet et le contrôle des appareils du réseau local (LAN).
Étiquette de prix numérique
Écran d’affichage électronique déployé dans des lieux tels que les centres commerciaux et les supermarchés. Les étiquettes de prix numériques se connectent aux nœuds Smart AP via des protocoles sans fil tels que Bluetooth ou ZigBee.
Service de gestion des étiquettes de prix numériques
Service backend qui gère le contenu affiché sur les étiquettes de prix numériques. Il traite des tâches telles que les mises à jour de prix et le suivi des demandes de modification.
RDS
ApsaraMQ for MQTT s’intègre à Alibaba Cloud Relational Database Service (RDS), un service de base de données en ligne stable, fiable et évolutif, afin de persister les changements d’état pour des tâches telles que les modifications de prix dans des solutions comme les systèmes d’étiquettes de prix numériques.
Log Service
ApsaraMQ for MQTT s’intègre à Alibaba Cloud Log Service pour stocker tous les journaux d’opération à des fins d’audit et de traçabilité dans des solutions telles que les systèmes d’étiquettes de prix numériques.