One more thing…if you continue using 2 separate client instances, make sure that both have a unique client id. I fell into that problem at one time too.
Dwayne
From: paho-dev-bounces@xxxxxxxxxxx [mailto:paho-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ian Craggs
Sent: Saturday, August 16, 2014 5:38 PM
To: paho-dev@xxxxxxxxxxx
Subject: Re: [paho-dev] Simultaneous sub/pub-instances
*** This is an EXTERNAL email. Exercise caution. DO NOT open attachments or click links from unknown senders or unexpected email. ***
Hi Daniel,
as Nick says, a single client instance can act as both publisher and subscriber. Or you can create two separate client instances from the same thread. Either way will work fine. The first is more efficient as only one TCP connection will be used to the server.
This will work with both the sync and async APIs. The async API might have more throughput, but its main purpose is to have no blocking calls, for applications for which timing is critical. The sync API has some blocking calls, which can make your applications
simpler.
As for the thread safety of the API, the locking is intended to be at the MQTTAsync.c level. But only one instance of the send and receive threads are supposed to be started, regardless of how many client objects or threads there are in the process. What
I suspect might be happening is that more than one instance of these threads is being started. A trace would confirm that for me. However, you don't need multiple threads to achieve your aim.
Ian
On 15/08/14 23:13, Daniel Rasmussen wrote:
Thanks for the answer.
Yeah, now I see that the callback function pointers are added to a command handler rather that to the main handle, as I first believed.
I’ll try out that first thing Monday morning.
//Daniel
From:
paho-dev-bounces@xxxxxxxxxxx [mailto:paho-dev-bounces@xxxxxxxxxxx]
On Behalf Of Nicholas O'Leary
Sent: 15. august 2014 23:45
To: General development discussions for paho project
Subject: Re: [paho-dev] Simultaneous sub/pub-instances
Hi Daniel,
a single instance of the client can act as both publisher and subscriber; you do not need to separate them.
I haven't touched the c client for a while, so can't point you at anything more specific, but hopefully that will point you in the right direction.
Nick
On 15 Aug 2014 22:16, "Daniel Rasmussen" <Daniel.Rasmussen@xxxxxxxxx> wrote:
Hi Paho team,
Thank you for a great MQTT library! I’m using the
org.eclipse.paho.mqtt.c library.
In a project connecting existing devices to the Internet, I want a service (on the Internet) to be able to receive messages from devices, but the device must also be able to publish
messages to the service. This means that the device needs to run both a publisher and a subscriber instance.
I’ve tried with the async API, running the two instances in two separate threads (eCos). It first seem very well, connecting success and subscribing and I’m able both send and receive
message through a mosquito broker. But sadly I’ve found that the API isn’t thread safe. The socket.c module holds a list of sockets (think is called
s), but this list is static and not protected so the list may be updated from one instance/thread while one other is accessing it.- A race condition causing the a zero pointer to be accessed.
Am I abusing the library by threading two instances in simultaneously or am I just doing it wrong? I guess I could transfer to the sync API, but I thought that the async API will
perform better yield-wise.
Thanks in advance.
//Daniel
______________________________________________________________________________
Daniel Rasmussen,
Software developer, Prevas A/S
Hedeager 1, 8200 Aarhus N, Denmark
Mobile: +45 40 29 24 87
Switchboard: +45 33 15 90 90
daniel.rasmussen@xxxxxxxxx
www.prevas.dk
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
|
