[Technical Question] [SDK v2] Lack of timeout options for IoT Hub device client

[bastyuchenko]

Hello,
I see that only IdleTimeout available for IotHubClientMqttSettings and ProvisioningClientMqttSettings. Maybe I'm wrong but it seems other timeouts are hardcoded or not implemented.
For example, Azure IoT SDK for C has OPTION_MESSAGE_TIMEOUT, OPTION_CONNECTION_TIMEOUT.
https://github.com/Azure/azure-iot-sdk-c/blob/main/doc/connection_and_messaging_reliability.md

Is there any way in Azure IoT SDK .NET v2 to configure similar parameters?

[patilsnr]

Hey @bastyuchenko - you're right in that many timeouts in the .NET SDK are private fields that are set internally and thus cannot be modified like in the C SDK. Are there specific timeouts that you're working with that you'd like to be able to tweak, or is this more of just a general wondering about how they work in .NET?

[patilsnr]

Closing this issue for now, feel free to reopen it should the desire arise.

[bastyuchenko]

Hi @patilsnr
Sorry for the time I took to reply to you, I was on vacation. Could you reopen this Tech Question?

Our customer is going to increase number of devices in a fleet and I'm implementing a performance test to understand how various options affect communication in our specific scenarios. After the perf testing is finished, I'm going to tweak the most suitable values of these options in PROD env.

I use MQTT protocol in our solution.
There are specific timeouts that I'm working with:

• OPTION_CONNECTION_TIMEOUT (IoTHubDeviceClient_SetOption) - While connecting, it is the maximum number of seconds the device client (when using MQTT) will wait for the connection to complete (CONNACK).
• PROV_OPTION_TIMEOUT (Prov_Device_LL_SetOption) - Maximum time to allow DPS to complete, in seconds.
• OPTION_KEEP_ALIVE (IoTHubClient_SetOption) - Frequency in seconds that the transport protocol will be sending MQTT pings to the Azure IoT Hub. Maybe keep_alive option was implemented through IotHubClientMqttSettings.IdleTimeout in .NET SDK, please confirm.
• OPTION_MESSAGE_TIMEOUT (IoTHubClient_SetOption) - Timeout for iothub client messages waiting to be sent to the IoTHub.

[patilsnr]

Hi @bastyuchenko. I have confirmed that OPTION_KEEP_ALIVE is implemented via IdleTimeout for MQTT connections. The others seem to be set internally, and I can find out where the .NET equivalents of them happen. Configuring these constants would have to be done through modifying the source code directly in this case, unlike in the C SDK.

[patilsnr]

Hi again @bastyuchenko. I've looked into it and it seems that these timeouts are internally handled through .NET's [IMqttClient](https://github.com/dotnet/MQTTnet/wiki/Client) and MqttClientOptions classes, for example:

These clients are used by the SDK in the MqttTransportHandler and ProvisioningMqttTransportHandler classes and are internal fields. I will keep looking and update you if I'm mistaken, but it seems that the .NET SDk is not as modular for upating timeouts as the C SDK is, and the best way to do so would be by forking off of GitHub and playing with where we define the IMqttClient in our transport handler files. I hope this helps, and please let us know if you have any questions.

[andyk-ms]

Provided suggestion and work around on source given the limitation on the current version of the SDK.