This topic describes the basic concepts and terms for ApsaraMQ for MQTT and the Message Queuing Telemetry Transport (MQTT) protocol.
Basic concepts
Instance
An instance is an entity that represents an ApsaraMQ for MQTT service that you purchase. Each ApsaraMQ for MQTT instance has a globally unique endpoint URL. Before you can use ApsaraMQ for MQTT, you must create an instance in the target region and use its endpoint to access the service. For instructions on creating an ApsaraMQ for MQTT instance, see Getting started with ApsaraMQ for MQTT.
Message ID
The globally unique identifier of a message. The ApsaraMQ for MQTT system automatically generates message IDs to uniquely identify each message. You can use a message ID to trace messages and troubleshoot issues. For more information, see Query message traces.
ApsaraMQ for MQTT broker
A server node provided by ApsaraMQ for MQTT for interactions based on the MQTT protocol. It is used to send and receive messages with ApsaraMQ for MQTT clients and ApsaraMQ for RocketMQ.
ApsaraMQ for MQTT client
A mobile node that interacts with an ApsaraMQ for MQTT broker is referred to as an ApsaraMQ for MQTT client.
P2P message
A special type of message that ApsaraMQ for MQTT provides based on the standard MQTT protocol. This type of message can be sent directly to a specific ApsaraMQ for MQTT client without requiring a matching subscription. For more information, see P2P messaging (MQTT).
Parent topic
The MQTT protocol is based on the publish-subscribe (pub/sub) model. Therefore, every message belongs to a topic. The MQTT protocol supports multiple topic levels. A level-1 topic is a parent topic. Before you can use ApsaraMQ for MQTT, you must create a parent topic in the ApsaraMQ for MQTT console.
Subtopic
Level-2 and level-3 topics are subtopics of a parent topic. You do not need to create subtopics in the console. You can specify them directly in your code. The naming format is <Parent topic name>/<Level-2 topic name>/<Level-3 topic name>. The parent topic and its subtopics are separated by forward slashes (/). For example, SendMessage/demo/producer. Note that in ApsaraMQ for MQTT, the total length of a parent topic and its subtopics cannot exceed 64 characters. If the length exceeds this limit, client exceptions occur.
Client ID
An identifier that globally and uniquely identifies a client in ApsaraMQ for MQTT. If you use a client ID that is already in use by another client to access the ApsaraMQ for MQTT service, the access request is denied.
A client ID consists of a group ID and a device ID. The format of a client ID is <GroupID>@@@<DeviceID>. A client ID cannot exceed 64 characters in length or contain non-printable characters. For more information, see Limits.
Group ID
An identifier for a group of nodes that have the same logic and features. A group ID represents a class of devices with the same features. You must create a group ID in the ApsaraMQ for MQTT console. For more information, see Getting started with ApsaraMQ for MQTT.
Device ID
A unique identifier that you specify for each device. A device ID must be globally unique. For example, you can use the serial number of a sensor as the device ID.
Rule
A resource that ApsaraMQ for MQTT uses to exchange data with other Alibaba Cloud products. Rules are classified into the following three types:
Data inbound rule: Reads data from a configured Alibaba Cloud product and pushes the data to an ApsaraMQ for MQTT client over the MQTT protocol. This lets you directly call the API of the Alibaba Cloud product to send data to the ApsaraMQ for MQTT client. For more information, see Data inbound from other cloud products.
Data outbound rule: Exports messages sent by an ApsaraMQ for MQTT client to another configured Alibaba Cloud product. This lets you directly call the API of the cloud product to read messages sent from the ApsaraMQ for MQTT client. For more information, see Data outbound to other cloud products.
Client online/offline notification rule: Exports the online and offline event data of ApsaraMQ for MQTT clients to another Alibaba Cloud product. For more information, see Data outbound for online and offline events of ApsaraMQ for MQTT clients.
Network
Endpoint
ApsaraMQ for MQTT provides public and internal endpoints. We recommend that you use public endpoints for mobile terminals. In addition to the standard protocol on port 1883, ApsaraMQ for MQTT also supports methods such as Secure Sockets Layer (SSL) encryption and WebSocket. An endpoint URL is automatically assigned after you create an instance. Keep the URL safe. For more information, see Getting started with ApsaraMQ for MQTT.
Protocol
MQTT
An industry-standard protocol for the Internet of Things (IoT) and mobile Internet fields. The protocol is suitable for data transmission between mobile terminals. ApsaraMQ for MQTT supports this protocol by default.
QoS
Quality of Service (QoS) is the service quality of message transmission. You can set QoS levels on the message sender and the message consumer.
QoS settings on the sender: Affect the transmission quality of messages sent from the sender to ApsaraMQ for MQTT.
QoS settings on the consumer: Affect the transmission quality of messages delivered from the ApsaraMQ for MQTT server to the consumer.
QoS includes the following levels:
QoS 0: at-most-once delivery.
QoS 1: at-least-once delivery.
QoS 2: exactly-once delivery.
cleanSession
The cleanSession flag in the MQTT protocol defines whether a consumer client retains its previous state after a TCP connection is established. This setting is independent of the message sender's settings. The semantics are as follows:
cleanSession=true: When the consumer client comes online again, it does not retain previous subscription relationships or offline messages.
cleanSession=false: When the consumer client comes online again, it retains previous subscription relationships and must process previous offline messages.
Note the following points when you use QoS and cleanSession together:
MQTT requires that the cleanSession flag for each client must be fixed for each connection and cannot be changed dynamically. Otherwise, offline messages may be misjudged.
MQTT does not support non-cleanSession for QoS 2 messages. If a client subscribes to messages with QoS 2, the cleanSession=false setting does not take effect.
The cleanSession setting for P2P messages is determined by the configuration of the receiving client.
Only client SDKs support the configuration of QoS and cleanSession.
The results of different combinations of consumer-side QoS and cleanSession are shown in the following table.
Table 1. Combinations of QoS and cleanSession
QoS level | cleanSession=true | cleanSession=false |
QoS 0 | No offline messages. Only one push attempt for online messages. | Offline messages are available. Only one push attempt for online messages. |
QoS 1 | No offline messages. Online messages are guaranteed to be delivered. | Offline messages are available. All messages are guaranteed to be delivered. |
QoS 2 | No offline messages. Online messages are guaranteed to be delivered and received only once. | Not supported. |
Solutions
RTC
Real-Time Communication. A network communication method used mainly for voice and video. Common application scenarios include voice calls, video calls, and video conferences.
RTC server
The audio and video media channel service provided by Alibaba Cloud Real-Time Communication (RTC).
Audio-and-video service management server
A management node in a Real-Time Communication system, also known as an audio-and-video management service. You must build your own audio-and-video management service to control the lifecycle of all RTC sessions. This management node is typically deployed in the cloud using basic Alibaba Cloud products.
Mobile audio-and-video application
The terminal application used by end users in a Real-Time Communication system, also known as a terminal app. End users use this app to initiate or join audio or video calls.
Smart AP
Common network devices, such as smart routers, that support application programming. They can handle both Internet access and local area network (LAN) device control.
Digital price tag
Electronic display screens distributed in places such as shopping malls and supermarkets. They are usually networked with smart access point (AP) nodes using wireless sensor network protocols such as Bluetooth or ZigBee.
Digital price tag management service
The backend service in a digital price tag system that manages the content displayed on the electronic screens. It is mainly responsible for managing and querying manual tasks such as price changes.
RDS
A stable, reliable, and scalable online database service from Alibaba Cloud. In a digital price tag system, it is used for the persistence of status changes for tasks such as price changes.
Log Service
A log storage service from Alibaba Cloud. In a digital price tag system, it is used to persistently store all operation logs for auditing and traceability.