الخلاصة

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

نافذة لا يملكها أول من فتحها

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

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

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

الفعل المكتوب والحالة المقروءة

تقسم اتفاقية RowStatus ست قيم إلى نوعين مختلفين. يمكن قراءة وكتابة active وnotInService. ويمكن قراءة notReady لكن لا يجوز للمدير كتابتها. أما createAndGo وcreateAndWait وdestroy فهي أفعال تُكتب ولا تظهر أبدًا نتيجة للقراءة.

عندما يكتب المدير createAndWait لا يضع هذا الاسم حالةً دائمة في العمود. إنه يطلب إنشاء الصف. إذا نجح الطلب ولم تتوافر معلومات كافية، يعلن الوكيل notReady. وإذا توافرت معلومات تكفي لمحاولة جعل الصف متاحًا للجهاز، يعلن notInService.

الحالتان تمنعان استنتاجين متسرعين. notReady لا تعني أن الإنشاء لم يقع؛ قد يكون الصف موجودًا ويستهلك موارد. وnotInService لا تعني أن الضبط صحيح أو أن التفعيل سينجح؛ إنها تعني أن الوكيل وصل فقط إلى عتبة المحاولة.

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

كيف احتاج نموذج المتغيرات إلى دورة حياة

صاغ RFC 1157 في مايو 1990 وظائف إدارة SNMP على هيئة قراءة متغيرات مسماة وتغييرها. أبقى هذا الاختيار البروتوكول صغيرًا بدل أن يحوله إلى قائمة أوامر خاصة بكل جهاز.

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

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

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

عمّم RFC 1443 الفكرة في أبريل 1993 ضمن اتفاقية RowStatus، وذكر صراحة أن أصلها EntryStatus في RMON. عدّل RFC 1903 الصياغة في 1996، ثم قدّم RFC 2579 في 1999 دورة الحياة التفصيلية المستخدمة هنا. انتقلت خبرة جدول تحكم بعينه إلى قاعدة قابلة لإعادة الاستخدام في جداول أخرى.

النقص الذي يمكن استكماله

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

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

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

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

الحذف فعل لا شاهد قبر

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

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

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

الوكيل ينظف ما لم يعد صاحبه حاضرًا

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

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

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

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

حدود الضمان داخل رسالة واحدة

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

يستطيع المدير جمع عدة أعمدة وفعل إنشاء في PDU واحد والاستفادة من هذه الحدود. لكن سلسلة createAndWait ثم القراءة ثم استكمال الأعمدة ثم active تتكون من طلبات مستقلة. أُغلق الطلب الأول برده، ويمكن أن تقع أعطال أو منافسة أو تغييرات قبل الطلب التالي.

لا يرجع rollback في الطلب الأخير إلى الوراء ليلغي الطلبات السابقة. ولا ينسق وكلاء عدة أجهزة. عبارة «كما لو كانت متزامنة» تخص التعيينات في SetRequest واحد عند كيان واحد، ولا تنشئ معاملة موزعة.

بل إن undoFailed يصرح بأن الاستعادة المحلية قد لا تكتمل. عند ظهوره لا يصح تسجيل «لم يتغير شيء»؛ يجب إعادة القراءة وتحديد الحالة الفعلية.

مسؤوليات صغيرة يمكن إثباتها

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

تنتج عن ذلك عبارات منفصلة: أُرسل الفعل؛ قُبل الإنشاء؛ الصف موجود؛ المعلومات كافية؛ قبل الوكيل التفعيل؛ تحقق الأثر المقصود. لا تثبت إحداها ما يليها تلقائيًا.

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

المصادر