Lorawan-stack: قم بتأكيد جلسة الجهاز النهائية بناءً على رسائل خادم الشبكة

أنا أؤيد هذا ، كما ناقشنا بالفعل.
يجب أن يثق خادم التطبيق دائمًا في خادم الشبكة ، لأنه يحتوي دائمًا على أحدث البيانات حول جلسة الجهاز.

• يرسل End Device FPort = 0 ارتباطًا صاعدًا - ولن يتلقى AS هذا الارتباط الصاعد

ألا يجب علينا تغيير هذا حتى يرسل NS هذا ، ولكن مع حمولة فارغة و FPort 0 ، بحيث لا يتم إرسالها في اتجاه التيار؟

• يرسل End Device FPort = 0 ارتباطًا صاعدًا - ولن يتلقى AS هذا الارتباط الصاعد

ألا يجب علينا تغيير هذا حتى يرسل NS هذا ، ولكن مع حمولة فارغة و FPort 0 ، بحيث لا يتم إرسالها في اتجاه التيار؟

إنها زائدة عن الحاجة ، نظرًا لأن رسائل NS-> AS غير متزامنة ، يمكن أن يصل إبطال قائمة الانتظار قبل إرسال الوصلة الصاعدة FPort==0 إلى AS لتأكيد الجلسة ، لذلك يتعين علينا القيام بذلك على أي حال. السبب الوحيد لإرسال ارتباط صاعد إلى AS ردًا على الارتباط الصاعد FPort==0 إلى NS ، هو ضمان إخطار AS بتغيير الجلسة في أقرب وقت ممكن ، ولكن ليس لدينا مثل هذه الحاجة. حتى مع ذلك ، سيكون من المنطقي أكثر تقديم رسالة SessionSwitch ، والتي سيرسلها NS إلى AS بدلاً من الارتباط الصاعد FPort 0.

لقد قمت بترقية الأولوية إلى prio/high لأنها تؤثر على عمليات نشر v3.11.1 .

يجب أن تكون التغييرات على النحو التالي:

• أضف SessionKeyID إلى DownlinkQueueInvalidation . إذا كانت قائمة الانتظار فارغة ، فلن يتمكن AS في هذه اللحظة من معرفة أي قائمة انتظار تم إبطالها.

يجب أن تكون الإضافة التالية proto (الحقل 3 ) كافية.

message ApplicationInvalidatedDownlinks {
  repeated ApplicationDownlink downlinks = 1;
  uint32 last_f_cnt_down = 2;
  bytes session_key_id = 3 [(gogoproto.customname) = "SessionKeyID", (validate.rules).bytes.max_len = 2048];
}

• يجب أن يقوم AS بتحديث قائمة الانتظار + FCnt للجلسة الصحيحة ، بدلاً من افتراض أن الإلغاء يتعلق بـ dev.Session .

https://github.com/TheThingsNetwork/lorawan-stack/blob/e2fa6c085eaaf1a0b70939020244875bd01e5857/pkg/applicationserver/applicationserver.go#L1020 -L1038

بدلاً من استخدام dev.Session دائمًا ، قم بالتبديل على SessionKeyID أجل تحديد الجلسة التي يجب استخدامها. إذا لزم الأمر ، قم بتحديث dev.Session .

• يجب أن يتحقق AS من الجلسة التي تأتي منها رسالة nacked - من الممكن أن تكون رسالة nacked من جلسة معلقة (من منظور AS) وبالتالي يجب إجراء تحديث FCnt في الجلسة الصحيحة.

https://github.com/TheThingsNetwork/lorawan-stack/blob/e2fa6c085eaaf1a0b70939020244875bd01e5857/pkg/applicationserver/applicationserver.go#L1060 -L1073

كما كان من قبل ، قم بتبديل SessionKeyID لتحديد الجلسة التي يجب استخدامها. إذا لزم الأمر ، قم بتحديث dev.Session .

• (اختياري) إرجاع تفاصيل الخطأ على DownlinkQueue{Push|Replace} بحد أدنى FCnt وقم دائمًا بتحديث LastAFCntDown لهذه القيمة. سيضمن هذا تقارب النظام إذا كنا في أي وقت خارج المزامنة بين AS و NS.

يجب ملء الإضافة التالية proto وإضافتها كتفاصيل خطأ إلى errFCntTooLow في NS:

