الخلاصة

  • RFC 1088، وهي STD 48، تغلف مخططات بيانات IP داخل مخططات NetBIOS وتحدد اسم المستقبِل IP.XX.XX.XX.XX حسابياً من عنوان IP.
  • يلغي ذلك استعلام عنوان مادي لهذا التعيين المحدد. ولا يثبت مساراً أو ملكية أو هوية أو قابلية وصول أو نجاح تطبيق، كما أنه لا يحاول دعم عناوين IP multicast.

قيمة RFC 1088 في ضيقها. فهي لا تقدم NetBIOS على أنه بديل عام للإنترنت، بل طريقة توافقية لنقل مخططات IP على شبكة NetBIOS باستخدام خدمة مخططات البيانات فقط. يحمل مخطط NetBIOS بيانات IP، ويُختار اسم NetBIOS للوجهة من كتابة عنوان IP وفق شكل مقرر سلفاً.

يمكن أن يكون اسم NetBIOS ستة عشر بايتاً. خصصت الوثيقة لتطبيقات IP البادئة IP. ثم أربعة بايتات من العنوان مكتوبة بالسادس عشري ASCII. ولأن الاسم ناتج من العنوان، تقول الوثيقة إنه لا يلزم نظام استعلام عنوان مادي مثل ARP. هذه جملة عن كيفية الحصول على الاسم في هذا الحامل، لا عن اختفاء كل مسائل الطبقة الدنيا.

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

تسجيل اسميْن ثم إبقاء الاستقبال قائماً

تفصيل التنفيذ في RFC مهم. عند البدء، يضيف المضيف إلى جدول أسماء NetBIOS اسمه الخاص IP.XX.XX.XX.XX واسم المجموعة IP.FF.FF.FF.FF. ثم يرسل طلب استقبال مخطط بيانات موجه إلى كل منهما. وإذا وصل مخطط إلى أحد الاسمين، تعالجه مكدسة البروتوكول ثم تعيد طلب الاستقبال. وعند إيقاف دعم IP، تلغي طلبات الاستقبال المعلقة وتحذف الاسمين.

هذا سجل حالة محلية: أضف، استقبل، أعد النشر، احذف. وليس آلية تكتشف مكان مضيف داخل طوبولوجيا مستترة. يوضح RFC 950 الفرق في حالة الشبكات الفرعية الشفافة: قد تضطر الجسور إلى اكتشاف LAN التي يوجد عليها المضيف، وبث الاستعلامات والاحتفاظ بذاكرات مؤقتة. RFC 1088 لا تدعي تلك المهمة. هي تعلن الاسم الذي ستستخدمه خدمة البيانات التي عرّفتها.

ولهذا لا يصح وصفها بأنها «استبدلت ARP». RFC 826 تعالج في سياق Ethernet تعيين عنوان بروتوكول إلى عنوان Ethernet. RFC 1088 تقول فقط إن عنوان IP، في اصطلاح NetBIOS هذا، ينتج الاسم الذي تحتاجه خدمة مخططات البيانات. زال استعلام واحد؛ لم تزل الطوبولوجيا أو قرار التوجيه أو عدم اليقين بشأن الاستجابة.

اسم بث وحدّ معلن للـ multicast

تمثل عناوين IP broadcast باسم مجموعة NetBIOS هو IP.FF.FF.FF.FF. ثم تقول RFC صراحة إنها لا تحاول إتاحة عناوين IP multicast باستخدام أسماء مجموعات NetBIOS. وجود اسم للبث لا يمنح دلالة عامة للمجموعات، وهذه العبارة تمنع قراءة معيار صغير كما لو كان قد نفذ قدرة لم ينفذها.

والحد الآخر هو الحجم. أقصى بيانات في مخطط NetBIOS هي 512 بايتاً، ولذلك يكون MTU لـ IP-over-NetBIOS 512 بايتاً. قد يلزم أن يعيد المضيفون المقابلون تجميع مخططات مجزأة. الاسم المشتق، والمخطط المرسل، والشظايا، ومخطط IP المعاد تجميعه حقائق منفصلة. لا يصح جمعها تحت «الوجهة مؤكدة» من دون إخفاء شروط التشغيل ذاتها.

أما العبارة عن الموجّه فهي شرطية أيضاً. إذا وُجد موجّه يستطيع تغليف IP في بروتوكولات وصل عادية وفي مخططات NetBIOS، أمكن لهؤلاء المضيفين الاتصال بالإنترنت الأوسع. تصف الجملة نتيجة قدرة موجّه من هذا النوع؛ لا تثبت أن موجهاً بعينه كان منشوراً، أو أن لعنوان محدد مساراً، أو أن الطرف الآخر قابل للوصول.

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

المصادر وحدود الإثبات

تثبت المصادر طريقة 1989، وشكل الاسم، وحالة الاستقبال، وحدود البث وmulticast وMTU، والفوارق مع IP وsubnetting وARP. ولا تثبت انتشاراً حالياً، أو إعداد مضيف بعينه، أو ملكية، أو هوية، أو تفويضاً، أو مساراً مرصوداً، أو تسليماً، أو نتيجة تطبيق.