الخلاصة

  • عامل RFC 3396 التكرارات ذات رمز DHCPv4 الواحد كشظايا متسلسلة لقيمة منطقية، سواء فرضها حد 255 ثُمانية أم ضيق المساحة في حقل محمّل بالخيارات.
  • اتبعت إعادة البناء الترتيب المنطقي options ثم file ثم sname، لا الترتيب المادي. لم تحمل نقطة القطع دلالة، ولم يثبت الإرسال الصحيح أن مستقبلاً منشوراً أعاد التجميع.

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

صدر النص في نوفمبر 2002 ضمن مسار المعايير. يتكون الخيار المتغير من ثُمانية للرمز، وثُمانية للطول، ومن صفر إلى 255 ثُمانية للقيمة. لم يكن ممكناً أن تحمل نسخة واحدة قيمة أطول.

كان RFC 2131 قد ذكر ضم الخيارات المتكررة، لكنه لم يحسم الترتيب كاملاً، واحتوى عبارة عامة تفيد بأن الخيار لا يظهر إلا مرة ما لم ينص تعريفه على خلاف ذلك. حذف RFC 3396 العبارة وجعل تكرار الرمز مدخلاً عاماً لإعادة تكوين كائن واحد قبل المعالجة.

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

جاءت المواضع الثلاثة من إرث BOOTP. يحمل حقل الخيارات العادي البيانات عادة، لكن option overload يسمح أيضاً باستعمال file وsname. عرّف RFC مخزناً تجميعياً منطقياً ترتيبه options ثم file ثم sname.

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

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

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

قسّم المثال اسم الإقلاع /diskless/foo إلى نسختين من الخيار 67. لم تكن /diskle ولا ss/foo اسماً مستقلاً. بساطة المثال أكدت أن القاعدة تحمي الهوية، لا الأحجام الهائلة فقط.

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

قسم RFC الخيارات إلى فئة تتطلب الضم وفئة لا تتطلبه. لا يدخل خيار الفئة الأولى إلا إذا أشار تعريفه صراحة إلى RFC 3396 وفرض الآلية. ينبغي تجنب التجزئة إلا للضرورة أو مع دليل قدرة النظير أو إعداد إداري صريح.

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

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

استخدمت RFC 3397 وRFC 3361 وRFC 3442 وRFC 3925 الأساس لقائمة بحث النطاقات ووكلاء SIP والمسارات غير الفئوية وبنى الموردين. لكل منها قواعد محتوى مستقلة؛ أما RFC 3396 فكان يعيد السلسلة الواحدة التي تقرؤها تلك القواعد.

لهذا لا تثبت اللقطة الكاملة أكثر من عبور الشظايا نقطة الرصد. لا تثبت تعرف العميل إلى overload أو ترتيبه الصحيح أو حفظه التكرارات أو تعامله مع المحاذاة والمصادقة أو تطبيقه للقيمة. لكل مرحلة إيصال تشغيل منفصل.

لا يعرض بحث التصحيحات الحالي نتيجة لـ RFC 3396. هذه حالة سجل، لا شهادة للبرمجيات. نشأ النص نفسه لأن الكلمات الأقدم والشيفرة المنشورة لم تنتجا واقعاً موحداً.

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

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

المصادر