الخلاصة

  • وزّع FTP فعل الملف على اتصالين: حمل اتصال البيانات البايتات، وحفظ اتصال التحكم حالة الأمر. كان رد 1yz إيجابياً لكنه تمهيدي، أي إن الفعل لم يكتمل بعد وينتظر رداً لاحقاً.
  • لم يكن لإغلاق اتصال البيانات معنى واحد. قد ينتج عن EOF طبيعي أو ABOR أو تغيير منفذ البيانات أو انتهاء اتصال التحكم أو خطأ لا يمكن تداركه.
  • عندما يقطع ABOR نقلاً جارياً، ينهي 426 النقل الأصلي سلبياً، ثم ينهي 226 أمر الإلغاء إيجابياً. الاحتفاظ بآخر رمز فقط يحوّل نجاح الإلغاء إلى نجاح للنقل الملغى.

الصمت على مسار البيانات لم يكن حكماً

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

عرفت عملية نقل البيانات إن كان الاتصال قد فُتح، وكم بايتاً عبر، وهل شوهد EOF أو فشل في النقل. وعرف مفسر البروتوكول لدى الخادم الأمر الجاري، والرد التمهيدي الصادر، والرد الذي سيغلق حالة ذلك الأمر.

لم يكن السجلان نسختين من إيصال واحد. يستطيع مسار البيانات أن يتوقف من دون أن يحدد سبب التوقف. ويستطيع اتصال التحكم أن يضيع بعد أن أحدث الخادم أثراً محلياً. أعطى الفصل FTP مرونة إبقاء الحوار حياً وإنشاء قنوات بيانات لكل فعل، لكنه منع حدثاً في TCP من وراثة معنى نجاح التطبيق.

فرّق FTP المبكر بين إغلاقين

قبل استقرار عائلات الرد الحديثة، ظهرت الحدود بوضوح. أدرجت RFC 354 في يوليو 1972 الرد 252 FTP transfer completed correctly. وأدرجت على حدة 452 FTP: File transfer incomplete, data connection closed.

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

كان FTP يصل أجهزة مختلفة في التمثيل وحجم الوحدة المنطقية وبنية الملف والتخزين. نسّق مفسر الخادم بين الأمر وعملية بيانات وأثر في نظام الملفات. لم يستطع عداد الشبكة وصف التحويل والكتابة ونتيجة الأمر معاً.

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

أصبحت الخانة الأولى قاعدة للحالة

أعادت RFC 640 سنة 1974 تنظيم الردود. 1yz إيجابي تمهيدي: بدأ الفعل لكنه غير مكتمل وسيتبعه رد آخر. 2yz اكتمال إيجابي. 3yz يقبل الخطوة السابقة وينتظر معلومة إضافية. أما 4yz و5yz فينهيان الطلب سلبياً، مع اختلاف ما يعنيه ذلك لإعادة المحاولة.

لم تعد كلمة «إيجابي» صندوقاً واحداً. يستطيع 150 أن يطلب من العميل الانتباه إلى اتصال البيانات، ولا يستطيع في الوقت نفسه منحه حق إغلاق الأمر على أنه ناجح.

وقد قدّمت RFC 640 لحظة الرد التمهيدي. أمكن إرساله حين يكون النقل ممكناً وحين يكون اتصال البيانات قائماً أو ستُجرّب إقامته. حسّن ذلك سرعة الحوار، لكنه ضيّق الدليل: الاستعداد والمحاولة ليسا اتصالاً ناجحاً ولا اكتمالاً.

بقي رد مستحق بعد 125 أو 150

حافظت RFC 765 ثم RFC 959 سنة 1985 على المرحلتين. تسمح RFC 959 برد 1yz واحد كحد أقصى لكل أمر، ثم يجب أن يصل رد اكتمال.

في أفعال الملفات يقول 125 إن اتصال البيانات مفتوح وإن النقل يبدأ. ويقول 150 إن حالة الملف سليمة وإن الخادم على وشك فتح الاتصال. وقد تكون النهاية 226 أو 250، أو فشلاً مناسباً مثل 425 أو 426 أو 451 أو 551 أو 552.

لذلك لا يحتوي تسجيل فيه 150 وكل البايتات المتوقعة وإغلاق TCP على نتيجة FTP كاملة إذا غاب الرد النهائي. وبالعكس لا يمحو تطابق العدد رداً نهائياً سلبياً. اختلاف الطبقتين معلومة يجب صونها.

ولهذا ينتظر العميل عادة اكتمال الأمر قبل إرسال أمر عادي جديد. ما زال الانتقال السابق مفتوحاً في مفسر التحكم. يحتاج ABOR وSTAT إلى معاملة خاصة لأنهما مطالبان بالوصول إلى عمل مستمر أو الاستعلام عنه.

كانت للإغلاق أسباب متعارضة

