Lorawan-stack: Optimiser la correspondance des appareils

Créé le 5 juin 2020 · 5Commentaires · Source: TheThingsNetwork/lorawan-stack

Sommaire

Optimiser la correspondance des appareils dans Network Server

Pourquoi avons nous besoin de ça?

Pour les E/S Redis, l'utilisation de la mémoire et les performances de calcul globales lorsque nous augmentons la réutilisation de DevAddr et la taille de DevAddr.

Qu'est-ce qu'il y a déjà ? Que voyez-vous maintenant?

Actuellement, NS couvre les appareils par DevAddr et décode le proto. Les protos sont gros, contenant l'état mac et les messages récents de liaison montante et descendante, et il peut y avoir de nombreux protos (des centaines) de DevAddr en double.

Que manque-t-il? Qu'est-ce que tu veux voir?

Nous avons besoin d'une vue matérialisée dans Redis pour faire correspondre les liaisons montantes aux appareils par UID, avant de charger l'appareil correspondant.

Comment proposez-vous de mettre cela en œuvre ?

Stockez les informations pertinentes pour la correspondance dans des clés dédiées, donc essentiellement DevAddr, FCnt, NwkSIntKeys et UID.

Un ensemble trié et/ou une carte de hachage serait utile car cela permet le tri et l'interrogation à partir de Redis par FCnt, en obtenant les clés d'intégrité et l'UID.

Mettez à jour cette vue matérialisée sur chaque liaison montante et join-accept.

Nous pouvons avoir une migration continue avec un repli vers le schéma de correspondance existant.

Comment proposez-vous de tester cela ?

Tests unitaires, potentiellement avec assertion des clés Redis et de leurs valeurs dans le test.

Pouvez-vous le faire vous-même et soumettre une Pull Request ?

Peut revoir

network server performance in progress scalability

Source

johanstokking

Tous les 5 commentaires

Je pense qu'une meilleure approche serait d'aborder cela d'une autre manière, ce qui augmente également les performances dans le cas général - séparez les données gourmandes en espace des protos et stockez-les séparément - c'est-à-dire recent_uplinks , recent_downlinks etc., il est également beaucoup plus logique de les stocker dans des listes au lieu de protos marshalés - cela signifie que nous n'aurions pas réellement besoin d'interroger les messages existants, mais que nous en ajouterions simplement un nouveau, ce qui est beaucoup plus efficace, mais Commençons par le proto et partons de là.
Étant donné que nous avons des masques de champ, le fractionnement du proto serait assez simple et entièrement géré par les implémentations de registre Redis.

Donc la suggestion est d'avoir:

ns:devices:uid:foo:bar:recent_uplinks
ns:devices:uid:foo:bar:recent_downlinks
ns:devices:uid:foo:bar:mac_state:recent_uplinks
ns:devices:uid:foo:bar:mac_state:recent_downlinks
ns:devices:uid:foo:bar:pending_mac_state:recent_uplinks
ns:devices:uid:foo:bar:pending_mac_state:recent_downlinks
...
ns:devices:uid:foo:bar - reste du proto

La migration se produirait automatiquement, de la même manière que les champs obsolètes sont déjà gérés dans les registres.

rvolosatovs le 22 juin 2020

Quel est le statut ici ?

johanstokking le 20 août 2020

Je m'attends à ce que cela soit prêt pour la fusion d'ici la fin de la semaine prochaine.
L'implémentation se fait pendant des semaines, en travaillant sur le refactoring puis en adaptant les tests depuis

rvolosatovs le 20 août 2020

👍1

Veuillez envisager de rendre l'erreur renvoyée plus claire si l'appareil ne peut pas être mis en correspondance. Voir par exemple https://github.com/TheThingsNetwork/lorawan-stack/issues/2394.

Nous ne pouvons pas fournir beaucoup d'informations, mais device_not_found implique que le périphérique est introuvable, alors qu'il se peut que la DevAddr ne soit pas du tout trouvée, que le MIC ne correspond pas aux entrées trouvées et/ ou que le FCnt est réinitialisé alors que cela n'est pas autorisé avec les entrées trouvées.

johanstokking le 24 août 2020

👍1

Bonne suggestion, mais je pense qu'il est préférable de le faire dans une prochaine étape, car ce sera un énorme PR à revoir avec beaucoup de fonctionnalités relativement complexes

rvolosatovs le 24 août 2020

👍1

Cette page vous a été utile?

0 / 5 - 0 notes