This topic describes key concepts for ApsaraMQ for MQTT and the Message Queuing Telemetry Transport (MQTT) protocol. Terms are organized into four categories: core product concepts, network, protocol, and solution-specific terms.
Core concepts
The following terms are specific to ApsaraMQ for MQTT. If you are already familiar with the MQTT protocol, start here to learn what is unique to this product.
Instance
An instance is an ApsaraMQ for MQTT service entity that you purchase. Each instance has a globally unique endpoint URL. To start using ApsaraMQ for MQTT, create an instance in your target region and connect through the assigned endpoint. For setup instructions, see Getting started with ApsaraMQ for MQTT.
ApsaraMQ for MQTT broker
A server node that handles MQTT protocol interactions. The broker routes messages between ApsaraMQ for MQTT clients and exchanges messages with ApsaraMQ for RocketMQ.
ApsaraMQ for MQTT client
A mobile node that connects to an ApsaraMQ for MQTT broker to publish or subscribe to messages.
Client ID
A globally unique identifier for each client connection. If a client attempts to connect with a Client ID that is already in use, the connection is rejected.
A Client ID uses the format <GroupID>@@@<DeviceID> and must meet the following requirements:
Maximum length: 64 characters
No non-printable characters
For the full list of constraints, see Limits.
Group ID
An identifier that represents a class of devices with the same features and logic. For example, all temperature sensors in a deployment might share one Group ID. Create Group IDs in the ApsaraMQ for MQTT console before connecting clients.
Device ID
A unique identifier that you assign to each individual device. Each Device ID must be globally unique. For example, you can use the serial number of a sensor as the Device ID.
Message ID
A globally unique identifier that ApsaraMQ for MQTT automatically assigns to each message. Use Message IDs to trace delivery paths and troubleshoot issues. For details, see Query message traces.
Parent topic
A first-level topic in the ApsaraMQ for MQTT topic hierarchy. MQTT uses a publish-subscribe model where every message belongs to a topic. You must create parent topics in the ApsaraMQ for MQTT console before publishing or subscribing.
Subtopic
A second-level or third-level topic under a parent topic. Unlike parent topics, subtopics do not need to be created in the console. Specify them directly in your code using the following format:
<Parent topic>/<Level-2 topic>/<Level-3 topic>For example: SendMessage/demo/producer
The combined length of the parent topic and all subtopic levels must not exceed 64 characters. Exceeding this limit causes client exceptions.
P2P message
A point-to-point message type that ApsaraMQ for MQTT provides as an extension to the standard MQTT protocol. P2P messages are delivered directly to a specific client without requiring a matching subscription on the receiving end. For details, see P2P messaging (MQTT).
Rule
A resource that enables data exchange between ApsaraMQ for MQTT and other Alibaba Cloud products. Three rule types are available:
| Rule type | Description |
|---|---|
| Data inbound rule | Reads data from another Alibaba Cloud product and pushes it to an ApsaraMQ for MQTT client over the MQTT protocol. This lets you use the source product's API to send data to MQTT clients. See Data inbound from other cloud products. |
| Data outbound rule | Exports messages from an ApsaraMQ for MQTT client to another Alibaba Cloud product. This lets you use the destination product's API to consume MQTT messages. See Data outbound to other cloud products. |
| Client online/offline notification rule | Exports client connection and disconnection events to another Alibaba Cloud product for monitoring or processing. See Data outbound for online and offline events of ApsaraMQ for MQTT clients. |
Network
Endpoint
The URL that clients use to connect to an ApsaraMQ for MQTT instance. Two types of endpoints are available:
Public endpoints: For mobile terminals and external devices.
Internal endpoints: For services running within the same Alibaba Cloud region.
In addition to the standard MQTT protocol on port 1883, ApsaraMQ for MQTT supports Secure Sockets Layer (SSL) encryption and WebSocket connections. An endpoint URL is automatically assigned when you create an instance. For setup details, see Getting started with ApsaraMQ for MQTT.
Protocol
MQTT
Message Queuing Telemetry Transport (MQTT) is an industry-standard messaging protocol for Internet of Things (IoT) and mobile Internet scenarios. The protocol is suitable for data transmission between mobile terminals. ApsaraMQ for MQTT supports this protocol by default.
QoS
Quality of Service (QoS) determines the delivery guarantee for each message. QoS is set independently on the sender side and the consumer side:
Sender-side QoS: Controls delivery reliability from the sender to the ApsaraMQ for MQTT broker.
Consumer-side QoS: Controls delivery reliability from the broker to the consumer.
Three QoS levels are available:
| Level | Guarantee | Typical use case |
|---|---|---|
| QoS 0 | At-most-once delivery. Messages may be lost. | High-frequency data where occasional loss is acceptable, such as periodic sensor readings where the next reading replaces a lost one. |
| QoS 1 | At-least-once delivery. Messages are guaranteed to arrive but may be duplicated. | Data where occasional duplicates are acceptable, such as device status updates. Handle duplicates at the application level if needed. |
| QoS 2 | Exactly-once delivery. Messages arrive once and only once. | Data that must not be lost or duplicated, such as billing events or security alerts. |
cleanSession
The cleanSession flag in the MQTT protocol controls whether a consumer client retains its session state across connections. This setting is independent of the sender's configuration.
IoT devices frequently disconnect due to network instability or power constraints. Without persistent sessions, a reconnecting client would lose its subscriptions and miss any messages sent while it was offline. The cleanSession flag addresses this by providing two modes:
cleanSession=true: The broker discards any previous session state when the client reconnects. The client starts fresh with no subscriptions and no queued offline messages.cleanSession=false: The broker preserves the client's subscriptions and queues messages sent while the client was offline. The client must process these queued messages after reconnecting.
Using QoS and cleanSession together
The combination of consumer-side QoS and cleanSession determines message delivery behavior:
| 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. |
Keep the following rules in mind:
The
cleanSessionflag must remain the same for every connection from a given client. Changing it between connections can cause offline messages to be misjudged.ApsaraMQ for MQTT does not support
cleanSession=falsefor QoS 2 messages. If a client subscribes with QoS 2, thecleanSession=falsesetting has no effect.For P2P messages, the
cleanSessionbehavior is determined by the receiving client's configuration.The configuration of QoS and cleanSession is supported only by client-side SDKs, not by server-side SDKs.
Solutions
The following terms apply to specific solution architectures built on ApsaraMQ for MQTT.
Real-Time Communication (RTC)
A network communication method for voice and video. Common use cases 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 an RTC system, also known as an audio-and-video management service, that controls the lifecycle of all RTC sessions. You must build and deploy this service yourself, typically on Alibaba Cloud infrastructure.
Mobile audio-and-video application
The end-user application in an RTC system, also known as a terminal app. Users interact with this app to initiate or join audio and video calls.
Smart AP
A network device, such as a smart router, that supports application programming. Smart APs handle both Internet access and Local Area Network (LAN) device control.
Digital price tag
An electronic display screen deployed in locations such as shopping malls and supermarkets. Digital price tags connect to Smart AP nodes through wireless protocols such as Bluetooth or ZigBee.
Digital price tag management service
The backend service that manages content displayed on digital price tags. It handles tasks such as price updates and change-request tracking.
RDS
ApsaraMQ for MQTT integrates with Alibaba Cloud Relational Database Service (RDS), a stable, reliable, and scalable online database service, to persist status changes for tasks such as price changes in solutions such as digital price tag systems.
Log Service
ApsaraMQ for MQTT integrates with Alibaba Cloud Log Service to store all operation logs for auditing and traceability in solutions such as digital price tag systems.