الخلاصة

  • وسعت RFC 1513 منظومة RMON لتشمل Token Ring. كان dropEvents يعدّ المرات التي أسقط فيها المسبار حزمًا بسبب نقص موارده، لا العدد الدقيق للإطارات التي لم تُحصَ.
  • حذرت الوثيقة من أن تقارير الأخطاء غير الجسيمة ذات التسليم المضمون قد تُرى مرتين في الرصد promiscuous. لذلك كان المبلّغ والجار الصاعد وترتيب المحطات وفترة العينة أجزاء من معنى الرقم.
  • قيمة القياس، واستنتاج الخسارة، وإسناد السبب، والإذن بإزالة محطة، والنتيجة التشغيلية إيصالات مستقلة. سمّت وثائق RMON-2 اللاحقة عدادات دقيقة للإطارات المسقطة بصورة منفصلة.

رقم صحيح لا يجيب عن كل سؤال

وضعت RFC 1271 وظائف الرصد داخل مسبار بعيد، يقيس ويختزن التاريخ والمضيفين والمصفوفات والمرشحات والالتقاط والأحداث. غير أن بعض صور طبقة الوصلة كانت مرتبطة بـ Ethernet. في سبتمبر 1993 جاءت RFC 1513 بأجسام خاصة بـ IEEE 802.5 Token Ring، وبمجموعات للمحطات وترتيبها وإعدادها وsource routing.

داخل تعريف tokenRingMLStatsDropEvents ظهر الحد الحاسم: يزداد العداد عندما يسقط المسبار حزمًا لنقص الموارد، لكنه لا يمثل بالضرورة عدد الحزم المسقطة؛ إنه عدد المرات التي اكتُشفت فيها الحالة.

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

لم يكن الرقم مضللاً. التضليل يبدأ حين نستبدل سؤال «كم مرة حدث النقص؟» بسؤال «كم إطارًا فُقد؟».

الشاهد نفسه يملك نقطة انهيار

كانت فائدة RMON اقتصادية: التصنيف والتلخيص قرب الشبكة بدل نقل كل إطار. ولهذا كان للمسبار معالج وذاكرة وصفوف محدودة. عندما تنفد، يصبح dropEvents دليلاً على نقص الرؤية بقدر ما هو دليلاً على وصول حركة لم تُعالج.

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

أظهرت RFC 4502 الفرق لاحقًا بتعريف DroppedFrames على أنه العدد الدقيق للإطارات التي أسقطتها عملية الجمع، «على خلاف dropEvents». القياس الجديد لم يفضح كذب القديم؛ بل قدم وعدًا أقوى باسم مستقل.

ضمان وصول التقرير قد يصنع نسخة ثانية

قالت RFC 1513 إن حزم تقارير soft error قد تُرسل بتسليم مضمون. يستطيع المسبار الذي يستمع promiscuously أن يسجل بعض الأخطاء مرتين. ضمان عدم ضياع التقرير ليس ضمانًا لأن كل وصول يخص حدثًا جديدًا.

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

الجار الصاعد ليس حكمًا بالمسؤولية

استخدمت قواعد المحاسبة شكل الحلقة. تزيد أخطاء Address Copied خانة أقرب جار صاعد للمحطة المبلغة. تزيد أخطاء line وburst خانة المبلغ وجاره الصاعد. أما internal وabort فتبقى مع المبلغ.

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

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

قابلية الكتابة ليست تفويضًا

سمحت Ring Station Configuration Group بإزالة محطة أو تنزيل إعدادات إليها. ومع ذلك، أوضحت RFC 1513 أن access level يصف فقط معنى القراءة أو الكتابة في البروتوكول، وهو مستقل عن سياسة الإذن الإداري.

read-write ليس وكالة. كما أن ارتفاع dropEvents، أو عدًا منسوبًا إلى جار، أو تقريرًا قابلاً للتكرار لا يكفي لإخراج محطة. يلزم مسار آخر: هوية الطالب، قرار الإذن، الهدف، ترتيب الحلقة قبل العمل، الأمر، الاستجابة، الحالة الجديدة والأثر المرصود.

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

حدود ما تثبته المصادر

يثبت سجل RFC Editor وDatatracker النشر والنسب والسلالة والحالة. وتعرض RFCs 1271، 1757، 2021، 2819، 3577 و4502 تطور عائلة RMON.

لا تثبت نشرًا فعليًا أو فقدًا أو انقطاعًا أو عيب مورد أو نجاح إصلاح محدد. Historic ليست نشرة حادث. وإهمال بعض إضافات Token Ring في RMON-2 لاحقًا لقلة تطبيقات مستقلة تثبت التشغيل البيني لا يثبت فشل RFC 1513 في موقع حقيقي.

تطالب Running-Code Primacy بإثبات التنفيذ والأثر. وتحافظ Minimum Initial Specification على معنى مشترك أدنى مع إظهار القرار المحلي. وتمنع On Reality Layers الرمز من استعارة سلطة الواقع الذي يمثله.

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

المصادر

  1. معلومات RFC 1513
  2. نص RFC 1513
  3. RFC 1513 في Datatracker
  4. معلومات RFC 1271
  5. نص RFC 1271
  6. معلومات RFC 1757
  7. نص RFC 1757
  8. معلومات RFC 2021
  9. نص RFC 2021
  10. معلومات RFC 2819
  11. نص RFC 2819
  12. معلومات RFC 3577
  13. نص RFC 3577
  14. معلومات RFC 4502
  15. نص RFC 4502
  16. Running-Code Primacy
  17. Minimum Initial Specification
  18. On Reality Layers