الخلاصة

  • فصل RFC 3542 بين خيارات IPv6 الدائمة التي يحتفظ بها المقبس وبين البيانات المساعدة المرفقة برسالة واحدة. لا تتجاوز البيانات المساعدة إلا الخيار الدائم الذي يحمل الاسم نفسه؛ وتظل الخيارات الأخرى فعالة.
  • لهذا النطاق حدود واضحة: يمكن لبيانات ذات طول صفري تعطيل خيار لرزمة واحدة، وقد تفتقر الرزم الموجودة سلفاً في قائمة الانتظار إلى بيانات وصفية طُلبت لاحقاً، كما أن استدعاء إرسال TCP لا يقابل مقطعاً منقولاً واحداً بالضرورة.

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

نُشر RFC 3542 في مايو 2003 بعنوان Advanced Sockets Application Program Interface (API) for IPv6. وهو مذكرة معلوماتية، لا معيار بروتوكول يحدد ما يظهر على السلك. موضوعه الحد الفاصل بين التطبيق والنواة: ما الذي يستطيع البرنامج طلبه من مكدس IPv6، لا ما الذي أرسلته الشبكة فعلياً. قبول استدعاء واجهة برمجية لا يثبت وحده أن الرزمة غادرت أو وصلت أو حققت نتيجة للتطبيق.

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

ليست هذه مسألة أسلوب برمجي فحسب؛ إنها تحدد مدى تأثير الاستثناء. إذا احتفظ المقبس باختيارات مستقلة لواجهة الخروج وفئة حركة المرور ومعالجة الترويسات الامتدادية، فلا ينبغي لبيانات مساعدة تخص المسار أن تمحو الاختيارين الآخرين. تدمج النواة الحالة الدائمة مع الاستثناء الضيق عند إنشاء الرزمة، لكن نجاح الدمج لا يعادل مشاهدة الرزمة التي أُرسلت بالفعل.

تسمح القاعدة أيضاً بطلب غياب محدد. يمكن للتطبيق ضبط IPV6_HOPOPTS كخيار دائم، ثم إرفاق بيانات مساعدة من النوع نفسه بطول صفري برسالة واحدة. والنتيجة المقصودة هي حذف ترويسة خيارات Hop-by-Hop من تلك الرزمة وحدها. لا يعني الصفر «انسَ جميع الإعدادات»؛ بل يعطل خياراً مسمى لمرة واحدة. وتعود الرزمة التالية إلى القيمة الدائمة ما لم يغيّرها التطبيق بطريقة أخرى.

في الاستقبال تظهر مشكلة زمنية مختلفة. يفعّل التطبيق خيارات IPV6_RECVxxx، ثم يمكن لـ recvmsg() أن يعيد معلومات الرزمة المتاحة في كائنات مساعدة. إذا غاب الكائن المتوقع، فربما لم تتضمن الرزمة المعلومة. لكن RFC 3542 ينبه أيضاً إلى أن الرزم التي دخلت قائمة الانتظار قبل تفعيل خيار الاستقبال قد لا تحمل البيانات الوصفية الجديدة. لذلك قد يصف الغياب محتوى الرزمة، وقد يصف أيضاً أن المراقبة بدأت متأخرة؛ ولا يكفي الغياب وحده لإعادة بناء ما كان على السلك.

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

وتحتاج الأمثلة التاريخية إلى تأريخ. يعرض RFC 3542 مثالاً لترويسة توجيه من النوع Type 0 يعود إلى حقبة RFC 2460. أما RFC 8200 فهو الآن المواصفة الأساسية لـ IPv6. يوضح المثال القديم ما أمكن للواجهة التعبير عنه في زمنه؛ ولا يمثل توصية حالية لتوجيه الحركة.

تتمثل دلالة RFC 3542 التاريخية في تضييق الاستثناء: تحوّل الاستبدال الشامل لمجموعة الخيارات في RFC 2292 إلى تجاوز الخيار المطابق وحده. ولإثبات السلوك، يجب تسجيل حالة المقبس قبل الاستدعاء، والبيانات المساعدة للرسالة، والرزمة التي شوهدت، والنتيجة اللاحقة كلٌّ على حدة. نجاح sendmsg() دليل على أن الواجهة قبلت النية، لا دليل على أن الرزمة سلكت الطريق المتوقع.

المصادر