ثلاثون دقيقة للنسيان، لا وعدٌ بالتحويل

الخلاصة

• مدة الإعلان الافتراضية في RFC 1256 هي 1,800 ثانية: من دون إعلان يجددها، قد ينتظر المضيف هذه المدة قبل أن ينسى موجّهاً تعلّمه ديناميكياً؛ وهذا ليس وعداً بالتحويل خلال نصف ساعة.
• تنص RFC على أن وتيرة الإعلان الافتراضية، مرة كل 7.5 إلى 10 دقائق، لا تكفي لاكتشاف ثقب أسود عند القفزة الأولى قبل انتهاء جلسة النقل. أما اكتشاف البوابة المعطلة فهو وظيفة منفصلة للمضيف، تصفها RFC 1122.

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

في سبتمبر 1991، أتاحت RFC 1256 للمضيفين اكتشاف الموجّهات المجاورة من دون صيانة قائمة عناوين يدوياً أو الاعتماد على بروتوكول توجيه بعينه. كانت الموجّهات ترسل إعلانات ICMP، وكان المضيف يستطيع إرسال عدد محدود من طلبات الاكتشاف عند بدء الواجهة. جعلت الآلية وجود الموجّه أمراً معلناً؛ أما القرار الأهم فكان: كم يدوم أثر هذا الإعلان؟

اختيرت القيم الافتراضية لتكون قليلة الإزعاج. الحد الأقصى لفاصل الإعلان 600 ثانية، والحد الأدنى الافتراضي يساوي 75% منه، أي 450 ثانية. يختار الموجّه الفاصل التالي عشوائياً داخل هذا النطاق، فتصل الإعلانات عادة كل 7.5 إلى 10 دقائق من دون تزامن. أما مدة الصلاحية الافتراضية فتساوي ثلاثة أمثال الحد الأقصى: 1,800 ثانية، أي نصف ساعة.

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

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

اكتشاف وجود موجّه لا يثبت أنه يمرر الحزم الآن. يقول الإعلان إن عنواناً ما عُرض بوصفه موجّهاً مجاوراً، وإنه يظل صالحاً حتى حد معين ما لم يصل تحديث. لكنه لا يختبر ما إذا كانت الحزمة التالية إلى وجهة بعينها ستعبر ذلك الموجّه. ولا تعد RFC 1256 بروتوكول توجيه يختار أفضل مسار لكل وجهة. أما ICMP Redirect فيعالج سؤالاً آخر: هل يوجد مسار أول أفضل بعد إرسال الحزمة عبر موجّه؟

توضح RFC 1122 النصف الآخر من البنية: يجب على طبقة IP اكتشاف تعطل البوابة التالية واختيار بديل. وفي 1989، أقر النص بأن خوارزمية عامة مُرضية تماماً لم تكن قد ظهرت. ومنع فحص البوابة بالـ ping المستمر لأنه مكلف وضعيف التوسع. بدلاً من ذلك، يمكن للطبقات الأعلى والأدنى أن تقدم المشورة: إقرار TCP دليل إيجابي، بينما قد تكون إعادة الإرسال المتكررة أو إشارة طبقة الوصلة دليلاً سلبياً. لم يُصمم مؤقت RFC 1256 ليحل محل هذا التقدير.

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

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

المراجع هي RFC 1256 والفقرة 3.3.1.4 من RFC 1122. وهي تثبت القيم وحدود التصميم، لا زمن تعافي نظام تشغيل أو شبكة أو مستخدم بعينه من عطل حقيقي.