Record the implementation of a cross-platform MQTT client based on Socket and make it into an RTT software package[Copy link]
The kawaii-mqtt package is a cross-platform MQTT client based on the socket API
The MQTT client based on the socket API has a very simple API interface, implements the QOS2 quality of service with very few resources, and seamlessly connects to the mbedtls encryption library. This repository is a software package specifically made for RT-Thread, and the original repository is located at:
Kawaii is the homonym of "卡哇伊", and the original meaning of the word is also cute. A cute software package made by a very cute programmer( ` )~
What are the advantages of using this software package?
1
Developed based on the standard BSD socket , it can be used on any system that is compatible with the BSD socket.
2
Stability: Whether it is disconnection and reconnection, or packet loss and retransmission, it is strictly implemented in accordance with the MQTT protocol standard. In addition, the test of large data volume is very stable whether it is receiving or sending (135K data is sent at a time, once every 3 seconds), and the high-frequency test is also very stable (7 topics are sent and received at the same time, once per second, that is, 14 MQTT messages per second, with service quality QoS0, QoS1, and QoS2). Because the author designed the recording mechanism with very few resources, the messages using QoS1 quality of service must be guaranteed to arrive once. When the published topic (applicable to both qos1 and qos2) is not received by the server, it will be automatically resent. The messages with QoS2 quality of service are guaranteed to be processed once and only once (if you don’t believe in its stability, you can modify the source code yourself, do a test specifically for QoS2 quality of service, deliberately not reply to the PUBREC package, let the server resend the QoS2 message, and see if the client processes it only once). As for the stability of reconnecting after disconnection, this is a basic operation , there is nothing much to say. After automatic reconnection, it will automatically re-subscribe to the topic to ensure that the topic will not be lost. Therefore, the stability is excellent in the test.
3
Lightweight: The entire code project is extremely simple. Without using mbedtls, it takes up very few resources. The author used the esp8266 module to communicate with the cloud. The entire project code consumes less than 15k of RAM (including the system overhead and data processing overhead. This time, it is still not optimized, and the stability of disconnection and reconnection is still perfectly retained. However, the corresponding qos1 and qos2 service quality messages are not tested because the STM32F103C8T6 chip resources are too few to afford).
4
Seamless connection with mbedtls encrypted transmission makes network transmission more secure, and the interface layer does not require users to care about it at all. Regardless of whether it is encrypted or not, the API interface provided by kawaii-mqtt to users does not change. This is very compatible with a set of application layer codes that can be encrypted or not.
5
It has a very simple API interface. In general, kawaii-mqtt's configuration has default values, and it can be used basically without configuration. It can also be configured at will, and there are robustness tests on the configuration. The API interface designed in this way is also very simple.
6
There are very good code styles and ideas: the whole code adopts a layered design, and the code implementation adopts the idea of asynchronous processing to reduce coupling and improve performance. Where is it specifically reflected? It's very simple. At present, many MQTT clients on the market have to block and wait for ack when publishing topics. This is a very violent behavior. It blocks the current thread to wait for the server's response. What if I want to send data, or what if I want to repeatedly detect data? You may say that if I specify the blocking time to wait, then if the network is delayed and the ack is not coming, will I wait in vain? What about the service quality of qos1 and qos2? So this idea of asynchronous processing is still required. If I publish a topic, I will publish it without waiting. For MQTT messages with qos1 and qos2 service quality, if the server does not receive it, I can resend it. This resending is also asynchronous processing and will not block the current thread at all.
7
The MQTT protocol supports topic wildcards "#" and "+".
8
The subscribed topic is completely separated from the message processing , making the programming logic simpler and easier to use, and users do not need to worry about complicated logical relationships.
9
The keep-alive processing mechanism has been implemented internally in kawaii-mqtt , so users do not need to pay too much attention to it. Users only need to concentrate on processing application functions.
10
Seamless connection salof: It is a synchronous and asynchronous log output framework. It outputs corresponding log information in idle time and can also write the information into flash for easy debugging.
提升卡
变色卡
千斤顶
京公网安备 11010802033920号
