Improvement of MQTT sas token renewal

[Werner-Prbk]

Currently using the Iot DeviceSdk DeviceClient with MQTT leads to a reconnect every ~60 minutes due to the way the sas token renewal is implemented. This also causes frequent calls of ConnectionStatusChanges handler and also error logs.
So device developers using the sdk will always have to filter the connection change reason and decide if they are "exceptional" or just caused by a "planned" sas token renewal.
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-troubleshoot-connectivity#mqtt-device-disconnect-behavior-with-azure-iot-sdks

I wonder why Microsoft choose to implement it like that and if there are any attempts to change this behavior in future?

Update:
In the meantime i found this old github issue which relates to the topic. Seems like there are no plans to change the behavior anytime soon :(
Azure/azure-iot-sdk-java#316

[drwill-ms]

I didn't make the decision, but my guess is that a SAS token is good for the specified duration, and seems to continue to work even if the symmetric key that it was generated from is recycled. Keeping it at 60 minutes seems to be a reasonable compromise between not generating a SAS token too often, but also kicking off a device from a hub when the symmetric key is revoked without waiting too long.

The version of MQTT we use simply disconnects clients after the SAS token has expired, as opposed to AMQP. I thought it was worth noting that part of the behavior appears to be related to this MQTT version.

We can't change the default now as the change in behavior could impact other customers.

If you wish, there is a way to provide your own implementation to increase the duration of the SAS token's TTL. I can't remember it off-hand and will get back to you on that.

[drwill-ms]

The class you want to derive from is AuthenticationWithTokenRefresh which you can use as a parameter to the DeviceClient factory method. You'll need to implement the method SafeCreateNewToken, but you can copy/edit the code from DeviceAuthenticationWithTokenReferesh.

[Werner-Prbk]

Thank you for your reply. I'll have a look at it.
My problem is, that every reconnect is logged and this pollutes my log files.
The current solution is to filter connection changes with state Disconnect_Retrying and reason Communication_Error. But I still have to to do more research if the combination Disconnect_Retrying && Connection_Error will only occur when SAS token is renewed.

https://github.com/Azure-Samples/azure-iot-samples-csharp/tree/master/iot-hub/Samples/device/DeviceReconnectionSample

[drwill-ms]

I'd suggest not logging everything from the connection status callback. Some are informational and others are significant, so even a logging level would make a big difference here, if you are capable of employing that. I'd say any condition from our sample where an action is taken (Device_Disabled, Bad_Credential, Retry_Expired, and Communication_Error) is probably interesting enough to log. Anything where action is not taken, then I wouldn't log it, or log it as verbose.