message UpdateDownlinkQueueErrorDetails {
  bytes session_key_id = 1 [(gogoproto.customname) = "SessionKeyID", (validate.rules).bytes.max_len = 2048];
  uint32 last_f_cnt_down = 2;
}

يمكن لـ AS بعد ذلك أخذ هذه التفاصيل وتحديث الجلسة الحالية.

التغييرات متوافقة مع الإصدارات السابقة ونأمل أن تكون ضئيلة من جانب NS. لقد خرج الجني بالفعل من الزجاجة - أصبح البروتوكول بأكمله بين AS و NS غير متزامن ببطء ، وببساطة لن يكون إرجاع التغيير FPort=0 كافيًا. لا أعتقد أن هذا التحول كان خاطئًا في نهاية اليوم ، ولكن يجب علينا إصلاح هذه المراوغات فيما يتعلق بتقليد الجلسة المزدوجة.

cc johanstokking ، rvolosatovs

يبدو أمرا جيدا لي!

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

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

أنا أعمل بالفعل على هذا ، مع التركيز بشكل كبير على النقطة التالية:

* (Optional) return error details on `DownlinkQueue{Push|Replace}` with the minimum `FCnt` and always update the `LastAFCntDown` to this value. This would ensure that the system converges if at any point we're for some reason out of sync between AS and NS.

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

• قد تكون الرسائل قديمة ، لكننا نريد إجراء إصلاحات لقائمة الانتظار _now_
• قد تضيع الرسائل - قائمة الانتظار ليست لانهائية
• يمكن إعادة ترتيب الرسائل - يتم دفعها بشكل غير متزامن في قائمة الانتظار ، ويتم ظهورها بطرق يُحتمل إعادة ترتيبها

بالنظر إلى هذه الخصائص ، هناك خياران:

• قم بتأجيل حساب قائمة الانتظار إلى نهاية معالجة الدُفعات (بشكل أساسي إذا تلقيت 10 إبطال لقائمة الانتظار الهابطة ، فأنت تعيد حساب قائمة الانتظار فقط في النهاية). هذا لا يكفي للأسباب التالية:
  
  
  
  • عندما يعالج AS مجموعة من الرسائل ، فإنه لا يزال لا يعرف ما إذا كان _ بالفعل _ في نهاية قائمة الانتظار ، أو يعالج بعض الدُفعات في المنتصف
  
  
  • قد تظل الرسائل مفقودة ، وتحديد ترتيبها ليس بالأمر الهين.
  
  
• فقط _ثق في NS_. ما أعنيه بهذا ، هو أن عمليات الدفع / الاستبدال تُرجع dev.Session.SessionKeyID ، dev.PendingSession.SessionKeyID ، و LastAFCntDown ، كجزء من تفاصيل الخطأ. ثم نستخدم تفاصيل الخطأ لإعادة بناء الجلسة في AS. يعني هذا أساسًا أنه عندما نحاول إجراء عملية قائمة انتظار للوصلة الهابطة ، باستخدام بيانات قديمة (ربما جلسة قديمة ، وربما تكون FCnt منخفضة جدًا) ، فإننا في النهاية نتقارب مع حالة NS. قد يستغرق الأمر محاولة واحدة أو اثنتين أو ثلاث محاولات ، وسأجعلها مقيدة لتجنب الدوران اللامتناهي ، لكننا على الأقل نعمل بمعلومات أحدث بشكل ملحوظ من تلك الموجودة في قائمة انتظار رسائل الارتباط الصاعد.

• فقط _ثق في NS_. ما أعنيه بهذا ، هو أن عمليات الدفع / الاستبدال تُرجع dev.Session.SessionKeyID ، dev.PendingSession.SessionKeyID ، و LastAFCntDown ، كجزء من تفاصيل الخطأ. ثم نستخدم تفاصيل الخطأ لإعادة بناء الجلسة في AS. يعني هذا أساسًا أنه عندما نحاول إجراء عملية قائمة انتظار للوصلة الهابطة ، باستخدام بيانات قديمة (ربما جلسة قديمة ، وربما تكون FCnt منخفضة جدًا) ، فإننا في النهاية نتقارب مع حالة NS. قد يستغرق الأمر محاولة واحدة أو اثنتين أو ثلاث محاولات ، وسأجعلها مقيدة لتجنب الدوران اللامتناهي ، لكننا على الأقل نعمل بمعلومات أحدث بشكل ملحوظ من تلك الموجودة في قائمة انتظار رسائل الارتباط الصاعد.

أعتقد أن هذا هو الخيار الأفضل.