الخلاصة

  • العدد المطلوب في RFC 10022 سقف لعدد الرسائل الموجودة داخل كل نطاق، وليس وعدا بعدد دقيق. يستطيع الخادم إعادة نطاق أصغر، كما أن UID في البداية أو النهاية قد لا يشير إلى رسالة موجودة.
  • يغلق OK UIDBATCHES completed مرحلة التخطيط فقط. أما إغلاق المهمة فيحتاج إلى هوية الصندوق وUIDVALIDITY، وحقبة الخطة، وإشعارات التغيّر، والرسائل التي تناولتها الأوامر اللاحقة فعلا، ومصير الرسائل المختفية والجديدة وغير المحسومة.

الحد الفارغ قد يكون صحيحا

يفترض كثير من أنظمة المتابعة أن كل رقم يظهر عند طرف نطاق يعرّف عنصرا حقيقيا. لا يمنح RFC 10022 هذا الضمان. يجوز للخادم أن يعيد النطاق 163886:99703 مع أن الرسالتين ذواتي الرقمين 163886 و99703 غير موجودتين.

تترك عمليات الحذف فجوات في فضاء UID. وقد يختار الخادم حدودا حسابية ملائمة تحيط بعدد تقريبي من الرسائل. عندما ينفذ العميل لاحقا UID FETCH على النطاق، تنطبق العملية على الرسائل الموجودة داخله، لا على نقاطه الفارغة.

وقد ينتهي أقدم نطاق عند UID 1 مع أن أقدم رسالة فعلية تحمل UID 302. وظيفة الرقم 1 هنا أن يجعل وصول الخطة إلى القاع واضحا؛ لا أن ينشئ رسالة وهمية.

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

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

العدد المطلوب يحد الأعلى فقط

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

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

قد تعيد عملية واحدة دفعات فيها 1990 و1977 و2000 رسالة، ثم دفعة أخيرة أصغر. لا يثبت الفرق عطلا تلقائيا، لكنه يمنع العميل من تسجيل العدد المطلوب بوصفه عددا منفذا.

الحجم المطلوب ميزانية عبء. يستطيع المجدول أن يضمن ألا تتجاوز الوحدة سقفا معينا. أما عدد الرسائل التي وُجدت وعولجت فلا يأتي إلا من الأمر التالي ونتيجته.

هناك حد أدنى قدره 500 رسالة. الطلب الأصغر يستحق TOOFEW. يحمي هذا القيد موارد الخادم، ويحمي أيضا قرار UIDONLY بإزالة أرقام التسلسل. لو سُمح بدفعة من رسالة واحدة لأمكن إعادة بناء المواضع الدقيقة من باب آخر. يمنح UIDBATCHES تجميعا خشنا، لا استعادة لسلطة الموضع.

نجاح التخطيط لا يجمّد 6823 رسالة

يعرض RFC 10022 مثالا لصندوق يحوي 6823 رسالة. يطلب العميل دفعات من 2000، فيعيد الخادم أربعة نطاقات مرتبة من أعلى UIDs إلى أدناها. من السهل أن يحول نظام العمليات هذه النطاقات إلى أربع وحدات خضراء ثم يكتب «تمت معالجة الصندوق».

لكن الرسائل الجديدة تحصل على UIDs أعلى من الحد السابق. لا تدخل في وسط النطاقات القديمة، ولهذا تبقى هندستها مستقرة. وفي المقابل تستطيع عمليات EXPUNGE أو VANISHED أن تنقص سكان النطاق. قد يقابل نطاق كان قريبا من ألفي رسالة 1985 رسالة فقط عند تنفيذ FETCH.

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

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

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

الاستجابة الفارغة لا تقول وحدها إن الصندوق فارغ

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

إذا كان في الصندوق أربع دفعات وطلب العميل 6:8، فالاستجابة الفارغة مع OK تعني أن النافذة المطلوبة لا تحتوي نطاقا. لا تعني أن الصندوق كله لا يحتوي رسالة.

السياق جزء من الدليل: الحساب، الصندوق المختار، UIDVALIDITY، tag، الحجم، نافذة الدفعات والوقت. حفظ السطر الأخير وحده يحفظ الإجابة ويمحو السؤال.

كذلك تحمل حالات الرفض معنى قابلا للتصرف. TOOFEW يطلب حجما أكبر. TOOMANY يطلب نافذة أضيق أو تقسيما. LIMIT يطلب إبطاء إعادة الحساب أو تصحيحها. وكتابة نافذة الدفعات 4:1 بدل 1:4 قد تعيد CLIENTBUG. جمعها تحت «خطأ ترقيم صفحات» يهدر السبب والمالك والإجراء.

مئة ألف رسالة ترسم الحد المشترك

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

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

