الخلاصة

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

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

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

لم يشترط RFC 966 أن تحتوي المجموعة على أعضاء طوال الوقت. يمكن أن تضم صفراً من المضيفين، وأن ينضم المضيف الواحد إلى مجموعات عدة. واقترح مجموعات عابرة تنتهي حين يغادر آخر أعضائها، مع عمليات CreateGroup وJoinGroup وLeaveGroup لتغيير العضوية. بهذا يصبح العنوان الدائم علامة على وظيفة يمكن البحث عنها، لا قائمة مضمونة بالأجهزة المتصلة الآن.

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

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

حل RFC 988 محل المقترح سنة 1986، وصاغ الفرق بوضوح: الدائم في المجموعة الدائمة هو العنوان لا أعضاؤها. واحتفظ RFC 1112 سنة 1989 بالتمييز نفسه، مع تسليم بأفضل جهد لا يضمن وصول الرسالة سليمة إلى كل عضو ولا ترتيباً واحداً لها. يبين تسلسل الوثائق بقاء الفكرة الأساسية، ولا يثبت تنفيذ تفاصيل مقترح 1985 في كل شبكة.

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

المصادر وحدود الاستنتاج

المصادر الأولية هي RFC 966 وRFC 988 وRFC 1112، مع RFC 919 للمقارنة بالبث العام. لا تحدد هذه النصوص أول تشغيل فعلي أو نسبة الانتشار أو نتيجة خدمة بعينها.