الخلاصة

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

وصل الاسم إلى باب الإدارة

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

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

بنت RFC 830 نظام SINS على هذه الفكرة. ارتبط بكل نطاق منطقياً DNS، ولو نفذته عدة خوادم للتكرار. وارتبط بكل نطاق طرفي Application Interface Process، أو AIP، يوجد عادة مع DNS.

كان DNS يمثل النطاق أمام الشجرة. وكان AIP يمثل الحوار مع التطبيقات. لذلك لم يكن عنوان DNS الطرفي مرادفاً لعنوان البرنامج المطلوب. إنه المكان الذي يستطيع المصدر أن يسأل فيه السؤال الثاني.

حمل المصدر مسؤولية السير في الشجرة

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

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

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

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

لم يكن العنوان النهائي معروفاً بعد

بعد نجاح حل النطاق، حصل AIP المصدر على عنوان DNS/AIP في نطاق الوجهة. لكن الوصول إلى هذا العنوان لا يحدد دائماً عنوان التطبيق. قد توفر رابطة دائمة مثل منفذ TCP معروف الجواب. وقد تكون القدرات متغيرة بحيث يلزم الحوار.

أرسل AIP المصدر وصفاً للنقل والبروتوكول التطبيقي ونوع الخدمة. تستطيع الوجهة أن تعيد قبولاً مع عنوان، أو رفضاً، أو خدمة بديلة من النوع نفسه. في أمثلة TCP جمع العنوان عنوان IP ورقم البروتوكول والمنفذ.

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

غيّر التفاوض الأداة وأبقى الغرض

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

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

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

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

التفاوض الحي لم يكن تفويضاً

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

تتوقف سلطة كل طرف عند سؤاله. يفوض الأب الاسم. ينشر النطاق نقطة خدمته. يعلن AIP القدرة. تقرر سياسة التطبيق من يقبل. يسجل التنفيذ ما حدث فعلاً.

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

كانت الذاكرة محلية والحوار مشتركاً

وحدت SINS بنية الأوامر بين التطبيق وAIP، وبين AIP وDNS، وبين AIP وآخر. حملت العناصر اسماً أو خدمة أو عنواناً أو تعليقاً. صممت الرسائل القصيرة غالباً لتستخدم UDP تجنباً لكلفة اتصال TCP، وأعيد الطلب داخل الرد لدعم الوثوقية.

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

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

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

لم يحسم الانتقال من HOSTS.TXT مكان الذكاء

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

حل هذا الانتقال مشكلة النسخة العالمية، لكنه لم يفرض أن تكون القدرة تفاوضاً حياً أو بيانات مسجلة. اختارت RFC 882 وRFC 883 المسار الثاني.

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

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

لم يعد التطبيق المحلي يحتاج بروتوكول تفاوض شبكي عام مع AIP. تكفي دالة أو نداء نظام إلى resolver. انتقلت قابلية التشغيل البيني إلى الرسائل بين resolver والخوادم وإلى البيانات ذات الأنواع.

اختار DNS تصريحاً يمكن نسخه

وضعت RFC 1034 لاحقاً RFC 830 بين عدة مقترحات للأسماء الهرمية. ونسبت التصميم الذي تطور إلى DNS إلى قاعدة البيانات الموزعة والموارد العامة في RFC 882 وRFC 883. بقيت الشجرة وتغير الحد المشترك.

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

لكن سهولة الاستخدام تغري بتوسيع معنى الرد. يثبت الرد ذو السلطة ما نشرته المنطقة. ويثبت رد الذاكرة ما احتفظ به resolver ضمن زمنه. لا يثبت أيهما وحده أن العملية تعمل الآن أو أن العميل متوافق أو مأذون أو أن المعاملة نجحت.

لا تدعو قصة RFC 830 إلى إحياء SINS. إنها تكشف سؤالاً بقي بعد انتصار DNS: من يثبت القدرة بعد أن يدلنا الاسم على موضع السؤال؟ يجب أن يبقى جواب التشغيل مستقلاً عن جواب الدليل.

المصادر