I'm glad it works for you :-)
Ian
On 04/28/2015 08:22 AM, Chris Summer
wrote:
Hi Ian,
with this fix the timing looks much better!
Thanks alot for all the support!
Chris
Date: Fri, 24 Apr 2015 09:10:32 +0100
From: icraggs@xxxxxxxxxxxxxxxxxxxxxxx
To: paho-dev@xxxxxxxxxxx
Subject: Re: [paho-dev] Varying Delay for MQTT Messages
Hi Chris,
I've added a fix for the problem as exhibited by Frank's code,
in the develop branch, under bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=465369.
Ian
On 04/22/2015 08:56 PM, Chris
Summer wrote:
Hi Ian,
compiling the library without tracing did not change
the situation. I tried the code on different machines
and saw the same behavior. I'd be happy if anybody had
any ideas!
Cheers,
Chris
Date: Thu, 5 Mar 2015
22:39:38 +0000
From: icraggs@xxxxxxxxxxxxxxxxxxxxxxx
To: paho-dev@xxxxxxxxxxx
Subject: Re: [paho-dev] Varying Delay for MQTT
Messages
Hi Chris,
thanks for checking, that seems to have got lost in
my in tray. It's always worth raising a bug to make
sure it doesn't get lost, although that doesn't
guarantee turnaround :-)
Looking at your original trace, I see the following:
20150130 170213.898 (3380758272) (6)>
MQTTPersistence_put:347
20150130 170213.898 (3380758272) (6)<
MQTTPersistence_put:381 (0)
20150130 170214.898 (3380758272) (6)>
Socket_putdatas:443
20150130 170214.898 (3380758272) (7)>
Socket_writev:399
the one second gap is actually after the return from
MQTTPersistence_put and before the call to
Socket_putdatas. But there isn't any code between
the two, to speak of:
#if !defined(NO_PERSISTENCE)
if (header.bits.type == PUBLISH &&
header.bits.qos != 0)
{ /* persist PUBLISH QoS1 and Qo2 */
char *ptraux = buffers[2];
int msgId = readInt(&ptraux);
rc = MQTTPersistence_put(net->socket,
buf, buf0len, count, buffers, buflens,
header.bits.type, msgId, 0);
}
#endif
#if defined(OPENSSL)
if (net->ssl)
rc = SSLSocket_putdatas(net->ssl,
net->socket, buf, buf0len, count, buffers,
buflens, frees);
else
#endif
rc = Socket_putdatas(net->socket, buf,
buf0len, count, buffers, buflens, frees);
My first guess at this point is that the process has
been swapped out for that one second. My second
guess is that the tracing itself may be
interfering. That could be checked by building the
library without tracing to see if that makes a
difference (compile with NOSTACKTRACE and
NO_HEAP_TRACKING). If anyone has any other
suggestions I'd be glad to hear them.
Ian
On 05/03/15 13:26, Chris Summer wrote:
Hi,
are there any news on this topic?
Has it just been solved with the new versions?
Cheers,
Chris
Date: Mon, 2 Feb 2015
12:14:00 -0500
From: fpagliughi@xxxxxxxxxxxxxx
To: paho-dev@xxxxxxxxxxx
Subject: Re: [paho-dev] Varying Delay for MQTT
Messages
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
_______________________________________________
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
_______________________________________________
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
|