AWS polling timeout should be different from reading timeout

Libraries
#1

When using a 2g/3g/4g module, with TLS manage by the application using for example mbetls, the reading of the data is often done by polling. Based ton the media that can be slow, the RX timeout has to be quite large enough to consider bad network condition. That said, when the core-mqtt want to check if data is received, it launch a read operation on the socket. This read on the physical module is oftenly just a simple check about received bytes. However, as the timeout is quite big, this operation takes a lot amount of time which is useless. For this specific operation of polling for received data, the timeout should be shorten I think. Otherwise, any pending publish should wait for the socket to be released.
I hope the explanation is complete enough to be understandable.

[159.276] >> TLS_FreeRTOS_recv bytesToRecv:1 ← this is the latest polling request from core-mqtt
[159.277] >> Modem_Recv 5 bytes <<
[159.305] Modem TX → AT#SI=1
[159.329] RX ← “#SI: 1,1788,5694,0,0”
[159.339] RX ← “OK”
[159.457] >> Modem_Recv 5 bytes <<
[159.482] Modem TX → AT#SI=1
[159.494] RX ← “#SI: 1,1788,5694,0,0”
[159.507] RX ← “OK”
[159.631] >> Modem_Recv 5 bytes <<
[159.652] Modem TX → AT#SI=1
[159.670] RX ← “#SI: 1,1788,5694,0,0”
[159.680] RX ← “OK”
[159.799] >> Modem_Recv 5 bytes <<
[159.824] Modem TX → AT#SI=1
[159.836] RX ← “#SI: 1,1788,5694,0,0”
[159.846] RX ← “OK”
[159.904] Sending publish request to agent with message on topic “…” ← this is the MQTT_Publish
[159.923] Task waiting for publish 3 to complete.
[159.968] >> Modem_Recv 5 bytes <<
[159.986] Modem TX → AT#SI=1
[159.997] RX ← “#SI: 1,1788,5694,0,0”
[160.007] RX ← “OK”
[160.119] >> Modem_Recv 5 bytes <<
[160.137] Modem TX → AT#SI=1
[160.148] RX ← “#SI: 1,1788,5694,0,0”
[160.160] RX ← “OK”
[160.270] >> Modem_Recv 5 bytes <<
[160.281] Modem TX → AT#SI=1
[160.296] RX ← “#SI: 1,1788,5694,0,0”
[160.306] RX ← “OK”
[160.423] >> Modem_Recv 5 bytes <<
[160.440] Modem TX → AT#SI=1
[160.452] RX ← “#SI: 1,1788,5694,0,0”
[160.464] RX ← “OK”
[160.575] >> Modem_Recv 5 bytes <<
[160.594] Modem TX → AT#SI=1
[160.606] RX ← “#SI: 1,1788,5694,0,0”
[160.619] RX ← “OK”
[160.735] >> Modem_Recv 5 bytes <<
[160.748] Modem TX → AT#SI=1
[160.760] RX ← “#SI: 1,1788,5694,0,0”
[160.770] RX ← “OK”
[160.905] >> Modem_Recv 5 bytes <<
[160.923] Modem TX → AT#SI=1
[160.940] RX ← “#SI: 1,1788,5694,0,0”
[160.956] RX ← “OK”
[161.066] >> TLS_FreeRTOS_send bytesToSend:32 ← this is the request to send data packet
[161.077] Modem_Send: request
[161.347] Successfully sent 61 bytes over network.
[161.348] Sockets_Send out
[161.349] >> TLS_FreeRTOS_send bytesToSend:9
[161.350] Sockets_Send in
[161.350] Modem_Send: request
[161.361] Modem TX → AT#SSENDEXT=1,38
[161.375] RX ← “>”
[161.376] Modem TX →
[161.392] RX ← “OK”

#2

Hi @sbacou,

If I understand correctly, you want the polling timeout to be short when checking if there’s any data available on the socket, and long while receiving data, to account for poor network conditions?

Can you try setting a short timeout for the socket and a longer timeout for the MQTT_RECV_POLLING_TIMEOUT_MS configuration macro and see if that helps?

#3

You understand correctly I think, but even if I will try it, I am pretty sure this will not work. During the connection phase, and SSL negociation, only the socket timeout is considered. So this one has to be quite long to consider network latency (around 10s in some hard cases).
Doing the opposite ( long socket timeout and short MQTT_RECV_POLLING_TIMEOUT_MS) will have the consequence to, at least, wait one socket timeout before continuing the Process_Loop.

#4

Hi @sbacou,

Have you tried initially setting a long socket read timeout, and then making it shorter after the TLS connection, as is done here?

#5

Hello,
Thanks for your support. I have done this test, and clearly it is a lot better. I do think it still have one problem, but not sure we can do better without touching library files (core-mqtt). When we set the socket timeout to a shorter one after connection, it shorten all reading on the socket. Polling but also forced reading. I am not sure yet if it is an issue, as it looks like that when connection is establised, a loop on the polling is done inside the the core-mqtt, but I will have to double confirm that.
Anyway thanks a lot for this huge upgrade of my application run time :wink: