In-situ MQTT Parser
The MQTT parsing and building software here uses in-situ parsing approach which do not allocate other buffer for string-based data to copy. Instead, it decodes string-based data by indicating the position of data at the raw-data received from network. For a figured explanation of in-situ parsing approach, refer to https://rapidjson.org/md_doc_dom.html. Because of binary nature of MQTT messages, as different from the method used for RapidJSON (and probably for RapidXML), we do not modify the base data (raw-data) with null-character, but use compact data structures to indicate pointer and the length of data. In this way method can also be used for non-printible octet-strings. We consider that, this approach minimizes memory allocation and copying overheads, improves cache coherence so the performance.
For building, after building completed, string data pointers are re-set to indicate data positions at the raw-data that has been built. So the external data passed during the building can be deallocated from the memory. After that, the mqtt_message instance reflects a compact structure which is independent of external data as similar to the message instances which are used for parsing (refer to test function named test_for_insitu_on_building() in testhead.c file.
The current implementation supports only MQTT 3.1.1 (MQTT v4) definition of messages. Some types of MQTT messages (i.e. SUBSCRIBE, SUBACK and UNSuBSCRIBE) consist of variable length data arrays. To handle this facility, we implemented two approaches, such that one supports dynamically allocated arrays, while the other uses statically allocated arrays. While the former may affect the performance, the latter may need optimization on array size. The method is determined by compiler flag USE_STATIC_ARRAY.
All implementation is based on mqtt_message structure, which is constructed by unions covering all possible message types. However some message types, currently (for MQTT v4) which are PINGREQ, PINGRESP and DISCONNECT do not have variable data, so applications still may use corresponding static octet-streams to send those message (such as c000, d000 and e000, respectively), instead of using builder for these kind of messages.