#azure #azure-iot-hub #azure-eventgrid #azure-iot-sdk
Вопрос:
Мне было интересно, сообщает ли IoTHub устройству о сбое в сообщении сетки событий? Вот поток архитектуры:
Устройство->IoTHub->>Сетка событий->>>Веб-крючок
Итак, когда EevntGrid получает какую-либо ошибку(например, ошибку 400/500 по какой-либо причине), сообщает ли IoTHub устройству об этой ошибке, когда устройство может повторить попытку, или отправляет полученное сообщение, в котором устройство будет считать, что сообщение успешно отправлено на веб-крючок? Существует ли рабочий процесс/ дизайн, в котором мы могли бы сообщить устройству об этой ошибке?
Ответ №1:
Итак, когда EevntGrid получает какую-либо ошибку(например, ошибку 400/500 по какой-либо причине), сообщает ли IoTHub устройству об этой ошибке, когда устройство может повторить попытку, или отправляет полученное сообщение, в котором устройство будет считать, что сообщение успешно отправлено на веб-крючок?
Нет, это асинхронный поток. Не будет никакого сообщения «облако-устройство», сообщающего, что устройство вышло из строя. По крайней мере, не из коробки. Кроме того, логика повторной попытки уже присутствует в сетке событий, поэтому устройству не нужно повторять сообщение, если только ему не удается связаться с центром интернета вещей.
Существует ли рабочий процесс/ дизайн, в котором мы могли бы сообщить устройству об этой ошибке?
Возьмем этот пример:
- Устройство отправляет телеметрию
- Центр интернета вещей получает сообщение и передает его в Сетку событий
- Сетка событий пытается доставить событие
- Сбой доставки событий из-за временной ошибки
- Сетка событий повторяет доставку событий n раз за заданный период
- Событие успешно доставлено или написано мертвыми буквами
- В случае успешной доставки сообщение обрабатывается конечной точкой.
Теперь сообщение «облако-устройство» можно отправить только на шаге 6 (или 7, если вы хотите включить ответ конечной конечной точки). Между этапом 1 и 6/7 могут быть миллисекунды, или могут быть минуты, часы или даже дни (в худшем случае, в зависимости от конфигурации повторной попытки и состояния конечной точки).
Логично, чтобы конечная точка опубликовала свое собственное событие и доставила его на облачное устройство, но это будет асинхронный поток.
Почему вы хотите обременить устройство результатами доставки сообщений? Я думаю, что ему не нужно беспокоиться о потоке, если он не сможет связаться с центром интернета вещей.