الخلاصة

  • تربط المسودة draft-ietf-core-conditional-attributes-14 كل مراقبة مشروطة بعنوان URI الكامل؛ لذلك يجب أن يعيد طلب الإلغاء الشروط الأصلية نفسها، وإلا فلا توجد حجة بأن الإسقاط المقصود انتهى.
  • وحتى مع إلغاء صحيح، لا يثبت صمت التدفق بقاء المورد في حالة آمنة: الدعم، وأخذ العينات، وتقييم الشرط، وجدولة الإشعار، وعبور الوكيل، وإقرار الرسالة، وتنفيذ التطبيق إيصالات مستقلة.

المراقب الذي نسيته الواجهة

لنتخيل مستشعراً لحرارة غرفة معدات. بدأ المشغّل مراقبة /temperature?c.gt=30، ثم غيّر العتبة في لوحة التحكم إلى 35 درجة. الواجهة أزالت السطر القديم وأرسلت إلغاءً للعنوان الجديد. بدا كل شيء نظيفاً: لا إنذارات قديمة ولا أخطاء ظاهرة.

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

نُشرت المراجعة 14 من مسودة Conditional Query Parameters for CoAP Observe في 14 سبتمبر/أيلول 2026، وتنتهي في 18 مارس/آذار 2027. وهي مسودة نشطة لمجموعة عمل CoRE تستهدف مسار المعايير، لكن سجل المجموعة ما زال يذكر الحاجة إلى مراجعة بعد مسألة أثيرت في المراجعة الأخيرة. ليست RFC، ولا قياساً للتبنّي، ولا شهادة مطابقة لأي منتج.

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

المورد ليس هو الإسقاط

تحدد c.gt وc.lt عبور حد أعلى أو أدنى بالنسبة إلى آخر قيمة أُبلغ عنها. ويقيس c.st مقدار التغير، بينما يحول c.band الحدين إلى حالة داخل نطاق أو خارجه، ويراقب c.edge اتجاهاً معيناً للانتقال المنطقي. هذه ليست أسماء مختلفة للحقيقة الفيزيائية نفسها؛ إنها قواعد مختلفة لاختيار ما يدخل سجل الإشعارات.

إذا تجاوزت الحرارة حد c.gt ثم استمرت في الارتفاع، فالإشعار المعتاد يخص لحظة العبور، لا كل قيمة لاحقة فوق الحد. وقد تقع قفزة كاملة بين تقييمين فلا تدخل السلسلة التي رآها الخادم. وعندما تتحقق شروط عدة في آن واحد لا توجد بينها أولوية: يرسل الخادم إشعاراً واحداً ويحدّث قيمة ووقت آخر إشعار. لذلك لا يجوز تحويل عدد الرسائل إلى عدد الحوادث الفيزيائية.

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

قبول الطلب لا يكشف مقدار الدعم

العلامة if="core.conditional" في الاكتشاف عامة واختيارية. الإعلان عنها لا يثبت دعم كل معلمة، وعدم الإعلان عنها لا ينفي أن المورد يدعم بعضها. ولا تقدم المسودة آلية اكتشاف دقيقة لكل شرط على حدة.

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

أما القيمة ذات النوع الخاطئ، أو المدة غير الموجبة، أو العلاقة المستحيلة بين حد أدنى وأقصى، فتقع في مسار 4.00 Bad Request. وهناك حالة ثالثة: يستطيع الخادم رفض تسجيل مراقب عندما تجعل قيم صغيرة جداً لـc.pmax أو c.epmax خطر تضخيم المرور غير مقبول. عندها يمكنه معالجة GET عادياً من دون خيار Observe. وجود رمز نجاح وحده لا يثبت قيام علاقة مراقبة؛ الخيار هو الإيصال الفاصل.

ثلاثة توقيتات تحت كلمة «صامت»

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

ويتحكم c.epmin وc.epmax في تقييم الشروط، لا في الإرسال. الأول يقول إن العميل لا يحتاج إلى تقييم أسرع، والثاني يحد أقصى مدة انتظار قبل التقييم التالي. كلاهما لا يثبت المراقبة المستمرة. يمكن للمورد أن يتجاوز الحد ثم يعود بين تقييمين، فلا يظهر العبور في أية عينة.

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

الوكيل وإقرار الرسالة لا يغلقان السلسلة

تعمل مراقبة CoAP عبر مخابئ ووكلاء، وهذه ميزة معمارية لكنها تضيف حد إثبات. تحذر المراجعة 14 من أن الوكيل قد يحجب تحديثات c.pmax عندما تظل التمثيلات متساوية، وتقترح Max-Age لا يتجاوز c.pmax للتخفيف. سجل الخادم الذي يقول «أُرسلت الرسالة» ليس إيصال وصول إلى العميل.

يطلب c.con=true إشعاراً مؤكداً، فيتاح إقرار وفق آلية موثوقية CoAP. لكن الإقرار يخص تبادل الرسالة. لا يثبت أن الوكيل عرض كل حالة، ولا أن التطبيق فهم الحمولة، ولا أن المشغّل شاهدها، ولا أن المشغّل أو المشغّل الآلي نفذ الإجراء المطلوب.

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

إيصال الإلغاء الذي يمكن الدفاع عنه

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

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

ثمانية إيصالات قبل قول «لا يوجد إنذار»

يتطلب الاستنتاج المهني سلسلة مترابطة:

  1. إيصال اكتشاف يحدد المورد والحقبة التي عُرفت فيها القدرة، إن أُعلن عنها أصلاً.
  2. إيصال تسجيل يحفظ URI والرمز المميز وخيار Observe وهوية الإسقاط.
  3. إيصال دعم يبين أي المعلمات فعّالة بدلاً من استنتاجها من علامة عامة.
  4. إيصال أخذ عينات وتقييم يحدد الدقة والقيم والأزمنة.
  5. إيصال تحقق يربط الحساب بالعتبة وبآخر قيمة أُبلغ عنها.
  6. إيصال جدولة يفسر c.pmin وc.pmax والدمج وأفضلية الجهد.
  7. إيصال تسليم يعبر الوكيل والمخبأ إلى العميل المقصود.
  8. إيصال تطبيق ونتيجة يثبت أن المعالجة والفعل والحالة النهائية حدثت.

أما إنهاء الإسقاط فيحتاج إيصالاً تاسعاً: إلغاء الهوية نفسها، لا مجرد عنوان قريب منها.

حدود ما تثبته المصادر

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

وفق تمييز Heng Lu بين السجل والسلطة، توفر المراقبة المشروطة سجلاً مفيداً لتنسيق العمل، لكنها لا تملك سلطة إعلان الحالة الفيزيائية أو النتيجة التشغيلية. السلطة العملية تأتي من ربط القرار بكامل سلسلة الإيصالات، بما فيها الإغلاق الصحيح للإسقاط القديم.

المصادر