الخلاصة

  • يسمح RFC 3528 لوكيل الدليل المعزز بالشبكة الذي يقبل التحديث بأن يعيد SrvAck إلى وكيل الخدمة قبل التمرير غير المتزامن إلى وكلاء الدليل النظراء. يثبت الإقرار قراراً محلياً ولا يثبت اكتمال الانتشار.
  • يجب فصل سلطة الكاتب والقبول المحلي والتمرير لكل نظير وإتمام anti-entropy وظهور الاستعلام وعمر التسجيل وحالة الحذف وإمكانية الوصول وصحة الخدمة والنتيجة التطبيقية. حتى الاتفاق التام على السجل لا يجعل ما يصفه السجل صحيحاً في العالم الخارجي.

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

صدر RFC 3528 في أبريل/نيسان 2003 بوصفه بروتوكولاً Experimental. وهو يضيف إلى SLPv2 شبكة كاملة بحسب النطاق بين وكلاء الدليل، وتمريراً مباشراً، وآلية anti-entropy. هذه الآليات توزع ادعاءات الدليل؛ ولا تختبر الخدمة التي تشير إليها.

الإقرار يتعلق بالجهة التي قبلت

يرسل Service Agent التسجيل إلى Directory Agent. يسمى الوكيل الذي يقبل التحديث accept DA. وإذا كان يدعم mSLP، يمرر الحالة لاحقاً إلى النظراء الذين يخدمون النطاقات نفسها.

التمرير المباشر غير متزامن. يستطيع accept MDA إرسال SrvAck إلى MSA قبل أن يرسل Srv(De)Reg إلى MDA آخر. لذلك ينتهي انتظار الكاتب قبل أن تنتهي مهمة الشبكة.

لا ينتقص ذلك من صحة الإقرار. إنه يقول إن وكيلاً معيناً استقبل حمولة بعينها وطبق قراراً محلياً. لكنه لم ير طوابير النظراء أو استعلاماتهم أو نتيجة الاتصال بالخدمة.

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

يتعين أن يضم سجل القبول هوية الوكيل، وهوية MSA ونتيجة توثيقه، والنطاقات، وبصمة الحمولة، وطابع النسخة، وaccept ID، والسياسة، ونوع سبب SrvAck. أما عبارة «نجح التسجيل» وحدها فتخفي حدود الشهادة.

النقل الموثوق لا يجعل المستقبل ماضياً

يحافظ النظيران على اتصال دائم موثوق مرتب يشمل نطاقاتهما المشتركة. يوفر الاتصال ترتيباً للنقل ويغني عن إقرار تطبيقي لكل تحديث يصل من نظير.

لكن موثوقية القناة لا تثبت أن الرسالة التي ما زالت في الطابور وصلت بالفعل. وقد ينقطع الاتصال فتحتاج الحالة إلى anti-entropy. كما لا يثبت TCP أن الطرف المقابل عضو مخول في الشبكة.

بعد المزامنة الأولى، يرسل accept DA التحديثات الجديدة مباشرة إلى النظراء المعنيين إلى أن يقع فشل. والتمرير قفزة واحدة من جهة القبول، وليس فيضاً متسلسلاً بلا ضبط.

لذلك يحتاج كل نظير إلى إثبات مستقل: هويته الموثقة، والنطاقات المشتركة، ومعرف الاتصال، وموضع التحديث، ونتيجة النقل، وآخر frontier شوهد بعد الاستعادة. حالة عامة تقول «mesh online» لا تحدد مرور التسجيل المقصود.

لكل مصدر ترتيبه وليس للشبكة ساعة واحدة

يجمع accept ID عنوان URL الخاص بوكيل القبول مع accept timestamp يزداد رتابياً عند ذلك الوكيل. يجب أن تنتشر تحديثات المصدر نفسه بهذا الترتيب.

أما التحديثات التي قبلتها وكلاء مختلفة فيمكن أن تنتشر بأي ترتيب نسبي. لا تصلح أرقام مصادر مستقلة لتكوين تسلسل كلي للشبكة.

ويضع MSA أيضاً version timestamp للتسجيل. يحسم هذا الطابع أي نسخة من التسجيل أحدث. لا يصلح وقت الوصول بديلاً، إذ قد تصل نسخة قديمة متأخرة بعد نسخة أحدث.

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

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

متجه الملخص يرسم حدود الاستلام

يسجل summary vector، لكل accept DA معروف، آخر accept timestamp وصل. إنه تلخيص لمدى تقدم عدة تدفقات مستقلة.

يطلب النظير الحالات اللاحقة لتلك الحدود. الطلب الكامل يشمل أيضاً المصادر الغائبة من القائمة، بينما يقتصر الطلب الانتقائي على accept IDs المذكورة.

يمكن لطلب انتقائي أن ينجح من دون فحص مصدر محذوف. ولهذا لا تكفي عبارة «اكتملت المزامنة»؛ يجب أن تحفظ مجموعة المصادر التي شملها الطلب.

