الخلاصة

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

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

وصف بيل كروفت وجون غيلمور المشكلة في RFC 951 الصادر في سبتمبر 1985. لم يكن BOOTP بروتوكولاً لنقل الملفات، بل تولى المرحلة الأولى: تحديد العنوان واختيار ملف الإقلاع. يستطيع PROM في العميل طلب عنوان وخادم واسم ملف؛ وبعد الرد، تتولى مرحلة ثانية نقل الملف إلى الذاكرة، عادةً باستخدام TFTP. وكان التصور أن يبدأ الحاسوب غير المراقب تلقائياً عند تشغيله. يصف المستند تصميماً مقترحاً، ولا يقدم إحصاءً لعدد الأجهزة التي استخدمته. (RFC 951، القسمان 2 و7.5.)

لم يحتج الطلب إلى عنوان IP يجهله العميل. فإذا لم يكن الخادم محدداً، أمكن للعميل إرسال حزمة IP/UDP بعنوان مصدر صفري إلى 255.255.255.255، وهو عنوان بث على الكابل المحلي. حمل الطلب أيضاً نوع العتاد وعنوانه لدى العميل ومعرّفاً للمعاملة. استطاع الخادم مطابقة العنوان العتادي بعنوان IP في قاعدة بياناته، وكتابة النتيجة في الحقل yiaddr بالرد، ثم اختيار مسار كامل لملف الإقلاع. وقد يتحول طلب عام مثل unix إلى ملف مخصص لذلك العميل. وهكذا صار سجل الخادم المحلي جزءاً من مسار بدء التشغيل. (RFC 951، الأقسام 2–3 و7.1 و7.3 و9.)

واجه الرد الأول معضلة الدجاجة والبيضة الخاصة به. يحتاج الخادم عادةً إلى ARP لمعرفة عنوان طبقة الربط المقابل لوجهة IP. لكن العميل لم يكن يعرف عنوانه بعد، ولم يستطع الرد على استعلام ARP الصادر من الخادم. اقترح RFC 951 حلين. إذا توفرت وظائف مناسبة في النواة أو برنامج التشغيل لدى المرسل، أمكن إنشاء مدخل مؤقت في مخبأ ARP اعتماداً على عنوان العميل العتادي والعنوان المقترح، مع ضبط مهلة لانتهائه. وذكر RFC تحديداً أن UNIX 4.2 BSD كان يملك هذه القدرة. وإذا لم تتوفر، أمكن للخادم بث الرد عبر الواجهة المتصلة بشبكة العميل. اعتمد الحل الممكن على إمكانات النظام المحلي الذي أرسل الرد. (RFC 951، القسم 4.)

ساعد منفذا UDP أيضاً في مسار العودة. ذهبت الطلبات إلى منفذ خادم BOOTP رقم 67، بينما أُرسلت الردود إلى منفذ العميل رقم 68. يوضح RFC 951 أن فصل المنفذين يسمح للنواة بتصفية الردود المبثوثة لدى الأجهزة التي لا تستمع إلى منفذ العميل، فلا تضطر إلى إيقاظ عمليات خوادم BOOTP الأخرى وجدولتها. وكان المنفذ العشوائي الذي يختاره العميل قد يجعل البث يبدو موجهاً إلى عملية تستمع على جهاز آخر. لم يكن ذلك تفصيلاً شكلياً: فقد منع رد الإقلاع الخاص بجهاز واحد من أن يصبح حدثاً تطبيقياً على كامل المقطع الشبكي. (RFC 951، القسم 3.)

لم يكن خادم الإقلاع دائماً على الكابل المحلي نفسه. جعل RFC 951 الإقلاع عبر البوابات خياراً يتطلب تعاون البوابة والخادم. أمكن لبوابة أو وكيل آخر استقبال البث، ووضع شبكة العميل في الحقل giaddr، ثم تمرير الطلب إلى الخادم. وحذر المؤلفان من إعادة بث الطلبات في كل مكان بلا ضوابط، لأن ذلك قد ينشئ حلقات. وفي أكتوبر 1993، رسم RFC 1542 الحد بصورة أدق: وكيل ترحيل BOOTP ليس موجهاً عادياً يمرر رزمة IP بشفافية. بإمكانه تلقي رسالة BOOTP كوجهة نهائية ثم إنشاء رسالة BOOTP جديدة. ويمكن وضع هذه الوظيفة في موجه أو في مضيف منفصل متصل بالشبكة الفرعية للعميل. الترحيل خدمة مهيأة بقواعد معالجة خاصة بها. (RFC 951، القسم 8؛ RFC 1542، القسمان 4–4.1.)

لذلك لا يصح اختزال BOOTP في عبارة «DHCP القديم». وصف RFC 2131 اللاحق DHCP بأنه امتداد لآلية BOOTP، وأبقى صيغة الرسائل وسلوك الترحيل كي تتفاعل الخوادم والعملاء القائمة معه. لكنه أضاف قدرة محورية: منح عنوان بمدة محدودة وإعادة استخدامه بعد أن يتوقف العميل عن الحاجة إليه. كان نموذج BOOTP في 1985 يبحث عن عنوان العميل وملف إقلاعه في سجلات الخادم. ويدعم DHCP التعيين اليدوي أيضاً؛ فالفرق ليس أن كل العناوين أصبحت مؤقتة، بل أن التعيين الديناميكي دخل البروتوكول. (RFC 2131، القسمان 1–2.)

كانت مهمة BOOTP التاريخية محدودة لكنها ضرورية. لم يجعل الحاسوب بلا قرص مستقلاً، ولم يتحقق من هوية المستخدم، ولم ينقل صورة نظام التشغيل بنفسه. بل حدد كيف يطلب جهاز لديه عنوان عتادي، لكن بلا هوية IP قابلة للاستخدام، المعلومات التالية اللازمة لبدء التشغيل؛ وكيف يختارها الخادم؛ وكيف يعود الرد قبل أن يعمل ARP بالطريقة المعتادة. في هذه الحالة بدأ الاتصال ببث محلي، وسجل صريح في الخادم، ورد يتطلب معالجة خاصة.

المصادر والحدود

كان RFC 951 اقتراحاً للنقاش، ويعرض السلوك المقصود لا مدى الانتشار الفعلي. وذكره لوجود مخبأ ARP في 4.2 BSD لا يثبت أن كل التطبيقات امتلكت تلك الوظيفة. يوثق RFC 1542 قواعد ترحيل لاحقة، لا التزاماً عالمياً بها. اختار BOOTP إعدادات الشبكة واسم الملف، أما نقل الملف فكان مرحلة منفصلة. أضاف DHCP عقود الإيجار الديناميكية، مع الإبقاء على التعيين اليدوي.