يستطيع العميل التحرك بنوافذ متتابعة. ولأن الصندوق قد يتغير بين طلبين، يقترح النص تداخل الحد، مثل 1:100 ثم 100:200. تكرار الدفعة رقم 100 يسمح بمقارنة رؤيتين واكتشاف الانحراف.

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

يجب حفظ الاستجابتين والوقت والتغيرات بينهما وقرار التسوية. هكذا تبقى آلية مشتركة رفيعة، بينما يظل القرار محليا وقابلا للمراجعة.

لكل امتداد عقد مختلف

يمنع UIDONLY أرقام التسلسل بعد تفعيله ويستخدم VANISHED للإعلان عن الرسائل المحذوفة. يوفر UIDBATCHES نطاقات UID خشنة من دون إعادة سلطة الموضع التي أزيلت.

يقسم PARTIAL نتائج SEARCH الفعلية أو يحد استجابات UID FETCH الفعلية. أما UIDBATCHES فينشئ حدودا قابلة لإعادة الاستخدام قبل التنفيذ. الصفحة جزء من نتيجة أمر؛ النطاق خطة لأوامر لم تقع بعد.

يتيح SEARCHRES حفظ نتيجة بحث في $. يمنع RFC 10022 UIDBATCHES من ملء $ لأنه ليس SEARCH. لا ينبغي أن تتحول الحدود التقريبية خفية إلى مجموعة رسائل مؤكدة.

تساعد QRESYNC وCONDSTORE في رؤية التغير وVANISHED وتسلسلات التعديل. تكشف أن الخطة ابتعدت عن الواقع، لكنها لا تحول خطة قديمة بأثر رجعي إلى لقطة جديدة.

ويعلن MESSAGELIMIT العدد الذي تستطيع أوامر لاحقة معالجته. إذا كان الحد ألف رسالة، ينبغي ألا يطلب العميل دفعة UIDBATCHES أكبر من ألف. صلاحية نطاق من 2000 لا تمنح FETCH حق تجاوز عقده الخاص.

قائمة CAPABILITY ليست مجموعة شارات نجاح. الوحدة القابلة للتنفيذ هي تقاطع العقود والفعل وحالة الصندوق.

سبع مجموعات أفضل من نسبة واحدة

يصبح الإغلاق قابلا للتدقيق عند فصل السكان:

المجموعة سؤال الدليل
P ما الرسائل التي تنتمي إلى سياسة المهمة وجيل الصندوق؟
B ما الرسائل الموجودة التي أمكن الوصول إليها عبر النطاقات عند التخطيط؟
A ما الرسائل التي تناولها أمر لاحق فعلا؟
C ما الرسائل التي نالت نتيجة نهائية مقبولة؟
X ما الرسائل المقصودة التي شوهد حذفها أو اختفاؤها؟
N ما الرسائل الجديدة فوق أعلى حد سابق؟
U ما النتائج المجهولة أو القابلة لإعادة المحاولة؟

يمكن لتصدير محدود زمنيا أن يشترط P = C ∪ X وأن تكون U فارغة مع سبب لكل عنصر في X، ثم يسند N إلى الحقبة التالية. ويمكن لمزامنة مستمرة فتح دفعة جديدة لـN. القرار محلي ولا يحتاج إلى توسيع سلطة المعيار.

لا تكفي مساواة الأعداد. قد تختفي رسالة مقصودة وتصل أخرى فتبقى الحصيلة نفسها بينما تتبدل الهوية. مفتاح التسوية يشمل الصندوق وUIDVALIDITY وUID وحقبة المهمة.

هذا ينسجم مع طرح Heng Lu عن المواصفة الأولية الدنيا والقرار المستقبلي المحلي: يحفظ المشترك الهوية والحدود والقابلية للتحقق، وتبقى خيارات التشغيل لدى من يتحمل أثرها.

ما لا يثبته السجل العام

لا يثبت RFC 10022 أن مزودا مسمى نشر UIDBATCHES، ولا أن عميلا بعينه يحترم قيود إعادة الحساب، ولا أن خادما إنتاجيا يحقق إرشاد 90%. الحالات هنا اختبارات تشغيل مبنية على العقد وليست حوادث منسوبة.

يثبت سجل IANA المعنى المشترك لـUIDBATCHES وTOOFEW وTOOMANY. لا يفحص برنامجا عاملا. CAPABILITY تصريح، واستجابة النطاق حالة تخطيط، ونتيجة الأمر اللاحق أثر. تضخيم طبقة إلى أخرى يمنح وثيقة سلطة على واقع لم تره.

أولوية الكود العامل لا تلغي المعيار؛ بل تسمح للأثر المرصود بتصحيح الخلاصة. إذا بقيت U فلا يستطيع اللون الأخضر أن يعلن الإغلاق لمجرد أن الحساب كان مطابقا.

المصادر