Before you use Message Queue for MQTT, make sure that you have understood the concepts and terms related to this service and the Message Queuing Telemetry Transport (MQTT) protocol.
An entity that you create when you purchase Message Queue for MQTT. Each Message Queue for MQTT instance maps to a globally unique endpoint URL. Before you use Message Queue for MQTT, you must create an instance in the corresponding region and access the service by using the corresponding endpoint. For more information about how to create a Message Queue for MQTT instance, see MQTT quick start.
- Message ID
- A globally unique identifier for a message. Each message ID is automatically generated by the Message Queue for MQTT system. Message IDs are used to trace messages and troubleshoot problems. For more information, see Message tracing.
- MQTT broker
- A broker provided by Message Queue for MQTT for MQTT-based interactions. An MQTT broker is responsible for messaging between an MQTT client and Message Queue for Apache RocketMQ.
- MQTT client
- A mobile node that interacts with the MQTT broker. It is short for Message Queue for MQTT client.
- P2P message
- A special type of message that is provided by Message Queue for MQTT based on the standard MQTT protocol. This type of message can be directly sent to a specified MQTT client without subscription matching. For more information, see P2P Messaging model (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.
- A level-2 or level-3 topic is a subtopic of a parent topic in Message Queue for MQTT. You can directly set subtopics in code, without creating them. Note that the total length of a parent topic and its subtopics cannot exceed 64 characters in Message Queue for MQTT. Otherwise, a client exception may occur.
- Client ID
A client identifier that is globally unique in Message Queue for MQTT. If a request uses two clients with the same ID to connect to the Message Queue for MQTT service, the request will be 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 invisible characters. For more information, see Limits.
- Group ID
- An identifier that specifies the shared group name of nodes with identical logic and functions, representing a category of devices with the same functions. You must create a group ID in the Message Queue for MQTT console before you can use it. For more information about how to create a group ID, see MQTT quick start.
- Device ID
- A unique identifier for each device that you specify. Device IDs must be globally unique. For example, you can use the serial number of a sensor device as its device ID.
- Rules are the resources that implement data exchanges between Message Queue for MQTT V3.x.x and other Alibaba Cloud services. Rules are divided into the following categories.
- Data inbound rule: A data inbound rule serves to read data from the Alibaba Cloud service that you have configured and push the data to an MQTT client by using the MQTT protocol. This way, you can directly call the API of the Alibaba Cloud service to send data to the MQTT client. For more information, see Redirect inbound data from other cloud services.
- Data outbound rule: A data outbound rule serves to export the messages from an MQTT client to another Alibaba Cloud service that you have configured. This way, you can directly call the API of the Alibaba Cloud service to read the messages published by the MQTT client. For more information, see Redirect outbound data to other cloud services.
- Rule for client status notification: A rule for client status notification serves to export the status event data of an MQTT client to other Alibaba Cloud services. For more information, see Obtain the status of an MQTT client.
Message Queue for MQTT supports 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, WebSocket, and Flash. The endpoint URL is automatically allocated after an instance is created. Keep the URL safe for future reference. For more information about how to create an instance, see MQTT quick start.
- An industry-standard protocol for the Internet of Things (IoT) and mobile Internet, which is suitable for data transmission between mobile devices. Message Queue for MQTT supports this protocol by default.
Quality of Service (QoS) indicates the service quality of data transmission. MQTT provides the following QoS levels:
- QoS0, which indicates at-most-once delivery.
- QoS1, which indicates at-least-once delivery.
- QoS2, which indicates exactly-once delivery.
In MQTT, cleanSession specifies whether an MQTT client wants to receive offline messages after a TCP connection is established for it. Set this parameter based on the following syntax:
- cleanSession=true: When an offline MQTT client goes online again, all its previous subscriptions and offline messages are cleaned up.
- cleanSession=false: When an offline MQTT client goes online again, it processes previous offline messages, and its previous subscriptions remain effective.
Note the following points when you use QoS and cleanSession in combination:
- MQTT requires that the value of cleanSession for each client cannot be modified during each connection. Otherwise, some messages may be mistaken as offline messages.
- In MQTT, cleanSession cannot be set to false for messages with QoS level 2. If an MQTT client subscribes to such messages, the subscription does take effect even if cleanSession is set to false.
- The cleanSession flag of P2P messages is subject to the configuration of the MQTT client that receives the messages.
Table 1 lists the results of different combinations of QoS levels and the cleanSession flag.
|QoS0||Offline messages are not delivered. Online messages are delivered only once but are not guaranteed to reach the intended recipients.||Offline messages are delivered, and all messages are guaranteed to reach the intended recipients.|
|QoS1||Offline messages are not delivered, and online messages are guaranteed to reach the intended recipients.|
|QoS2||Offline messages are not delivered. Online messages are delivered exactly once and guaranteed to reach the intended recipients.||Not supported|
- Real-time communication (RTC)
- A real-time network communication method that targets audio and video communications. Popular scenarios include voice calls, video calls, and video conferencing.
- RTC server
- A server that hosts audio-and-video media channel services, for example, 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 the audio-and-video management service. You must develop your own audio-and-video management services to manage the lifecycles of all RTC sessions. Such management nodes are usually deployed in the cloud. We recommend that you use Alibaba Cloud services to build the nodes.
- Mobile audio-and-video application
- A terminal application that is used by a user in the RTC system. The user uses this application to initiate or join a voice or video call.
- Smart access point (AP)
- A common network device, such as a smart router, that supports application programming and can simultaneously perform Internet access and LAN device management.
- Digital price tag
- An electronic screen in a shopping mall, a supermarket, or another place. Digital price tags are networked by using a wireless sensor network protocol, such as Bluetooth or ZigBee, and smart AP nodes.
- Digital price tag management service
- A backend service in a digital price tag system. This service is used to manage the content displayed on electronic screens and to manage and query manual tasks, such as price changes.
- ApsaraDB for 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 (SLS)
- A log storage service provided by Alibaba Cloud. This service is used to persistently store all the operational logs in a digital price tag system for auditing and tracing purposes.