إشعار واحد للجميع، والخادم يحصي المستمعين بالقرعة

Summary

• تقترح مسودة إشعارات CoAP متعددة الوجهات، المراجعة 17، بتاريخ 2 نوفمبر 2026، إشعاراً واحداً لعملاء يراقبون المورد نفسه. وهي ما زالت مسودة عمل لدى IETF.
• تدعو Feedback-Divider جزءاً عشوائياً من العملاء المهتمين إلى الرد. احتمال رد كل منهم 1 / 2^Q؛ ويتلقى الخادم R تأكيدات ويحسب المؤشر E = R × 2^Q.
• في مثال الوثيقة يبدأ التقدير عند 32 مراقباً، بينما ينشط 18 فعلياً. يختار خمسة الرد، وتضيع رسالة واحدة. تصل أربع رسائل، فيصبح المؤشر 16 والتقدير الجديد 16 وفق معامل التخفيف المستخدم في المثال.

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

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

جواب من عيّنة بدلاً من كشف حضور

تشرح الفقرة الثامنة من المراجعة 17 كيف يطلب الخادم التغذية الراجعة من غير أن يغرق نفسه بردود الجميع. يضع خيار Feedback-Divider وقيمة Q في الإشعار. يختار كل عميل متوافق يريد الاستمرار رقماً صحيحاً عشوائياً من الصفر إلى أقل من 2^Q. من يحصل على الصفر فقط يرسل إعادة تسجيل Observe فردية بعد انتظار عشوائي. بقية العملاء قد يظلون نشطين، لكنهم لا يردون.

يسمي الخادم التأكيدات الصحيحة التي وصلت R ويضربها في 2^Q ليحصل على E. إذا طُلب الرد من ربع الجمهور تقريباً ووصلت أربع إجابات، فالنتيجة المقترحة 16. لا توجد ستة عشر إيصالاً مستقلاً. الاختيار العشوائي يتقلب وقد تضيع ردود في الطريق. تقر المسودة بأن فقدان الحزم يحرّف التقدير. ثمن توفير الرسائل هو تحويل الجمهور من قائمة أشخاص إلى رقم مستنتج.

قد ينضم عملاء جدد أثناء الجولة. تنطلق المسودة من قيمة العدّاد الحالية COUNT'، وتقارن E بالتقدير القديم N، ثم تضبط العدد بواسطة (E − N) / D حيث D عدد صحيح موجب يخفف التغيّر. يجب أن يكون التحديث ذرياً بالنسبة إلى تسجيلات جديدة؛ فلا تُسقط عيّنة قديمة عميلاً دخل لتوّه. هذه قاعدة لصحة سجل الخادم، لا إثباتاً لوصول إشعار محدد إلى جهاز بعينه.

في الحساب الذي وضعه المؤلفون، يعتقد الخادم أن 32 عميلاً نشطون ويختار Q=2، أي احتمال رد يبلغ الربع لكل واحد. العدد الفعلي هو 18. يصيب الاختيار خمسة، لكن جواباً يضيع، فتصل أربعة أجوبة. يعطي ذلك E=16، ومع D=1 ينخفض العداد من 32 إلى 16 وتستمر المراقبة الجماعية. يعرف قارئ المثال الرقم الحقيقي 18 لأن المؤلفين كشفوه. الخادم التشغيلي لا يرى سوى ما وصل إليه.

انخفاض الكلفة يترك قرار العتبة للمشغّل

إذا صار Q=0 دُعي كل عميل نشط إلى التأكيد، فارتفعت حركة الرد وبقي احتمال الضياع. يقلل السؤال المتباعد الحركة لكنه يجعل العدد أقدم. ويبطئ معامل تخفيف أكبر التعديل. تحدد سياسة التطبيق موعد السؤال التالي والعدد الذي عنده تنتهي المراقبة الجماعية. الإنهاء المبكر يترك مهتمين من دون القناة المشتركة، والإبقاء على مجموعة فارغة يهدر الموارد. البروتوكول يعطي أداة حساب، أما العتبة فيملكها المشغّل.

يحدد RFC 7252 أسس رسائل CoAP التي تستند إليها المسودة. الجديد هو كلفة توزيع تحديثات Observe. العدّاد يقدّر استمرار الاهتمام ولا يسجل استلام كل جهاز أو معالجته أو تنفيذه لإشعار محدد. يمكن لتطبيق يعرض درجة حرارة أن يختار طريقة النقل اعتماداً على جمهور تقريبي. أمر موجّه إلى جهاز معين يحتاج رداً من ذلك الجهاز.

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

مسودة CoAP متعددة الوجهات · سجل Datatracker · RFC 7641 · RFC 7252