Мы получили этот вопрос с поля и ответили по электронной почте.В целях документации я также опубликую ответ здесь.
Это действительно хорошие вопросы.
iothub_client_ll, iothub_device_client_ll и iothub_client_core_ll
Заказчик должен использовать API-интерфейс iothub_device_client_ll *,Это действительно новый способ, которым мы хотим, чтобы люди использовали движение вперед.Iothub_client_core_ll является только внутренним (он поддерживает device_client / legacy client / module_client).Iothub_client_ll - это то, что мы имели ранее, как правильно догадался Sub Zero.
API, который, кажется, выполняет асинхронные методы, не является тем, что мы взяли в iothub_device_client_ll.С точки зрения сервисной стороны методы являются синхронными (в частности, см. https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-direct-methods, и параграф, начинающийся с «Прямые методы являются синхронными и либо успешно выполняются, либо заканчиваются ошибкой по истечении времени ожидания (по умолчанию: 30 секунд, устанавливается до 3600 секунд»).
Мы понимаем, что существуют сценарии - например, обновление прошивки - когда метод может запустить долгосрочное задание. У нас есть пример этого здесь, в частности, они должны изучить функцию device_method_callback, котораяобрабатывает обратный вызов и затем вращает поток, когда method_name == ”FirmwareUpdate” и быстро возвращает. Поток do_firmware_update (), когда завершится, обновит свой статус для сервера, вызвав sendChillerReportedProperties (), который в основном обновляет сообщенные значения для объекта-близнеца.
Асинхронный метод в устаревшем iothub_client_ll не интегрируется в двойника и имеет ограниченное значение, поэтому мы не хотим использовать его в iothub_device_client_ll.