Lorawan-stack: Оптимизировать сопоставление устройств
Резюме
Оптимизация сопоставления устройств на сетевом сервере
Зачем нам это нужно?
Для Redis I / O использование памяти и общая производительность вычислений при увеличении повторного использования DevAddr и увеличении размера DevAddr.
Что там уже есть? Что ты видишь сейчас?
В настоящее время NS пробегает устройства по DevAddr и декодирует proto. Прототипы большие, содержат состояние Mac и недавние сообщения восходящего и нисходящего каналов, плюс может быть много протоколов (сотни) дублированных DevAddr.
Чего не хватает? Что вы хотите увидеть?
Нам нужно материализованное представление в Redis для сопоставления восходящих каналов с устройствами по UID перед загрузкой сопоставленного устройства.
Как вы предлагаете это реализовать?
Храните соответствующую информацию для сопоставления в выделенных ключах, в основном DevAddr, FCnt, NwkSIntKeys и UID.
Сортированный набор и / или хеш-карта были бы полезны, поскольку это позволяет Redis сортировать и запрашивать отправку с помощью FCnt, получая ключи целостности и UID.
Обновите это материализованное представление для каждого восходящего канала и подтверждения присоединения.
У нас может быть скользящая миграция с откатом к существующей схеме сопоставления.
Как вы предлагаете это проверить?
Модульные тесты, потенциально с утверждением ключей Redis и их значений в тесте.
Можете ли вы сделать это самостоятельно и отправить запрос на слияние?
Можно просмотреть
johanstokking
Все 5 Комментарий
Я думаю, что лучшим подходом было бы решить эту проблему другим способом, который также увеличивает производительность в общем случае - выделите занимающие много места данные из протоколов и сохраните их отдельно, то есть recent_uplinks , recent_downlinks и т. д., также имеет смысл хранить их в списках вместо маршалированных протоколов - это означает, что нам на самом деле не нужно запрашивать существующие сообщения, а просто добавить новое, что намного эффективнее, но давайте начнем с прототипа и продолжим.
Учитывая, что у нас есть маски полей, разделение прототипа будет довольно простым и полностью обработано реализациями реестра Redis.
Итак, мы предлагаем:
ns:devices:uid:foo:bar:recent_uplinksns:devices:uid:foo:bar:recent_downlinksns:devices:uid:foo:bar:mac_state:recent_uplinksns:devices:uid:foo:bar:mac_state:recent_downlinksns:devices:uid:foo:bar:pending_mac_state:recent_uplinksns:devices:uid:foo:bar:pending_mac_state:recent_downlinks
...ns:devices:uid:foo:bar- остальная часть прото
Миграция будет происходить автоматически, аналогично тому, как устаревшие поля уже обрабатываются в реестрах.
rvolosatovs
22 июн. 2020
Какой здесь статус?
johanstokking
20 авг. 2020
Я ожидаю, что это будет готово к слиянию к концу следующей недели.
Реализация длится недели, работа над рефакторингом, а затем адаптация тестов с тех пор.
rvolosatovs
20 авг. 2020
Пожалуйста, постарайтесь сделать возвращаемую ошибку более понятной, если устройство не может быть сопоставлено. См., Например, https://github.com/TheThingsNetwork/lorawan-stack/issues/2394.
Мы не можем предоставить полный объем информации, но device_not_found подразумевает, что устройство не может быть найдено, хотя может случиться так, что DevAddr вообще не найден, что MIC не совпадает с найденными записями и / или что FCnt сбрасывается, пока это не разрешено с найденными записями.
johanstokking
24 авг. 2020
Хорошее предложение, но я думаю, что лучше сделать это в качестве следующего шага, потому что это будет огромный пиар для обзора с большим количеством относительно сложных функций.
rvolosatovs
24 авг. 2020
Смежные вопросы
johanstokking
·
8Комментарии
johanstokking
·
6Комментарии
ecities
·
5Комментарии
htdvisser
·
9Комментарии
w4tsn
·
6Комментарии