Hi Chris,
actually I was thinking of the default trace level, but maximum is
good :-)
I'm gathering the Paho 1.1 release together this week, so it might
take me until next week to get to look.
Thanks
Ian
On 02/02/2015 10:04 AM, Chris Summer
wrote:
Hi Ian,
sorry for the delay... I was out and travelling...
Find attached the Trace with LogLevel Maximum!
Chris
Date: Fri, 30 Jan 2015 17:23:00 -0500
From: fpagliughi@xxxxxxxxxxxxxx
To: paho-dev@xxxxxxxxxxx
Subject: Re: [paho-dev] Varying Delay for MQTT Messages
Hello Ian,
Sorry for the delay on this. Earlier this week a very large
pile of snow developed between where I was and where my laptop
was.
I made a slight modification to the MQTTAsync_publish sample
app so that when a transfer is completed another message is
sent immediately, but I was seeing about a second between each
message.
The 'running' variable is now an int counting down the number
of messages to send, five in this case. The normal output
would be:
$ build/output/samples/MQTTAsync_publish
Waiting for publication of 'Hello World!'
on topic 'MQTT Examples' for client with ClientID:
ExampleClientPub
Successful connection
Sent message with token value 1
Message with token value 1 delivery confirmed
Sent message with token value 2
Message with token value 2 delivery confirmed
Sent message with token value 3
Message with token value 3 delivery confirmed
Sent message with token value 4
Message with token value 4 delivery confirmed
Sent message with token value 5
Message with token value 5 delivery confirmed
Attached is the source and log. According to the log, it seems
that the delay I noticed turned out to be exactly 1sec in a
persistence "put" call despite MQTTCLIENT_PERSISTENCE_NONE
being specified? This is ~Line 411 in the log and repeats for
each message sent.
20150130 170213.898 (3380758272) (3)>
MQTTProtocol_startPublishCommon:124
20150130 170213.898 (3380758272) (4)>
MQTTPacket_send_publish:677
20150130 170213.898 (3380758272) (5)>
MQTTPacket_sends:226
20150130 170213.898 (3380758272) (6)>
MQTTPacket_encode:268
20150130 170213.898 (3380758272) (6)<
MQTTPacket_encode:278 (1)
20150130 170213.898 (3380758272) (6)>
MQTTPersistence_put:347
20150130 170213.898 (3380758272) (6)<
MQTTPersistence_put:381 (0) <------ Here -----
20150130 170214.898 (3380758272) (6)>
Socket_putdatas:443
20150130 170214.898 (3380758272) (7)>
Socket_writev:399
20150130 170214.898 (3380758272) (7)<
Socket_writev:420 (31)
20150130 170214.898 (3380758272) (6)<
Socket_putdatas:485 (0)
20150130 170214.898 (3380758272) (5)<
MQTTPacket_sends:253 (0)
20150130 170214.898 3 ExampleClientPub -> PUBLISH msgid:
1 qos: 1 retained: 0 (0) payload: Hello World!
This was run on a ThinkPad i7 laptop running Linux Mint13,
x86_64.
Thanks,
Frank
On 01/28/2015 08:29 AM, Ian
Craggs wrote:
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
_______________________________________________
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
|