الخلاصة

  • اقترح RFC 906 استخدام TFTP فوق IP كطريق موحد للحصول على أول شيفرة حاسوبية لجهاز بلا قرص، بعدما جعل اختلاف أساليب الشركات المصنّعة دعم عدة أنواع من الأجهزة يتطلب أحياناً خوادم إقلاع متعددة.
  • في المثال الذي أورده Ross Finlayson لمحطة Motorola 68000 تعمل عبر Ethernet، لم تُنهِ رسالة ERROR الانتظار؛ بل حددت أول حزمة DATA صالحة الطرف الذي سيكمل النقل. شغلت شيفرة ROM أقل من 4 كيلوبايت دون احتساب برنامج تشغيل Ethernet. وهذا دليل على تنفيذ واحد، لا على انتشار واسع.

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

وصف RFC 906، الذي نشره Ross Finlayson في يونيو 1984، الاحتكاك العملي عند هذه الحدود. فقد استخدم كل مصنع أسلوباً مختلفاً لتحميل الملفات الأولى. وربما احتاجت المؤسسة التي تشغّل أنواعاً متعددة من الحواسيب إلى أكثر من تنفيذ لخادم الإقلاع، رغم أن الأجهزة تتخاطب بحرية بعد بدء تشغيلها. لذلك اقترح RFC 906 بروتوكولاً مشتركاً لأول عملية نقل: TFTP فوق IP. ويسمي المستند نفسه صراحةً مقترحاً لمجتمع ARPA Internet ويطلب النقاش والتحسين؛ ولا يدّعي أن الأسلوب كان قد أصبح ممارسة عامة.

كان اختيار TFTP محدوداً عن قصد. يرسل برنامج الإقلاع طلب قراءة يتضمن اسم الملف، ثم يستقبل حزم DATA ويردّ بإقرارات أو رسائل خطأ. ويرى RFC أن بطء النقل الأولي مقبول، لأن مرحلة لاحقة تستطيع استخدام بروتوكول أسرع. وكان على العميل استقبال حزم IP يصل حجمها إلى 524 ثمانياً، من دون رأس IP: حتى 516 ثمانياً لحزمة TFTP DATA، إضافة إلى رأس UDP ذي الثماني ثمانيات. ولم يكن مطلوباً من الجهاز أثناء الإقلاع الرد على طلبات TFTP الواردة للقراءة أو الكتابة. إنه عميل محدود لجلب الشيفرة، لا خادم ملفات عاماً.

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

ويجعل التنفيذ الموصوف هذا التقسيم ملموساً. فقد ذكر Finlayson برنامج إقلاع في ROM لمحطة Motorola 68000 تعمل عبر Ethernet. كان المستخدم يدخل اسم الملف، ويمكنه أيضاً إدخال عنوان IP للمحطة أو للخادم. وإذا لم يحدد عنوان الخادم، أمكن لأكثر من خادم TFTP تلقي الطلب. لذلك لم يكن السؤال المهم مجرد ما إذا كان أحد سيرد، بل أي استجابة ستغير حالة العميل.

كانت القاعدة واضحة. إذا أرسل أحد الخوادم رسالة TFTP ERROR، لم ينهِ العميل المحاولة، لأن خادماً آخر قد يرسل الملف المطلوب لاحقاً. أما أول حزمة DATA صالحة فتحدد عنواني Internet وEthernet اللذين ستُرسل إليهما رسائل ACK التالية. وإذا أرسل خادم آخر DATA بعد ذلك، يرد عليه العميل برسالة ERROR. قد يسمع عدة خوادم الطلب، لكن أول استجابة صالحة تجعل أحدها شريك النقل لهذه العملية.

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

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

وتوضح مستندات لاحقة البنية الأوسع من دون أن تثبت مسار اعتماد مباشر. وصف RFC 951 عام 1985 بروتوكول BOOTP كمرحلة أولى لتحديد العنوان واختيار ملف الإقلاع، تليها عادةً عملية نقل عبر TFTP. وفي عام 1989 وصف RFC 1123 إقلاع الأجهزة بلا قرص على مرحلتين يديرهما برنامج في ROM: إعداد IP ثم تحميل شيفرة النظام. تجعل هذه النصوص الفصل بين الإعداد والنقل أكثر وضوحاً، لكنها لا تحول التنفيذ الواحد المذكور في RFC 906 إلى إحصاء للانتشار.

تكمن القيمة التاريخية لـRFC 906 في رسم حدّ، لا في إعلان انتصار مكتمل. استطاع برنامج صغير في ROM طلب الملف التالي عبر IP، بينما بقي بدء الجهاز وبعض قرارات اختيار الخادم محلياً. وحددت أول حزمة DATA صالحة لحظة واضحة يتحول فيها خادم واحد إلى شريك النقل. أبقى ذلك البروتوكول صغيراً، لكنه ترك للمشغّل مسؤولية معرفة مصدر الشيفرة الذي سيرد أولاً.

تقدم Note 65 اللاحقة لـHeng Lu هنا انضباطاً تحريرياً، لا دليلاً على نية Finlayson: فالمقترح المنشور والتنفيذ المذكور يختلفان عن النشر الفعلي والاستخدام. تثبت المواد المتاحة وجود مقترح ومثال واحد؛ ولا تبين عدد المواقع التي اعتمدته أو ما إذا كان قد أزال عبء الدعم الذي وصفه.

المصادر