Date 1 - 4 of 4
RFC / Proposal - MQTT offloading support
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
- 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
Mail : axel.moinet@...
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.
On Mon, 2022-12-19 at 21:49 +0100, Axel Moinet via lists.zephyrproject.org wrote:
"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
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.
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...
|1 - 4 of 4|