الخلاصة

  • ألزم RFC 2097 النظام البعيد بطلب إضافة أسماء NetBIOS محددة إلى شبكة النظير. وقد تنجح أسماء في التفاوض نفسه بينما تتلقى أسماء أخرى أسباب فشل واضحة.
  • كشف NBFCP أيضاً فئة النظير وفترة البث المتعدد وأولويته، وشرط ترويسة IEEE MAC بطول اثني عشر ثُمانية.
  • بقيت حالة Opened وAdded=0 دليلاً محلياً، لا إثباتاً للتفرد العالمي أو الهوية أو التفويض أو الربط بين شبكتين محليتين أو التسليم الكامل أو الأمن.

قد تكون وصلة النفاذ البعيد حية كهربائياً، وقد ينتهي LCP ويدخل PPP مرحلة بروتوكولات طبقة الشبكة، فيما لا يزال الاسم الذي يعتمد عليه التطبيق بلا موضع على الشبكة البعيدة. جعل RFC 2097 هذه الفجوة قابلة للرصد.

نُشر PPP NetBIOS Frames Control Protocol في يناير 1997، وخصص 0x803f لحزم تحكم NBFCP و0x003f لمخططات بيانات NBF. وكان نطاقه الطوبولوجي ضيقاً: يستطيع نظام طرفي الاتصال بنظير أو بالشبكة المحلية التي يتصل بها النظير. لكنه لا يصلح لربط شبكتين محليتين بسبب قيود أسماء NetBIOS وآليات الدفاع عنها.

فتح الناقل وقبول الأسماء حدثان منفصلان

قسّم PPP العمل إلى مراحل. ينشئ LCP وصلة البيانات ويهيئها ويختبرها، وقد تأتي بعده المصادقة وقياس الجودة. لا يجوز تبادل NBFCP قبل مرحلة بروتوكولات الشبكة، ولا تُرسل مخططات NBF قبل بلوغ Opened.

ومع ذلك، فرض RFC 2097 على الأنظمة الطرفية تفاوض Name-Projection. يسرد الطالب أسماء NetBIOS ذات الستة عشر ثُمانية التي يريد من النظير إضافتها، ويبيّن إن كان كل اسم فريداً أم جماعياً. ولأن حقل Length ثُماني واحد، لا تستوعب خانة واحدة أكثر من أربعة عشر اسماً؛ وتحتاج المجموعة الأكبر إلى خانات متعددة.

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

ظل القبول الجزئي ظاهراً في القائمة كاملة

إذا تعذر على المستقبل إضافة كل الأسماء، وجب أن يعيد Configure-Nak بالقائمة الكاملة. يحمل الاسم المضاف Added=0، وتحمل الإخفاقات قيماً غير صفرية تميز بين تكرار في الجدول المحلي، وامتلاء الجدول، واسم مستخدم على NetBIOS البعيد، وتعارض مكتشف، واسم معرف في بيئة أخرى، ونفاد الموارد.

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

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

لذلك لا يثبت Added=0 إلا أن هذا النظير قال في ذلك التبادل إنه استطاع إضافة ذلك الاسم. ولا يثبت اتساق الرؤية بين المقاطع أو خوادم الأسماء أو الجسور. وقد أقر RFC 1001 بأن الأعطال قد تترك معلومات الأسماء غير متسقة.

فئة النظير المعلنة لم تكن مصادقة على هويته

أتاحت Peer-Information إرسال فئة التنفيذ، والإصدارين الرئيس والفرعي، واسم اختياري. وميزت الفئات الأولية بين بوابة NetBIOS على PPP، وخادم نفاذ محلي فقط، وجسر NBF، ونظام طرفي.

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

قد تخفي سياسة البث المتعدد خدمة قابلة للوصول

تحتاج بعض تطبيقات NetBIOS إلى البث المتعدد، بينما لا تحتاجه أخرى. لذلك تفاوض Multicast-Filtering على فترة قصوى للتمرير وبت للأولوية. تعني القيمة صفر تمرير كل الحزم؛ وتحدد القيمة العادية، حتى ستين ثانية، الحد الأعلى للتكرار؛ وتعبر 0xFFFF عن قيمة مجهولة أو غير موجودة بحسب موقعها في Request أو Nak. وتحدد الأولوية أيهما يسبق: البث المتعدد أم الحزم الموجهة.

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

غيرت اثنا عشر ثُمانية شكل الغلاف المقبول

ظهرت حزم NBF مع ترويسات 802.3 Ethernet و802.5 Token Ring وDIX Ethernet وFDDI. احتاجت بعض تطبيقات PPP إلى الترويسة كاملة للجسر، وبعضها إلى عناوين IEEE فقط، وبعض البوابات لم يحتج حقول MAC.

جسّد IEEE-MAC-Address-Required هذا الاعتماد. الافتراض عدم وجود ترويسة MAC. فإذا نجح التفاوض، وجب أن يبدأ كل مخطط NBF باثني عشر ثُمانية لعناوين الوجهة والمصدر. ولأن القرار يأتي بعد تفاوض LCP على MRU، كان على المستقبل قبول حزم NBF أكبر من MRU باثني عشر ثُمانية.

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

كانت Opened إذناً ضيقاً لا شهادة نتيجة

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

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

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

ويظهر الفرق مع RFC 1088 بوضوح. فقد اشتق RFC 1088 اسم NetBIOS آلياً من عنوان IPv4. أما RFC 2097 فلم ينشئ الاسم؛ بل حمل مجموعة اختارها النظير إلى نقطة قبول بعيدة وأعاد نتيجة لكل عنصر.

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

المصادر