我们正在处理设备可以“解锁”的情况，并且我们希望确保解锁状态正确地传播到服务器。
目前我们正在使用直接方法，但有人担心在通话超时时会发生什么。据我们了解，如果服务器超时但设备成功响应（从IoT-Hub获取MQTT PUBACK），那么我们就会发现设备被“解锁”但服务器认为失败的不一致。这是我们想要避免的状态，设备和服务器同步非常重要。
有什么好的模式如何解决这个问题？
答案 0 :(得分：0)
在我看来，请不要担心这个问题。直接方法表示与类似于HTTP调用的设备的请求 - 回复交互，因为它们成功或立即失败（在用户指定的超时之后）。此方法对于立即操作的过程因设备是否能够响应而不同的情况非常有用。直接方法是同步的，并且在超时期限之后成功或失败（默认值：30秒，可设置为3600秒）。但是对于方法调用的排序或任何并发语义都不能保证。
答案 1 :(得分：0)
我们将重新考虑如何看待超时并在这种情况下接受不确定性。如果我们超时，我们会认为这是不确定的，并等待来自设备的下一个遥测数据得出结论。