Пакет SDK для Azure Iot Hub для C: какой клиентский модуль использовать?

Мы получили этот вопрос с мест и ответили по электронной почте. Для документации я также опубликую здесь ответ.

Это действительно хорошие вопросы.

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 (), который в основном обновляет сообщаемые значения на двойнике.

Метод «async» в устаревшем iothub_client_ll не интегрируется в двойник и имеет ограниченную ценность, поэтому мы не хотели использовать его в iothub_device_client_ll.

Если вы просмотрите исходные файлы, вы увидите, что все они вызывают iothub_client_core_ll, поэтому практически не имеет значения, какой из них вы используете. Эти разные версии существуют только для обратной совместимости.

Я не понимаю, что вы имеете в виду под асинхронной обработкой. Ll в этих файлах обозначает низкий уровень, что означает, что у них меньше зависимостей, чем у версий без ll. Одна из них заключается в том, что он не использует никаких потоков внутри, так что код может быть запущен на процессорах, которые не поддерживают потоки, поэтому все будет работать в одном потоке, и вам потребуется вызывать IoTHubClient_LL_DoWork на регулярной основе (подумайте 100 раз второй) для подключения к хабу и отправки и получения сообщений. Если вам нужно обработать метод устройства вторым потоком, вы должны использовать версию без обозначения ll.