Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


Back to the top