Hi Chris,
I was hoping for a full trace. This seems to be just a protocol
level trace?
Ian
On 01/27/2015 03:07 PM, Chris Summer
wrote:
Hi Ian,
0) I am using the MQTTAsyncAPI with callbacks. I am processing
the incoming messages within the MessageArrived Callback
Function. I did an implementation using the MQTTClient, then
there is no such effect.
1) Is turned off
2) Find tracefile in the attachement
Thanks a lot!
Chris
Date: Mon, 26 Jan 2015 14:00:35 -0500
From: fpagliughi@xxxxxxxxxxxxxx
To: paho-dev@xxxxxxxxxxx
Subject: Re: [paho-dev] Varying Delay for MQTT Messages
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
_______________________________________________
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
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
|