الخلاصة

  • نقل الملف يسلّم معلومات؛ أما طلب execute البعيد فيطلب من حاسوب آخر تنفيذ عمل. جمع RFC 114 بينهما في اقتراح محدود.
  • فصل RFC 171 وRFC 172 لاحقاً نقل البيانات عن أوامر الملفات في FTP. وأبقى RFC 172 التنفيذ البعيد ممكناً من دون إجراء معياري.

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

لم تكن كلمة «ملف» في RFC 114 تعني وثيقة يراد نسخها فحسب. يحمل عنوان المقترح تاريخ 16 أبريل 1971، بينما يسجل فهرس RFC Editor تاريخ 1 أبريل. ووصف معاملات تتيح لعمليات متعاونة استخدام نظام ملفات مضيف آخر. شملت العمليات التعرف والاسترجاع والتخزين والإلحاق وإعادة التسمية والحذف والفتح والإغلاق والبحث؛ كما شملت execute.

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

كان السياق المقصود محدداً ومحدوداً. يقول RFC 114 إن البروتوكول طُوّر للتنفيذ الفوري على مضيفين في معهد ماساتشوستس للتكنولوجيا، هما GE 645/Multics وPDP-10/DM/CG-ITS، وربما على مضيف في هارفارد أيضاً. وكانت نسخة مؤقتة محدودة الإمكانات قيد التصحيح. يثبت ذلك وجود جهد تنفيذي بعينه، لكنه لا يثبت عمل كل معاملة مدرجة ولا انتشار البروتوكول عبر الشبكة.

توضح وثائق التصميم اللاحقة الحد الفاصل. اقترح RFC 171 الصادر في يونيو 1971 بروتوكولاً مشتركاً لنقل البيانات يخدم تطبيقات متعددة: نقل الملفات، وإدخال المهام عن بعد، والبريد، والرسوميات، والتنفيذ البعيد للبرامج. وكان المبرر معمارياً: فصل النقل عن وظائف التطبيقات يزيد مرونة التنفيذ، ويقلل التعقيد، ويحد من تكاثر البروتوكولات.

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

هذا الفرق مهم: إدراج عملية في نطاق وثيقة لا يجعلها خدمة موثوقة بين التطبيقات المختلفة. وتناقش تعليقات RFC 141 المعاصرة الوصول إلى الملفات المحلية، والمجموعات الفرعية من الأوامر، واحتمال أن يستغرق تنفيذ المهمة زمناً طويلاً. إنها تكشف أسئلة المصممين، لا مسحاً للاستخدام. وتبين المراجعات اللاحقة لـFTP تسلسلاً من المواصفات، لكنها لا تثبت شيوع معاملة execute الواردة في RFC 114.

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

الأدق قراءة ذلك بوصفه تغيراً في نطاق المواصفة، لا قصة ميزة خطرة انتشرت على نطاق واسع ثم أزيلت. يسجل RFC 114 مسودة أولى طموحة وتنفيذاً مؤقتاً محدوداً؛ وتسجل RFC 171 وRFC 172 تقسيماً أوضح للمسؤوليات. تبين الوثائق ما اختار المؤلفون تحديده، لكنها لا تثبت وحدها مدى الانتشار أو السلامة التشغيلية أو سلوك كل مضيف.

المصادر