الخلاصة

  • أتاحت ALLO للعميل أن يعلن عدد البايتات المنطقية المطلوبة قبل STOR أو APPE، مع قيمة إضافية اختيارية لأقصى سجل أو صفحة.
  • كان على الخادم الذي لا يحتاج إلى تخصيص مسبق أن يعامل الأمر كعملية بلا أثر، وأن يستطيع الرد بـ202 كإتمام إيجابي لأن الأمر زائد في ذلك الموقع.
  • لا يثبت هذا الرد وجود مساحة محجوزة؛ فالدليل الأقوى يأتي من اتصال البيانات، والرد النهائي، وحالة الحصة التخزينية، والملف الذي يمكن قراءته والتحقق منه.

رقم يسبق الملف إلى الخادم

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

سجّل RFC 354 سنة 1972 هذا الاختلاف داخل تعريف ALLOCATE (ALLO). قد تطلب بعض الخوادم الأمر كي تحجز تخزينًا كافيًا للملف الجديد. وكانت وسيطته عددًا عشريًا من البايتات وفق حجم البايت المختار، ثم يتبعه STORE أو APPEND.

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

وسّع RFC 765 سنة 1980 شكل الإعلان. دلّ العدد الأول على البايتات المنطقية اللازمة للملف. وإذا استُخدمت بنية السجلات أو الصفحات أمكن إضافة أكبر حجم لسجل أو صفحة بعد مسافة ثم R ثم مسافة. وكان على الخادم المهتم بالقيمة الثانية وحدها أن يقبل قيمة شكلية في الحقل الأول ويتجاهلها.

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

لماذا كان 202 جوابًا إيجابيًا

حافظ RFC 959 سنة 1985 على الصيغة: عدد عشري، ثم R وعدد آخر عند الحاجة. وأبقى شرط أن يلي ALLO أمر STOR أو APPE، وأن يعامله الخادم كـNOOP إذا لم يحتج إلى معرفة الحجم الأقصى قبل الكتابة.

تظهر الدقة في قواعد الرد. قد يحصل أمر مثل TYPE أو ALLO على 200 عندما يُنفَّذ بنجاح من دون أن يمنح عملية المستخدم معلومة جديدة. وإذا لم ينفّذ خادم معين ALLO لأن الفعل لا صلة له بنظامه، فمع ذلك يُراد رد إتمام إيجابي كي يعرف العميل البسيط أنه يستطيع متابعة خطته. الرمز المخصص هو 202، والنص المثالي يقول إن تخصيص التخزين غير ضروري.

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

أما الفعل غير الخاص بالموقع إذا كان غير منفذ فيستخدم 502، ويعبّر 504 عن وسيطة غير مدعومة في أمر موجود. يميز البروتوكول إذن بين أنواع «لا أفعل ذلك» بحسب أثرها في مقصد المستخدم.

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

عند STOR يبدأ اختبار السعة الحقيقي

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

تقسم الردود العمل إلى مراحل. يدل 125 على أن اتصال البيانات مفتوح وأن النقل يبدأ، بينما يدل 150 على أن حالة الملف مناسبة وأن الاتصال سيفتح. كلاهما رد أولي، لا خاتمة. قد يأتي 226 أو 250 كإتمام إيجابي، وقد تظهر أخطاء اتصال أو معالجة محلية أو مسار أو تخزين.

يعني 452 أن الفعل المطلوب لم يُتخذ لعدم كفاية مساحة التخزين في النظام. ويعني 552 أن فعل الملف أُوقف لأنه تجاوز تخصيص التخزين للدليل أو مجموعة البيانات. لذلك يمكن لجلسة أن تستقبل 202 ثم تفشل لاحقًا بأحد هذين الرمزين من دون تناقض: عدم الحاجة إلى الحجز السابق لا يساوي استحالة نفاد المساحة أثناء الكتابة.

تزداد قوة الدليل مع تقدم التسلسل. يحمل ALLO ادعاء العميل. ويحمل 202 قرار الخادم بأن المتابعة لا تتطلب حجزًا. ويحمل 125 أو 150 خبر بدء مرحلة البيانات. أما الاستنتاج بأن الملف وصل كما ينبغي فيتطلب نهاية مناسبة وفحص الكائن الناتج.

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

الأمر الاختياري ظل قابلًا للوصول

وضع RFC 1123 سنة 1989 دعم الخادم لـALLO في خانة الخيار. لكنه أوجب على برنامج FTP لدى المستخدم توفير QUOTE، وهو طريق يرسل سلسلة حروف اعتباطية إلى الخادم ويعرض كل ردوده.

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

لا يزال سجل IANA لأوامر FTP وامتداداته يدرج ALLO كأمر أساسي بمعنى “Allocate” ويحيل إلى RFC 959. يثبت السجل هوية الكلمة ومرجعها. لكنه لا يثبت أن خادمًا بعينه ينفذها أو يحجز مساحة أو يملك سعة كافية أو أتم نقلًا محددًا.

السجل المفيد يتبع الجلسة حتى الكائن

إذا اختصر نظام المراقبة النتيجة إلى «ALLO ناجح» فإنه يمحو الفرق الذي صممه البروتوكول. يجب الاحتفاظ بنص الأمر، والعددين إن وُجدا، وTYPE وSTRU الفعالين، والرمز العددي، ونص الرد كاملًا. ينتمي 200 و202 إلى الفئة الإيجابية، لكنهما يصفان قرارين مختلفين.

ثم ينبغي ربط التحضير بـSTOR أو APPE: هل فُتح اتصال البيانات؟ كم بايتًا أُرسل واستُقبل؟ هل انقطع النقل؟ ما الرد النهائي؟ هل وُجد الملف بالحجم والبصمة المتوقعين؟ ولإثبات السعة يجب حفظ المساحة الحرة والحصة وحدود الدليل والنشاط المتزامن في الوقت المناسب.

لا تكفي البايتات المنطقية لحساب الاستهلاك المحلي. قد تغيّر بنية السجلات والتمثيل وملفات sparse والبيانات الوصفية وسياسة الملف المؤقت الكلفة الفعلية. البروتوكول ينقل معلومة التخطيط، ولا يحل محل محاسبة التخزين.

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

المصادر