Lorawan-stack: Otimize a correspondência de dispositivo
Resumo
Otimize a correspondência de dispositivos no servidor de rede
Por que nós precisamos disso?
Para Redis I / O, uso de memória e desempenho geral de computação quando aumentamos a reutilização do DevAddr e aumentamos o tamanho do DevAddr.
O que já está aí? O que você vê agora?
Atualmente, NS alcança dispositivos por DevAddr e decodifica o proto. Os protos são grandes, contendo o estado do mac e as mensagens recentes de uplink e downlink, além de poder haver muitos protos (centenas) de DevAddr duplicados.
O que está faltando? O que você quer ver?
Precisamos de uma visão materializada no Redis para combinar uplinks com dispositivos por UID, antes de carregar o dispositivo correspondido.
Como você pretende implementar isso?
Armazene informações relevantes para correspondência em chaves dedicadas, basicamente DevAddr, FCnt, NwkSIntKeys e UID.
Um conjunto classificado e / ou mapa de hash seria útil, pois permite a classificação e a partir da consulta do Redis por FCnt, obtendo as chaves de integridade e UID.
Atualize esta visão materializada em cada uplink e adesão-aceitação.
Podemos ter uma migração contínua com fallback para o esquema de correspondência existente.
Como você pretende testar isso?
Testes de unidade, potencialmente com a afirmação das chaves Redis e seus valores no teste.
Você pode fazer isso sozinho e enviar uma solicitação pull?
Pode revisar
johanstokking
Todos 5 comentários
Eu acho que uma abordagem melhor seria lidar com isso de outra maneira, o que também aumenta o desempenho no caso geral - separar os dados que consomem espaço dos protos e armazená-los separadamente - ou seja, recent_uplinks , recent_downlinks etc., também faz mais sentido armazená-los em listas em vez de protos empacotados - isso significa que não precisaríamos realmente consultar as mensagens existentes, mas apenas anexar uma nova, que é muito mais eficiente, mas vamos começar apenas com o proto e partir daí.
Visto que temos máscaras de campo, a divisão do proto seria bastante simples e totalmente gerenciada pelas implementações de registro do Redis.
Portanto, a sugestão é ter:
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- resto do proto
A migração aconteceria automaticamente, da mesma forma como os campos obsoletos já são tratados nos registros.
rvolosatovs
em 22 jun. 2020
Qual é o status aqui?
johanstokking
em 20 ago. 2020
Espero que esteja pronto para fusão no final da próxima semana.
A implementação é feita por semanas, trabalhando na refatoração e, em seguida, adaptando os testes desde então
rvolosatovs
em 20 ago. 2020
Considere deixar o erro retornado mais claro se o dispositivo não for compatível. Veja, por exemplo, https://github.com/TheThingsNetwork/lorawan-stack/issues/2394.
Não podemos fornecer muitas informações, mas device_not_found implica que o dispositivo não pode ser encontrado, embora possa ser que o DevAddr não tenha sido encontrado, que o MIC não corresponda às entradas encontradas e / ou que o FCnt seja redefinido enquanto isso não for permitido com as entradas encontradas.
johanstokking
em 24 ago. 2020
Boa sugestão, mas acho que é melhor fazer isso como uma próxima etapa, porque será um grande PR para revisar com muitas funcionalidades relativamente complexas
rvolosatovs
em 24 ago. 2020
Questões relacionadas
adriansmares
·
8Comentários
kschiffer
·
7Comentários
w4tsn
·
6Comentários
johanstokking
·
3Comentários
kschiffer
·
4Comentários