05. Tencent cloud IOT device side learning -- mqtt protocol client implementation

The main purpose of this series is to record the learning notes of Tencent cloud Internet of things device , And on the device side SDK Make a supplementary explanation .

Source Overview

For the relevant source code files, see https://github.com/tencentyun/qcloud-iot-explorer-sdk-embedded-c/tree/master/sdk_src/protocol/mqtt

mqtt Overview of client source code

mqtt The protocol client mainly implements the construction and sending of each control packet and the processing of the server reply , All downlink data （ except connack）, adopt qcloud_iot_mqtt_yield Receive and process , subscribe 、 Unsubscribing and publishing are implemented by the user through providing an external interface .

The normal process is （ Under multithreading Yiled Usually a separate thread is used for , Please see the _mqtt_yield_thread）：

SDK API Call general process

Implementation details

• CONNECT：CONNECT The control package is built in _serialize_connect_packet in , It is mainly set according to the authentication method usrname and password, as well as clean session.
• CONNACK：CONNECT After the control packet is sent, it will pass wait_for_read wait for CONNACK, And then call _deserialize_connack_packet Judge the result
• SUBSCRIBE：SUBSCRIBE The control package is built on _serialize_subscribe_packet. For subscriptions , Would call push_sub_info_to Join the subscription queue list_sub_wait_ack in , And then in qcloud_iot_mqtt_yield Call in qcloud_iot_mqtt_sub_info_proc Determine the timeout of the subscription in the queue or receive SUBACK After treatment . One of the key things is SubTopicHandle Of on_message_handler（ Handle the downlink message of the subscription topic ） and on_sub_event_handler（ Handle events such as timeout ）.
• SUBACK：SUBACK Will pass qcloud_iot_mqtt_yield Receive and process , Mainly judge whether the reply is normal according to the agreement
• UNSUBSCRIBE and UNSUBACK： and SUBSCRIBE Similar treatment , Also add to list_sub_wait_ack in , However, it is rarely used in actual scenarios , Generally, the device subscription relationship is determined at the time of design , There are few scenarios in which you need to cancel your subscription .
• PUBLISH（ client -> The server ）&PUBACK：PUBLISH The control package is built on _serialize_publish_packet, Usually we only specify QoS Grade and payload. about QoS1 The news of , Would call _mask_push_pubInfo_to Add to list_pub_wait_ack in , And then in qcloud_iot_mqtt_yield Call in qcloud_iot_mqtt_pub_info_proc The timeout judgment published in the queue or the receipt PUBACK To deal with . One of the key things is Qcloud_IoT_Client Medium event_handle Will tell you that the release timed out , So as to realize... In the application layer QoS1 Retransmission of . Practical application , Even using QoS1 There is no guarantee that the message will arrive , Because in most cases, you can't receive PUBACK All because the equipment is disconnected from the network , At this time, the application layer design strategy is needed to realize , For example, store messages locally .
• PUBLISH（ The server -> client ）&PUBACK： Sent by the server PUBLISH The news will be here qcloud_iot_mqtt_yield Call in _handle_publish_packet Handle , according to QoS reply PUBACK, Then call back the message to SubTopicHandle Of on_message_handler Message processing .
• PINGREQ&PING： Keep alive news in qcloud_iot_mqtt_yield call _mqtt_keep_alive Send , And then through _handle_pingresp_packet Process the reply .
• DISCONNECT： This message is usually not required , You can refer to qcloud_iot_mqtt_disconnect

Some of the parameters

On the client side MQTT There will be some parameters related to the actual application in the implementation , It needs to be adjusted to meet the needs of the business , As listed below ：

• QCLOUD_IOT_MQTT_MAX_REMAIN_WAIT_MS ： Maximum waiting time for header reception , Under the weak network, it is necessary to set a large
• QCLOUD_IOT_MQTT_COMMAND_TIMEOUT：MQTT Timeout for blocking calls , Including connection, etc , Large can be set under the weak network
• QCLOUD_IOT_MQTT_KEEP_ALIVE_INTERNAL： Keep alive by default , Generally speaking, through API Input parameters can be modified , This is just a demonstration
• QCLOUD_IOT_MQTT_TX_BUF_LEN and QCLOUD_IOT_MQTT_RX_BUF_LEN： Receive and send buffer sizes , Set according to business requirements , No more than 16K
• MAX_RECONNECT_WAIT_INTERVAL： Maximum wait time for reconnection , If a quick reconnection is required, the value should be reduced
• MQTT_RMDUP_MSG_ENABLED and MQTT_MAX_REPEAT_BUF_LEN： These two parameters are mainly used for message filtering , Because the platform is based on QOS1 Retransmission will be realized , However, due to the delay of messages in the link , So we need to filter the messages we have received , Avoid repeated reception processing . It is generally recommended to open ,BUF The length is set according to the actual application , The oldest messages are overwritten ID The strategy of