تسرد RFC 959 أسباباً متعددة لإغلاق الخادم اتصال البيانات: نهاية طبيعية للنقل، استقبال طلب إلغاء، أمر يغير مواصفة المنفذ، إغلاق قانوني أو غير طبيعي لاتصال التحكم، أو خطأ لا يمكن تداركه.

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

في وضع Stream قد يدل إغلاق اتصال البيانات على نهاية الملف. هذه قاعدة لتأطير المحتوى، لا إيصالاً عاماً بالنجاح. تظهر الحدود في الاستئناف: إذا لم يبق سياق التحكم فقد يصعب التفريق بين نهاية طبيعية وانقطاع مبكر.

على نظام الرصد أن يحفظ «شوهد EOF/إغلاق البيانات» و«اكتمل أمر FTP بالرمز X» كحدثين. وقوعهما في اللحظة نفسها لا يوحد سلطتهما.

كان 226 الإيجابي قد يخص الإلغاء

إذا وصل ABOR بعدما اكتملت الخدمة السابقة، فلا يبقى عمل لإيقافه. ومع ذلك يستطيع الخادم إرسال 226 لأنه عالج أمر الإلغاء. الرد يخص ABOR، ولا يصدر ضماناً جديداً للملف السابق.

أما إذا ظل النقل جارياً فتطلب RFC 959 ردين. يعلن 426 أولاً إغلاق اتصال البيانات وإلغاء النقل الأصلي. ثم يعلن 226 أن أمر ABOR عولج بنجاح.

هناك نتيجتان منفصلتان:

  1. النقل الأصلي ← اكتمال سلبي بسبب الإلغاء (426)؛
  2. طلب الإلغاء ← اكتمال إيجابي (226).

من يحتفظ بآخر رمز يمنح النجاح للفعل الخطأ. ومن يربط الردين بالنقل الأصلي يفقد حقيقة أن الإلغاء نجح. ترتيب الرد ومالك الفعل جزءان من المعنى، لا بيانات ثانوية.

توقفت سلطة 226 عند حدود FTP

في المسار العادي يقول 226 إن اتصال البيانات يُغلق وإن فعل الملف المطلوب نجح في FTP. لا يحمل بصمة للمحتوى ولا هوية نسخة. ولا يضمن التخزين الدائم أو النسخ الاحتياطي أو استمرار الأذونات أو استهلاك تطبيق لاحق للملف أو اكتمال التزام تجاري.

تحتاج الادعاءات الأقوى إلى إيصالات مستقلة: ملخص لمقارنة المحتوى، وسجل مزامنة للاستدامة المحلية، ومعرف ثابت للنسخة، وإقرار من التطبيق للقبول اللاحق.

كذلك لا يثبت غياب 226 غياب الأثر. قد ينهي الخادم الكتابة ثم يفقد اتصال التحكم قبل وصول الرد. قد تكرر المحاولة العمياء الملف أو تستبدله. الوصف الصادق هنا هو «نتيجة FTP مجهولة»، لا «لم يحدث شيء».

كان سجل التحكم جزءاً من سجل النقل

يحفظ الملف القابل للتدقيق الأمر وترتيبه، و125 أو 150، ونقطة البيانات، ونتيجة الفتح، والبايتات وEOF، وسبب الإغلاق إن عُرف، وكل الردود النهائية بترتيبها، وتوقيت ABOR أو STAT.

ويحفظ إلى جانبها حقائق لا يشهد بها FTP: التمثيل والوضع، وتفسير المسار، والأثر المحلي، والاستدامة، والبصمة، وهوية الكائن. إنها أدلة متكاملة وليست بدائل.

لا تكفي خانة done. يجب التمييز بين قبول تمهيدي، وانتظار اتصال، وبيانات نشطة، وبيانات أُغلقت في انتظار النهاية، ونقل اكتمل إيجابياً، ونقل اكتمل سلبياً، وإلغاء طُلب، ونقل أُلغي، وإلغاء عولج، ونتيجة تحكم مجهولة.

بعد ضغطها في حالة واحدة لا يمكن استعادة الفعل الذي أنهى آخر رمز. الخسارة التي لا يمكن عكسها هي خسارة التسلسل الدلالي.

المصادر وحدود الدليل

تعتمد المقالة على RFC 354 وRFC 542 وRFC 640 وRFC 765 وRFC 959 وRFC 1123. تثبت هذه المصادر فئات الرد والاتصالين وأسباب الإغلاق وتسلسل ABOR.

لاحظت RFC 1123 سنة 1989 أن الاستئناف وABOR ووضع Block مفيدة للمتانة، لكنها لم تكن واسعة التنفيذ آنذاك. ذلك وصف تاريخي، لا قياس للمنتجات الحالية. ولا تثبت المصادر مطابقة تطبيق حديث أو دوام نظام ملفات.