الخلاصة

  • ميّز RFC 849 بين أحدث ملف رئيسي لدى NIC وبين النسخ المحلية التي كانت المواقع تستخدمها فعلياً لحل الأسماء.
  • أعطى التصميم المفضل مسار السرعة لدفع واحد، ومسار التعافي لفحص رخيص للنسخة عند الإقلاع ثم لاستطلاع دوري احتياطي.

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

لا يلزم أن يكون الملف الرئيسي مخطئاً. فالخلل يقع بين النشر والاستخدام.

هذه هي المسافة التي صاغها Mark Crispin في مايو/أيار 1983 في RFC 849، وعنوانه Suggestions for Improved Host Table Distribution. شدد النص منذ بدايته على أن الحلول المقترحة لم تكن معايير. كانت الوثيقة طلباً فعلياً للتعليقات، على أمل أن يقود توافق لاحق إلى معيار. لذلك لا تصلح دليلاً على أن البروتوكول نُشر أو اعتُمد. لكنها تصلح دليلاً ممتازاً على أن كلمة «محدّث» كانت تخفي سلسلة من الحالات المستقلة.

المصدر الواحد لم يصنع حالة تشغيل واحدة

وصف RFC 608 ترتيباً مبكراً يحتفظ فيه NIC بملف مصدر، ويولد منه دورياً ملفاً نصياً بأسماء المضيفين وعناوينهم وخصائصهم. اقترح التشغيل أسبوعياً أو كلما استدعت الحال، وأتاح الناتج <NETINFO>HOSTS.TXT عبر FTP.

وحّد ذلك جهة إصدار الملف، لكنه لم يوحّد توقيت وصوله إلى كل مستخدم.

في 1982، حدّث RFC 810 الصيغة لتشمل شبكات وبوابات ومضيفين وأنظمة تشغيل وبعض معلومات البروتوكولات. أمكن جلب الجدول من SRI-NIC عبر FTP المجهول أو الحصول عليه من Host Name Server. وفي الوقت نفسه حمّل المستخدم مسؤولية تحويل الجدول إلى الصيغة التي يحتاجها محلياً.

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

أضاف RFC 811 خدمة حية على منفذ TCP رقم 101. يبحث HNAME بالاسم، وHADDR بالعنوان، بينما يعيد ALL الجدول كاملاً بين BEGIN وEND. جعل ذلك الوصول إلى بيانات NIC أسهل، لكنه لم يوفر جواباً قليل الكلفة عن سؤال محلي: هل النسخة المثبتة لدي هي أحدث نسخة؟

من دون هوية للنسخة، يصبح الصمت ملتبساً

شرح Crispin أن المواقع احتفظت بنسخ محلية لأن SRI-NIC لم يكن موثوقاً بما يكفي ليكون خدمة الأسماء الوحيدة المتاحة في كل وقت. كان NIC يقدم تفريغاً كاملاً للسجل وFTP مجهولاً، لكن أحداً ظل محتاجاً إلى معرفة أن إصداراً جديداً موجود. وذكر أن الإعلان عن تحديثات السجل لم يكن دائماً دقيقاً.

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

اقترح RFC 849 بروتوكولاً يبلغ عن «version» الحالية لجدول المضيفين. وفي أنظمة Tenex وTOPS-20 كان رقم جيل الملف مناسباً بطبيعته. كان Crispin يحتفظ أصلاً بملف SYSTEM:HOSTS.TXT يحمل الجيل نفسه الموجود لدى NIC، ثم يفحص أحياناً ما إذا كان الرقم البعيد قد تغير. أراد جعل المقارنة آلية.

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

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

سرعة الدفع حمّلت المركز ذاكرة الغياب

ذهب الاقتراح الأول في الاتجاه الآخر. ينشئ كل موقع متعاون عملية خادم تستمع على منفذ مسجل، وتتلقى التحديثات من مواقع محددة وموثوق بها، وبالأساس SRI-NIC. إذا كان المضيف المستلم يعمل، يصل التحديث بصورة شبه فورية.

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

اقترح النص أيضاً checksum للتأكد من أن سجل الأسماء المحدّث وصل كاملاً وسليماً. ينبغي إبقاء هذه الدعوى في حدودها. لم يحدد RFC 849 توثيقاً تشفيرياً لهوية المصدر، ولم يدّع مقاومة الاستبدال العدائي، ولم يبرهن صحة معنى كل سجل. سلامة النقل، وهوية الناشر، وصحة المحتوى، ونجاح التفعيل أدلة منفصلة.

البريد نقل الملف ولم يُكمل التحول

كان الاقتراح الثالث إرسال الجدول بالبريد إلى قائمة مستلمين، على أن يضع كل موقع إجراءه الخاص. هو أبسط بالنسبة إلى NIC، لكن RFC 849 رأى البريد أداة سيئة لشحن ملف متنامٍ بالجملة إلى عدد كبير من المستلمين.

كما أن قبول الرسالة لا يعني تشغيل الجدول. تظل قائمة انتظار وصندوق بريد واستخراج وتحويل وتفعيل. يستطيع نظام البريد أن يسجل «تم التسليم» فيما تواصل خدمة الأسماء المحلية استخدام النسخة السابقة.

جعل الاقتراح الرابع عودة الجهاز لحظة تعافٍ

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

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

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

لم يَعِد التصميم بتقارب فوري. قد يكون NIC غير متاح وقت الإقلاع، وقد ينقطع النقل أو يفشل checksum أو يتعطل التحويل أو تبقى النسخة القديمة نشطة. ميزته أنه لا يذيب تلك الاحتمالات في عبارة واحدة مثل «تم تحديث HOSTS.TXT». لكل إخفاق حد مرئي وخطوة تالية.

التوزيع لم يلغ زمن الحداثة

في نوفمبر/تشرين الثاني 1983، ذكر RFC 881 أن معظم مضيفي Internet كانوا يستخدمون شكلاً من جدول يعتمد على الملف الرئيسي HOSTS.TXT لدى NIC. وخطط لفترة تتعايش فيها الجداول مع أسماء النطاقات.

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

لا يعني ذلك أن RFC 849 كان مخططاً أولياً نُفذ في DNS. اقتراحاته لم تكن معياراً، وكانت وثائق النطاقات تعالج تفويض السلطة والاستعلام والصيانة على نطاق أوسع. الاستمرار المؤكد مفهومي فقط: حيث توجد نسخ توجد نسخة زمنية وعمر وقاعدة تجديد ومسار للتعامل مع فشل التجديد.

الحالة الحقيقية هي آخر انتقال اكتمل

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

ترك RFC 849 لذلك سلّماً للأدلة: إصدار المصدر، محاولة الإشعار، البايتات المستلمة، سلامة النقل المقبولة، التحويل المكتمل، الحالة النشطة المرصودة، ومسار التعافي. كل درجة تحمل دعوى مختلفة.

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

المصادر