الخلاصة

  • استبدل Demand RIP البث الدوري على شبكات X.25 وISDN بتبادلات تُطلقها التغييرات وتُؤكَّد بالاستلام، فأمكن إغلاق الدوائر الخاملة. وأصبحت المسارات المتعلَّمة من الاستجابات المُطلقة دائمة عادة، فلا تنتهي لمجرد استمرار الصمت.
  • إذا فشل إنشاء دائرة فعلية، استطاع مدير الدائرة إبلاغ تطبيق التوجيه بأن القفزة التالية غير قابلة للوصول، فتبدأ الشيخوخة وفترة الحجز ثم الحذف. أما الإقرار فيثبت وصول تحديث أو جزء منه، لا صحة المسار ولا نجاح حركة المستخدم.
  • لم يسجل RFC 1581 سوى تنفيذ مكتمل واحد اختُبر مع نفسه على X.25 وISDN. ويفصل RFC 1264 بوضوح بين هذا الدليل التنفيذي وبين قابلية التشغيل البيني المستقلة بين مورّدين متعددين.

نبضة تكلف أكثر مما تبدو

صدر RFC 1582 في فبراير 1994 وفق سجله الرسمي. كانت شبكات البيانات العامة الموجّهة بالاتصال تتيح فتح دائرة افتراضية عند ظهور الحركة وإخلاءها حين تهدأ. وقد تكون جلسة المستخدم قصيرة ومتباعدة، لكن RIP التقليدي يكرر جدول التوجيه كل فترة حتى حين لا يتغير شيء.

على شبكة محلية، قد تعني كلمة «بث» إرسالًا واحدًا على وسط مشترك. أما على شبكة واسعة بلا مرفق بث، فكانت تعني طابورًا من الرسائل المنفصلة إلى كل وجهة معروفة. وضع RFC 1582 حسابًا مباشرًا: يمكن لعدد N من الموجّهات أن ينتج N × (N - 1) تحديثًا في كل دورة عبر N × (N - 1) / 2 اتصالًا. وقد يكون عدد القنوات الفعلية أقل من عدد الجيران؛ ومثاله واجهة ISDN أساسية لا تدعم سوى مكالمتين متزامنتين.

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

صار الصمت استمرارًا لآخر حالة، لا قياسًا جديدًا

RFC 1581 تحليل Informational مرافق، كما يوضح سجل RFC Editor. لخص المقايضة: لا بث دوريًا على دائرة الطلب؛ يُعاد إرسال التحديث حتى يصل الإقرار؛ والمعلومة المستلمة لا تنتهي في السياق العادي.

فصل RFC 1582 بين نوعين من السجلات. المسار المتعلَّم من استجابة دورية على LAN مؤقت، ويشيخ إن لم يتجدد. أما المسار المتعلَّم من استجابة مُطلقة على WAN فـ«دائم» عادة، ولا ينتهي بسبب غياب رسالة دورية لم يعد التصميم يرسلها أصلًا.

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

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

منح مدير الدائرة صوتًا داخل قرار التوجيه

وضع RFC 1582 مدير الدائرة بين طبقات IP وIPX وبين شبكة X.25 أو ISDN. يحتفظ بعلاقة بين عنوان القفزة التالية المنطقي والعنوان الفيزيائي اللازم للاتصال. إذا وصلت بيانات أو رسالة توجيه ولا توجد دائرة افتراضية، فتح واحدة؛ وإذا استمر الخمول أغلقها.

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

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

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

الإقرار يثبت التسليم ضمن حدوده

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

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

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

حتى قائمة النظراء لها حدودها. فهي تحدد مَن تُرسل إليه التحديثات وممّن تُقبل، ويجب طرح رسالة قادمة من خارج القائمة المناسبة. ويمكن لـRIP-2 إضافة مصادقة. غير أن إثبات هوية المتكلم وصلاحية حديثه لا يحول كل ادعاء توجيه إلى واقع مُشاهد.

انخفضت كلفة الخط وارتفعت كلفة الذاكرة

المسار الدائم لا يُصلح نفسه بالنسيان. طالب RFC 1582 بحفظ كل المسارات البديلة، أو حفظ مجموعة محدودة مع تسجيل أن بدائل أُسقطت وطلبها من جديد قبل ضياع الخيارات الباقية. المعلومة التي كان التحديث الدوري يعيد بناءها صارت دينًا في الذاكرة أو طلبًا صريحًا لاحقًا.

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

كما كشف RFC 1582 مشكلة استقلال الأعمار البرمجية. في التنفيذ الموصوف كان مدير الدائرة وتطبيق التوجيه مرتبطين كأنهما برنامج واحد. وفي Unix قد يكون الأول داخل النواة والثاني عملية منفصلة، أو قد يعيش المدير على بطاقة مستقلة. إذا أمكن لأحدهما التوقف والعودة دون الآخر، وجب keepalive وإعادة مزامنة جداول الحالة. حياة مكوّن لا تثبت أن الآخر يعيش في العصر نفسه.

تنفيذ واحد، ودليل واحد بالحجم الصحيح

ذكر RFC 1581 أنه لم يكن يُعتقد بوجود أكثر من تنفيذ مكتمل واحد. دعم تنفيذ Spider Systems ‏IP RIP-1 وIPX RIP وIPX SAP، ولم يكن يدعم RIP-2 حينها. اختُبر مع نفسه على X.25 وISDN، وعمل إلى جانب تطبيقات RIP عادية على Ethernet LAN. وكان تنفيذان مخصصان لـNovell قيد التطوير.

هذا أكثر من مواصفة ورقية: ثمة كود عامل وتجربة على وسيطين واسعين. لكنه أقل من اختبار ميزة WAN بين تنفيذين مستقلين. لا يثبت أن مورّدًا ثانيًا فسّر الأجزاء والمؤقتات وإعادة التشغيل وإشارات up/down بالطريقة نفسها.

RFC 1264 وسجله وضعا معيارًا مناسبًا: بروتوكول التوجيه خوارزمية موزعة وفورية، ونجاح تنفيذ واحد في بيئة واحدة لا يضمن النجاح في بيئة أخرى ومع مورّدين متعددين. وجود تنفيذات مستقلة واختبار كل الميزات ووسائل الأمن أدلة منفصلة.

لا ينبغي رفع «نُفّذ» إلى «تَشغّل بين المورّدين»، ولا إنزال الاختبار الذاتي إلى الصفر. القيمة التاريخية في إبقاء كل إيصال ضمن نطاقه.

تغيرت طريقة إرسال التحديث وبقيت حدود الإثبات

جاء RFC 2091 في يناير 1997، كما يبين سجله الرسمي. وصف مزايا كفاءة مقارنة بتصميم RFC 1582: بعد التبادل الكامل تُرسل التغييرات وحدها، فتقل الحركة والذاكرة، ويزول حد 255 جزءًا لأن الآلية الجديدة لا تستخدم تجزئة التصميم السابق.

لكن المقايضة الأساسية بقيت. المسارات المتعلَّمة من استجابات WAN ما زالت دائمة عادة. ومدير الدائرة ما زال يبلغ down وup. والتحديثات ما زالت تحتاج إقرارًا وإعادة إرسال. وقد يؤدي استمرار غياب الإقرار إلى إعلان القفزة غير قابلة للوصول. وعند الاستعادة أو التشغيل من جديد يلزم flush وتبادل كامل.

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

المصادر