الخلاصة

  • أتاحت RFC 3315 لعميل DHCPv6 طلب تبادل Solicit–Reply بدلاً من Solicit–Advertise–Request–Reply المعتاد، لكن الخادم ظل قادراً على رفض هذا المسار وفق سياسته وإعداده.
  • في Rapid Commit يلتزم الخادم بالتخصيص قبل إرسال Reply. وقد تلتزم عدة خوادم بعناوين لا يستخدم العميل منها إلا تخصيص خادم واحد؛ كما قد يترك الرد المفقود حالة الخادم منفصلة عما تسلمه العميل فعلياً.

كانت الرسائل الأربع تؤدي وظيفة تتجاوز إضافة انتظار. يرسل العميل Solicit، ثم يتلقى Advertise من الخوادم المتاحة، ويختار أحدها ويرسل Request قبل وصول Reply المؤكد. نشر RFC 3315 في يوليو 2003 بروتوكول الإعداد ذي الحالة لـIPv6، وسمح أيضاً بمسار أقصر عندما تكون سرعة الإعداد مهمة. لكنه لم يجعل هذا المسار تلقائياً.

يضع العميل خيار Rapid Commit ذي الطول الصفري في Solicit ليشير إلى استعداده لتلقي Reply فوراً. الإشارة لا تلزم الخوادم. فكل خادم يطبق سياسته الإدارية وإعداده؛ ويمكنه تجاهل الخيار وإرسال Advertise إذا لم يكن معداً للالتزام بتخصيص فوري. عندئذ يستطيع العميل متابعة اختيار الخادم بالطريقة المعتادة. أما الخادم الذي يقبل الخيار فيسجل التخصيص قبل إرسال Reply.

هذا الترتيب هو موضع المفاضلة. يستطيع العميل استعمال الإعداد الذي يتضمنه Reply صالح يحمل Rapid Commit من دون إرسال Request. لكن الخادم لا يتلقى بعد ذلك تأكيداً بأن العميل تسلم الرد. وتشير RFC 3315 تحديداً إلى أن تعدد الخوادم المستجيبة لـSolicit واحد قد يجعل كل خادم يلتزم بعناوين، بينما لا يستخدم العميل إلا عقود الإيجار الصادرة عن خادم واحد. تبقى التخصيصات الأخرى ملتزماً بها وإن لم تُستخدم. وإذا ضاع Reply أثناء النقل، فقد يحتفظ الخادم بتخصيص لم يصل إلى العميل كي يعمل به.

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

تذكر RFC 3315 أن الخدمات التي تستخدم Solicit–Reply تُنظم عادة بحيث لا يستجيب سوى خادم واحد. وتقترح مدد إيجار أولية أقصر لتقليل العناوين غير المستخدمة. هذه وسائل تخفيف تصميمية وليست ضماناً لوجود خادم واحد دائماً أو لمزامنة حالة الخوادم. يكون المسار القصير أوضح حين تكون مجموعة المستجيبين مضبوطة عن قصد.

في 2005، نقلت RFC 4039 خيار Rapid Commit إلى DHCPv4، وناقشت بيئات عالية الحركة يتغير فيها موضع اتصال الشبكة كثيراً، حيث قد تكون سرعة الإعداد مفيدة. كما أوضحت ميزة التبادل ذي الرسائل الأربع: تبقى عروض الخوادم الاحتياطية مؤقتة حتى يختار العميل. ويسجل هذا نسباً في تطور التصميم، لا انتشاراً شاملاً أو قياساً لأوقات البدء. ثم جمعت RFC 8415 مواصفات DHCPv6 عام 2018؛ وفي 2026 حلت RFC 9915 محلها مع الإبقاء على طلب العميل وقرار الخادم والتحذير من التخصيصات الملتزم بها وغير المستخدمة.

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

المصادر: RFC 3315، RFC 4039، RFC 8415، وRFC 9915.