Azure Iot Hub SDK для C: какой клиентский модуль использовать?
Мы создаем IoT-продукт с Azure IoT Hub в качестве внутреннего решения. Основное приложение написано на C, и мы собираемся использовать Azure SDK для C. Мы изучили SDK и решили, что будем использовать низкоуровневый клиент. Но вот в чем дело - в Azure SDK есть несколько модулей, которые кажутся независимыми - iothub_client_ll.h, iothub_device_client_ll.h а также iothub_client_core_ll.h, Какой использовать?
Также мы отметили, что iothub_device_client_ll.h не имеет возможности обрабатывать метод устройства асинхронно, и нам это действительно нужно. Но модуль device_client кажется самым последним - возможно, ребята из Microsoft планируют удалить iothub_client_ll модули из SDK вообще?
Мы не смогли найти ответы на эти вопросы на веб-сайте Azure или в документах репозитория github и в обсуждениях. Кто-нибудь может помочь нам понять это?
2 ответа
Мы получили этот вопрос с поля и ответили по электронной почте. В целях документации, я также опубликую ответ здесь.
Это действительно хорошие вопросы.
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.