الخلاصة

  • جعلت RFC 1068 واجهة المستخدم تضع معلمات عملية FTP في طابور دائم على مضيف تحكم، ثم تركت لعفريت FTC جدولة الاتصال بخادمين والمحاولة من جديد. كان submit يثبت بقاء الأمر، لا عبور الملف.
  • عند وجود ملفات متعددة، ثبّت BFTP أعضاء الدفعة من أول نتيجة NLST ناجحة، واحتفظ بتقدم كل عنصر. وقد ينتهي الطلب بنجاح الجميع أو بفشل دائم أو بنفاد المحاولات؛ لذلك حمل التقرير الخاص بكل ملف معنى النتيجة الفعلية.

تنطلق RFC 1068 من عبء بشري بسيط: كان نقل FTP في الواجهة الأمامية يحتاج إلى شخص يراقبه، وإذا غاب المضيف البعيد أو انقطع الاتصال أعاد الشخص الأمر بنفسه. ومع ازدياد الازدحام والتأخير وعدم الإتاحة، أصبح حضور المستخدم جزءاً من آلية التعافي.

نقل BFTP ذلك الحضور إلى حالة محفوظة. تجمع واجهة تفاعلية تفاصيل العمل، ثم يتولى عفريت للتحكم في نقل الملفات، FTC، التنفيذ لاحقاً. لم تقترح المذكرة بروتوكولاً سلكياً جديداً؛ بل قالت إنها تريد تحفيز النقاش. كان الابتكار هو إحاطة FTP بطابور وموعد وعدّاد محاولات وسجل تقدم وإشعار بريدي.

احتفظ مضيف التحكم بوصف للعمل لا بنسخة الملف

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

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

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

أصدر المتحكم الأوامر فيما سلكت البايتات طريقاً آخر

استخدم BFTP نموذج FTP بين خادمين الوارد في RFC 959. فتح FTC اتصال تحكم مع المصدر وآخر مع الوجهة. طلب PASV في جانب، ومرر عنوانه ومنفذه إلى الجانب الآخر بواسطة PORT، ثم قرن RETR بـ STOR. نشأ اتصال البيانات مباشرة بين خادمي FTP، فتجاوزت البايتات مضيف التحكم الذي يحتفظ بالطابور.

لذلك خلّف النظام ثلاثة أنواع من الأدلة. وصف الطابور ما أراده المتحكم. وسجل اتصالا التحكم الأوامر التي قبلها كل خادم أو رفضها. وحمل اتصال البيانات المحتوى. طلبت RFC 959 بقاء اتصالي التحكم مفتوحين أثناء النقل وانتظار الرد النهائي 226 أو 250 قبل أمر النقل التالي. لا يكفي رد تمهيدي أو اتصال مقبس أو إغلاق مسار البيانات وحده لإثبات نتيجة الملف.

واعتمد التركيب على خوادم غير متجانسة. احتاج جانب واحد على الأقل إلى PASV. تسجل RFC 1068 نتائج NLST غير معيارية، وردوداً سيئة التكوين، وخوادم أعادت أخطاء انقطاع الاتصال على هيئة 5xx دائمة بدلاً من 4xx مؤقتة. لا يستطيع محرك المحاولة أن يصنف الواقع بدقة أعلى من لغة الأعطال التي يتلقاها.

عاشت الموثوقية فوق جلسة FTP الواحدة

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

أصبحت عائلتا 4yz و5yz في RFC 959 قراراً عملياً. تقول 4yz إن الفعل لم يحدث ولكن يمكن إعادة الطلب نفسه. أما 5yz فلا تشجع على التكرار من دون تغيير. فإذا صُنّف انقطاع قابل للتعافي على أنه دائم، ألغى العفريت محاولة كان يمكن أن تنجح. وإذا عُكس التصنيف، استمر الطابور في عمل لا طريق له إلى التقدم.

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

جعل أول تعداد ناجح حدود الدفعة ثابتة

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

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

استخدمت RFC 1068 كلمة «مكتمل» في ثلاث حالات: نجاح جميع العناصر، أو حدوث فشل دائم، أو نفاد مرات المحاولة. كان الاكتمال يعني أن العفريت لن يجدول عملاً آخر، لا أن كل نسخة موجودة في الوجهة. لذلك عدد الإشعار حالة كل ملف؛ فالسجل التفصيلي وحده يفرق بين نجاح كامل ونتيجة جزئية وفشل.

أتاحت الكلمة المفتاحية العثور، لا هوية قوية

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

ظهر لاحقاً حد أمني آخر لسلطة الاتصال بين طرفين. شرحت RFC 2577 كيف يمكن لأمر PORT في FTP الوكيل أن يدفع خادماً إلى الاتصال بخدمة أخرى، أي هجوم FTP bounce، وكيف قد تؤدي القيود إلى فقد وظيفة الوكيل. لا تثبت الوثيقة وقوع حادث في BFTP. لكنها تبين أن من يختار وجهة الاتصال يمارس سلطة حقيقية، ولو لم تمر البايتات عبره.

حدود ما تقوله المصادر

تصف RFC 1068 تنفيذاً استُخدم بضعة أشهر في ISI، ولا تثبت انتشاراً عاماً أو نسباً مباشراً لطوابير الأعمال الحديثة. توفر RFC 959 فصل مساري التحكم والبيانات ومعاني الردود، وتضيف RFC 2577 حداً أمنياً لاحقاً. ولا تثبت أي منها تسليم ملف مسمى أو أمان الاعتمادات أو وجود نشر حالي.

الدلالة التاريخية أضيق من ذلك: دوام النية يساعد على إعادة المحاولة، لكنه ينشئ آلة حالات ثانية يجب ألا تختلط بالشيء الذي تأمر به. يستطيع الطابور أن يقول «حاول». أما ما حدث بالفعل فتقوله أدلة كل ملف.