Date
1 - 4 of 4
RFC / Proposal - MQTT offloading support
|
Axel Moinet
Hi,
I am currently working on a project using an LTE-M modem which has MQTT offloading support, and was wondering if MQTT offloading in Zephyr may be useful for others (or if someone already thought about it). I already have implemented a module to provide custom MQTT functions using offloading for my modem, and am willing to contribute to the project, but before starting on integrating my code back in Zephyr I am seeking feedback on my idea. I was thinking on implementing a system slightly similar to what socket offloading already uses. It would (roughly) look like that : - A 'struct mqtt_op_vtable' would contain all the MQTT implementation function pointers for the device, with support for nullable values since everything may not be supported by some devices. It would also contain a pointer to the 'struct device *' of the modem, which allows finding back the right offloader at init. - A modem driver would register its vtable through a NET_MQTT_OFFLOAD_REGISTER macro, along with its custom init handler. - The function 'mqtt_client_init' would take an additional 'struct device *' argument to allow finding which vtable to use from available ones, and default to the native one if NULL. This allows setting chosen nodes in a devicetree overlay to easily refer to a specific device in app. This would also discard the need for a dispatcher as in socket offloading. - A pointer to the active vtable would be added to the 'struct mqtt_client' as part of the init process. - The current native implementation would be moved to a 'struct mqtt_op_vtable' set of functions, with current user-accessible API unchanged and now performing common operations and calling the corresponding active vtable function for a given client. - Adding a NET_MQTT_NATIVE Kconfig option to disable native implementation if not needed, to save code space. The main benefit of such offloading would be the possibility of using the MQTT API without any network stack nor native MQTT code compiled- in, thus reducing code size. As it would be my first contribution to Zephyr, other architectures, improvements and insights on how to do it are more than welcome, and if someone is willing to help me properly upstreaming code it would be great ! -- Axel MOINET Codium Electronique Mail : axel.moinet@... https://codium.fr |
|
|
|
McCrae, Jamie
Hi,
I think a question that needs to be asked is how useful is this for offloading that the zephyr API should be changed to add support for this? How many modems actually support this feature and how many users want to use it? It seems like a very narrow feature,
for offloading sockets and encryption it makes sense because of security and hardware acceleration which is gained with almost any protocol/socket, but MQTT specifically? The only benefit would be to not have a networking stack, and that adds the additional
risk of relying on the quality of that vendor's code (which would be entirely unknown) - what happens if a bug is found in the vendor's offloaded MQTT, who is then responsible for fixing it or will it even be fixed? At which point you'd just be back to where
you started, using zephyr's stack.
Thanks,
Jamie
On Mon, 2022-12-19 at 21:49 +0100, Axel Moinet via lists.zephyrproject.org wrote:
|
|
|
|
Marcin Niestrój
"Axel Moinet via lists.zephyrproject.org" <axel.moinet=codium.fr@...> writes:
Hi,If you already have something working, I think it makes sense to compare that to using Zephyr MQTT stack on top of TCP (or TLS if you use secure communication) modem sockets. I mean some performance, ROM size, RAM size metrics. I was thinking about something similar, but instead of MQTT it would be CoAP. After some thinking, I figured that there would be not much gain of having CoAP (or MQTT, doesn't matter in this context) implemented on the modem side. Both CoAP and MQTT are application protocols. This implies that you want deep control over those protocols from your application, which is implemented in C, on top of Zephyr. Most probably you still want to receive all the ACK messages from MQTT/CoAP and put some meaning of those to the application logic. So handling those messages cannot be dropped from application, which means that amount of flash usage savings is limited. On the other hand, there is lots of AT commands to be handled specific to the MQTT/CoAP protocol. TCP (or TLS) protocol handling with AT commands is pretty small, i.e. you just receive or send a stream of bytes. MQTT/CoAP protocols need much more AT commands, due to various MQTT/CoAP option handling. So I see potentially lots of AT commands complexity that would increase flash usage. But those are just my thoughts, I never started any implementation of that. Do you have some initial data of how much code size that would save? TBH I see potentially lots of code needed to handle AT commands specific to MQTT protocol.
-- Regards, Marcin Niestrój |
|
|
|
Hi Axel,
If you have a started building something start a pull request, if it interesting then you'll get community support. There are a lot of contributors that will help optimise code, test and improve functionality if there is a desire for the functionality. I'm guessing you are looking at the ESP32 or UBlox modules? Build it and see if they come... |
|
|