الخلاصة

  • يتيح RFC 3082 لوكيل المستخدم الاشتراك في تغيّرات الخدمات بدلاً من الاستعلام المستمر؛ ويختلف مسار الإشعار باختلاف وجود Directory Agent من عدمه.
  • إذا اختفى DA، يستطيع وكلاء الخدمة الذين تلقوا التعليمات من قبل مواصلة الإرسال، لكن وكيلاً جديداً قد لا يتلقى الاشتراك. استمرار الإشعارات القديمة لا يثبت بقاء تغطية الخدمات الجديدة.

الاستعلام ليس موجز أحداث

بُني Service Location Protocol على الاكتشاف عند الطلب: يعلن وكلاء الخدمة (SAs) عن خدماتهم، ويبحث وكلاء المستخدم (UAs) عنها عند الحاجة. أما التطبيق الذي يريد تحديث صورته المحلية كلما ظهرت خدمة أو اختفت، فعليه أن يستعلم من الشبكة دورياً. صدر RFC 3082 في مارس 2001 بوصفه بروتوكولاً تجريبياً، واقترح إشعار العملاء بالتغيير لتجنب الاستعلامات المتكررة. وهو لا يحدد معياراً للإنترنت.

يبدو الانتقال من السؤال إلى الاستماع بسيطاً إلى أن يظهر سؤال الوكيل الجديد: من يخبره أن هناك UA يستمع؟ يجيب RFC 3082 بطريقتين، وفق وجود Directory Agent (DA). ولا تحتفظ الطريقتان بالحالة نفسها في الموضع نفسه.

طوبولوجيتان وتكلفتان مختلفتان

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

في الشبكات الأكبر ذات DAs، يضيف UA امتداد Subscribe إلى طلب الخدمة. يعيد DA عناوين مجموعات متعددة الوجهات NotifyAt الموافقة لنوع الخدمة والنطاق. ويمكنه إخطار SAs القائمة بإعلان DAAdvert؛ كما قد يتضمن SrvAck المرسل إلى SA جديد ومطابق الامتداد نفسه. وعند انتهاء إعلان خدمة من دون إلغاء منظم، يرسل DA إشعار الإلغاء أيضاً. يظل SA هو المرسل الأساسي للأحداث، ولا يتحول DA إلى مرحّل مركزي لكل رسالة.

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

ما يختفي وما يستمر

يصف القسم العاشر إخفاقاً جزئياً بوضوح. عند اختفاء DA على نحو غير متوقع، تضيع معلومات اشتراكات UAs التي كان يحتفظ بها. ومع ذلك تظل UAs تتلقى إشعارات من SAs القائمة لأنها تلقت NotifyAt بالفعل. أما SA جديد فلن يعرف الاشتراك، ما لم يحتفظ DA آخر بالمعلومة نفسها.

قد لا يكتشف UA بديلاً إلا عندما يصدر طلباً نشطاً. لذلك يمكن لخدمة أن تسجل نفسها بعد اختفاء DA القديم وقبل اكتشاف UA بديلاً وتجديد الاشتراك لديه. يبدو تدفق الإشعارات مستمراً لأن الخدمات القديمة ما زالت تظهر، بينما قد لا تظهر الخدمة الوافدة قط.

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

الإشعار لا يثبت اكتمال الخدمة

تؤكد بقية الآلية ضرورة فصل الأدلة. تكرر رسائل البث متعدد الوجهات على مدى 15 ثانية مع تراجع أسي بين الإرسال. ويقول RFC إن هذا يزيد احتمال وصول رسالة واحدة؛ ولا يضمن التسليم أو يقدم سجل أحداث دائماً قابلاً لإعادة التشغيل. قد تتجاوز قائمة السمات سعة حزمة UDP، وعندها يشير بت التجاوز إلى أن UA قد يحتاج إلى استعلام لاحق من SA أو DA. كما يصف RFC كتل مصادقة يستطيع UA التحقق منها، لكن مصادقة الرسالة لا تثبت استقبال كل مستمع لها، أو بقاء نقطة النهاية قابلة للوصول، أو إتمام التطبيق معاملته.

لذلك يجب فصل اشتراك UA، وحالة النوع والنطاق لدى DA، وتعليمات NotifyAt التي تصل إلى SA، والانضمام إلى مجموعة البث، وإرسال الحدث، واستقباله فعلياً، والاستعلام اللاحق عند نقص السمات، والتعامل مع الخدمة. يحدد RFC بعض الانتقالات؛ لكنه لا يجمعها في إيصال واحد من طرف إلى طرف.

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

المصادر

النص والسجل التاريخي: RFC 3082، سجل محرري RFC، سجل Datatracker، RFC 2608: SLPv2، RFC 2119، RFC 2373، RFC 2730، وRFC 2908. عدسات تحريرية فقط وليست أدلة على سلوك SLP: ملاحظتا Lu Heng، Running-Code Primacy وOn Reality Layers.