الخلاصة

  • رقّمت RFC 3479 عمليات LDP المحمية، وجعلت ACK التراكمي حداً للبادئة التي ثبّتها المستقبِل في حالة قابلة للاستعادة.
  • عند إعادة الاتصال أُعيد إصدار الذيل غير المؤكد، ودفعت نقطة التحقق الإقرارات، بينما أوقفت ثلاث رسائل Cork الاتجاهين عند حد واحد.

لا تتذكر جلسة TCP الجديدة أين انتهت القديمة. قد تكون رسالة Label Request الأخيرة بقيت عند المرسل أو وصلت أو عولجت أو حُفظت في تخزين يصمد أمام التحويل. لم تعتبر RFC 3479 فتح اتصال جديد حلاً لهذه الفجوة، بل بنت طريقة يقارن بها نظيران سجلين جزئيين.

حدد FT Session TLV نطاق السجل. فعّل S العمليات ذات أرقام التسلسل، واستطاع A فرض الحماية على كل الملصقات، واختار C نقاط التحقق حتى من دون S. لذلك لا يكفي حفظ ACK وحده؛ فلا يُعرف ما الذي غطاه ما لم تبقَ نتيجة التفاوض.

حملت العملية المحمية FT Protection TLV ورقماً خاصاً بتلك الجلسة. وكان على المستقبِل أن يؤمّن الرسالة أو الحالة الناتجة من معالجتها قبل إرسال FT ACK. تركت المواصفة شكل التخزين للتنفيذ: رسالة كاملة أو نتيجة. لكنها لم تترك ديمومة الدليل اختيارية.

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

عندما عاد TCP أعلن كل نظير آخر تسلسل أمّنه. أعاد المرسل العمليات الواقعة بعد هذا الحد، وعالجها المستقبِل كأنها تصل للمرة الأولى. لم تُستعد سلسلة البايتات المفقودة؛ بل أُعيد بناء الجزء الذي لم يثبت مصيره في ذاكرة الطرف الآخر.

سمحت القواعد بإلغاء زوجين net-zero: Label Request مع Label Abort، وLabel Mapping مع Label Withdraw. لكن وجود طرفي الزوج محلياً لم يكن كافياً. ربما عبر الطرف الأول قبل الانقطاع. كان لا بد من معرفة حد ACK لدى النظير أولاً، ثم تقرير أن الإلغاء لا يترك حالة أحادية.

دخلت رسائل Address وAddress Withdraw في الحماية أيضاً. وإلا أمكن أن يرى طرف العنوان صالحاً بينما يراه الآخر مسحوباً. وجب سحب العنوان الذي فقد صلاحيته صراحة بعد العودة. وإذا لم يعلن الطرفان حفظ الحالة، عُدّت العناوين القديمة مسحوبة وأُعيد إعلان الصحيح منها.

غيّرت نقطة التحقق حجم الوحدة المؤكدة. طلب Keepalive محمي من الطرف أن يؤمّن كل الرسائل السابقة القابلة لنقطة التحقق ثم يعيد الحد. مع C من دون S لم تحمل الرسائل العادية أرقاماً نشطة منفردة، فزامنت النقطة المجموعة. ومع S غطت عمليات الملصقات المرقمة والعناوين. الاسم وحده لم يجعلها لقطة لكل النظام.

لم يكفِ اتجاه واحد للإغلاق المنظم. احتاج طالب التوقف أيضاً إلى إثبات أنه حفظ ما أرسله النظير. أنشأ FT Cork TLV ثلاث خطوات: طلب السكون، إنهاء الطرف الآخر للمعالجة ووقف العمليات الجديدة، ثم إغلاق الاتجاه المقابل. قبل الرسالة الثالثة لم يكن السجلان عند النهاية نفسها.

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

تحمي IESG Note التاريخ من المبالغة. فقد قالت إن إرشادات المؤقتات والمحاولات غير كافية، وحذرت من التحويل المبكر، ورفضت جعل التصميم نموذجاً عاماً لتحمل أعطال TCP مستقبلاً. حددت RFC لغة المطابقة، لا إعداداً آمناً لكل شبكة.

هذا الموضوع لا يكرر مقال RFC 3478 الذي يملك الحالة القديمة ونوافذ الزمن، ولا مقال RFC 3612 الذي يملك الفصل بين الحالة المحفوظة وACK وحقيقة التمرير. يملك هذا المقال فقط نطاق الحماية، والتسلسلات، والحد الدائم، وإعادة الإصدار، وnet-zero، ونقطة التحقق، وCork.

وفق ترتيب Heng Lu يبدأ التدقيق بهوية الجلسة القديمة والجديدة، وبتات S/A/C/R والمعلمات الثابتة. ثم يبني عموداً لكل نظير: ما أرسله، وما أمّنه، وما أرسله فعلاً من ACK. عند العطل تُجمّد الطوابير، وبعده تُبرر كل إعادة وكل إلغاء، وفي الإغلاق تُحفظ رسائل Cork الثلاث ولحظة توقف كل اتجاه.

لا يغطي ACK رقماً مستقبلياً. ولا تغطي نقطة التحقق مجموعة لم تُتفق عليها. ولا تثبت Cork واحدة سكون الاتجاهين. كما لا يثبت أي منها وصول خدمة إلى تطبيق. إنها تجيب عن سؤال أسبق: أي جزء من تاريخ العمليات يستطيع الطرفان الاعتراف به معاً؟

هنا تكمن قيمة RFC 3479 التاريخية. لم تسم فقدان الذاكرة استعادة؛ بل حدّت الخلاف بين ذاكرتين. قيّدت الأرقام النزاع، وحدد ACK الماضي المشترك، وأعادت الإصدارات الذيل الغامض، وصنعت Cork نقطة نهاية مشتركة.

المصادر