Pubsubclient: Definitive explanation of MQTT_KEEPALIVE and MQTT_SOCKET_TIMEOUT ?

[dagnall53]

@knolleary Nick, Would it be possible for you to give a short but Definitive explanation of the keep_alive and socket_timeout functions and what they (exactly) do please.
From: https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_mqtt_the_protocol_for_internet_of_things?lang=en I see that the KeepAlive time seems to set a delay in the broker before a LWT message from a disconnected (or quiet?) client is sent?
From http://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over I think the Socket_timeout is the longest time expected between communications, so the broker will assume the connection is lost (?) if the client does not send any pingreq (or any other communications) before that timer times out.

From this I deduce that socket_timeout should probably be very long for any node that has only infrequent communications. (to prevent the broker thinking the node has disconnected).
Also that KeepAlive should be short if I want a LWT message delivered promptly on disconnect, but that otherwise the KeepAlive setting does not affect communications reliability much.

Hopefully I have understood the functions correctly but confirmation would help me sort out some disconnect behaviour I am seeing, and will probably assist others as well.

Many thanks in advance.
Dagnall

FYI,
The broker I am using is Mosquitto running under Rasberian (Debian+Pixel) on a Rasberry pi zero w.
The main publisher program node (also running on the pi zero W) sends out a timestamp to all subscribed nodes once every minute at the very least.
The nodes are NodeMcu V2, running my ESPWiFiRocknet code. https://github.com/dagnall53/ESPWIFIROCNET The nodes only send messages if they see a sensor change, so communication from these nodes to the broker can be very infrequent. The code does run a check for connection every cycle (say 10ms or so ):
` if (!client.connected()) {
connects = connects + 1;
reconnect();
}
client.loop();

`

[knolleary]

Hi,
MQTT_SOCKET_TIMEOUT is how long the client will wait for data to arrive. For example, after sending the initial CONNECT, it is how long it will wait for the CONACK to arrive before deciding the connection is dead. Or when trying to read a complete packet from the network, how long it will wait between individual bytes. It isn't related to anything regarding the MQTT protocol itself - its just basic TCP timeout handling solely on the client.

MQTT_KEEPALIVE is an MQTT protocol defined timeout. It is how long either end of the connection should wait without having received any data from the other side before deciding the connection is dead. So to be clear - this is when the underlying TCP connection is still open, but no data is flowing. When the keepalive timer expires (typically, a 2x grace period is used), the connection is considered dead and should be closed. As an 'abnormal' disconnection, it will trigger any Will message provided by the client on the original connect. The client includes its keepalive timer value as part of the connect packet - so the broker knows what keepalive interval to expect the client to honour.
Just to reiterate, this along applies whilst the TCP connection is open - if the TCP connection drops, they the Will will send straight away (assuming the client didn't first send a proper MQTT Disconnect packet).

[Sunrise17]

Dear @knolleary, what is the ideal MQTT_SOCKET_TIMEOUT and MQTT_KEEPALIVE (as seconds) for IoT Device which is connected to AWS IoT? Have you ever experienced to find out some convenient values?
Thanks again for your detailed explanation above.

[knolleary]

@Sunrise17 sorry, no I don't have any suggested values for AWS IoT

[Sunrise17]

Hope 60secs. does not cause any issue. Thanks again for your quick response,