الخلاصة

  • تعرض جداول Admin في RFC 2051 القيم المتوقعة للقراءة فقط، بينما تشهد جداول Oper على الحالة الحالية أو المتفاوض عليها. ويمكن حذف صف Admin الخاص بالنمط مع بقاء جلسة نشطة وصف Oper المقابل.
  • للجلسة والمحادثة والعدادات الاختيارية وسجل النهايات غير الطبيعية دورات حياة مختلفة. ولا يثبت أي منها منفردا الإعداد أو موافقة الطرف المقابل أو نجاح التطبيق أو الاكتمال أو الأمان.

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

كانت Admin تمثل القيم الافتراضية أو المتوقعة، لكن MIB لم يكن ينشئ ذلك الإعداد أو يغيره، ولذلك كانت الكائنات للقراءة فقط. أما Oper فكانت تمثل القيم الحالية أو المتفاوض عليها. وقد يبدأ الكائن الديناميكي من قالب إداري ثم يمتلك دورة حياة مستقلة.

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

شمل RFC مجموعات global وLU وبرنامج المعاملة والجلسة والمحادثة وCPI-C. لكن هذا الاتساع لم يجعله جهاز تحكم كاملا. لم يكن ينشئ أو يحذف عموما وحدات LU الشريكة أو الأنماط أو البرامج، ولم يكن يفعّل LU أو يبدأ المحادثات أو يفعّل الجلسات.

وُجدت ضوابط محددة: اختيار الإحصاءات أو التتبع، وإصدار CNOS، وطلب تعطيل جلسة. كانت الكتابة دليلا على وضع طلب عند سطح التحكم، لا إيصالا بتحقق النتيجة.

في CNOS حملت Admin القيم المرغوبة، وحملت Oper القيم الفعلية بعد التفاوض. وتشرح وثيقة IBM الحالية عن بدء الجلسات أن CNOS تعني Change Number Of Sessions. وهي سياق للمصطلح، وليست دليلا على تطبيق RFC في منتج بعينه أو نجاح تفاوض معين.

تتبعت الجلسة النشطة حالات unbound وpendingBind وbound وpendingUnbind. كان agent ينشئ الصفوف ويحذفها وفق هذه الدورة. قد تبدأ كتابة unbound على جلسة مرتبطة عملية التعطيل؛ لكن الحالة اللاحقة هي التي توضح ما فعله agent.

حتى bound لا يعني أكثر من حالة الجلسة. لا يثبت تخصيص محادثة أو اكتمال برنامج أو صحة رد الطرف الآخر أو نجاح عملية تجارية. يحتاج الطرف المقابل والتطبيق إلى أدلتهما الخاصة.

المحادثة أقصر عمرا من الجلسة. ينشئ agent صفها عند البداية ويحذفه عند النهاية. ويمكن أن تمر محادثات متعددة عبر جلسة واحدة تظل مستمرة.

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

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

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

يضع RFC 1666 هذا النموذج ضمن إدارة SNA. النسب المعياري ليس دليلا على النشر. تستطيع المواصفة تعريف الكائنات بدقة من دون أن تثبت أن مشغلا ركّبها أو فعّلها أو حماها أو فسّرها بصورة صحيحة.

تحتاج الحالة الرسمية إلى الدقة نفسها. يسجل IETF Datatracker وصفحة RFC Editor الوثيقة كـ Proposed Standard على Standards Track منذ أكتوبر 1996. لا يظهر RFC 2051 في فهرس تغييرات الحالة المجمد، ولا تظهر وثيقة تحديث أو إحلال. النص قديم وتقنيته موروثة، لكن المصادر الرسمية لا تثبت حالة Historic.

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

أما الأمان فحده صريح: يقول RFC إن مسائل الأمان غير مناقشة. لا تثبت صفة Standards Track التحكم في الوصول أو سلامة الكتابات أو موثوقية العدادات. يمكن لجلسة تشغيلية أن تكون غير آمنة.

لكل شاهد اختصاص محدود: Admin للإعداد المعروض، وcontrol للطلب، وagent للانتقال، وCNOS Oper لنتيجة التفاوض، وsession للعلاقة النشطة، وconversation لتفاعل واحد، والإحصاءات لنافذة قياس، والتاريخ لبعض النهايات الشاذة. على الطرف الآخر والتطبيق تقديم إيصالاتهما.

المصادر