الخلاصة

  • أعادت RFC 891 استخدام تبادل HELLO لقياس زمن الذهاب والعودة واختيار الطريق وحمل انحراف الساعة المرتبط به، مع شروط قبول مستقلة لكل نتيجة.
  • كان الطريق الأقل تأخيراً ناقلاً لمعلومة الوقت لا ناخباً للساعة المرجعية؛ فقد حدد الإعداد CLOCK-HID هوية المرجع.
  • سمح اختلاف طول رسالتي الإرسال والاستقبال بتحديث الطريق من دون الانحراف، كما أمكن لقفزة كبيرة في الساعة أن تبطل الطوابع الزمنية مؤقتاً.

لا تبدأ مسألة الوقت في RFC 891 بسؤال «كم الساعة؟»، بل بسؤال «ماذا يمكن أن أثبت من رحلة ذهاب وعودة قبل أن تتفق الساعتان؟». هذا الترتيب هو ما أتاح للتوجيه أن يبدأ، ثم أتاح لمعلومة التوقيت أن تسافر معه من دون افتراض حل المشكلة سلفاً.

صُمم النظام لشبكات DCN المحلية الصغيرة، بحد أقصى 256 مضيفاً وبوابة، وغالباً على أجهزة PDP-11 وLSI-11 المسماة Fuzzballs. ربطت بينها وصلات نقطة إلى نقطة ومتعددة النقاط. حمل كل مضيف وظائف تحويل الرزم والعبور والخدمة، ولم توجد قيادة توجيه محلية منفصلة.

احتفظت Host Table لكل وجهة بعملية الخروج، وتأخير الذهاب والعودة، وانحراف الساعة، ووقت آخر تحديث، وعدّاد للحياة. وكان للمضيف المادي أن يضم مضيفين افتراضيين عدة. أما Net Table للشبكات الأجنبية فبقيت منفصلة وتحت سلطة الإعداد عادة، باستثناء تحديثات عمليات GGP أو EGP.

بدأت القياسات من تبادل لا يحتاج إلى اتفاق الساعتين

استخدمت رسائل HELLO داخل الشبكة نفسها رقم بروتوكول IP‏ 63 وحملت حقول التأخير والانحراف. وما زال سجل IANA لأرقام البروتوكولات يسجل 63 بعبارة “any local network”. إنه سجل تخصيص، لا تعداد لانتشار DCN اليوم.

جمع حساب الرحلة حالة من رسالة مستقبلة بالرسالة التالية التي يرسلها المضيف. أوضحت الوثيقة أن الطريقة لا تتطلب تساوي الساعات ولا فواصل إرسال ثابتة، وأن ضياع HELLO أو انعكاسها لا يهدم المبدأ.

لكن صلاحية التنسيق والمجموع الاختباري لم تكن تصريحاً عاماً باستخدام كل قيمة. احتاج الحساب الدقيق للانحراف إلى تساوي طول آخر HELLO مرسلة وآخر HELLO مستقبلة. إن اختلف الطولان جاز تغيير الطريق مع إبقاء الانحراف القديم.

هنا يظهر الفصل العملي: وصلت الرسالة نفسها إلى حلقتين محليتين، ولكل حلقة حق مختلف في الرفض.

أجاب التأخير عن الطريق ولم يجب عن صاحب السلطة

أضاف المستقبل تأخير الرحلة إلى الجار إلى التأخير الذي يعلنه ذلك الجار للوجهة. ولم يبدّل المخرج إلا إذا تفوق المسار الجديد على الحالي بهامش مضبوط. تذكر العينة قرابة 100 ملي ثانية عتبةً، و120 ثانية للاحتفاظ، و30 ثانية حداً لمسار. هذه قيم تنفيذية تاريخية وليست ثوابت عامة.

عند قبول المسار خُزن معه الانحراف القادم عبره. لذلك حمل المسار المقبول المعلومة الزمنية. إلا أن الساعة المرجعية لم تنتج عن سباق التأخير؛ عرّفها CLOCK-HID بوصفه رقم مضيف مضبوطاً مسبقاً.

قد يكون جار آخر أسرع، فيفيد التوجيه ولا يملك سلطة ضبط الساعة. وحتى انحراف المضيف الذي يطابق CLOCK-HID احتاج إلى تاريخ صالح وإلى قرار من إجراء الساعة المحلية. فصل التصميم بين الوصول والهوية والأثر.

بقي رابط المصدر جزءاً من معنى المسار

إذا أعاد مضيف إعلان طريق عبر الرابط نفسه الذي تعلمه منه، أمكن أن تنشأ حلقة تعتمد على نفسها. استبدلت RFC 891 القيمة بـ MAXDELAY في ذلك الاتجاه. تقدم RFC 2453 لاحقاً مفردات المقارنة: split horizon وpoisoned reverse والتحديث المحفز والعد إلى اللانهاية.

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

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

قفزة الساعة كانت توقف أداة القياس

ميزت الوثيقة بين الساعة الفيزيائية والظاهرة والفعلية. عولجت الفروق الصغيرة تدريجياً بنقل جزء من CLK.DELTA، واقترحت المعلمات إبقاء معدل التعديل دون نحو ملي ثانيتين في الثانية.

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

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

سبقت ذلك خدمة DCNET في RFC 778، إذ استخدمت طوابع ICMP وGGP لحساب زمن الاتجاه الواحد والرحلة. دمجت RFC 891 القياس في حالة موزعة متجددة تخدم التوجيه أيضاً.

أثّر Hellospeak في NTP من دون أن يكون NTP

سمت RFC 1059 بروتوكول Fuzzball باسم “Hellospeak”، وذكرت صراحة أن دمج الوقت في التوجيه أثّر بقوة في NTP، كما قالت إنه غير مناسب خارج بيئته المحلية.

وضعت RFC 958 اقتراح NTP الأول فوق UDP وحددت الهرمية وتمثيل الرسائل، لكنها لم تحدد خوارزميات المزامنة والترشيح ولا اكتشاف الأقران ولا المصادقة. ثم وصفت RFC 1305 ترشيح خوادم متعددة واختيارها وحدود الخطأ وساعة منطقية مستمدة من عمل Fuzzball.

إذن التأثير موثق، أما التطابق فغير صحيح. نقل NTP الوقت إلى سطح مخصص للترشيح والاختيار على نطاق لم يدّع نظام DCN المحلي أنه يصلح له.

المصادر والحدود

تعتمد المقالة على RFC 778 وRFC 891 وRFC 958 وRFC 1059 وRFC 1305 وRFC 2453 وسجل IANA. لا تثبت هذه المصادر انتشار DCN حالياً، أو وحدة المعلمات في كل Fuzzball، أو مصادقة المرجع، أو تماثل التأخير، أو نسباً مباشراً إلى RIP، أو أن أقل زمن رحلة يساوي دائماً أقل خطأ زمني.