الخلاصة

  • كان على MessageID أن يختلف فقط عن أرقام الطلبات التي ما زالت قيد التنفيذ في جلسة LDAP نفسها. تكرر الرقم في الإدخالات والإحالات والنتيجة النهائية للبحث، فأمكن للردود أن تتداخل من غير أن تختلط.
  • حمل Abandon رقماً خاصاً في غلافه ورقماً آخر للعملية المستهدفة، لكنه لم يُرجع إقراراً بالنتيجة. أضاف RFC 3909 عملية Cancel حين احتاج التطبيق إلى معرفة النجاح أو العجز أو فوات الأوان.
  • استخدمت كل صفحة من البحث المقسم messageID جديداً، بينما حملت cookie معتمة حالة الاستمرار. لم يكن الرقم اعتماد هوية ولا اسماً دائماً للاستعلام ولا دليلاً على التراجع عن كتابة.

لم يكن البحث جواباً واحداً

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

وضع RFC 1487، المنشور في يوليو/تموز 1993، كل عملية داخل غلاف مشترك اسمه LDAPMessage. كان الحقل المشترك عدداً صحيحاً هو messageID، ويجب أن يختلف عن أرقام الطلبات الأخرى المعلقة في جلسة LDAP نفسها. يكرر الخادم القيمة في كل غلاف رد يخص ذلك الطلب.

إذن لم يكن الرقم عداد حزم. يمكن لمئة رسالة إدخال أن تنتمي إلى حالة بحث واحدة. يسمّي distinguished name كائن الدليل، ويحدد نوع protocolOp شكل الرسالة، أما الرقم فيربط الوحدة الواصلة بالحالة المحلية الصحيحة لدى العميل.

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

جعل العمل غير المتزامن الرقم ضرورياً

قرر RFC 1777 سنة 1995 أن العميل والخادم غير ملزمين بسلوك متزامن. يمكن تبادل طلبات وردود عمليات متعددة بأي ترتيب.

قد يصل إدخال من البحث 51، ثم تنتهي مقارنة تحمل 52، ثم تعود بقية إدخالات 51 ونتيجته النهائية. يرتب TCP البايتات، لكنه لا ينسب رسائل التطبيق إلى عملياتها. حوّل Message ID مسار نقل واحداً إلى عدة مسارات منطقية.

أبقى RFC 2251 الآلية في LDAPv3 سنة 1997، وحدد القيمة القصوى بـ2^31−1، ومنع إعادة الرقم قبل الرد النهائي. كانت البرامج عادة تزيد عداداً، لكن الضمان لم يكن الزيادة الرتيبة؛ بل عدم التكرار بين العمل المعلق.

صار البحث يعيد SearchResultEntry وSearchResultReference بترتيب متداخل، ثم SearchResultDone واحداً. وصول إدخال صحيح لا يثبت اكتمال البحث. يخبر الرد النهائي كيف انتهت العملية، ويوفر في الحالة العادية الحد الذي يسمح بإخراج الرقم من سجل العمل الجاري.

احتُفظ بالصفر لكلام الخادم من دون سؤال

أعيد تنظيم مواصفات LDAPv3 عام 2006. يسجل RFC 4510 صلة المجموعة الجديدة بالقديمة، ويعرض RFC 4511 قواعد البروتوكول المنقحة.

أصبح messageID في الطلب غير صفري صراحة. حُجز الصفر لإشعار غير مطلوب يرسله الخادم، مثل Notice of Disconnection. فالإشعار لا يجيب عن طلب عميل، ولا ينبغي أن يبدو كأنه جزء من عملية صفر وهمية.

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

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

سمّى Abandon الهدف بدقة ولم يُخبر بمصيره

عملية Abandon طلب LDAP جديد، ولذلك يحمل غلافها MessageID جديداً. أما المحتوى فيحمل MessageID آخر، هو رقم العملية السابقة التي يريد العميل التخلي عنها. بقي ترابط الفعل الجديد واختيار الهدف حقيقتين منفصلتين.

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

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

لذلك أجّل RFC 2251 إعادة استعمال رقم Abandon ورقم الهدف إلى أن يصل رد على طلب أُرسل لاحقاً. لم يكن ذلك الرد تصديقاً للتخلي؛ كان دليلاً حذراً على أن معالجة الجلسة تقدمت بما يكفي لتقليل خطر الخلط الفوري.

أنشأ Cancel نتيجة جديدة بدلاً من تضخيم الإشارة القديمة

عرّف RFC 3909 سنة 2004 عملية Cancel الموسعة للتطبيقات التي تحتاج إلى معرفة النتيجة. لم يغيّر معنى Abandon بأثر رجعي.

يحمل غلاف Cancel رقمه الخاص، ويحمل cancelID رقم العملية المستهدفة. إذا نجح الإلغاء يعيد الخادم success لطلب Cancel، وتنتهي العملية المستهدفة بالنتيجة canceled. وتفصل النتائج الأخرى بين عملية لا يعرفها الخادم، وعملية لا تقبل الإلغاء، وطلب وصل بعد فوات الأوان.

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

لا يمكن إلغاء Bind وStartTLS وUnbind وAbandon وCancel نفسه. تنشئ هذه العمليات أو تغير أو تنهي علاقة المصادقة والأمن التي تستمد منها أرقام العمليات العادية معناها. لم يسمح البروتوكول لمفتاح ترابط أن يحكم الإطار الذي يكوّنه.

احتاجت الصفحة التالية إلى عملية جديدة

يبين RFC 2696 ضيق وظيفة الرقم بوضوح. يضع الخادم cookie معتمة في SearchResultDone. عندما يطلب العميل الصفحة التالية، يكرر قيم البحث لكنه يغير messageID، ويرسل آخر cookie، وقد يغير حجم الصفحة.

كل صفحة عملية LDAP جديدة. تحمل cookie حالة الاستمرار بين العمليات. قد تصبح قيمة قديمة غير صالحة، وتعلن cookie الفارغة نهاية السلسلة. يمكن لـAbandon وقف صفحة جارية لكنه قد يبطل cookie. أما إنهاء السلسلة ترتيباً فيستخدم بحثاً جديداً بحجم صفر وآخر cookie.

يجيب Message ID عن سؤال: أي عملية جارية في هذه الجلسة أنشأت الرسالة؟ وتجيب cookie: أي موضع نتيجة يسمح الخادم لعملية لاحقة باستئنافه؟ أما اسم الكائن والإذن وصحة السمات فلها أدلة أخرى.

حدود ما تثبته المصادر

تتكون الحزمة التاريخية المغلقة من RFC 1487، وRFC 1777، وRFC 2251، وRFC 2696، وRFC 3909، وRFC 4510، وRFC 4511. تثبت هذه النصوص القواعد وتطورها، ولا تقيس الانتشار الحالي أو تصدق منتجاً أو تثبت مصير عملية بعينها.

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