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:
http://mbed.org/teams/mqtt/code/MQTT/ and sample:
http://mbed.org/teams/mqtt/code/HelloMQTT/).
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:
http://modelbasedtesting.co.uk/?p=94.
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!
Ian
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? :-)
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
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Committer on Paho, Mosquitto
|
