الخلاصة

  • مثّل STRU P الملفات غير المتصلة كصفحات مستقلة مفهرسة؛ وكان Page Index يحدد موضع الصفحة في الملف، لا ترتيب عبورها الشبكة.
  • لم تُرسل الخانات الفارغة في جدول الصفحات، بينما ظلت الصفحة الموجودة ذات القيم الصفرية محتوى فعلياً. وشددت RFC 959 على أن الفجوة ليست صفحة أصفار.
  • نشأت البنية أساساً من احتياجات TOPS-20 وNLS. ثم لم توص RFC 1123 بتنفيذها عموماً، لكنها ألزمت باستخدام الصيغة القياسية عند الحاجة الحقيقية إلى ملفات متقطعة أو عشوائية الوصول.

موضع صامت في الخريطة

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

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

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

ثلاث طبقات لوصف ملف واحد

فصل FTP بين TYPE للتمثيل المنطقي، وSTRU للتنظيم الداخلي، وMODE لتأطير النقل على اتصال البيانات. تتفاعل الخيارات من دون أن يحل أحدها محل الآخر.

اعتبرت File Structure الافتراضية الملف سلسلة متصلة من بايتات البيانات. وحافظت Record Structure على سجلات متتابعة. أما Page Structure فحافظت على صفحات مستقلة ذات مواضع مفهرسة.

جاء هذا من اختلاف المضيفات. قارنت RFC 959 تخزين الشيفرة في سجلات ثابتة على حاسوب IBM كبير بعرضها كسيل محارف على TOPS-20. من دون إعلان البنية لا يستطيع المستقبل معرفة أي الحدود أصلية وأيها نتيجة تخزينه المحلي.

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

ولهذا لا تكفي بايتات الحمولة لإثبات النتيجة. معلمات النقل الفعالة جزء من الدليل.

نوع الصفحة يفسر طولاً صفرياً

اشتمل الحد الأدنى لرأس الصفحة على Header Length وPage Index وData Length وPage Type. وكان كل حقل بايتاً منطقياً تحدد TYPE عرضه.

منع Page Type طول البيانات الصفري من حمل معنى واحد. أغلقت Last Page النقل برأس أدنى ومن دون بيانات. حملت Simple Page بيانات عادية. نقلت Descriptor Page معلومات تخص الملف كله. وأضافت Access Controlled Page حقلاً مرتبطاً بالصفحة.

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

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

الحاجة المحددة في TOPS-20

تنسب RFC 765 وRFC 959 الدافع الرئيسي إلى النقل الكفء بين أنظمة TOPS-20، وخاصة ملفات NLS.

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

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

استعمل المثال الموثق TYPE L 36, STRU P, MODE S. كان الحقل المنطقي كلمة TOPS-20 بطول 36 بتاً. عين الفهرس مكان الصفحة، وحملت صفحة الوصف السمات العامة، وأمكن لصفحة البيانات أن تحمل معلومات التحكم الخاصة بها.

لم يفرض ذلك تخزين TOPS-20 على بقية المضيفات. بل قدّم صيغة مشتركة لمن يحتاج إلى إبقاء تلك الفروق ظاهرة.

فجوة وصفحة صفرية وصفحة مختصرة

سمح الملحق أيضاً بحذف الأصفار النهائية داخل صفحة موجودة عبر تقليل Data Length. وهكذا توجد ثلاثة أسباب مختلفة لقلة ما يعبر الاتصال.

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

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

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

غير موصى بها، لا خاصة

لم توص RFC 1123 بتنفيذ Page Structure عموماً. كانت وظيفة متخصصة لا ينبغي أن تثقل الحد الأدنى المشترك لكل مضيف.

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

بقيت File Structure مطلوبة. وطُلبت Record Structure من المضيفات التي تدعم أنظمة ملفاتها السجلات. وظلت Page Structure اختيارية. إلزامية الأمر STRU لا تعني أن كل رمز وسيطة مدعوم.

ما يثبته سجل IANA

أدرجت RFC 5797 STRU ضمن أوامر الأساس الإلزامية. ويحفظ سجل IANA لأوامر FTP وامتداداته وصف File Structure وفئة ضبط المعلمات ومرجع RFC 959.

ينسق السجل الاسم والدور. لا يثبت أن خادماً يقبل P، أو أن عميلاً يعيد جدول TOPS-20، أو أن بيانات التحكم تبقى، أو أن الوظيفة مستخدمة اليوم.

وجود الأمر في السجل ليس وجود القدرة على الخادم. وغياب صفحة عن النقل ليس وجود صفحة أصفار في الملف.

لا تملأ الغياب تلقائياً

تدمج صيغ حديثة كثيرة الغائب والصفر والمجهول والمحجوب وغير المنطبق في قيمة واحدة. يسهل التحليل وتضيع دلالة المصدر.

يترك STRU P انضباطاً مفيداً: مثّل الغياب صراحة، وافصل الموضع المنطقي عن ترتيب الوصول، وانقل بيانات إعادة البناء، واختبر إمكان عكس التحويل.

لم تكن الصفحة الغائبة تنتظر إصلاحاً. كان مكانها الفارغ جزءاً من الملف.

المصادر