Иерархия тем MQTT для публикации 3 точек данных

Это сложная проблема, связанная с темами MQTT.

У меня есть несколько клиентов MQTT (сенсорных узлов), которые публикуют полученные данные как «_data», мощность сигнала как «_rssi» и время сбора данных «_toc» в своих трех темах.

/node/node_id/data/
/node/node_id/rssi/
/node/node_id/toc/

где "node_id" - идентификатор (целое/число) клиента (узла) (уникальный для узла). Соответствующие полезные данные: _data (данные с плавающей запятой), _rssi (с плавающей запятой) и _toc (дата-время Unix). . Ясно, что все три точки данных связаны друг с другом.

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

Тем не менее, есть одна замечательная вещь, связанная с использованием 3 разных тем для каждого узла/клиента: если соединение между клиентом MQTT и сервером прерывается (теряется) сразу после публикации полезных данных «data» и перед публикацией «rssi» и «timestamp». " полезной нагрузки, то это несоответствие между тремя точками данных, сообщение из темы "данные" будет отражать новое значение, в то время как две другие темы будут содержать старые значения ~ потеря целостности.

Я мог бы использовать однострочную тему, например

/узел/идентификатор_узла/данные/_данные/rssi/_rssi/toc/_toc

Or

/узел/идентификатор_узла/(_данные,_rssi,_toc)

И замените _data, _rssi и _toc соответствующими значениями, проанализируйте их и разделите значения. Последний стиль темы, в частности, уменьшает количество раз, когда клиент будет публиковать, экономя на стоимости данных и ошибках целостности. Он также короткий по длине. Но, конечно, это беспорядочно, очень нестандартно по своей природе, и ошибки могут легко возникнуть.

Может ли кто-нибудь предложить промежуточный способ всегда иметь целостность данных и минимизировать количество публикаций, которые должен выполнять клиент, а также поддерживать чистую структуру сообщений. Я определенно предпочел бы целостность данных, но также хотел бы разделить права доступа между подписчиками.


person solyarist    schedule 06.02.2017    source источник
comment
Вы хотите сказать, что из набора измерений (выше вы указали 3: _data, _rssi и _toc) некоторым подписчикам разрешено видеть только подмножества (например, _data и _toc по сравнению с _rssi и _toc по сравнению со всеми тремя)? Кажется, вы не хотите, чтобы ваши сенсорные узлы отвечали за контроль доступа. С точки зрения дизайна разрешите только одному подписчику иметь полный доступ к необработанным измерениям, затем разделите эти данные и повторно опубликуйте подмножества в соответствии с правами доступа.   -  person Gambit Support    schedule 06.02.2017
comment
@GambitSupport да, очень даже; реальная сетевая архитектура немного сложна со многими компонентами в игре. Повторная публикация выглядит отличным решением; он решает все 3 архитектурные проблемы - целостность, контроль доступа, низкие затраты на передачу данных. Удивительно простое решение, которое ускользнуло от меня. Спасибо!   -  person solyarist    schedule 07.02.2017


Ответы (1)


Не кодируйте данные в темы, это в конечном итоге будет очень беспорядочным и означает, что вам придется использовать действительно неприятные подписки с подстановочными знаками, чтобы все заработало.

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

person hardillb    schedule 06.02.2017
comment
Вы, сэр, видимо, что-то видели. Мне даже в голову не пришло, что ОП кодирует данные в топике... - person Pavel Zdenek; 06.02.2017
comment
Конечно, я не буду помещать данные в тему. Мы собираемся использовать решение, предоставленное @gambit, поместив все данные в одну тему в качестве полезной нагрузки, а затем проанализировав их дальше. Спасибо за ваш ответ. - person solyarist; 07.02.2017