Summary

  • تقترح مسودة CoRE للنشر والاشتراك، النسخة 22، المحدثة في 2 نوفمبر 2026، وسيطاً لعملاء CoAP الذين قد يغيبون عن الاتصال طويلاً. ينشر المرسل عبر PUT ويقرأ المشترك أحدث تمثيل للموضوع أو يراقبه. الوثيقة ما زالت قيد تقييم IESG.
  • تقصر الفقرة 3.3 الاسترجاع على أحدث تمثيل. قراءة التمثيلات السابقة وعدد النسخ التي يخزنها الوسيط مؤجلان إلى عمل لاحق.
  • وجود الموضوع وقبول المنشور ونجاح الاشتراك ووصول الإشعار أربعة أمور منفصلة. إذا غاب خيار Observe من الرد، لم يثبت الاشتراك حتى مع رمز نجاح.

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

في تصميم مجموعة CoRE، يستضيف الوسيط مجموعات من الموضوعات، ومورداً لضبط كل موضوع، ومورداً آخر لبياناته. يرسل الناشر PUT إلى عنوان مورد البيانات. ويرسل المشترك GET مع Observe: 0 ليتلقى التحديثات وفق RFC 7641. ويمكنه إرسال GET عادي لآخر قيمة. لا يلزم أن يشبه عنوان مورد البيانات عنوان مورد الضبط؛ تعرض خاصية topic-data العنوان الصحيح. هكذا يستطيع طرفان لا يظلان متصلين في الوقت نفسه تبادل أحدث الحالة.

الصمت له أكثر من سبب

عند إنشاء موضوع جديد ينشأ مورد البيانات قبل نشر أي تمثيل. تستخدم المسودة الرد المقترح 2.06 No Content لهذه الحالة. إن كان المورد غير موجود فالرد المعتاد 4.04 Not Found. وإن نشر محتوى، يرجع GET أحدث تمثيل. لوحة تحوّل الحالات الثلاث إلى عبارة «لا إنذار» تخفي الفرق بين موضوع فارغ وموضوع محذوف وموضوع له قراءة راهنة.

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

للاشتراك نفسه علامة مستقلة. يعيد GET مع Observe: 0 قيمة حاضرة غالباً في 2.05 Content حاملة خيار Observe. إذا لم ينشر شيء بعد، قد يؤكد 2.06 No Content مع Observe التسجيل، ثم تأتي أول قيمة في إشعار لاحق. لكن غياب Observe يعني أن التسجيل فشل، ولو حمل الرد رمز نجاح. عند بلوغ حد max-subscribers لا يضيف الوسيط الخيار. البرنامج الذي يقرأ الرمز وحده قد يعرض «مراقبة مستمرة» بينما خرج من قائمة المراقبين.

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

إيصال الوسيط ليس إيصال غرفة التحكم

يرد الوسيط على PUT ناجح عادةً بـ2.04 Changed وفق نموذج طلبات CoAP في RFC 7252. هذا إثبات لقبول التحديث عند الوسيط، لا لوصوله إلى جميع المشتركين ولا لفعل التطبيق. وإذا كثرت المنشورات بسرعة، يمكن للوسيط إرجاع 4.29 Too Many Requests مع Max-Age يحدد موعد إعادة المحاولة. سجل الحادث يحتاج المرفوض والمقبول معاً.

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

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

مسودة CoRE · RFC 7641 · RFC 7252