Topic: Feature request - multiple clients without shared library resources

For a system, which has more than ONE client, it is desirable that the MQTT library resources are independent for each client.

There are many advantages to this approach, and for the most part, the library achieves this goal through its use of session contexts (eg the MQTTCtx context in examples).
However the current MQTT library (v1.9.0) has several static data resources which are shared across all clients.

1.  the "static MqttProp clientPropStack[MQTT_MAX_PROPS]" and its associated semaphore lock.
When running just TWO clients, this resource was depleted and the MQTT_MAX_PROPS value had to be increased as a work-around, by multiplying the default value by number of clients.
Although this is an acceptable solution, it is dependent on a single non-specified initialisation of the array (not done by library)
and is reliant on "MqttProps_Free" to be executed on ungraceful disconnects to clean up the array.
So the library has to be compiled for the highest expected number of clients in any system or compiled on a per-system basis where the number of clients is uniquely specified.

As a possible feature request, the library could be changed to have the "clientPropStack" (and semaphore) included within the session context, where it can be initialised and used independently on a per-client basis.
Each client would then be in control of its own private prop stack, just like all the other variables in the current session context structure.

2.  the "static byte will_done" within the SN_Client_Connect routine.
I am not using SN operation, but point this variable out as a potential issue if ever multiple clients are used.

I hope this note will help users to avoid the prop stack issue when running multiple clients,
and this feature request will help generalise the library.



Re: Feature request - multiple clients without shared library resources

Hello Kelvin

That is an excellent suggestion! I've copied your post to a new GitHub issue in our repository:

Eric @ wolfSSL Support