ألغى العميل المراقبة، لكن الخادم لم يسمع بذلك بعد

الخلاصة

• تمنح RFC 7641 العميل تدفقًا خفيفًا لأحدث تمثيل لمورد CoAP، مع تسليم بأفضل جهد واتساق نهائي، من دون ضمان رؤية كل حالة وسيطة.
• تحدد قيمة Observe ذات 24 بت وشرط 128 ثانية وMax-Age ما الذي يمكن اعتباره حديثًا؛ لكنها لا تنشئ طابورًا دائمًا أو سجلًا قابلًا لإعادة التشغيل.
• يتطلب التشغيل المسؤول دليلًا على آخر تمثيل مقبول وعلى التحديث والإلغاء، وسياسة صريحة للحالة المجهولة، وآلية تاريخ مستقلة حين تكون كل نقلة مهمة.

التسجيل يظهر في الاستجابة

يرسل العميل طلب GET وفيه Observe بقيمة صفر ورمز Token يختاره. إذا أعاد الخادم استجابة 2.xx تحمل Observe أيضًا، فقد أنشأ قيدًا للمراقب يرتبط بنقطة نهاية العميل والرمز. الإشعارات اللاحقة استجابات إضافية لذلك الطلب الواحد. وإذا لم يستطع الخادم الاحتفاظ بالقيد أو لم يرد ذلك، جاز أن يتعامل مع الطلب كـ GET عادي من دون Observe. يعرف العميل عندئذ أنه لن يتلقى التغييرات وعليه استخدام الاستطلاع.

تقلل هذه العلاقة الأسئلة المتكررة عن قيمة لم تتغير، فتحفظ البطارية والسعة وحالة الخادم. ويمكن للذاكرة الوسيطة والوكيل أن يشاركا فيها. لكن RFC 7641 تقول بوضوح إن Observe لا يقصد أن يحل محل شبكات النشر والاشتراك العامة.

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

الرقم يرتب الإشعارات ولا يعدّ الأحداث

يحمل كل إشعار ناجح الرمز نفسه وقيمة Observe. يستخدم الخادم أقل 24 بت من تسلسل متزايد حصرًا، ويقارن العميل القيم بحساب الأرقام التسلسلية كي يتعامل مع الالتفاف إلى الصفر على نحو صحيح.

إذا مضى أكثر من 128 ثانية منذ وصول أحدث إشعار مقبول، يمكن اعتبار الإشعار الجديد أحدث من دون الاعتماد على فرق التسلسل. يحد هذا الشرط غموض الحيز الصغير بعد صمت طويل. لكنه لا يحدد زمن الحدث الفيزيائي ولا عدد التغييرات المفقودة.

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

انتهاء Max-Age يعني أن المعرفة لم تعد كافية

يحدد Max-Age المدة المقبولة لاختلاف التمثيل المرصود عن الحالة الفعلية. بعد انقضائه لا يجوز للعميل أن يفترض أن التمثيل ما زال حاليًا. يستطيع التحديث أو إعادة التسجيل بالرمز نفسه.

لا يثبت الانقضاء أن المورد تغير، ولا أن حزمة ضاعت، ولا أن الخادم تعطل. الحالة الصحيحة هي «غير معروفة» إلى أن يصل دليل جديد. تحويلها آليًا إلى طبيعي أو صفر أو إلى آخر أمر معروف قرار مخاطر يتخذه مالك التطبيق، وليس حكمًا من RFC.

ولا يكمل الإقرار ACK التاريخ. يمكن للإشعار أن يكون تأكيديًا أو غير تأكيدي بصرف النظر عن نوع الطلب الأول. الإقرار يثبت وصول رسالة CoAP المحددة، لا إرسال كل الحالات السابقة أو حفظها.

للإلغاء مساران وكلاهما معرض للفقد

يمكن للعميل أن ينسى العلاقة ثم يرفض إشعارًا تأكيديًا ذا رمز غير معروف برسالة Reset. ويمكنه أن يرسل GET بالرمز نفسه وObserve بقيمة واحد لإلغاء التسجيل صراحة. إذا ضاع Reset أو طلب الإلغاء، قد يحتفظ الخادم بالقيد ويستمر في الإرسال.

ينظف الخادم المراقبين المهجورين تدريجيًا عبر الإشعارات التأكيدية وإعادة الإرسال والمهلات. إذا كان استمرار الإرسال يمس الخصوصية أو الطاقة أو سعة الخادم، فيجب أن تعرض الواجهة نتيجة الإلغاء وأن تنفذ إعادة محدودة.

الوكيل يملك حداثة محلية

يستطيع الوسيط جمع عدة عملاء في مراقبة واحدة إلى الخادم الأصلي ثم توزيع الإشعارات. كل قفزة تولد قيم Observe الخاصة بها، وتختار نوع الرسالة، وتحدد Max-Age بحسب تمثيلها المحلي. تقل الكلفة، لكن العميل يرى حاضر الوكيل لا تسلسل الأصل الخام.

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