Any cost or con to disable `AWS_IOT_SEND_TIMEOUT`?

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 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)