Re: [mosquitto-dev] eDRX and MQTT

[john rubis <john.rubis@xxxxxxxxxxx>]

Hi Greg,

I think what you describe is exactly what may be happening. I wouldn't mind the tuning approach as much if I knew the TCP timeouts were going to be consistent from machine to machine. I'll have to check the tcpdump you mention to confirm. 

John

-----Original Message-----
From: Greg Troxel <gdt@xxxxxxxxxx> 
Sent: Saturday, February 23, 2019 10:15 AM
To: john rubis <john.rubis@xxxxxxxxxxx>
Cc: mosquitto-dev@xxxxxxxxxxx
Subject: Re: [mosquitto-dev] eDRX and MQTT

john rubis <john.rubis@xxxxxxxxxxx> writes:

> My initial testing went well up to the point I set the eDRX time to
> 1310 seconds. At that point, if I sent a message to the device while 
> it wasn't reachable, I noticed Mosquitto would report a socket error 
> and disconnect around 1000 seconds. I thought maybe the OS was closing 
> the socket for inactivity, but that timeout is 2 hours. So some error 
> handling in Mosquitto must be timing out and giving up at 1000 
> seconds.  If I do not attempt to send a message to the device it stays 
> connected with no socket errors and at the KA interval, I see a KA 
> sequence between the broker and the device.

I suspect what's going on is that there is a TCP connection from your device to the broker which remains open during sleep.  When there is a message those bytes are sent in a TCP segment, and they are probably buffered in the cell network.  If the modem doesn't wake up and accept them and your remote computer doesn't send an ACK, then the original TCP sender will retry.  This will happen with exponential backoff until a limit is reached and then the TCP connection is broken.  All of this has nothing to do with MQTT.

If you can run tcpdump on the remote computer, I would try using 600s as the eDRX sleep time and then just into the sleep send something.  I would expect to see the segment with the data, and then see it multiple times with exponential backoff.  The TCP implementation in the remote computer should hand the first packet's data to the application and then discard the rest, sending some duplicate acks.  I don't mean to suggest that you tune it this way to operate -- the suggestion about session resumption sounds far better -- but it would be interesting to see if the model of TCP and modem sleep I described is actually right.


The other thing to do would be to develop a new transport protocol that deals with this sort of sleep as an expected case, instead of TCP.  But that would probably look like MQTT session resumption at the transport layer and be a lot of work...