Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Embedded MQTT C Client

Hi Sergio,

I always intended that the various levels of embedded API would be exposed and used, because in general, the easier they are to use, the more resources they take. Ideally these APIs will cater for any application. (

I did not intend originally that there would be an MQTTClient layer in C, only C++. But our experiences with a couple of platforms showed that C++ support in some cases is not ideal, where C is the de facto standard. So the MQTTClient-C package is intended as a "copy" of the embedded MQTTClient package, a higher level API for C environments. The C++ and C versions of these APIs could and should be identical, except for the replacement of C++ classes with C structures. This would simplify the maintenance of the two APIs. (I have toyed with the idea of generating the C code from the C++ code, with a script.)

It had occurred to me to use the MQTTPacket_read() function in MQTTClient(), but it didn't quite fit, which resulted in an almost duplicated function (readPacket() in C and MQTT::Client::readPacket() in C++). If they could be rationalized into one, that might be a good thing.

By the way, we're intending to produce similar higher level embedded clients for MQTT-SN - so similar considerations apply there too.

So, yes, MQTTPacket is intended to be used in its own right where the lowest resource use is needed. Making it as helpful as we can is great. I view MQTTPacket as a toolkit, from which you can take the pieces you need, whereas MQTTClient and MQTTClient-C are more holistic APIs.

If you shared your proposed APIs here maybe that would help the discussion?


On 09/23/2014 02:07 AM, Sergio R. Caprile wrote:
Hi guys,
just git pulled and bumped into a new MQTTClient-C directory in the tree
and after reading some messages in the list I think we are doing the
same from different sides.

Last month I removed the transport specific parts from the MQTT-SN
library and provided clean samples.
Last week, I Just started doing the same on MQTT, so I basically
developed a set of low-level routines accessed by MQTTPacket. After
having problems on low-speed links I realized the packet reader was not
following the usual behaviour with TCP, so I checked with Ian and
started modifying MQTTPacket.c.
Now that I see the client code and read some msgs, I guess you guys are
probably doing the same... we should coordinate on a "transport"
interface that both use, or the client delegate on the packet, or the
packet on the client, but just one of these... do you guys agree ?
I vote for the transport API for two reasons: 1) It's almost done(*) 2)
Presents a similar interface as the one in MQTT-SN library 3) Someone
might not need a full client and could get along with just the
MQTTPacket code 4) Both, Client and Packet, remain independent. Please
correct me if I'm wrong.

(*) So far I have a simple transport API, OS-agnostic, with non-blocking
functions, that, even though it needs extensive debugging, seems to be
working (with small test messages)


paho-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Committer on Paho, Mosquitto

Back to the top