الخلاصة

  • استبدل DRAP وجود نظير DLSw في كل محطة بعدد كبير من العملاء الخفيفين وخادم واحد وعلاقة DLSw واحدة نحو الموقع المركزي.
  • كان الخادم يخصص عناوين MAC أو يخزنها، ويجيب عن استعلامات الوصول، ويتفاوض على القدرات، وينشئ معرفات الجلسات، ويحافظ على الدوائر أثناء تعليق TCP.
  • لم تثبت هذه الإشارات هوية الشخص أو التفويض أو أصالة المصدر أو التسليم من طرف إلى طرف؛ لم يحدد RFC 2106 آلية مصادقة، وكانت صفته Informational لا معيار إنترنت.

نقل الحالة بدلاً من مضاعفة الاتصالات

بدأ RFC 2106 من مشكلة توسع واضحة. إذا شغّلت كل محطة بعيدة DLSw كاملاً، زاد عدد جلسات TCP المتجهة إلى الموقع المركزي بزيادة عدد المحطات. وهكذا وصل بروتوكول صُمم للتبديل بين الأجهزة إلى كل جهاز مستخدم.

غيّر DRAP البنية الهرمية. أصبحت المحطات عملاء لخادم قريب، ولم يحتفظ بعلاقة نظير DLSw مع الموجّه المركزي سوى ذلك الخادم. أمكن لعدد كبير من اتصالات الحافة أن يشترك في علاقة واحدة مع العمود الفقري. لم يختف التعقيد؛ انتقل إلى بوابة تتذكر حالة العملاء وتتحدث باسمهم.

هذا هو الحد الذي يميز الموضوع عن المقالات المجاورة. عالج RFC 1434 رابطَي LLC محليين فوق نقل مشترك، وعرض RFC 2024 صفوف دليل DLSw وذاكرته المؤقتة ونقله ودوائره، وفصل RFC 2043 قبولين لـ SNA فوق PPP، وعالج RFC 2097 قبول أسماء NetBIOS. أما RFC 2106 فجعل الخادم ذاكرة تشغيلية وسلطة ناطقة لمحطات كثيرة.

عنوان MAC افتراضي ليس وثيقة هوية

قد تملك المحطة المتصلة عبر PPP عنوان IP ولا تملك عنوان MAC لشبكة محلية. كان خادم DRAP قادراً على تخصيص MAC افتراضي. وإذا قدم العميل عنواناً غير صفري، تحقق الخادم من عدم تكراره وخزنه. وللجلسات التي يبدأها الخادم، أمكن للعميل تسجيل MAC وIP مسبقاً.

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

وعند إعداد أكثر من خادم، أمكن للعميل إرسال الطلبات واختيار أول من يجيب. أثبت الرد الأول التوفر والزمن في تلك اللحظة، لا صحة السلطة الإدارية.

لكل انتقال دلالة محدودة

كان CAN_U_REACH يسأل عن الهدف، ويحمل I_CAN_REACH قول الخادم بشأن الوصول. طلب START_DL إنشاء محطة وصلة، وأعلن DL_STARTED إنشاءها. ميزت معرفات المصدر والمتلقي الدوائر. واتفق تبادل القدرات على MAC ودعم NetBIOS وقوائم SAP وإمكان انتظار اتصال TCP جديد.

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

استخدم RFC 2106 اتصال TCP ثنائي الاتجاه لكل زوج من العميل والخادم على المنفذ 1973. وكان ممكناً تعليق TCP مع إبقاء دوائر وصلة البيانات. وعند ظهور بيانات جديدة يعيد العميل الاتصال من دون تكرار تبادل القدرات. اختبرت keepalive الاختيارية استجابة النظير؛ وبعد ثلاثة إخفاقات أوصى النص بإغلاق TCP والدوائر.

لذلك لم تكن عبارة «متصل» حالة واحدة. قد يغيب المقبس وتبقى الدائرة المنطقية حية. وقد تثبت keepalive أن النظير يجيب، لا أن المعاملة وصلت إلى التطبيق النهائي.

وثيقة Informational لا إجماع معياري

نُشر RFC 2106 في فبراير 1997 بصفة Informational، ونص صراحة على أنه لا يحدد معياراً للإنترنت. لم يصف مصادقة ولم يتضمن قسماً لاعتبارات الأمن. كان وصفاً للوصول البعيد وانتقالات الحالة، لا بنية للهوية والتفويض.

جعل RFC 2114 الوثيقة قديمة في الشهر نفسه، وسمى النظام DCAP وأضاف خيارات للاكتشاف مع إبقاء جوهر العميل والخادم. يمكن لمنفذ مسجل أو تنفيذ متوافق أو رقم RFC أن يجعل النظام قابلاً للتشغيل. لا يثبت أي منها بمفرده إجماعاً معيارياً دائماً.

المصادر