5 sec delay in the loop() function

[ppatierno]

Hello,
I'm using this great library on Intel Galileo board with some little changes as reported in another issue.
I see that there is a 5 sec delay inside client.loop() function when the client doesn't receive any data. Why ?
In this way if I use client.loop() as first statement in the loop() sketch function, the subsequent instruction are always executed with a 5 sec delay.

Paolo.

[knolleary]

There isn't any 5 second delay in the library - can you point to where you think there is one?

[ppatierno]

I know that there isn't an explicit delay function called....
It seems that the problem is the readPacket() function here

for (uint16_t i = 0;i<length;i++)
{
if (len < MQTT_MAX_PACKET_SIZE) {
buffer[len++] = readByte();
} else {
readByte();
len = 0; // This will cause the packet to be ignored.
}
}

If I comment readByte() there isn't the delay....
The problem there is when the client doesn't receive any packet and it is checked if there is something to read.

Paolo.

[knolleary]

The client checks to see if there is data available before reading the packet. But once it starts reading the packet it will block until a whole packet has been read.

The readByte() line you reference is only called when the incoming packet is larger than MQTT_MAX_PACKET_SIZE - the client will read the whole packet off the network but discarding it so you won't get a callback for it. Do you know how large the message arriving is?

[ppatierno]

If I write a simple sketch with only client.loop() inside main loop() and print millis() function output I see

1161118
1166130
1171137
1176144
1181154
1186161

As you can see there is a about 5 sec between the calls....

The example is simple

void loop()
{
client.loop();
Serial.println(millis());
}

The client is connected but it doesn't publish anything and it isn't subscribed to anything.
Sometimes the client.loop() is much faster and it happens where there is the pingreq/pingresp exchange with the broker.

Paolo.

[knolleary]

That suggests there is data available for the client to try reading - which shouldn't be the case if the client isn't subscribed to anything. As I linked to in my previous comment, the client will only try reading a whole packet from the network if _client->available() returns true. Otherwise loop returns straight away.

What hardware are you running this on?

[ppatierno]

I'm running on a new Intel Galileo board :-)
It seems that on this board _client->available() doesn't return immediately if there aren't bytes to receive ?

[knolleary]

Possibly - obviously I cannot comment on how the galileo performs.

I don't consider this an issue with this library - so with your agreement, I'd like to close this item?

[ppatierno]

Oh yes...I try to discover where is the problem.
Did you see the other my issue with IPAddress class ?

[knolleary]

Yes - not had time to look.