الملخص

  • عرّف RFC 1283 بصورة تجريبية نقل SNMP عبر CLTS غير المتصل وCOTS الموجه بالاتصال. في COTS يُفتح الاتصال، وترسل رسالة أو أكثر، ثم يحرر.
  • لم يحق للمبادر اشتراط عودة الرد على الاتصال نفسه أو اعتبار الاتصال ضماناً لموثوقية عملية SNMP. بقي timeout وإعادة الإرسال والإلغاء عند التطبيق.
  • أزال RFC 1418 لاحقاً mapping الخاص بـ COTS وأبقى CLTS للبيئات التي لا يتوافر فيها UDP. تغير الوثيقة لا يثبت زوال كل implementation في اللحظة نفسها.

حملت المراجعة خبرة لا شهادة نجاح

قدم RFC 1161 في يونيو 1990 وسيلة تجريبية لتشغيل SNMP فوق خدمات نقل OSI. لم يكن Internet standard، بل ترك احتمال مراجعة لاحقة بعد التجربة وقيام consensus كافٍ.

في ديسمبر 1991 أبطل RFC 1283 سابقه وظل Experimental. قال المحرر إن التغييرات تعكس خبرة تشغيلية منذ النشر الأول. هذا دليل على مراجعة specification، لا على نجاح deployment بعينه.

كان الهدف إعادة استخدام استثمار SNMP في مواقع اكتسبت قدرة OSI. لذلك ربط النص SNMP بخدمات النقل مباشرة بدلاً من إعادة بنائه كتطبيق OSI كامل.

حافظ CLTS على نموذج الحزمة

شابه CLTS خدمة UDP: تحمل الحزمة معلومات العنونة كاملة، ويتكون عنوان النقل من عنوان شبكة وselector. لم يستخدم OSI well-known ports هنا، بل octets غامضة ذات معنى محلي عند الوجهة. نسق RFC 1283 الاسمين snmp وsnmp-trap فوق CLNP.

حدد selector باب الخدمة المحلية فقط. لم يصادق manager، ولم يمنح Set، ولم يثبت صحة variable. تسمية التسليم ليست تفويضاً للإدارة.

أضاف COTS association ولم يضف نتيجة

لم يحتج SNMP بطبيعته إلى اتصال قائم. لذلك حدد mapping ثلاث مراحل: إنشاء transport connection، إرسال رسالة SNMP أو أكثر، ثم تحرير الاتصال.

قد يفشل الاتصال قبل الفتح، أو يفتح من دون request مكتمل، أو يقبل bytes ثم يغلق قبل response. حالة established تثبت عقد النقل وحده؛ لا تثبت decode أو access decision أو قراءة object أو تنفيذ Set.

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

كان عمر الاتصال موزع الملكية أيضاً. الأفضل أن يحرره initiator، لكن responder يستطيع الإغلاق لضيق الموارد. المدة implementation-specific وتحتاج dynamic algorithm. قد يدل الإغلاق على policy أو ضغط أو خمول أو failure، وليس وحده نتيجة SNMP.

توقف ACK قبل اكتمال التطبيق

كانت العبارة الأهم في RFC 1283 منع المبادر من إسناد reliability إلى الاتصال. بقيت retransmission لرسائل SNMP عند SNMP application لا transport service.

شرح RFC 1270 أن transport ACK لا يعني بالضرورة تسليم البيانات إلى destination application process. ظل SNMP يحتاج timeout وretry ليتأكد من أن برنامج SNMP استلم packet.

يمكن للنقل حماية عقد bytes الخاص به. لكن وصول bytes واكتمال management operation حقيقتان منفصلتان. يلزم response مرتبط للثانية، وحتى الرد تقرير من agent لا إثبات تلقائي لحالة الشبكة الفعلية.

لكل سياسة اتصال كلفتها وسجلها

قارن RFC 1270 بين اتصال دائم لكل managed object، واتصال جديد لكل operation، وpool محدود يستبدل connections بخوارزمية. الأول يستهلك سجلات كثيرة وقد يولد keepalive بلا فائدة. الثاني يعيد establishment وclose وTIME-WAIT. الثالث يحتاج usage ledger ويقترب من الثاني حين يزيد agents على حجم pool.

من يغلق، وبأي دليل، وكيف يعامل late response أصبحت أسئلة control جديدة. الخدمة ذات state لم تلغ دفتر الحالة بل نقلته.

أبقت مراجعة 1993 المسار غير المتصل

أبطل RFC 1418 RFC 1161 وRFC 1283 في مارس 1993. احتفظ فقط بـ connectionless OSI mapping عندما لا يكون UDP متاحاً، ولم يطلب من كل agent دعم mappings متعددة.

أمكن تحقيق CLTS فوق network service غير متصل أو موجه بالاتصال، مع selectors مختلفة. بقاء connection في طبقة أدنى لم يحول contract الذي يراه SNMP إلى اتصال.

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

يعتمد المقال على RFC 1161 وRFC 1270 وRFC 1283 وRFC 1418. تثبت قواعد تاريخية وتعاقب وثائق، ولا تثبت implementation حالياً أو هوية أو تفويضاً أو اتصالاً مرصوداً أو request أو response أو retry أو outage أو نتيجة. لم تناقش الوثائق مسائل الأمن.