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
|
