الخلاصة

  • يفرض RFC 1542 إرسال كل رسائل BOOTREQUEST الصادرة عن عميل واحد إلى الوجهة نفسها أو إلى مجموعة الوجهات نفسها.
  • يشرح المعيار الخطر بمثال مرحّل يختار الخادم التالي بالتناوب، فتصل طلبات متتابعة من العميل ذاته إلى خوادم مختلفة.
  • يسمح الاختيار الثابت حسب هوية العميل بتوزيع الحمل بين الخوادم من دون تفريق رسائل العميل الواحد.

طلب الإقلاع لا يبقى دائماً على الشبكة المحلية

صُمم BOOTP لأجهزة قد تبدأ التشغيل من دون أن تعرف عنوان IP الخاص بها أو مكان الخادم الذي يزوّدها بمعلومات الإقلاع. وصف RFC 951 الصادر عام 1985 مرحلة أولى لتحديد العنوان واختيار ملف الإقلاع. يستطيع العميل بث BOOTREQUEST على شبكته المحلية، لكن البث المحدود لا يعبر إلى خادم موجود على شبكة أخرى بمجرد التوجيه العادي.

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

حاول RFC 1532 توضيح BOOTP في أكتوبر 1993. وفي الشهر نفسه صدر RFC 1542، محدّثاً RFC 951 وناسخاً RFC 1532 بعدما أُدخلت أخطاء تحريرية في الوثيقة الأسبق. ويذكر ملخصه أن عمل مرحلات BOOTP من المواضع التي احتاجت إلى توضيح وتقوية. أصبح قرار المرحّل بشأن الوجهة جزءاً من شروط تبادل الرسائل، لا مجرد تفصيل في جهاز توجيه.

وجهة ثابتة لكل عميل

ترك RFC 1542 مساحة للضبط المحلي. يجب أن تتوافر آلية لتفعيل الترحيل أو تعطيله، ويجب أن يكون معطلاً افتراضياً. وعلى المرحّل إسقاط الطلبات التي تتجاوز قيمة hops فيها 16، مع إتاحة حد أصغر قابل للضبط. إذا كان giaddr صفراً، يملؤه الوكيل بعنوان واجهة الاستقبال، ويزيد hops، ويحافظ على بقية حقول BOOTP. كما تُضبط الوجهة أو مجموعة الوجهات محلياً.

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

لم تكن المشكلة في وجود أكثر من خادم، بل في إعادة اختيار الخادم لكل حزمة رغم أن المحادثة قد تتكون من عدة طلبات وردود. يقول RFC 1542 إن هذا الأسلوب يتصرف على نحو سيئ مع DHCP وربما مع بدائل أخرى لـ BOOTP تعتمد على تبادلات متعددة. إذا استقبل خادم طلباً مبكراً ثم وصل الطلب التالي إلى خادم آخر، فقد يتوزع سياق التبادل بينهما. يحدد المعيار خطراً بروتوكولياً؛ ولا يوثق انقطاعاً بعينه أو يقيس مدى انتشار ذلك التطبيق.

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

ما الذي تضمنه القاعدة

لا يضمن RFC 1542 توافر الخوادم أو مشاركة حالتها أو اكتمال إقلاع العميل. إنه يقيد فقط قرار المرحّل بشأن وجهة طلبات العميل الواحد. ولا يفرض استخدام خادم واحد لكل العملاء؛ إذ يسمح بمجموعة وجهات وباختيار ثابت لكل عميل.

شرح RFC 1534 الصادر أيضاً في أكتوبر 1993 شروط التشغيل المشترك بين BOOTP وDHCP، لأن رسائل DHCP تستند إلى صيغة رسائل BOOTP. ثم عرض RFC 2131 الصادر عام 1997 مراحل DHCP بمزيد من التفصيل: يكتشف العميل الخوادم، ويتلقى عروضاً، ويختار خادماً، ثم يرسل طلبات لاحقة. يوضح ذلك لماذا قد يتطلب الإقلاع تبادلات متعددة، لكنه لا يثبت أن المثال المذكور في RFC 1542 تسبب في عطل إنتاجي محدد.

يسجل RFC Editor تصحيحاً موثقاً واحداً لـ RFC 1542. فهو يبدل كلمة BOOTREPLY إلى BOOTREQUEST في فقرة علامة البث بالقسم 3.1.1. وهذا موضع منفصل عن قاعدة ثبات الوجهة في القسم 4.1.1، ولا يغيرها.

الخلاصة التاريخية عملية ومحددة: يمكن توزيع العملاء بين خوادم عدة، لكن تبديل الوجهة لكل حزمة تخص العميل نفسه قد يفرق محادثة متعددة المراحل. جعل RFC 1542 هذا الحد واضحاً، وترك قرار التفعيل وطريقة الاختيار المستقر لمدير الشبكة.

المصادر