Lorawan-stack: تحسين مطابقة الجهاز

أعتقد أن النهج الأفضل هو معالجة هذا بطريقة أخرى ، مما يؤدي أيضًا إلى زيادة الأداء في الحالة العامة - تقسيم البيانات التي تستهلك مساحة من البروتوس وتخزينها بشكل منفصل - على سبيل المثال recent_uplinks ، recent_downlinks وما إلى ذلك ، فمن المنطقي أيضًا تخزينها في قوائم بدلاً من البروتو المنظمة - وهذا يعني أننا لن نحتاج في الواقع إلى الاستعلام عن الرسائل الحالية ، ولكننا سنلحق رسالة جديدة فقط ، وهي طريقة أكثر كفاءة ، ولكن لنبدأ بالجزء الأولي فقط وننطلق من هناك.
بالنظر إلى أن لدينا أقنعة ميدانية ، فإن تقسيم البروتو سيكون واضحًا تمامًا ويتم التعامل معه بالكامل بواسطة تطبيقات تسجيل Redis.

لذا فإن الاقتراح هو أن يكون لديك:

• 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 - باقي البروتو

سيحدث الترحيل تلقائيًا ، وبالمثل يتم التعامل مع الحقول المهملة في السجلات بالفعل.

ما هو الوضع هنا؟

أتوقع أن يكون هذا جاهزًا للدمج بحلول نهاية الأسبوع المقبل.
يتم التنفيذ لأسابيع ، حيث يتم العمل على إعادة البناء ثم تكييف الاختبارات منذ ذلك الحين

يرجى التفكير في جعل الخطأ الذي تم إرجاعه أكثر وضوحًا إذا كان الجهاز لا يمكن مطابقته. انظر على سبيل المثال https://github.com/TheThingsNetwork/lorawan-stack/issues/2394.

لا يمكننا تقديم الكثير من المعلومات ، ولكن device_not_found يشير إلى أنه لا يمكن العثور على الجهاز ، في حين أنه من المحتمل أن DevAddr غير موجود على الإطلاق ، وأن MIC غير متطابق مع الإدخالات التي تم العثور عليها و / أو أن FCnt إعادة التعيين في حين أن ذلك غير مسموح به مع الإدخالات التي تم العثور عليها.

اقتراح جيد ، لكنني أعتقد أنه من الأفضل القيام بذلك كخطوة تالية ، لأنه سيكون بمثابة علاقات عامة ضخمة للمراجعة مع الكثير من الوظائف المعقدة نسبيًا