خادم الأسماء لا يوزّع مخططات البيانات الجماعية: RFC 1001 وRFC 1002

الخلاصة

• أسندت RFC 1001 وRFC 1002 تسجيل الأسماء واكتشافها إلى NetBIOS Name Server ‏(NBNS)، بينما أسندتا توزيع مخططات بيانات المجموعة إلى وظيفة منفصلة هي NetBIOS Datagram Distribution Server ‏(NBDD).
• في مسار العقد P وM، لا تعني الإجابة الإيجابية من NBDD سوى أنه أعلن استعداده للترحيل. تسمح المواصفة بتوزيع جزئي أو رفض الطلب، ولا تقدم للمرسل سجل استلام لكل عضو.

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

تصنف الوثيقتان العقد الطرفية إلى B وP وM. تعمل عقدة B ضمن نطاق بث؛ وتعتمد P على بنية نقطة إلى نقطة؛ وتجمع M بين بعض خصائصهما. في مسار P/M، يذهب مخطط البيانات الموجه إلى اسم فريد مباشرة إلى عنوان IP الذي جرى اكتشافه. أما اسم المجموعة أو اسم البث في NetBIOS فيدفع المرسل إلى إرسال المخطط إلى NBDD بأسلوب أحادي الوجهة (unicast)، الذي يفترض أن يرحله إلى العقد المرتبطة باسم الوجهة. ولا يفترض التصميم أن بث IP متاح عبر كل جزء من المسار.

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

يمكن لعقدة P أو M أن تسأل NBDD قبل الإرسال عما إذا كان سيوزع المخطط لاسم وجهة معين. تعني الإجابة الإيجابية أن الخادم أعلن أنه سيرحل البيانات. وإذا كانت الإجابة سلبية، يستطيع المرسل طلب قائمة مالكي الاسم من NBNS ثم إرسال نسخة إلى كل عنوان على حدة. والاستعلام اختياري؛ إذ تسمح RFC 1002 بالإرسال فوراً مع احتمال أن يهمل NBDD المخطط. هذه مسارات تحكم مختلفة وليست تأكيدين على تسليم مكتمل.

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

ويحتاج سياق البث المتعدد إلى صياغة دقيقة. تصف RFC 1001 بيئة لا يمكن فيها افتراض دعم البث أو البث المتعدد عبر الإنترنت في كل عقدة وشبكة، كما تعرض في ملحقها تصوراً للتكامل مع Internet Group Multicasting. لا يعني ذلك أن البث المتعدد لم يُقترح من قبل: فقد طرحت RFC 988، الصادرة في يوليو 1986، امتدادات للبث المتعدد بين مضيفي IP بمستويات دعم مختلفة. والاستنتاج الأضيق هو أن تصميم NetBIOS لم يستطع افتراض توافر خدمة بث متعدد شاملة.

تصف RFC 1001 وRFC 1002 نفسيهما بأنهما مقترحا معيار. وهما يوثقان تصميماً، لا انتشاراً في شبكة مسماة ولا سلوكاً موحداً للتطبيقات ولا استلام البرامج لكل مخطط بيانات. كما تُبقي RFC 1001 أنشطة عقد B خارج رؤية خوادم NBNS/NBDD المساندة، ولا تحدد هذه الخوادم جسوراً إليها. حدّدت الوثيقتان المسؤوليات بوضوح أكبر من إثبات نتيجة طرف إلى طرف.

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