Any cost or con to disable `AWS_IOT_SEND_TIMEOUT`?

tedhavelka66

Hello CircuitDojo Community,

Over past couple of months I have been working with Sparkfun Thing Plus nRF9160 board, and Nordic Semi’s Zephyr based aws_iot sample app. I’m sending sensor data to an AWS S3 bucket. I notice however, that my MQTT client-to-broker connections do not persist for very long. Project review of Kconfig settings, using west build -t menuconfig shows:

AWS_IOT_SEND_TIMEOUT(=y) “Send data with socket timeout”
AWS_IOT_SEND_TIMEOUT_SEC(=60) “Send timeout”

I’m actually working to develop a battery powered device, and prefer to minimize celular and or NB-IoT transmissions, some non-trivial ones of which are needed to do the initial client authentication and certificate sharing.

Question 1: Is there a cost if I disable this “AWS IoT send timeout” configuration item? Would my MQTT client-to-broker connection then persist?

Question 2: Would there as well then be any difficulty to reconnect, if some intermediary failure happened and broke my device’s connection to the MQTT broker?

Part of Nordic Semi’s AWS IoT library API includes a routine to disconnect a client from a broker or remote server. But I’m guessing that disconnect performs some kind of clean up and resetting so that a new connection can be made straight away, whereas an externally dropped or lost connection may leave stuff in the running firmware not properly updated with the lost connection status.

Thanks ahead of time for help you and the community can offer on this topic!

jaredwolff

tedhavelka66

tedhavelka66 Question 1: Is there a cost if I disable this “AWS IoT send timeout” configuration item? Would my MQTT client-to-broker connection then persist?

Looking at the internals, it looks like it’s setting the socket timeout parameter.

if (IS_ENABLED(CONFIG_AWS_IOT_SEND_TIMEOUT)) {
		struct timeval timeout = {
			.tv_sec = CONFIG_AWS_IOT_SEND_TIMEOUT_SEC
		};

		err = setsockopt(client.transport.tls.sock,
				 SOL_SOCKET,
				 SO_SNDTIMEO,
				 &timeout,
				 sizeof(timeout));
		if (err == -1) {
			LOG_WRN("Failed to set timeout, errno: %d", errno);

			/* Don't propagate this as an error. */
			err = 0;
		} else {
			LOG_DBG("Using send socket timeout of %d seconds",
				CONFIG_AWS_IOT_SEND_TIMEOUT_SEC);
		}
	}

Generally the underlying MQTT client will send immediately if connected and return. If not connected, it will return error. I don’t believe the client retains any data in these cases.

tedhavelka66 Question 2: Would there as well then be any difficulty to reconnect, if some intermediary failure happened and broke my device’s connection to the MQTT broker?

Part of Nordic Semi’s AWS IoT library API includes a routine to disconnect a client from a broker or remote server. But I’m guessing that disconnect performs some kind of clean up and resetting so that a new connection can be made straight away, whereas an externally dropped or lost connection may leave stuff in the running firmware not properly updated with the lost connection status.

No, it’s easy but you have to invoke the reconnection yourself. Monitor the MQTT event callback to reconnect if need be.

Hope that helps!

tedhavelka66

Thank you Jared,

I think this helps. One question this reminds me, you mention “MQTT client will send immediately”. In this statement you refer to MQTT client publishing (sending) to a topic, correct? What then is the MQTT mechanism to manage subscriptions? For example, let’s say a device is in power down mode and wakes once an hour. An MQTT broker does not know about this. How does the client obtain messages from the broker, messages in the MQTT topics to which the client has subscribed?

At a lower level, does an MQTT client send out some type of “I’m here and subscribed to topics x, y, z” message when the client first connects to its broker?

jaredwolff

tedhavelka66 What then is the MQTT mechanism to manage subscriptions? For example, let’s say a device is in power down mode and wakes once an hour. An MQTT broker does not know about this. How does the client obtain messages from the broker, messages in the MQTT topics to which the client has subscribed?

Good question. It depends on how you have your connection intervals setup. If you have EDRx or PSM enabled, that socket will be at the mercy of those modes. Whenever the device checks in with the tower is when it may receive new events. But, and this part is important, if the server side has a timeout it may disconnect your device prematurely.

tedhavelka66 At a lower level, does an MQTT client send out some type of “I’m here and subscribed to topics x, y, z” message when the client first connects to its broker?

The subscriptions are all up to you. As long as you subscribe and keep the socket open, it maintains that MQTT connection state. There’s also options in the Zephyr MQTT to either connect with a reset state or try to re-inherit the one created earlier. I haven’t played much with this but it may be possible that through connects and disconnects the state is maintained and restored on reconnect. (i.e. you’ll have to play with it to see if it does what you need)