الخلاصة

  • تسمح RFC 5277 ببدء الإعادة من أقدم إشعار ما زال متاحا حين يسبق startTime المطلوب حدّ الاحتفاظ. لذلك يمكن أن تكون replayComplete صادقة بينما تظل بداية الفترة المطلوبة مفقودة.
  • الاكتمال محصور في تقاطع السجل المحتفَظ به، وعضوية التدفق، والمرشّح، وصلاحيات الجلسة. أما قبول الاشتراك والتسليم وجودة الساعة والحفظ لدى العميل ونتيجة التطبيق فتحتاج إلى إيصالات مستقلة.

لا تسأل هل اكتملت الإعادة قبل أن تسأل: إعادة ماذا؟

تعطي RFC 5277 للعلامة معنى محدودا: أرسل الخادم كل إشعارات الإعادة المنطبقة على ذلك الاشتراك. كلمة «المنطبقة» ليست زينة لغوية. فهي تحمل الحدود التي تمنع العلامة من التحول إلى شهادة عن تاريخ النظام كله.

إذا طلب العميل البداية عند الزمن A، لكن أقدم إشعار باق يبدأ عند B، تبدأ الإعادة من B. لا يعيد الخادم بناء الفترة A–B، ولا يقرر أن أحداثا لم تقع فيها، ولا يفشل لمجرد أن السجل لم يعد يملكها. وبعد إرسال المجموعة المتاحة تأتي replayComplete بصورة نظامية.

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

وقد تطورت بنية الإشعارات بعد ذلك؛ تحدّث RFC 8639 نموذج الاشتراكات، وتحول RFC 8641 مخطط إدارة إشعارات RFC 5277 إلى YANG. يركز هذا التحليل على حدود RFC 5277، ولا يفترض أن نموذج عام 2008 هو البنية الوحيدة المستخدمة اليوم.

عمر الحاوية ليس عمق الذاكرة

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

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

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

التدفق نافذة منتقاة لا مرآة كاملة

تعرّف RFC 5277 تدفق الأحداث بأنه مجموعة إشعارات توافق شروط التوجيه. ويضم تدفق NETCONF الافتراضي إشعارات أحداث NETCONF XML التي يدعمها الخادم، لا كل تغير وقع داخل النظام المدار.

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

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

المرشّح والصلاحية يصنعان ماضيا خاصا بكل جلسة

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

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

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

قبول الاشتراك ليس إقرارا بكل إشعار

يثبت الرد الإيجابي على create-subscription أن الخادم قبل الطلب. أما الإشعارات اللاحقة فهي رسائل أحادية الاتجاه، ولا تحدد RFC 5277 ردا لكل إشعار. كذلك يثبت إعلان القدرة دعم الآلية، لا توليد واقعة بعينها أو وصولها أو حفظها.

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

كما يجب الفصل بين replayComplete وnotificationComplete. الأولى تنهي الجزء التاريخي من الإعادة، والثانية تشير إلى انتهاء اشتراك ذي وقت توقف. شاشة تجمعهما في حالة عامة اسمها «مكتمل» تحذف الحد الذي يفسر كل واحدة منهما.

الانتقال إلى البث الحي وصلة تحتاج إلى دليل

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

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

مكونات إيصال لا يبالغ في الادعاء

ينبغي للتحقيق ذي العواقب العالية أن يجمع ما يلي:

  • الخادم المصادق عليه، وجلسة NETCONF، وهوية العميل؛
  • إعلان قدرة الإشعارات ونتيجة اكتشاف التدفقات؛
  • اسم التدفق، ونسخة تعريفه، وحالة دعم الإعادة؛
  • أوقات البداية والتوقف المطلوبة والبداية الفعلية؛
  • إنشاء السجل وحد التقادم وجيله أو إعادة ضبطه؛
  • أول وآخر إشعار شوهد فعليا؛
  • المرشّح الحرفي وجيل سياسة التفويض؛
  • نتيجة RPC وهوية الاشتراك لدى الخادم؛
  • علامتي الإكمال وأوقات استقبالهما؛
  • وصلة الإعادة بالبث الحي والفجوات والتكرارات المكتشفة؛
  • eventTime وأزمنة الإرسال والاستقبال والتحليل والحفظ؛
  • الحالة المرجعية أو نتيجة التطبيق المستخدمة للتحقق.

الصياغة المنضبطة هي: «اكتملت إعادة الأحداث المحتفَظ بها والمنطبقة والمصرّح بها بين B وC». حذف هذه القيود لا يختصر الحقيقة نفسها؛ بل ينشئ ادعاء جديدا لا تحمله الأدلة.

Sources