الملخص

  • جعل RESERVE اسم صندوق البريد غير متاح لمطالبة أخرى، لكن RFC 3656 أوضح أن ذلك لا يعني أن الصندوق أصبح جاهزاً للعميل.
  • وصفت MAILBOX السجل النشط المتاح بعد الإنشاء المحلي وACTIVATE. أوصى البروتوكول بهذا الترتيب، لكنه اعتمد على تعاون المشاركين ولم يفرض الحجز شرطاً مسبقاً على الخادم.

الاسم أولاً، والصندوق بعده

تحتاج مجموعة خوادم البريد إلى إجابتين مختلفتين: أي خادم يملك الاسم، وهل يمكن للعميل استخدام الصندوق الآن؟ فصل RFC 3656، المنشور كبروتوكول تجريبي في ديسمبر 2003، بين الإجابتين. هدف MUPDATE إلى منح خوادم IMAP أو POP3 فضاء أسماء موحداً بينما تتقاسم عدة آلات مسؤولية التسليم.

بدأ التسلسل المعتاد بأمر RESERVE. يطلب العميل من الخادم الرئيسي حجز اسم صندوق في موقع محدد. وبعد وصول OK، ينشئ الصندوق محلياً ثم يرسل ACTIVATE مع الاسم والموقع وACL. يجعل التفعيل الناجح السجل نشطاً. ويمكن للموقع أن يوجّه العميل إلى الخادم الذي يخزن الصندوق، فيما تصف ACL حقوق الوصول.

توضح الاستجابتان الحد الفاصل. تعني RESERVE أن الاسم لم يعد متاحاً لمطالب آخر، لكن RFC ينص صراحة على أن ذلك لا يعني أن الصندوق متاح للعملاء في اللحظة نفسها. أما MAILBOX فتصف سجلاً جاهزاً للوصول. مساواة الرسالتين تحول قفل الاسم إلى إشارة توافر مضللة: قد لا يكون الكائن المحلي قد أُنشئ، أو قد لا تكون عملية الإنشاء قد انتهت.

الذرّية كانت انضباطاً مشتركاً

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

تكشف الصياغة المعيارية هذا الحد. SHOULD حجز الصناديق الجديدة قبل تفعيلها، لأن التصميم يفترض تعاون الحسابات المصادق عليها للحفاظ على ذرّية العمليات. ومع ذلك لا يشترط ACTIVATE وجود حجز سابق. تسمح المواصفة بذلك لتسهيل المزامنة مع الموقع الفعلي للصناديق. ويمكن لمشارك يتجاوز قفل الاسم المشترك أن يسهم في قاعدة غير متسقة؛ فالقاعدة لا تستطيع استنتاج معاملة محلية لم يُبلّغها أحد بها.

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

لاستجابة النسخة حد زمني

بعد إصدار التابع UPDATE، يرسل الرئيسي قائمة أولية ثم يبث التغييرات اللاحقة. وتطلب المواصفة إرسال التغيير الذي يقع في قاعدة الرئيسي إلى التابع خلال 30 ثانية. يستطيع التابع إرسال NOOP؛ وبعد UPDATE لا يجوز أن يعود OK إلا بعد إرسال جميع التحديثات المعلقة لحظة NOOP. هذه نقطة مزامنة محددة، وليست ضماناً بأن قاعدة البيانات ستظل محدثة عالمياً بعد الرد.

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

المصادر