This topic describes the terms of Message Queue for MQTT and the Message Queuing Telemetry Transport (MQTT) protocol.

Terms

instance

An entity that you create when you purchase Message Queue for MQTT. Each Message Queue for MQTT instance maps to a globally unique endpoint. Before you use Message Queue for MQTT, you must create an instance in the corresponding region and access the service by using the endpoint of the instance. For more information about how to create a Message Queue for MQTT instance, see Use Message Queue for MQTT SDK for Java to send and subscribe to messages without cross-service data exchanges.

message ID
A globally unique identifier for a message. Each message ID is automatically generated by Message Queue for MQTT. Message IDs are used to track messages and troubleshoot errors. For more information, see Query the message traces.
Message Queue for MQTT broker
A broker provided by Message Queue for MQTT for MQTT-based interactions. A Message Queue for MQTT broker is responsible for messaging between a Message Queue for MQTT client and Message Queue for Apache RocketMQ.
Message Queue for MQTT client
A mobile node that interacts with a Message Queue for MQTT broker.
P2P message
A special type of message provided by Message Queue for MQTT based on the standard MQTT protocol. This type of message can be sent to a Message Queue for MQTT client without subscriptions. For more information, see P2P messaging for Message Queue for MQTT.
parent topic
MQTT is a messaging protocol based on the publish-subscribe model. Therefore, each message belongs to a topic. The MQTT protocol supports multiple levels of topics. A level-1 topic is a parent topic. Before you use Message Queue for MQTT, you must create a parent topic in the Message Queue for MQTT console or the Message Queue for Apache RocketMQ console.
subtopic
A level-2 or level-3 topic is a subtopic of a parent topic in Message Queue for MQTT. You can specify subtopics in code without the need to create them in the Message Queue for MQTT console. The naming format is <Name of the parent topic>/<Name of the level-2 topic>/<Name of the level-3 topic>. The parent topic and its subtopics are separated by forward slashes (/). Example: SendMessage/demo/producer. The total length of the name for a parent topic and its subtopics cannot exceed 64 characters in Message Queue for MQTT. Otherwise, a client exception occurs.
client ID

An identifier that globally and uniquely identifies a client in Message Queue for MQTT. If a client uses a client ID that has been used by another client to access Message Queue for MQTT, the access request is denied.

A client ID consists of two parts in the format of <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 with identical logic and features. A group ID represents a set of devices that have the same features. A group ID must be created in the Message Queue for MQTT console. For more information about how to create a group ID, see Use Message Queue for MQTT SDK for Java to send and subscribe to messages without cross-service data exchanges.
device ID
An identifier that you specify to uniquely identify each device. Device IDs must be globally unique. For example, you can use the serial number of a sensor as its device ID.
rule
A resource that implements data exchanges between Message Queue for MQTT V3.x.x and other Alibaba Cloud services. You can specify the following types of rules in Message Queue 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 a Message Queue for MQTT client over the MQTT protocol. This way, you can directly call the API of the specified Alibaba Cloud service to send data to the Message Queue for MQTT client. For more information, see Data inflow across cloud products.
  • Data outbound rule: You can configure a data outbound rule to export messages from a Message Queue for MQTT client to another Alibaba Cloud service. This way, you can directly call the API of the Alibaba Cloud service to read messages sent from the Message Queue for MQTT client. For more information, see Export data from Message Queue for MQTT to other Alibaba Cloud services.
  • Rule for client status notification: You can configure a rule for client status notification to export the status event data of a Message Queue for MQTT client to other Alibaba Cloud services. For more information, see Export online and offline events of Message Queue for MQTT clients.

Network-related terms

endpoint

Message Queue for MQTT provides both public and internal endpoints. We recommend that you use public endpoints for mobile devices. In addition to standard MQTT port 1883, Message Queue for MQTT also supports SSL encryption and WebSocket. The endpoint is automatically allocated after an instance is created. Keep the endpoint for future reference. For more information about how to create an instance, see Use Message Queue for MQTT SDK for Java to send and subscribe to messages without cross-service data exchanges.

MQTT-related terms

MQTT
An industry-standard protocol for the IoT and mobile Internet, which is applicable to data transmission between mobile devices. By default, Message Queue for MQTT supports this protocol.
QoS
The quality of service (QoS) level in message transmission, which can be separately set in the producer and consumer.
  • The QoS level in the producer affects the transmission quality of messages sent from the producer to Message Queue for MQTT.
  • The QoS level in the consumer affects the transmission quality of messages sent from the Message Queue for MQTT broker to the consumer.
MQTT provides the following QoS levels:
  • QoS0: Messages are delivered to intended Message Queue for MQTT clients at most once.
  • QoS1: Messages are received by intended Message Queue for MQTT clients at least once.
  • QoS2: Messages are delivered to intended Message Queue for MQTT clients exactly once.
cleanSession
In the MQTT protocol, the cleanSession parameter specifies whether a Message Queue for MQTT client in the consumer wants to receive offline messages after a TCP connection is established for it, which is not affected by the configuration in the producer. Set this parameter based on the following syntax:
  • cleanSession=true: When an offline Message Queue for MQTT client in the consumer goes online again, all its previous subscriptions and offline messages are cleaned up.
  • cleanSession=false: When an offline Message Queue for MQTT client in the consumer goes online again, it processes previous offline messages, and its previous subscriptions remain effective.

Take note of the following points when you use QoS 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 a Message Queue 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 Message Queue for MQTT client that receives the messages.

Table 1 lists the results of different combinations of QoS levels and the cleanSession parameter in the 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 not delivered. Only one delivery attempt is made for online messages.
QoS1 Offline messages are not delivered. Online messages are guaranteed to reach the intended Message Queue for MQTT clients. Offline messages are delivered. Both offline and online messages are guaranteed to reach the intended Message Queue for MQTT clients.
QoS2 Offline messages are not delivered. Online messages are delivered only once. Not supported

Solution-related terms

RTC
A real-time network communication method for 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, such as related services provided by Alibaba Cloud Real-Time Communication.
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. Such management nodes are usually 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 users in the RTC system. 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 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. It is used to manage the content that is displayed on the electronic screens and to manage and query manual tasks, such as price changes.
ApsaraDB RDS
A stable, reliable, and scalable online database service provided by Alibaba Cloud. It is used to persistently store task status changes such as price changes in a digital price tag system.
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.