Add a way to change the default TLS timeout

[tortila]

Hi, I use this library together with awsiot to establish MQTT connection and use it for publishing messages to the IoT Core broker from devices that very often have poor network conditions (TCP packets getting lost, high latency). Recently one of the issues I spotted was that the MQTT connection fails with the following error:

awscrt.exceptions.AwsCrtError: AwsCrtError(name='AWS_IO_TLS_NEGOTIATION_TIMEOUT', message='Channel shutdown due to tls negotiation timeout', code=1067)

To reproduce the issue:

• introduce a high delay for each TCP packet, e.g. on Linux: sudo tc qdisc replace dev wlp0s20f3 root netem delay 1500ms 200ms (where wlp0s20f3 is the name of the network interface)
• run any script that will initiate the MQTT connection (e.g. https://github.com/aws/aws-iot-device-sdk-python-v2/blob/master/samples/pubsub.py)
• revert the network delay with: sudo tc qdisc del dev wlp0s20f3 root (replace wlp0s20f3 with a correct interface name)

Even though the mqtt_connection_builder provides a number of timeout-related parameters, none of them has an impact on the TLS negotiation timeout that is the cause of the failure.

After some debugging I was able to find out that the C library aws-c-io (that this library has bindings to) defines an object aws_tls_connection_options that contains the parameter timeout_ms. However, the method that aws-crt-python is calling sets this parameter to a default, hard-coded value of 4000ms. What's more, the Python structures that provide the application-level abstraction (namely TlsContextOptions) do not contain the timeout property, so there's no way to change the value even after the context was initialized with the default one.

In order to establish the MQTT connection reliably from the device in a high-latency network, it's crucial that the TLS negotiation timeout can be set to a value higher than 4 seconds. Please provide a way to set the timeout to any custom value.

[jamesod-martin]

Have you found any workarounds for this? I'm stuck in the same situation.

[tortila]

@jamesod-martin I applied a simple retry mechanism around the connect() method call (of the MQTT connection) as a workaround. This is not ideal, because it relies on an opportunistic condition that at some point the latency will be small enough for consecutive requests that the whole TLS negotiation will be performed under 4 seconds. I'm using the tenacity library to achieve this. In my use case this solution appeared to be good enough so I'll stick with it until this feature request is implemented in the SDK - but it doesn't mean it's good enough for other use cases (e.g. where latency is never low enough).

[tfeldmann]

I'm stuck on this issue with a device having very bad latency. Any workaround for this? Retrying the connection is hopeless as the negotiation does never complete within 4 seconds.

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=51 time=1062 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=51 time=801 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=51 time=1140 ms