حين اختار المستقبل الوعاء ولم يملك حق البتر

الخلاصة

• ثبّت FTP الناضج وحدة النقل في ثمانية بتات، لكنه أبقى في TYPE L حجماً منطقياً مستقلاً وإلزامياً يمكن أن تعبر حدوده وسط بايت النقل.
• يملك المستقبل اختيار تمثيل محلي مناسب، شرط أن يكون التحويل قابلاً للعكس وأن يعيد الملف المطابق إذا استُخدمت المعلمات نفسها في الحفظ والاسترجاع.
• يتعامل Image مع سلسلة بتات متصلة، أما Local فيضيف حدود الوحدات. لا يثبت قبول الأمر معنى البيانات ولا الحجز المادي ولا الانتشار الحالي لأي حجم.

حرية التخزين ليست حرية تغيير الشيء

يضرب RFC 959 مثالاً بوحدات منطقية طولها 36 بت تصل إلى مضيف كلماته 32 بت. يمكن للمضيف أن يضع كل وحدة في كلمة مزدوجة من 64 بت كي يسهل التعامل معها. الفراغ المحلي الباقي لا يصبح جزءاً من الملف الذي عبر الشبكة.

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

لم يكتف البروتوكول بكلمة «مناسب». اشترط أن يكون التحويل قابلاً للعكس، وأن يُعرّف المنفذون طريقته. إذا حُفظ الملف واستُرجع بالمعلمات نفسها، وجب أن يخرج مطابقاً. هذه هي الحافة التي تحول الاختيار المحلي من تحكم مطلق إلى مسؤولية قابلة للاختبار.

أول FTP حاول تسمية اختلافات الآلات نفسها

في RFC 114 الصادر سنة 1971، لم تكن الأنواع مجرد نص وصورة. شملت القائمة أشكالاً متعددة من ASCII وEBCDIC وSIXBIT، وأعداداً عشرية وثمانية وسداسية عشرية، وأعداداً صحيحة بتمثيلات مختلفة للإشارة، وصيغ فاصلة عائمة تخص IBM 360 وPDP-10. بعض الحقول سمح بحجم من بت واحد إلى 255 بتاً.

كانت معلومات النوع تفسيرية. المضيف الذي يقبل النوع يستطيع تحويله إلى تنظيم داخلي يلائم آلته. آلة بكلمة من 36 بت قد تضع خمسة محارف ASCII من سبعة بتات في كلمة، أو أربعة محارف من ثمانية أو تسعة بتات، أو ستة محارف SIXBIT.

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

حين كان حجم بايت اتصال البيانات متغيراً أيضاً

فصل RFC 354 في 1972 بين نوع التمثيل وحجم البايت المستخدم على اتصال البيانات. استخدم ASCII وبعض أنواع الطباعة ثمانية بتات، بينما استطاع Image وLocal Byte استعمال حجم آخر يختاره الطرفان.

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

اعتمد تحويل Local Byte آنذاك على حجم النقل وعلى المضيف المعين. كان عليه أن يكون قابلاً للعكس ومعلناً. وبقي على المستخدم أن يحفظ النوع والحجم اللذين استعملهما. انتهاء الاتصال لم يمح قيمة هذا السياق.

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

ثمانية بتات أصبحت قاعدة الطريق لا تعريفاً للملف

بسّط RFC 765 النموذج: صار بايت النقل دائماً ثمانية بتات. حافظ RFC 959 على الفصل، وذكر حجمين يجب عدم الخلط بينهما: حجم البايت المنطقي الذي يفسر بنية الملف، وحجم بايت النقل على اتصال البيانات. وقد يختلف كلاهما عن كلمة التخزين الفعلية في النظام.

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

تُحزم الوحدات المنطقية متتابعة بلا فراغ، متجاهلة حدود بايتات النقل. لم يمنع تثبيت الطريق في ثمانية بتات الملفات ذات الوحدات التساعية أو ذات 18 و36 بتاً. نقل عبء التغليف إلى الطرفين وخفّض ما يجب على الوسط فهمه.

تسعة بايتات تحمل كلمتين

