الخلاصة

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

مشكلة الشكل سبقت مشكلة البحث

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

تصف RFC 3663، المنشورة في ديسمبر 2003 بوصفها وثيقة تجريبية، خدمة Referral LDAP التي أطلقتها VeriSign لاختبار استخدام LDAP في بيانات إدارة النطاقات. وكان تقدير التصميم كبيراً: قد تتحول مجموعة علائقية تضم نحو 20 مليون كائن إلى أكثر من 115 مليون كائن في شجرة معلومات الدليل (DIT) غير المطبّعة المقترحة. هذا تقدير ذكرته الوثيقة عند المفاضلة بين التصميمات، وليس نتيجة مؤكدة لبناء خدمة بهذا الحجم. وبذلك صار شكل الدليل مسألة تخزين وتشغيل، لا مجرد اختيار اصطلاحي. RFC 3663

امتدت التجربة من تاريخ أقدم لخدمات الدليل. فقد نصّ العقد الأصلي لـ InterNIC على دليل X.500 لبيانات تسجيل النطاقات الإدارية. وعندما ظهرت مشكلات في برمجيات الخوادم المتاحة، أُنشئ مؤقتاً خادم NICNAME/WHOIS. ثم جاء RWhois لتوسيع النموذج، لكن RFC 3663 تقول إنه لم يحظ بقبول واسع لبيانات النطاقات. كان هدف Referral LDAP أضيق: توفير استعلامات ونتائج منظّمة يسهل على البرامج قراءتها، وإحالة البحث من بيانات السجل إلى خدمة مُسجّل النطاق المناسب بعد انفصال بعض مسؤولياتهما. RFC 954 RFC 2167 RFC 3663

نقلت الإحالات التعقيد إلى العميل

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

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

أما الإحالات بين الخوادم فكان لها غرض مختلف: تمثيل الفصل التنظيمي بين السجل ومُسجّل النطاق، اللذين قد يعملان في مؤسستين أو شبكتين مختلفتين. ومع ذلك، كان من الممكن أن تظهر في النتائج إحالات لا يطابقها مرشح البحث، فتملأ حدّ النتائج المعتاد البالغ 50 مدخلاً. عندها يحصل المستخدم على وجهات متابعة بدلاً من السجلات التي أرادها. تصف الوثيقة ذلك بأنه صعوبة في توزيع الاستعلامات، لا برهان على خلل شامل في LDAP. RFC 3663 RFC 2251

البروتوكول العام لم ينتج عميلاً عاماً

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

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

ولم تختف مسألة تكلفة البحث أو استخراج البيانات بمجرد تنظيم النتائج. كان السماح بأي بحث LDAP قد يحمّل الخدمة العامة كلفة كبيرة، لذلك قصرت التجربة أنواع الاستعلامات المسموح بها. ومع ذلك سأل المستخدمون عن تجاوز القيود باستعلامات قاموسية متكررة؛ وكان كثير من مشغلي WHOIS يصفون ذلك بالتنقيب عن البيانات. أما قسم الأمن فيقول صراحة إن عرض المصادقة بالاسم المميز وكلمة المرور لا يصلح نموذجاً إنتاجياً. RFC 3663 RFC 2026

السؤال كان: من يتولى التحويل؟

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

لاحظت RFC أن البحث يظل يبدأ عند السجل حتى عندما يستهدف مستخدماً خدمة مُسجّل أو صاحب نطاق بعينه. ولم تنفّذ التجربة اكتشاف الخادم عبر DNS SRV أو NAPTR. كما كان فحص خوادم LDAP محدود النطاق: ملفات مناطق .com و.net و.org و.edu، واختبار المنفذ 389 على أسماء النطاقات ومضيفي ldap أو dir، من دون البحث عن سجلات SRV. لذلك فإن تقدير وجود خادم LDAP لدى نحو 0.5% من النطاقات النشطة في العينة لا يمثل مسحاً للإنترنت كله ولا يصف الوضع الراهن. RFC 3663

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

المصادر