What Is MQTT?
Message Queuing Telemetry Transport (MQTT) is a lightweight publish/subscribe protocol designed to minimize requirements for network bandwidth and device resource. MQTT is commonly used in scenarios such as automotive, logistics, smart home, consumer electronics, and transportation. For more scenarios, see Use Cases. The OASIS organization provides three standard protocol specifications: v3.1, v3.1.1, and v5. Differences Between TDMQ for MQTT and Standards
TDMQ for MQTT is developed based on MQTT v3.1.1 and MQTT v5, but some features are not yet supported:
1. TDMQ for MQTT supports QoS Publish and Subscribe, but cannot guarantee Exactly Once semantics in extreme scenarios.
2. TDMQ for MQTT does not support AUTH control messages temporarily.
What Is the Server Retransmission Mechanism If the Client Fails to Acknowledge Message Consumption in Time When QoS 1 Is Used for Subscription?
When clients use MQTT v3.1 and MQTT v3.1.1 to access TDMQ for MQTT, the default transmission window size is 16, meaning a maximum of 16 messages can be in-flight. After a message enters the window, a timer starts. If the corresponding PUBACK, PUBREC, or other acknowledgment packets are not received within 120 seconds, the server will retransmit the message with the DUP flag set in the retransmitted packet.
When MQTT v5 is used for access, the window size is controlled by Receive Maximum, and the retransmission interval is also 120 seconds.
Which TLS Versions Are supported?
TDMQ supports SSLv1, TLSv1.1, TLSv1.2, and TLSv1.3. National Cryptography supports TLCPv1.0. SSLv3 can be consulted via submitting a ticket for specific details. Is One-Vehicle-One-Certificate Typically Used in IoV Scenarios Supported?
TDMQ for MQTT supports the "one-device-one-certificate" usage scenario and can reuse user PKI facilities. It also supports activating, deactivating, and revoking device certificates through TencentCloud API to achieve the objective of the OCSP protocol specification.
Low-Computing-Power Scenarios Cannot Use "One-Device-One-Certificate". Does It Support Independent Authentication and Authorization for Each Device?
TDMQ for MQTT supports the "one-device-one-secret" scenario. Users can register each low-computing-power device in the cloud through Shared Access Token, using pre-shared keys to issue tokens for authentication. Users can also integrate existing JWT, HTTP Service, or other methods to achieve authentication and authorization per device. How Is TDMQ for MQTT Billed?
Go to the Purchase page from the console, then select the corresponding specification based on your actual business volume level. MQTT supports postpaid by hour and prepaid yearly/monthly subscription billing modes. Whether TDMQ for MQTT Supports Public Network Access?
Support. When purchasing a TDMQ for MQTT cluster, you can enable public network access. After purchasing the cluster, you can enable or disable public network connection at any time.
Usage Limitations of TDMQ for MQTT
TDMQ for MQTT is sold in different specifications, with each cluster specification supporting different TPS levels and client connection limits. For detailed quota limitations, see Product Constraints and Usage Quotas. Supported Authentication and Authorization Modes for Sending/Receiving Messages Using TDMQ for MQTT?
Authentication and authorization using the username and password: TDMQ for MQTT validates the username and password of the role used by the connected client. Different roles have different permissions (such as sending or consuming messages), which you can freely and flexibly define.
X.509 certificate authentication: Enable server-side authentication using the default certificate. You can also use your own certificate for mutual authentication between the client and server.
Custom JWT authentication and authorization: Supports the use of customers' own JWT services for authentication and authorization.
External HTTP authentication and authorization: Supports client authentication and authorization by integrating with external third parties or HTTP services within the user's vpc.
In the future, TDMQ for MQTT will also introduce more diverse authentication and authorization methods based on customer needs. For detailed information about authentication, see Configuring Authentication. How to Calculate the TPS Specification of TDMQ for MQTT?
When the MQTT protocol is used to send and receive messages, the sending or receiving action for each message is counted as one basic billing unit. The TPS specification is comprehensively calculated based on the sum of three dimensions: message service QoS, message storage resource usage, and message body size.
Message service QoS
Message service QoS=0 is calculated as 1 TPS.
Message service QoS=1 is calculated as 2 TPS.
Message service QoS=2 is calculated as 5 TPS.
Storage resource usage
When messages use the Will feature and Retain feature, they consume additional broker storage resources. Therefore, an additional 10 TPS will be calculated respectively for each feature when users configure the Will and Retain features.
Message body size
Each message is calculated in units of 4 KB. Messages below 4 KB incur no additional TPS calculation, while each additional 4 KB increment beyond that adds 1 TPS.
For example, suppose a cluster has three clients connected simultaneously. At this moment, the cluster sends one QoS=1 message with a 64 KB message body to the first client. The corresponding cluster production TPS specification is calculated as 2 + ⌈64/4 - 1⌉ = 17 TPS. The cluster receives one QoS=2 message with the Retain feature enabled and a 32 KB message body from the second client. The corresponding cluster message TPS specification is calculated as 5 + 10 + ⌈32/4 - 1⌉ = 22 TPS. The third client connects to the cluster with the Will feature enabled, adding an extra 10 TPS. Therefore, the comprehensive cluster TPS specification is calculated as 17 + 22 + 10 = 49 TPS.