Центр Интернета вещей Azure — сокращение загрузки/отправки данных

Я работаю с Azure IoT Hub, и в данный момент у меня запущена тестовая среда. Однако мы используем подписки на передачу данных 4G (мобильные устройства) для загрузки измерений с наших устройств, и я много сделал для сокращения объема данных, которые мы собираем и загружаем каждые 10 минут. Однако при измерении потребления данных я все еще вижу довольно большие накладные расходы. Мои сжатые данные занимают около 300 байт, но после измерения данных с помощью NetBalancer я вижу, что через 1 день мое приложение отправило 1,2 МБ и получило 2,3 МБ. Я использую протокол MQTT, поскольку он должен занимать наименьшую площадь.

Кажется, я не могу найти какой-либо передовой опыт или что-то подобное, чтобы уменьшить объем данных, отправляемых по сети с помощью Центра Интернета вещей. Любая помощь высоко ценится! :)


azure c# azure-iot-hub iot
person Daniel Hansen    schedule 28.12.2018    source источник
comment
Возможно, вы захотите определить потерю пакетов соединения, так как это приведет к потере данных. ретранслируется.   -  person rickvdbosch    schedule 28.12.2018
comment
Вы абсолютно уверены, что размер RX/TX, который вы измеряете, это ТОЛЬКО трафик MQTT? Является ли ваш клиент MQTT ПК с Windows? С Windows происходит много болтовни в / из Интернета, даже когда Центр обновления Windows отключен.   -  person evilSnobu    schedule 29.12.2018

Ответы (2)


arrow_upward
0
arrow_downward

Вы можете уменьшить размер сообщения, сериализовав его с помощью буферов протокола. (для C# доступны пакеты nuget).

Взгляните на Сериализация телеметрии с помощью Руководство по Protocol Buffers о том, как вы можете его реализовать.

Надеюсь, поможет!

person Itay Podhajcer    schedule 31.12.2018

arrow_upward
0
arrow_downward

Вот некоторые вещи, которые вы можете попробовать:

  1. Если вы отключаетесь после каждого сообщения, избегайте этого. Квитирование TLS может стоить до 10 килобайт, в то время как пинги поддержания активности стоят всего 80 байт, отправляемых каждую минуту. Повторное подключение после каждого сообщения часто неэкономично.
  2. Полностью избегайте TLS и используйте шлюз протокола между клиентом и IoTHub в качестве точки завершения TLS. (Это рискованно, но если вы можете зашифровать свою полезную нагрузку каким-либо другим надежным способом, это может оказаться жизнеспособным вариантом)
  3. Как предложил Itay, попробуйте альтернативные варианты сериализации, такие как буферы протокола или плоские буферы. Они, как правило, имеют гораздо меньшие размеры, чем JSON.
  4. Убедитесь, что вы используете лучший алгоритм сжатия для полезной нагрузки.

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

person aescwine    schedule 06.03.2019