This topic introduces the terms that are used in ApsaraMQ for MQTT and the Message Queuing Telemetry Transport (MQTT) protocol.
Basic terms
instance
An entity that you create when you purchase ApsaraMQ for MQTT. Each ApsaraMQ for MQTT instance corresponds to a globally unique endpoint. Before you use ApsaraMQ for MQTT, you must create an instance in the corresponding region and use the endpoint of the instance to access the service. For information about how to create an ApsaraMQ for MQTT instance, see Use ApsaraMQ for MQTT SDK for Java to implement messaging between ApsaraMQ for MQTT clients.
message ID
The globally unique identifier of a message. Message IDs are automatically generated by ApsaraMQ for MQTT and are used to track messages and troubleshoot errors. For more information, see Query message traces.
ApsaraMQ for MQTT broker
A server node provided by ApsaraMQ for MQTT for MQTT-based interactions. ApsaraMQ for MQTT brokers are used to implement messaging with ApsaraMQ for MQTT clients and ApsaraMQ for RocketMQ.
ApsaraMQ for MQTT client
A mobile node that is used to interact with an ApsaraMQ for MQTT broker.
P2P messaging
A special messaging model provided by ApsaraMQ for MQTT based on the standard MQTT protocol. In this messaging model, messages can be sent to an ApsaraMQ for MQTT client without subscription. For more information, see P2P Messaging model (MQTT).
parent topic
MQTT is a messaging protocol that is based on the publish-subscribe (pub/sub) model. In MQTT, each message belongs to a topic. The MQTT protocol supports multiple topic levels. Level-1 topics are parent topics. Before you use ApsaraMQ for MQTT, you must create a parent topic in the ApsaraMQ for MQTT console or the ApsaraMQ for RocketMQ console.
subtopic
A level-2 topic or level-3 topic is a subtopic of a parent topic in ApsaraMQ for MQTT. You can specify subtopics in your application code without the need to create subtopics in the ApsaraMQ for MQTT console. The name of a subtopic is in the <Name of parent topic>/<Name of level-2 topic>/<Name of level-3 topic> format. The parent topic and its subtopics are separated by forward slashes (/). Example: SendMessage/demo/producer. The name of a subtopic cannot exceed 64 characters in length in ApsaraMQ for MQTT. Otherwise, exceptions can occur on the client.
client ID
An identifier that globally and uniquely identifies a client in ApsaraMQ for MQTT. If you use a client ID that has been used by another client to access ApsaraMQ for MQTT, 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 and cannot contain non-printable characters. For more information, see Limits.
group ID
An identifier that specifies a group of nodes that use identical logic and features. A group ID represents a set of devices that support the same features. You must create groups in the ApsaraMQ for MQTT console. For information about how to create a group, see Use ApsaraMQ for MQTT SDK for Java to implement messaging between ApsaraMQ for MQTT clients.
device ID
An identifier that you specify to uniquely identify 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 is used by ApsaraMQ for MQTT to exchange data with other Alibaba Cloud services. You can specify the following types of rules in ApsaraMQ for MQTT:
Data inbound rule: You can configure a data inbound rule to read data from an Alibaba Cloud service and push the data to an ApsaraMQ for MQTT client over the MQTT protocol. This way, you can call the API operations of the specified Alibaba Cloud service to send data to the ApsaraMQ for MQTT client. For more information, see Import data from other cloud services to ApsaraMQ for MQTT.
Data outbound rule: You can configure a data outbound rule to export messages from an ApsaraMQ for MQTT client to another Alibaba Cloud service. This way, you can call the API operations of the Alibaba Cloud service to read messages that are sent from the ApsaraMQ for MQTT client. For more information, see Export data from ApsaraMQ for MQTT to other Alibaba Cloud services.
Rule for client status notifications: You can configure a rule for client status notifications to export the status event data of an ApsaraMQ for MQTT client to another Alibaba Cloud service. For more information, see Export status events of ApsaraMQ for MQTT clients.
Network-related terms
endpoint
ApsaraMQ for MQTT provides public and internal endpoints. We recommend that you use public endpoints for mobile devices. In addition to the standard MQTT port 1883, ApsaraMQ for MQTT also supports Secure Sockets Layer (SSL) encryption and WebSocket. An endpoint is automatically assigned to an instance after the instance is created. Keep the endpoint for future reference. For information about how to create an instance, see Use ApsaraMQ for MQTT SDK for Java to implement messaging between ApsaraMQ for MQTT clients.
MQTT-related terms
MQTT
An industry-standard protocol for the IoT and mobile Internet fields. The protocol is suitable for data transmission between mobile devices. By default, ApsaraMQ for MQTT supports the MQTT protocol.
QoS
The quality of service (QoS) level in message transmission. You can separately specify QoS levels for producers and consumers.
The QoS level of a producer affects the transmission quality of messages that are sent from the producer to ApsaraMQ for MQTT.
The QoS level of a consumer affects the transmission quality of messages that are delivered from the ApsaraMQ for MQTT broker to the consumer.
MQTT provides the following QoS levels:
QoS0: Messages are delivered to the intended ApsaraMQ for MQTT clients at most once.
QoS1: Messages are received by the intended ApsaraMQ for MQTT clients at least once.
QoS2: Messages are delivered to the intended ApsaraMQ for MQTT clients exactly once.
cleanSession
In the MQTT protocol, the cleanSession parameter specifies the method that is used to process offline messages and previous subscriptions after a TCP connection is established. The configuration of this parameter is not affected by the configuration in the producer. Set this parameter based on the following syntax:
cleanSession=true: When an offline ApsaraMQ for MQTT consumer client goes online again, all its previous subscriptions and offline messages are cleaned up.
cleanSession=false: When an offline ApsaraMQ for MQTT consumer client goes online again, it processes previous offline messages, and its previous subscriptions remain effective.
Take note of the following points when you use QoS levels and the cleanSession parameter together:
In the MQTT protocol, the value of the cleanSession parameter for each client cannot be modified upon each connection. Otherwise, some messages may be mistaken as offline messages.
In the MQTT protocol, the cleanSession parameter cannot be set to false for messages with QoS2. If an ApsaraMQ for MQTT client subscribes to such messages, the subscription does not take effect even if the cleanSession parameter is set to false.
The cleanSession parameter of P2P messages is subject to the configuration of the ApsaraMQ for MQTT client that receives the messages.
The following Combinations of QoS levels and the cleanSession parameter table lists the results of different combinations of QoS levels and the cleanSession parameter in a consumer.
Table 1. Combinations of QoS levels and the cleanSession parameter
QoS level | cleanSession=true | cleanSession=false |
QoS0 | Offline messages are not delivered. Only one delivery attempt is made for online messages. | Offline messages are delivered. Only one delivery attempt is made for online messages. |
QoS1 | Offline messages are not delivered. Online messages are guaranteed to reach the intended ApsaraMQ for MQTT clients. | Offline messages are delivered. Offline and online messages are guaranteed to reach the intended ApsaraMQ for MQTT clients. |
QoS2 | Offline messages are not delivered. Online messages are guaranteed to reach the intended ApsaraMQ for MQTT clients and are received only once. | Not supported. |
Solution-related terms
RTC
A real-time network communication method for the audio and video fields. This method is used in scenarios such as voice calls, video calls, and video conferencing.
RTC server
A server that hosts audio-and-video media channel services provided by Alibaba Cloud Real-Time Communication (RTC).
audio-and-video service management server
A management node in the RTC system, which is also called an audio-and-video management service. You can develop your own audio-and-video management services to manage the lifecycles of all RTC sessions. In most cases, such management nodes are deployed on Alibaba Cloud. You can use Alibaba Cloud services to deploy your audio-and-video management services.
mobile audio-and-video application
A terminal application that is used by end users in the RTC system. End users use this application to initiate or join a voice or video call.
smart AP
A common network device that supports application programming and can enable Internet access and manage LAN devices. For example, a smart router is a smart access point (AP).
digital price tag
An electronic screen that is used in places such as shopping malls and supermarkets. Digital price tags are networked by using smart AP nodes based on a wireless sensor network protocol such as Bluetooth or ZigBee.
digital price tag management service
The backend service of a digital price tag system. The service is used to manage the content that is displayed on the electronic screens and to manage and query manual tasks such as price changes.
RDS
A stable, reliable, and scalable online database service provided by Alibaba Cloud. RDS is used to persistently store task status changes, such as price changes, in a digital price tag system.
Simple Log Service
A log storage service provided by Alibaba Cloud. This service is used to persistently store all the operation logs in a digital price tag system for auditing and tracing purposes.