الخلاصة

  • القيم active وnotInService وnotReady حالات يستطيع الوكيل إرجاعها، أما createAndGo وcreateAndWait وdestroy فهي أفعال يطلبها المدير ولا تظهر أبداً كحالة مخزنة عند القراءة.
  • يختار المدير الفهرس ويرسل القيم، لكن تعريف MIB والوكيل يحددان صلاحية الانتقال. لذلك قد يوجد الصف قبل أن يكتمل، وقد يكتمل قبل أن يُتاح للجهاز.

شكل الجدول لم يكن وعداً بقاعدة بيانات

بدت كائنات MIB، مع الأعمدة وفهارس المثيلات، كأنها جداول مألوفة. لكن RFC 1212 وصفها بالجداول والصفوف المفاهيمية. الترابط بينها اتفاق تفهمه التطبيقات، لا نموذج علائقي يفرضه SNMP ويضمن اكتمال كل صف تلقائياً.

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

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

أظهر RMON مرحلة «قيد الإنشاء»

قدّم RFC 1271 في RMON سلفاً مباشراً باسم EntryStatus. ميّز بين createRequest وunderCreation وvalid وinvalid. يحصل أول مدير ينجح في إنشاء فهرس معين على الصف، بينما يتلقى المنافسون خطأ. وبعد ذلك يستكمل القيم قبل جعل الإدخال صالحاً.

أضاف RMON أيضاً OwnerString كي تعرف أدوات الإدارة من أنشأ المورد وتتعاون. غير أن النص صرّح بأنه ليس تحكماً في الوصول؛ فالمدير غير المتعاون يستطيع التعديل أو الحذف. معرفة المصدر تساعد التنسيق، لكنها لا تمنح حقاً حصرياً.

هيأت هذه التجربة للسؤال الذي حله RowStatus: ما الذي يطلبه المدير، وما الذي يستطيع الوكيل أن يثبته عن الحالة الراهنة؟

ست قيم تنتمي إلى فئتين

وحّد RFC 1443 RowStatus في SNMPv2، ويحمل RFC 2579 التعريف الحالي.

لا تعيد قراءة صف موجود إلا ثلاث حالات. تعني active(1) أن الصف متاح لاستخدام الجهاز المُدار. وتعني notInService(2) أنه موجود وغير متاح، مع امتلاك الوكيل معلومات كافية لمحاولة تفعيله. لكنها لا تضمن الاتساق الداخلي أو توفر الموارد أو نجاح المحاولة. أما notReady(3) فتعني أن مثيلاً أو أكثر من الأعمدة المطلوبة لم يُنشأ بعد.

القيم الثلاث الأخرى أفعال للكتابة. تطلب createAndGo(4) الإنشاء والتفعيل فوراً، وتطلب createAndWait(5) الإنشاء من دون دخول الخدمة، وتطلب destroy(6) حذف جميع المثيلات التابعة للصف المفاهيمي.

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

createAndGo لم يكن حفظاً لمسودة ناقصة

في الإنشاء الفوري يختار المدير معرّف مثيل غير مستخدم، ويرسل الأعمدة الضرورية مع RowStatus=createAndGo في SetRequest واحد. وقد يضيف الوكيل قيماً افتراضية لأعمدة أخرى.

إذا كفت المعلومات، ينشئ الوكيل الصف وتصبح حالته المقروءة مباشرة active. وإذا لم تكف، تفشل العملية بـinconsistentValue ولا يُنشأ الصف. لا يحق للمدير أن يفترض أن الفشل ترك مسودة قابلة للإصلاح. عليه استكمال الطلب وإعادته، أو استخدام المسار المرحلي إذا كان الوكيل يدعمه.

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

createAndWait جعل النقص مرئياً من دون تشغيله

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

يكتب المدير بعد ذلك active. يستطيع الوكيل القبول أو إرجاع inconsistentValue بسبب القيم أو الموارد أو حالة الجهاز. اكتمال المعلومات ليس وعداً بالتفعيل.

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

تستهلك الصفوف غير النشطة موارد رغم ذلك. لذلك يطلب RFC 2579 من الوكيل اكتشاف الصفوف التي تبقى زمناً طويلاً بصورة غير طبيعية في notReady أو notInService وحذفها. ينبغي أن تحدد DESCRIPTION المدة؛ وعند غيابها يقترح RFC قرابة خمس دقائق، بما يشمل وقت تفكير الإنسان. هذا اقتراح افتراضي لا قياس لسلوك كل منتج.

بقيت القواعد الدقيقة في وصف MIB

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

حوّل RFC 4181 ذلك إلى إرشادات صريحة. ينبغي عادةً للجدول الذي تدير التطبيقات إنشاء صفوفه ديناميكياً أن يملك عمود RowStatus بصلاحية read-create. كما يجب توثيق البقاء بعد إعادة التشغيل أو StorageType، وشروط إنشاء الوكيل للصفوف أو حذفها، والقيود أثناء النشاط.

وحّد المعيار لغة الانتقال، لا سياسة كل جهاز. ويبقى الوصف الخاص بكل MIB هو الذي يمنح الحالات معناها التشغيلي المحدد.

انتهت الذرية عند حدود SetRequest واحد

غالباً ما تسافر قيم الأعمدة وتغيير RowStatus في الطلب نفسه. يصف RFC 3416 معالجة SetRequest بمرحلتين مفاهيميتين: التحقق من جميع روابط المتغيرات، ثم تعديلها إذا نجح التحقق كله. تحدث عمليات الإسناد كما لو كانت متزامنة بالنسبة إلى الإسنادات الأخرى في الطلب ذاته.

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

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

كان الإنجاز هو عدم تسمية الوجود تشغيلاً

يوزع RowStatus الأدوار. يعرض المدير التغيير المرغوب. تنشر MIB العقد. يتحقق الوكيل من الوصول والقيم والانتقال. ويكشف الجهاز العامل النتيجة التشغيلية الأخيرة.

قد يكون الصف المرئي ناقصاً. وقد يكون الصف المكتمل خارج الخدمة. وقد يُرفض طلب التفعيل. وحتى active لا يثبت البقاء بعد إعادة التشغيل أو صحة الأمن أو مرور الحركة. تفيد كل حالة لأنها لا تتحدث نيابة عن الطبقة التالية.

المصادر والحدود

يوثق RFC 1212 وRFC 1271 الأعراف المبكرة وسلف RMON. ويعرّف RFC 1443 وRFC 2579 دورة RowStatus. ويحدد RFC 3416 معنى SetRequest، بينما يلخص RFC 4181 واجبات مؤلفي MIB. لا تقيس هذه المصادر الانتشار الحديث أو توافق الموردين أو الأمن أو مدة تنظيف عامة أو أثر مستوى البيانات. تفسير RowStatus كفصل بين النية والجاهزية والخدمة استنتاج من الآلية.