الخلاصة

  • حولت RFC 3074 معرّف العميل أو عنوان العتاد إلى قيمة من 256 قيمة، ثم استخدمت خريطة مشتركة لتقرير خادم DHCP الذي ينبغي أن يخدم الطلب.
  • وتناولت أيضاً خادماً معيناً غير متاح أو بلا عناوين، وسلالاً بلا مالك، ووقت عميل غير دقيق، وخريطة قابلة للتلاعب. أثبتت التجزئة تكليفاً مضبوطاً، لا قدرة تشغيلية حية.

يصل بث DHCPDISCOVER إلى أكثر من خادم، وقد يجيب الجميع. ويمكن لوكيل BOOTP أن يعيد المشكلة عندما يرسل الطلب إلى كل وجهاته. في فبراير 2001 نشر B. Volz وS. Gonczi وT. Lemon وR. Stevens الوثيقة RFC 3074 لتقليل هذا التكرار: بعد إعداد مشترك أولي، يحسب كل مشارك قرار «اخدم / لا تخدم» نفسه مستقلاً.

بدأ الحساب بـService Transaction ID. إذا وجد Client Identifier وجب استخدامه؛ وإلا حدد hlen الطول وقدمت chaddr ستة عشر بايتاً كحد أقصى. أعادت دالة Pearson المحددة قيمة بين صفر و255. وحمل كل خادم Hash Bucket Assignment من 32 ثمانية؛ البت المضبوط يعني أن الخادم يجب أن يخدم الطلبات التي تقع في سلته.

كان الاتفاق حقيقياً: المدخل وجدول المزج وHBA المتطابقة تنتج المسؤول نفسه من دون محادثة مستمرة. ويمكن للوكيل استعمال أزواج Server-ID والسلة لاختيار وجهة. وهكذا توزعت الطلبات من دون تغيير عملاء DHCP الموجودين.

لكن الدالة لم تقرأ حالة الخادم. لم تختبر العملية أو المسار أو توافق قاعدة الإيجارات أو بقاء عنوان مناسب. وصف STID المعاملة، وأعلنت HBA مسؤولية إدارية؛ ولم يكن أي منهما مقياساً للجاهزية.

تذكر RFC الحد صراحة: قد يكون الخادم المفترض أن يجيب غير متاح أو بلا عناوين مناسبة. ويتيح Delayed Service الاختياري لخادم تستبعده التجزئة عادة أن يجيب بعد S ثوان من المحاولة الأولى. لا يلغي ذلك صحة التعيين، بل يفتح فرصة أخرى بعد أن مضت فرصة المسؤول الأول بلا خدمة.

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

من دون Delayed Service تكون الخريطة فاصلاً صارماً. السلة غير المسندة تجعل المعاملة تُهمَل كلياً، وقد يكون ذلك مقصوداً في بعض الحالات. لذلك التغطية إيصال مستقل: يستطيع برنامج صحيح أن يحسب بدقة قيمة لا يخدمها أحد.

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

الإعداد جزء من التنفيذ. قد تأتي HBA من ملف أو سجل Windows NT أو EEPROM أو خوارزمية متفق عليها، وقد تنتقل داخل بروتوكول آخر. لا تقدم RFC أمناً بذاتها. يجب حماية الخريطة المنقولة من التعديل، لأن تغيير السلال قد يحرم بعض العملاء أو جميعهم. لا تصلح الشيفرة المتطابقة خرائط مختلفة أو خريطة مشتركة خبيثة.

تضع RFC 2131 ذلك في سياقه: العميل مستعد لردود متعددة، وDHCP آلية تحت سياسة الإدارة المحلية. بعد DISCOVER تبقى OFFER والاختيار وREQUEST وACK واستعمال الإعداد. تنظم RFC 3074 من يبدأ، ولا تضمن البقية. وتشرح RFC 1542 الوكيل، لكنها لا تثبت تنفيذ هذه الخوارزمية في جهاز معين.

وصفت RFC 7031 لاحقاً اختلاف إعداد الشريكين بأنه مشكلة متكررة، وأبقت موازنة الحمل خارج لب failover في DHCPv6. ليست تقريراً رجعياً عن نشر RFC 3074، لكنها تحافظ على الفصل بين توزيع الطلبات ومزامنة الحالة والتعافي من العطل.

يرتب Running-Code Primacy الإيصالات: مصدر STID، السلة، التغطية، الخادم، الوصول، العنوان، الاستجابة المتأخرة، OFFER، الاختيار، REQUEST، ACK، ثم إعداد يعمل. ويفصل Reality Layers يقين المالك المحسوب رمزياً عن الأثر التشغيلي. هاتان عدستان لاحقتان لا تنسبان إلى المؤلفين أو IETF.

أجابت RFC 3074 بدقة عن سؤال من يحاول أولاً. وكان نجاحها في تقليل التنسيق، وحدها في أنها لم تجعل ذلك إثباتاً للحضور أو السعة أو النجاح. السلة تسند المسؤولية؛ الخدمة تحتاج الواقع.

المصادر