المثال الأشهر يستخدم مضيفين بكلمات من 36 بت وTYPE L 36. مجموع كلمتين 72 بتاً، أي تسعة بايتات نقل. تحمل البايتات الأربعة الأولى 32 بتاً من الكلمة الأولى. تكمل البتات الأربعة الأولى من البايت الخامس تلك الكلمة، وتبدأ البتات الأربعة الباقية الكلمة الثانية.

لذلك لا يملك وسيط أن يعامل كل بايت نقل كعنصر ملف مستقل. قد ينسخ كل الثمانيات من غير خطأ، ثم يفسد الحدود. كما لا يملك أن يبدأ وحدة جديدة عند حد حزمة IP أو مقطع TCP؛ تلك حدود لحمل النقل وليست قواعد التمثيل.

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

الحشو دين في النهاية لا فاصل بين الوحدات

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

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

حتى رؤية أصفار في التقاط شبكة لا تثبت أنها حشو. يلزم معرفة TYPE الفعّال والحجم والبنية ونقطة النهاية. من دونها لا يرى المحلل إلا أوعية من ثمانية بتات.

Image وLocal قد ينتجان الشيء نفسه بدليلين مختلفين

يعامل Image البيانات كسلسلة بتات متصلة، تُحزم في بايتات النقل. يجب على المستقبل حفظ الاستمرار. وإذا فرض التخزين محاذاة إلى كلمة أو كتلة، فلا يظهر حشو الأصفار إلا في نهاية الملف أو السجل، ويجب أن يمكن تمييزه ونزعه.

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

يشرح RFC 1123 أن TYPE L 8 يعادل Image في آلة بايتاتها ثمانية بتات. وبين آلتين بكلمات من m بت، ينبغي أن يكون لـTYPE L m أثر Image نفسه. هذه مساواة مشروطة بالهندسة المعروفة، لا إذن باختراع حد m عندما أرسل الطرف Image فقط.

الحد الإلزامي بقي ضيقاً

يفرض RFC 1123 دعم TYPE I وTYPE L 8. ويجيز لآلة ذاكرتها منظمة في كلمات من m بت، حين لا يكون m مضاعفاً للثمانية، أن تدعم TYPE L m أيضاً.

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

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

المعلمات نفسها جزء من وعد الهوية

يظهر شرط المعلمات نفسها في الاسترجاع لأن التحويل المحلي حالة مستمرة. لا يَعِد FTP بأن ملفاً خُزن بـTYPE L 36 سيخرج مطابقاً إذا طُلب لاحقاً بـTYPE L 8. ولا يستطيع أرشيف حذف طريقة التحويل ثم توقع أن يستنتجها برنامج آخر من الأوعية المحلية.

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

تناولت مقالة FTP restart المنشورة لماذا لا تكون علامة الاستئناف مجرد رقم بايت: المستقبل قد يحتاج إلى ترميز حالة تحويله. TYPE L يحدد وحدة تدخل ذلك التحويل، بينما تحدد العلامة موضعاً لاستعادته. حفظ أحدهما لا يعوض ضياع الآخر.

ALLO يعد بالوحدة ولا يصنعها

كان ALLO يستطيع التعبير عن تقدير مساحة بعدد البايتات المنطقية. النوع الفعّال هو الذي يعرّف هذه الوحدة. لا ينشئ أمر الحجز حد 36 بتاً، كما أن الرد الإيجابي عليه لا يثبت أن كتل قرص حُجزت فعلاً.

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

السجل يعرف اسم الأمر لا خزانة المضيف

يسجل IANA أوامر وامتدادات FTP الأمر TYPE بوصفه Representation Type ويربطه بالمواصفة. يثبت ذلك الاسم والمرجع.

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

كلما قل ما يفسره الطريق زادت قيمة الأصل عند الطرف

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

ينجح هذا التواضع فقط إذا احتفظ الطرفان بما رفض الطريق أن يعرّفه. سلسلة البتات والنوع والحجم والبنية وإصدار التحويل هي معاً أصل قابل للاسترجاع. تسعة بايتات سليمة لا تثبت هل كانت تسعة وحدات أم كلمتين من 36.

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

تعتمد المقالة على RFC 114، وRFC 354، وRFC 765، وRFC 959، وRFC 1123، وسجل IANA. تثبت هذه الوثائق التصميم والواجبات، لا نسبة الانتشار الراهن ولا سلوك منتج بعينه ولا معنى تطبيقي لقيمة من 36 بتاً.