ترسل الحالات المطلوبة بترتيب accept ID، ثم يعاد SrvAck بعد معالجة طلب anti-entropy. هذا الإقرار يخص المصالحة ولا يخص تسجيل MSA الأول، رغم اشتراكهما في الاسم.

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

الشطب يبقى حالة كي يمنع الرجوع

ينتقل التسجيل في الاستعادة مع المدة المتبقية من عمره، ولا يحصل على عمر كامل جديد. وإلا جددت كل مصالحة الإعلانات القديمة.

وتُحفظ deregistration كحالة تسجيل محذوفة. تعمل هذه tombstone على منع تحديث أقدم متأخر من إحياء ما حذف. ويمكن تطهيرها عندما ينتهي عمر التسجيل الأصلي.

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

ينبغي حفظ هوية التسجيل والنسخة وaccept ID وعلامة الحذف والمدة المتبقية ومسار الاستعادة ومشاهدات الاستعلام. كلمة «محذوف» بلا موضع وزمن تخفي بنية النظام.

النطاق يحدد من ينبغي أن يعرف

تكوّن جميع MDAs التي تخدم نطاقاً واحداً شبكة كاملة. ويحمل اتصال واحد بين نظيرين حالات عدة نطاقات مشتركة. ويكفي أن يسجل MSA لدى مجموعة من MDAs يغطي اتحاد نطاقاتها نطاقاته، ثم يعتمد على التمرير.

لذلك لا يتحدث إقرار في نطاق عن أدلة خارجه. وقد يختار User Agent دليلاً آخر أو نطاقاً آخر، فيرى نتيجة مختلفة من دون أن يكون الإقرار الأول كاذباً.

اختار RFC الشبكة الكاملة للبساطة والاعتمادية، لكنه يذكر عموماً عشرات من MDAs أو أقل، لا عدداً غير محدود. هذا حد تصميمي وليس قياساً لنشر حالي.

وتقسيم نطاق أب إلى نطاقين ابنين يغير واجب التسجيل. قد يحتاج ما كان مسجلاً مرة واحدة إلى الظهور في الاثنين. إدارة النطاقات تغير سطح الاكتشاف وليست مجرد تسمية.

سلطة الإدخال تسبق صدق السجل

يستخدم mSLP توثيق SLPv2. ينبغي لـMDA توثيق MDAs الأخرى قبل peering، وتوثيق MSAs قبل قبول تحديثاتها وتمريرها، وينبغي لـMSA توثيق MDA الذي يستخدمه.

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

اختراق MDA واحد قد يؤثر في الجميع لأن الحالة تنتشر. يوسع fan-out التوافر، ويوسع في الوقت نفسه أثر قرار قبول خاطئ.

يعترف SLPv2 بأن bootstrap من دون إعداد أمني سابق قد يتطلب قدراً من «الإيمان الأعمى». تبقى إدارة المفاتيح وسياسة الثقة مسؤولية نشر، وليستا نتيجة تلقائية لاستخدام البروتوكول.

يسجل IANA الامتداد Mesh-enhancement بالمعرف 0x0006 ويحيل إلى RFC 3528. يثبت السجل معنى الرقم، ولا يثبت التنفيذ أو التفعيل أو التوثيق أو التقارب أو صحة الخدمة.

حتى الاستعلام الناجح ليس فحص صحة

مسار الكاتب غير مسار القارئ. يكتب SA إلى DA، ثم يختار UA لاحقاً DA وفق قواعد اكتشاف ونطاق مختلفة.

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

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

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

سلسلة تمنع السجل من ادعاء أكثر مما رأى

تبدأ السلسلة بهوية البروتوكول وحالته، وتعريف النطاق، وهوية الكاتب واعتماده، وسياسة الثقة وقرار التخويل. وترتبط ببصمة الحمولة وversion timestamp وaccept DA وaccept ID.

يبقى SrvAck الأول دليلاً محلياً لا يتغير. تنشأ أدلة أخرى لتمرير كل نظير وحدود summary vector وطلب anti-entropy. لا ينبغي تعديل معنى الإقرار القديم بحقائق عُرفت بعده.

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

حدود الأدلة

لا يحدد هذا المقال تطبيقاً أو مورداً أو مشغلاً أو شبكة أو وكيلاً أو خدمة أو endpoint أو تسجيلاً أو حادثاً أو انقطاعاً أو هجوماً أو نتيجة عميل. ولا يقيس تبنياً أو حجماً أو زمناً أو نجاح استعلام أو صحة حالية.

يعامل RFC 3528 كبروتوكول Experimental صدر في أبريل/نيسان 2003، لا كمعيار إنترنت. قيمتا 200 ثانية للـkeepalive و300 ثانية للـtimeout قيمتان افتراضيتان في الوثيقة، لا إعداداً أو قياساً لنظام حي.

تحدد السجلات والبيانات الوصفية هوية الوثيقة والقيم المسندة ولا تصادق على running code.

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

الخلاصة محددة: يمكن أن يكون القبول المحلي صحيحاً بينما الانتشار أو الاستعلام أو الخدمة أو التطبيق لم ينجح بعد.

المصادر