الخلاصة

  • قد يدفع ACK المتأخر طرفي الاتصال إلى إعادة إرسال الحزم الحالية، فتنتقل الازدواجية إلى الكتل التالية.
  • منع RFC 1123 مرسل DATA من الرد على ACK مكرر بإعادة إرسال الكتلة الحالية؛ الخطر هو تعثر النقل تحت الازدحام، لا تلف ملف اكتمل استلامه.

اقتصاد كتلة واحدة في كل مرة

في يونيو 1981، نشرت Karen Sollins المراجعة الثانية لبروتوكول نقل الملفات البسيط. جاءت البساطة من تبادل محدود: طلب قراءة أو كتابة، وكتل بيانات حجم كل منها حتى 512 بايت، وإقرار لكل كتلة قبل الانتقال إلى التالية. لم يكن على المرسل الاحتفاظ إلا بالكتلة الجاري إرسالها. وفّر ذلك الذاكرة وخفّض عبء التنفيذ، وهو أمر مهم لجهاز يحتاج إلى جلب نظامه قبل أن يصبح مضيفاً مهيأً بالكامل.

يصف RFC 1123 في 1989 تهيئة المضيف عبر شبكة محلية بأنها الاستخدام الأهم لـTFTP، ويشير إلى أن صغر البروتوكول يسمح بوضعه في EPROM. يمكن لـBOOTP توفير معلومات التهيئة، ثم ينقل TFTP صورة النظام. كانت الخطوتان متجاورتين في عملية الإقلاع لكنهما مختلفتين؛ فتوفير العنوان لا يزيل أثر التأخير على نقل الملف.

عمل TFTP فوق UDP، لذلك أدارت طبقة التطبيق إعادة الإرسال بنفسها. إذا لم يصل الرد المتوقع قبل انتهاء المؤقت، يعيد المرسل إرسال الحزمة المعلقة. عند فقد الحزمة يبدو الأمر مباشراً. أما إذا كانت الحزمة متأخرة ولم تُفقد، فيتغير تسلسل الأحداث.

حين يغيّر ACK قديم الحالة الحالية

لنتخيل أن المضيف A أرسل DATA 20، وأن B أعاد ACK 20 لكنه تأخر في الطريق. ينتهي مؤقت A، فيرسل DATA 20 مرة أخرى. يتعرف B على الكتلة المكررة ويرسل ACK 20 مجدداً. يصل الإقرار الأول فيتقدم A إلى DATA 21. ثم يصل ACK 20 الثاني. ووفق القاعدة القديمة، يرد A بإعادة الحزمة التي يحملها الآن، أي DATA 21، بدلاً من تجاهل الإقرار المتأخر.

يستقبل B نسختين من DATA 21 ويرسل ACK 21 مرتين. إذا وصل أحد الإقرارين بعد تقدم A إلى DATA 22، فقد يؤدي إلى نسخة أخرى من الكتلة الحالية. لا يقتصر أثر الحزمة القديمة على استعادة حالة قديمة؛ فالرد يُبنى على الحالة الراهنة لكل طرف. وهكذا يصبح التكرار سبباً لتكرار جديد.

سمّى Robert Braden هذا النمط «Sorcerer’s Apprentice syndrome» في RFC 1123. يبيّن المثال أن بقية الحزم قد تُرسل مرتين ما لم تفقد إحدى الرزم فتقطع السلسلة. لم يكن ذلك يعني أن محتوى الملف يصبح خاطئاً حتماً: يوضح النص أن النقل المكتمل يترك الملف صحيحاً. الخطر أن استهلاك الوقت والسعة قد يدفع النقل إلى انتهاء المهلة قبل اكتماله.

الشبكة تضخم الأثر

قد تكون الشبكة سبب الحلقة ونتيجتها. فالازدحام يؤخر ACK حتى تنتهي المهلة؛ ثم تشغل DATA وACK المكررة سعة إضافية، فتزيد فرصة التأخير التالي. حذّر RFC من مزيد من الازدحام والتأخير. وهذا وصف لآلية في البروتوكول، لا دليل على أن كل نقل بطيء مر بها أو أن حادثة تاريخية بعينها نتجت عنها.

طلب RFC 1123 مؤقتات تكيفية وأوصى بالتراجع الأسي، لكن تحسين التوقيت لا يزيل السلوك الذي يكرر الكتلة الحالية بسبب ACK قديم. جاء الإصلاح في الرد نفسه: يجب على مرسل DATA ألا يعيد إرسال DATA الجاري لمجرد وصول ACK مكرر. عندها لا يستطيع الإقرار المتأخر إطلاق النسخة التالية من الحلقة. ويمكن الاستغناء عن مؤقت ACK لدى المستقبل بعد ضمان هذه القاعدة، مع إبقائه إن كان مفيداً لتعويض ACK ضائع فعلاً؛ أما مؤقت المرسل فيظل ضرورياً.

قاعدة صغيرة قبل مراجعة المواصفة

في مايو 1992 أدرج Noel Chiappa الإصلاح في مراجعة البروتوكول. ثم حل RFC 1350 المنشور في يوليو محل RFC 783 وسجل هذا التعديل. التسلسل مهم: متطلبات المضيفين في 1989 حددت بالفعل السلوك اللازم، ثم ثبّتت مراجعة TFTP القاعدة في مواصفة البروتوكول. لا تكشف هذه التواريخ متى حدّثت كل عملية تنفيذ.

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

Sources