Yeah, the bear on my doorstep rarely makes me late for work. She
seems friendly enough. Though it always amazes me how she can get
the lid off the garbage and take the bag out without even knocking
the can over.
On 02/02/2015 12:02 PM, Ian Craggs
wrote:
No problem. Good excuse. Almost as good as the Canadian post
that wasn't delivered because of "bear on doorstep". :-)
I had plenty to keep me occupied in any case. I'll look at the
persistence call, seems odd.
Ian
On 01/30/2015 10:23 PM, Frank
Pagliughi wrote:
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
--
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
|