الخلاصة

  • أرسلت Who-Provides? سؤالاً بالبث عندما كان عنوان المزود مجهولاً، لكنها طلبت الكلام من المطابقين فقط؛ لذلك لم يكن الصمت نفياً صريحاً.
  • ألزمت Do-You-Provide? المضيف المحدد بالرد ولو بقائمة فارغة، بينما بقي جواب They-Provide عن مضيف ثالث مجرد إشارة تحتاج عادة إلى تحقق مباشر.
  • بُني اسم المورد كمسار تفكيك متعدد الطبقات، فلا يعني دعم UDP أو منفذ معين دعم كل وظيفة متخصصة فوقهما.

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

لم يكن الابتكار مجرد بث السؤال. وزعت الوثيقة أنواعاً مختلفة من السلطة على أنواع مختلفة من الأجوبة: من يعلن عن نفسه، ومن ينفي عن نفسه، ومن يشير إلى غيره، ومن يؤكد الإشارة مباشرة.

وصف اسم المورد الطريق إلى معالجته

بدأ محدد المورد برقم أدنى بروتوكول Internet يُستخدم للوصول إليه، ثم طول المعرّف ومكوناته الخاصة. كانت المكونات هي القيم الطبيعية التي تفصل البروتوكولات في الطبقات الأعلى. في مثال DNS عبر UDP ظهر الرقم 17 ثم المنفذ 53.

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

كان الانتهاء الدقيق وحده تأكيداً كاملاً. قد يقدم المضيف TFTP ولا يقدم خدمة محددة لنقل تفريغ العطل فوق TFTP. دعم طبقة لا يملك حق اختراع دعم الطبقة التالية.

سأل البث الجميع لكنه استدعى الموافقين فقط

كانت Who-Provides? تُرسل عادة إلى عنوان بث. يجيب من يقدم مورداً واحداً على الأقل برسالة I-Provide، ويستطيع من لا يقدم شيئاً أن يظل صامتاً.

خفض ذلك عدد الأجوبة، لكنه جعل الفراغ ملتبساً. قد لا يوجد مزود، أو قد يضيع السؤال أو الجواب، أو قد تعمل الخدمة على مضيف لا ينفذ RLP. وصفت RFC 919 بث IP بأنه غير موثوق وغير مرتب وقابل للتكرار، وذكرت أن كل مضيف يسمع البث يدفع جزءاً من كلفة معالجته.

قلل السؤال العام الحاجة إلى قائمة عناوين مسبقة، لكنه استهلك انتباه الشبكة ولم ينتج إحصاءً سلبياً موثوقاً.

جعل السؤال الموجّه القائمة الفارغة نفياً قابلاً للنسبة

تذهب Do-You-Provide? إلى عنوان معلوم. كان على المستلم الرد حتى لو لم يقدم أي عنصر مطلوب. لذلك أصبحت I-Provide الفارغة نفياً صريحاً يخص ذلك المضيف وذلك الطلب.

منعت RFC 887 بث هذا النوع. لو أُلزم كل مستمع بإرسال نفي، لتحول سؤال واحد إلى سيل من الردود. فصل البروتوكول بين اقتصاد السؤال الجماعي ودقة السؤال الفردي: يتكلم الموافقون أمام الجميع، ويتكلم المخاطَب باسمه في الحالتين.

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

عرف المضيف الذكي عنواناً، لكنه لم يتكلم باسم صاحبه

سمحت Who-Anywhere-Provides? وDoes-Anyone-Provide? بسؤال مضيف معروف يملك معلومات عن مضيفين آخرين. نفع ذلك الشبكات التي لا تدعم البث، أو البوابات التي جمعت معرفة من شبكات مجاورة.

يحمل الرد اسم They-Provide. قالت الوثيقة بوضوح إن الطالب غير ملزم بالاعتماد على هذه المعلومة من دون فحص، وإن عليه غالباً أن يرسل Do-You-Provide? إلى العنوان المقترح.

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

لا تعني مخالفة S لذاكرة الوسيط أن أحدهما كاذب؛ ربما تقادمت المعلومة. حفظ مصدر كل ادعاء يجعل القِدم تفسيراً قابلاً للاختبار بدلاً من تناقض غامض.

قيدت علامة Local-Only العناوين بالشبكة المحلية للطالب، وفرضت على المضيف متعدد الواجهات اختيار عنوان المصدر المحلي المناسب. كان النطاق جزءاً من السؤال، لا مرشحاً تجميلياً بعد الجواب.

لم يتحول Message-ID إلى هوية

ساعد Message-ID المكوّن من 16 بت على ربط الرد بالطلب. لم يثبت هوية المرسل أو حقه أو حداثة قوله. ولم يكن checksum الخاص بـ UDP توقيعاً تشفيرياً.

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

أعادت بروتوكولات لاحقة توزيع الاسم والنطاق والثقة

المقارنة لا تثبت نسباً مباشراً. نظمت RFC 2608 ‏SLPv2 حول أنواع الخدمة وسماتها، وفصلت بين User Agent وService Agent وDirectory Agent والنطاقات الإدارية. كما عرّفت توثيق URL والسمات، مع التصريح بأنها لا توفر السرية.

مكّنت RFC 6762 عمليات شبيهة بـ DNS على الوصلة المحلية من دون خادم DNS أحادي تقليدي. واستخدمت RFC 6763 سجلات DNS لاكتشاف نسخ مسماة بحسب نوع الخدمة والنطاق. تغيرت البنية، ولم يصبح الإعلان والتأكيد والإذن والنتيجة حقيقة واحدة.

بقي المنفذ 39 في السجل ولم يثبت بقاء الخدمة

خصصت RFC 887 المنفذ 39 لـ UDP. وما زال سجل IANA لأسماء الخدمات وأرقام المنافذ يعرض rlp على المنفذ 39 لكل من TCP وUDP. هذا استمرار إداري، لا قياس لنشر البرمجيات.

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

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

يعتمد المقال على RFC 887 وRFC 919 وRFC 2608 وRFC 6762 وRFC 6763 وRFC 6335 وسجل IANA. لا تثبت هذه المصادر مدى انتشار RLP، ولا أنه أصل مباشر للأنظمة اللاحقة، ولا سلوك منتج أو شبكة حالية بعينها.