الخلاصة

  • حدّ RFC 1224 مجموع تنبيهات الوكيل عبر maxAlertsPerTime وwindowTime وحالة alertsEnabled.
  • عند تجاوز الحد يرسل الوكيل alertsDisabled مرة واحدة ثم يتوقف، مع أن رسالة التوقف نفسها قد تضيع.
  • يحفظ سجل قابل للاستطلاع alertId وalertData، لكن القراءة أو الحذف لا يثبتان معالجة العطل.

الصمت كان فشلاً محتملاً لا علامة طمأنينة

صدر RFC 1224 في مايو 1991. يصنفه سجل RFC Editor وثيقة تجريبية، ويحفظ IETF Datatracker هويته ضمن عمل Alert-Man. لم يحدد النص شروط إنشاء التنبيه أو محتواه، بل عالج حركة المعلومة بعد إنشائها.

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

يضع RFC 1157 رسائل SNMP فوق خدمة رزم غير موثوقة، ويترك اختيار وجهات Trap-PDU للتنفيذ. أما RFC 1215 فيقنن تعريف trap مع تحذير قوي من تكثيرها. صحة البنية لا تخلق دليلاً على الوصول.

نافذة القياس صنعت صمتاً مقصوداً

استخدمت آلية «الدبوس» حدين: عدد maxAlertsPerTime وزمن windowTime. وكان الحساب يجمع كل أنواع التنبيه لدى الوكيل.

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

حمت الخطوة المعالج وعرض النطاق والمدير، لكنها فتحت فجوة جديدة: قد تضيع الرسالة التي تعلن توقف الرسائل. لهذا أوصى RFC 1224 بأن يستطلع المدير الحالة دورياً، ويعيد تفعيلها ويسجل احتمال فقد traps أثناء الصمت. لم يعد غياب الحركة دليلاً على غياب المشكلة.

السجل عهدة مؤقتة

في المسار الثاني ينشئ كل تنبيه صفاً يتضمن alertId متزايداً ونسخة OPAQUE في alertData. يستطيع المدير طلب الصف التالي أو رقماً بعينه، ثم حذفه بعملية كتابة أو حذف إن دعمها التنفيذ. يقدم RFC 1189 سياق عمليات CMOT/CMIP التي استخدمها RFC 1224 للمقارنة.

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

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

قد يرى مديرون متعددون حدوداً وحالات ونسخاً مختلفة بحسب community. فعل أحدهم لا يصبح تلقائياً سلطة على الآخر. كما صرح RFC 1224 بأنه لا يناقش الأمن، فلا تكفي SET أو DELETE لإثبات هوية موثقة أو صلاحية.

المصادر