Hi Ian,
I saw a strange delay of about 1-sec in the latest Asynhronous C
library. I had modified the publisher example app to send several
messages; sending the next as soon as one is acknowledged (QoS=1). I
ran it all on the same machine over localhost, talking to mosquitto.
The timing seemed odd, but I haven't had time to investigate further
yet.
I will see I can recreate the test app and send it to you ASAP.
Frank
On 01/26/2015 08:12 AM, Ian Craggs
wrote:
Hi Chris,
are you using the MQTTClient or MQTTAsync API? If MQTTClient, are
you setting callbacks? I think it's most likely that the timing
differences are an artifact of the threading model. With
MQTTClient, if you use the receive call rather than the
messageArrived callback, no background threads are started.
1) make sure you have turned off message persistence when creating
the client object (MQTTCLIENT_PERSISTENCE_NONE).
This shouldn't be used for QoS 0, but might have an effect.
2) You can take a trace by setting the environment variable
MQTT_C_CLIENT_TRACE=(ON or filename), and then I can check to see
what is happening.
3) Other client options for C/C++ are the Paho embedded clients
and libmosquitto in the Mosquitto project, which follows the same
API model as the Python API because they are both written by Roger
Light. I'd like to see if we can understand and solve your
problem first though -- so please take a trace.
Thanks
Ian
On 01/26/2015 10:23 AM, Chris Summer
wrote:
Hi all,
I am experiencing some behavior I cannot explain.
Here is what I do.
I am using the paho-c library and as a reference the paho
python library. My Broker is mosquitto.
The goal of my experiments is to measure the application layer
roundtrip time. Therefore I have the following setup
Application <----> Broker <---> Reflector
What I do is:
* I take the time in the application, put it into a packet
and send it to the broker. (QoS 0)
* The reflector is subscribed to theses messages, receives
them, packs them into a new packet and sends the back to the
broker using a different topic.
* Finally I receive the message back at the application, take
the current time and calculate the time difference between the
current time and the time contained in the packet.
I have this implementation, both in C and in Python. All
processes are running on the same machine.
No here are the observations that keep me busy.
If I watch the application delay for the c implementation I
get something like
5, 1005, 106, 5, 1005, 104, 6 ...
For the python implementation it is like:
5, 5, 5, 6, 4, ....
You see the difference, unfortunately I need an implementation
in C thanks to the target platform. I checked my code several
times, there is nothing I could pinpoint to cause the delay.
To me, it resembles effects that I have seen in other projects
when using TCP. Could it be, that somewhere in the library
code there is some issue with the socket handling?
Any other ideas? Did I miss a configuration flag or something?
Cheers,
Chris
_______________________________________________
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
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
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
|