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: http://modelbasedtesting.co.uk/?p=4.
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.
Ian
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.
Thanks,
Frank
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Committer on Paho, Mosquitto
|
