وصل الملف. أربعة بتات بقيت في المحطة

الخلاصة

• اقترحت RFC 913 أنماط ASCII وBinary وContinuous لبروتوكول بسيط لنقل الملفات. صفحة TOPS-20 المؤلفة من 512 كلمة، في كل منها 36 بتاً، تنتج في أمثلة الوثيقة 2560 و2048 و2304 بايتات ذات ثمانية بتات على الترتيب.
• يأخذ Binary أربعة بايتات من كل كلمة ويترك بتاتها الأربعة الأخيرة؛ أما Continuous فيصل البتات عبر حدود الكلمات ويحمل السلسلة كاملة. وصول التدفق المختار لا يثبت أن كل بت في صفحة المصدر كان جزءاً منه.

يعرض الحاسوب رسالة نجاح، فيفتح المستخدم الملف ويبحث عن محتواه. إن وجد نقصاً، فالوصلة قد تكون بريئة تماماً: نقلت كل بايت طُلب منها نقله. في سبتمبر 1984 قدّم Mark Lottor في RFC 913 بروتوكولاً اسمه Simple File Transfer Protocol. استعمل الاختصار SFTP على منفذ TCP رقم 115، وهو تصميم أقدم ومختلف عن أداة نقل الملفات التي ارتبط اسمها لاحقاً بـSSH. أراده أكثر نفعاً من TFTP وأسهل تنفيذاً من FTP، باستخدام اتصال TCP واحد. وكانت كلمة الأمر TYPE هي التي تحدد هيئة الحمولة.

اختار المؤلف حاسوب TOPS-20 مثالاً. كل كلمة تخزين فيه طولها 36 بتاً، والصفحة تضم 512 كلمة؛ المجموع 18432 بتاً. في نمط ASCII تؤخذ خمسة أحرف طول الواحد منها سبعة بتات من كل كلمة، أي 35 بتاً، ويظل البت الأخير خارج تمثيل النص. ينتقل كل حرف في وحدة من ثمانية بتات مع تصفير البت الأعلى، وتتحول نهايات السطور المحلية إلى CRLF وفق NETASCII. لذلك تخرج من الصفحة 2560 بايتاً. هذا عمل مناسب حين يكون المطلوب نصاً قابلاً للقراءة على آلات مختلفة؛ وهو اختيار مختلف عن نقل الصورة الكاملة لبتات القرص.

اسم Binary يوحي بالحفظ الشامل، لكن تعريفه في المذكرة أدق. يستخرج أربع مجموعات من ثمانية بتات من كل كلمة ذات 36 بتاً. ترحل 32 بتاً وتبقى البتات من 32 إلى 35. تصبح الصفحة 2048 بايتات منقولة. هل كانت البتات المتروكة تحمل معلومات مهمة؟ يتوقف ذلك على تنظيم الملف الأصلي. لا تسرد المذكرة حادثة فقدان بعينها؛ إنها تكشف أن كلمة «ثنائي» هنا تعني وحدات نقل من ثمانية بتات، ولا تعني نقل كل بت في كلمة المصدر. يمكن للقطار أن يصل بدقة وقد ترك جزءاً من الأمتعة حسب لائحة الشحن.

في Continuous لا تتوقف التعبئة عند نهاية كل كلمة. بعد إخراج أربعة بايتات كاملة من الأولى، تتحد بتاتها الأربعة الباقية مع البتات الأربعة الأولى من الثانية. تستمر السلسلة حتى تعبر بتات الصفحة كلها، فتصير 18432 بتاً في 2304 بايتات. تقول RFC إن Binary وContinuous ينبغي أن يتطابقا عندما يكون عرض كلمة الآلة من مضاعفات الثمانية. عرض TOPS-20 البالغ 36 بتاً جعل التمييز ضرورياً. الأول يأخذ بايتات من كل كلمة؛ الثاني يحفظ الشريط الكامل. ويبقى على جهاز الاستقبال أن يعرف كيف يعيد تفسير الشريط ملفاً نافعاً.

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

تصنف بطاقة RFC Editor المقترح اليوم وثيقة تاريخية. أرقام الصفحة الثلاثة أمثلة حسابية، وليست إحصاءً لملفات ضاعت. ومع ذلك، فإن صفحة واحدة تتحول بقرار واحد إلى 2560 أو 2048 أو 2304 بايتات تكفي لسؤال نافذ: من الذي قرر تعريف «الملف» قبل أن يبدأ نقله؟ الشبكة تستطيع أن تؤدي عملها بامتياز، فيما أربعة بتات من كل كلمة لم تحصل أصلاً على تذكرة السفر.