Skip to main content

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

Hi Frank,

when I started the existing C library the extent of portability I was thinking of, was to use ANSI standard C, not C++, and Posix/Windows libraries.  It seemed to me at the time that embedded systems were focussing in on Linux and/or Windows, and that supporting other system libraries and OSes was not necessary.

That view doesn't look right now - hence the embedded client libraries.  I am very happy with the direction the embedded client libraries are taking (I don't know if you've seen the latest: and sample:

I am hoping that the "embedded" libraries will be just as functional as the existing libraries while being more lightweight and much more portable.  I've also written about them here:

In that vein, I was actually hoping that I would only be fixing bugs on the current C client libraries, that they would be stabilizing and that I would be able to move onto something else!


On 05/01/2014 01:38 PM, Frank Pagliughi wrote:
Hey Ian,

I was giving some thought to the C library. It's impressive in its versatility, and I'm guessing that when you started it was meant to be portable to most different types of systems. But as an effort branches off to make a new library for resource constrained systems, perhaps this leaves existing library for use solely in Posix, Windows, and high-end RTOS systems.

In that case, it eliminates the need for a single-threaded model. If you always have threads available, why wouldn't you always use them? Especially since many of these systems are evolving to multi-core designs, and spreading threads across the cores is the optimal solution.

So the library can evolve to a middle ground between the asynchronous and synchronous libraries, that looks an awful lot like the "asynchronous mode" of the current synchronous library. At least from the outside.

It can be a single library with the option to compile with or without encryption/SSL features. Internally, it can always use an I/O thread, and thus it can be implemented asynchronously. The functions that generate network traffic don't need to bring the operation all the way down to the wire, but they can create packets and tokens in the caller's thread and then queue the packets for the I/O threads to send.

The synchronous calls are still desirable, so we would want separate sync and async functions, but they can all be in the same library, and the synchronous calls can be defined easily in terms of the async calls:
int MQTTClient_publish(MQTTClient handle, char* topicName, int payloadlen, void* payload, 
                       int qos, int retained)
    MQTTClient_deliveryToken dt;
    MQTTClient_asyncPublish(handle, topicName, payloadlen, payload, qos, retained, &dt);
    return MQTTClient_waitForCompletion(handle, dt, (unsigned long) -1);

Does that make sense?

Or is it too early to be discussing Rev 2? :-)


On 04/30/2014 12:24 PM, Ian Craggs wrote:
Hi Frank,

the asynchronous mode of the synchronous client (we should find some more terms :-) does not behave the same way as the asynchronous client apart from the connect/disconnect callbacks.  The publish calls still block until the publish packet has been written to the wire, and you can't make other API calls in the callbacks (apart from connect in connectionLost).  It is still a bit more synchronous than the asynchronous API.  I've tried to explain more here:

The async C API is different to the Java API in that it allows more messages to be queued, and blocks less.  This is a reason for the differences.  It may be possible to do what you need, but I'll have to think about it.   Raising a bug would be useful.


On 04/23/2014 07:22 PM, Frank Pagliughi wrote:
Hello Ian, and all,

I'm trying to wrap up the next rev of the C++ library, and have one nagging issue that I believe I inquired about last time. In the C library, the MQTTAsync_send() and MQTTAsync_sendMessage() functions claim:
An MQTTAsync_token is issued when this function returns successfully.
I can't find how to get this MQTTAsyncToken value until the callback which happens after the message is delivered.

The problem is that, like the Java client, the C++ client has a publish() function which returns a token, and that token is supposed to know the message ID of the outgoing packet. It is reported via:
int     itoken::get_message_id();
So, to implement this I need the Message ID (MQTTAsyncToken) as soon as the message is queued - before returning from the publish() function.

It seems that the latest version of the ...err... asynchronous mode of the synchronous library has everything I would need to publish messages, since the publish functions take a pointer to an MQTTClient_deliveryToken
int MQTTClient_publish(MQTTClient handle, char *topicName, int payloadlen,
                       void *payload, int qos, int retained,

                       MQTTClient_deliveryToken *dt)
That would be perfect!  I would switch over to the synchronous library, but there are not corresponding asynchronous  versions of connect() and disconnect().

If those existed, I (we?) wouldn't need the asynchronous library at all.


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

paho-dev mailing list

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

Back to the top