Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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...

Back to the top