الخلاصة

  • ميّز RFC 1498 أربعة أشياء يمكن تسميتها: الخدمات أو المستخدمين، والعقد، ونقاط الاتصال بالشبكة، والمسارات.
  • لا تحدد الطباعة نوع الشيء؛ وقد تمر عملية الوصول بثلاث روابط متغيرة من الخدمة إلى العقدة، ثم إلى نقطة الاتصال، ثم إلى المسار.
  • تعديل جدول تشغيل الخدمة يغير موضعها ولا يعيد تسميتها. كما أن العنوان لا يثبت الهوية أو السلطة أو الوصول أو التسليم.

فخ الحروف والأرقام

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

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

نُشرت ورقة Jerome Saltzer أول مرة سنة 1982، ثم أعيد نشرها في أغسطس 1993 بوصفها RFC معلوماتية، لا معيار إنترنت. وكانت حجتها أن الخلط لا يُحل بتفضيل كلمة «اسم» على «عنوان»، بل بتحديد الأشياء والروابط بينها.

أربعة أشياء قبل العنوان

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

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

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

ثلاث روابط، وكل واحدة قد تعطي قائمة

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

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

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

تغيير الصف لم يكن تغيير الاسم

تضع الورقة مثالاً لصف يقول إن Lockheed DIALOG Service يعمل على العقدة 5. داخل الجملة ثلاث علاقات. اسم DIALOG مرتبط على نحو طويل الأمد بخدمة محددة. والرمز 5 مرتبط بعقدة محددة. أما العلاقة الموضوعة في الجدول القابل للتعديل فهي تشغيل الخدمة الآن على تلك العقدة.

استبدال 5 بـ6 ينقل التشغيل. لا يمنح الخدمة اسماً جديداً ولا يغير هوية العقدتين. إعادة التسمية الحقيقية تحتاج إلى تعديل البرامج والوثائق والملاحظات والإعلانات، لأن رابطة الاسم بالشيء موزعة خارج هذا الجدول.

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

حين حملت 48 بت اسمين

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

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

وفي ARPANET NCP بدت أسماء مثل RADC-Multics أسماء عقد أو خدمات، بينما كانت أسماء نقاط اتصال. إذا انتقل الحاسوب إلى منفذ آخر لزم اسم ظاهر جديد أو تحديث جداول كثيرة. وقد تتوافر خدمة البريد على حاسوب بديل، لكن المستخدم يحتاج إلى ما يبدو اسماً آخر للخدمة لأن الاسم الأصلي توقف عند طبقة الاتصال.

المسار ليس إيصالاً

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

أكدت وثائق لاحقة استمرار المشكلة من زوايا أخرى. أوصى RFC 1958 باستخدام الأسماء بدلاً من العناوين المثبتة في التطبيقات، ودافع عن الفصل المعياري. وفرّق RFC 2101 بين متطلبات المعرّف والمحدِّد المكاني، ووصف جمعهما في حقول IPv4 بأنه واقعة تاريخية عارضة. وسجل RFC 2956 مشكلات خلط هوية العقدة بموقع التسليم. هذه مقارنات لاحقة وليست إضافات إلى النص الأصلي.

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

ينبغي أن يحفظ الدليل الاسم ومجاله ونوع الشيء، ووقت الاستعلام، وكل البدائل، وحالة العقدة والاتصال، وسياسة الطريق، والاختيار، والـsocket، والجلسة، واستجابة التطبيق. علّمنا RFC 1498 أن السؤال الأول ليس كيف يبدو الاسم، بل أين يتوقف معناه.

المصادر