الخلاصة

  • يعرّف RFC 9508 ثلاثة أسباب مختلفة لـ Echo Reply: تطابق الاسم الإداري للموجّه، أو بادئة يخدمها تطبيق محلي، أو كائن مطابق داخل Content Store.
  • يمنع nonce بطول 64 بت تجميع طلبات التشخيص داخل PIT ويربط الرد بطلب واحد؛ أما قواعد الحداثة فتمنع إعادة استخدام رد قديم ولا تجعل الكائن نفسه حديثاً.
  • تربط التوقيعات اسم المستجيب بالمفتاح المقبول، لكن سلطة المنتج ومصدر الكائن والتسليم العادي ونتيجة القارئ تحتاج إيصالات مستقلة.

الاسم الواحد لا يحدد جهة واحدة

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

يسجل RFC 9508 سبب التوقف. يعني T_ECHO_RETURN_FORWARDER أن الاسم الأساسي طابق تماماً اسماً إدارياً للموجّه. ويعني T_ECHO_RETURN_APPLICATION أن Longest Name Prefix Match وجد face لتطبيق محلي. ويعني T_ECHO_RETURN_OBJECT أن الاسم طابق كائناً داخل Content Store لذلك الموجّه.

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

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

الـ nonce يعزل التجربة ولا يمنح المحتوى سلطة

يمكن تجميع Interests المتطابقة في Pending Interest Table. يفيد ذلك كفاءة الشبكة، لكنه يجعل طلباً لاحقاً يستفيد من حالة أنشأها طلب سابق، فتتغير دلالة RTT. يضيف RFC 9508 nonce بطول 64 بت إلى اسم التشخيص كي يصبح كل طلب متميزاً ويرتبط الرد به بدقة.

عند فحص Content Store يتجاهل الموجّه nonce واللاحقة الخاصة بـ ping ويبحث بالاسم الأساسي. المعاملة التشخيصية فريدة، أما الكائن فيحتفظ باسمه. لذا يثبت object reply أن طلباً مميزاً وجد نسخة للاسم الأساسي في هذه العقدة.

لا يثبت ذلك أصل النسخة. فللكائن منتج وتوقيع وإصدار وفترة حداثة وقاعدة ثقة. توقيع الموجّه يثبت أنه أبلغ عن hit، ولا يحوله إلى منتج المحتوى. يجب حفظ الاسم الأساسي وnonce ورمز الرد واسم المستجيب ومعرّف الكائن أو بصمته ونتيجة توقيع المنتج.

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

قد يكون الرد جديداً والكائن قديماً

يضع CCNx قيمة ExpiryTime صفراً في Echo Reply. ويستخدم NDN MustBeFresh في الطلب وFreshnessPeriod بقيمة واحد في الرد، فيصبح رد التشخيص stale سريعاً. الغرض ألا يعود رد قديم كأنه مشاهدة حالية.

هذه الحداثة تخص التصريح بوجود hit، لا عمر Content Object الذي سببه. قد يقول الموجّه الآن وبصدق إنه يحتفظ بـ X، بينما تكون نسخة X قد استبدلت في منطق الخدمة أو تغير مفتاح منتجها أو رفضها التطبيق.

أثناء تعطل المصدر قد يستمر cache في خدمة القراء. هذا نجاح للاستمرارية، لكنه ليس نجاحاً لفحص origin. يجب أن تحدد السياسة مسبقاً ما إذا كان object reply يغلق «وجود نسخة محلية»، وما إذا كان application reply يغلق «وجود ربط محلي»، وأي canary منفصل يثبت المصدر والتسليم.

كما أن الصمت لا يحدد السبب. No Route، وضياع الطلب أو الرد، والإسقاط بالسياسة، وفشل التوقيع، وخطأ mapping، وانتهاء المهلة تنتج نتائج مختلفة وتتطلب استجابات مختلفة.

التوقيع يصادق صاحب التصريح

يحمل رد CCNx اسم المرسل وتوقيعه، وتحمل NDN Data توقيع منتج الرد. يقترح سلوك العميل الإرشادي الحصول على مفتاح الموجّه والتحقق من الرسالة والاسم الموجود فيها.

يمنع ذلك هجوماً محدداً: يستطيع موجّه مخترق من دون التوقيع وضع اسم ضحية ودفع العميل إلى إرسال حركة إدارية لاحقاً إليها. يربط التوقيع الاسم بالمفتاح وفق قاعدة الثقة التي اختارها المتحقق.

لكن تبقى أسئلة السلطة. من فوّض المفتاح للاسم الإداري؟ هل trust schema ما زال سارياً؟ هل يملك التطبيق البادئة؟ من وقع الكائن المخزّن؟ هل تغير المفتاح أو أُلغي؟ الصحة الرياضية للتوقيع تخص العبارة الموقعة ولا تمنح تفويضاً شاملاً للمحتوى.

يحفظ السجل اسم المستجيب ومعرّف المفتاح أو بصمته وقاعدة الثقة ونتيجة التحقق والوقت ورمز الرد. عبارة «التوقيع صالح» من دون نوع المستجيب تظل ناقصة.

مسار التشخيص ليس تسليم المحتوى المعتاد

يرجع Echo Reply وفق الحالة العكسية التي أنشأتها PIT. ويمكن تحديث Path Label من RFC 9531 قفزة بعد قفزة وإعادة استخدامه لتوجيه pings لاحقة نحو فرع مشابه، أو حذفه لاستكشاف فروع أخرى. هذا يساعد التكرار ولا يرسم جميع الطرق.

يمتلك RFC 9507 آلية traceroute وHopLimit المتتابع وتعدد الطرق. سؤال RFC 9508 أضيق: أي نوع من الجهات أوقف هذا ping وأجاب؟ لا يجوز لسبب محلي أن يرث سلطة وصف المسار الكامل.

وقد تختلف Interest عادية: ربما تتجمع، ولا تحمل nonce ولا لاحقة ping، وتستخدم parameters أو strategy أخرى. إذا كانت المطالبة هي التسليم، يجب تنفيذ استرجاع عادي بعد ping والتحقق من اسم الكائن أو digest وتوقيع المنتج والإصدار وقبول التطبيق ونتيجة القارئ.

الأسماء المحلية تضيف عهدة mapping

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

الحصول على Link Object خارج النطاق. وتفترض إعادة الكتابة أن الحدود تعرف المنطقة المجاورة وتعرف أن بقية الاسم قابلة للتوجيه داخلياً. تعدد المناطق والبادئات يزيد الحالة المطلوبة.

ينبغي حفظ كائن أو قاعدة mapping والموقع والصلاحية والحدود والاسم قبل التحويل وبعده واستعادة الرد. نجاح رد واحد يثبت سلسلة واحدة، لا صحة كل البدائل.

المصادر