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? :-)
Frank
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: 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
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
|
