الخلاصة

  • نقل RFC 1419 رسائل SNMP العادية فوق رزم AppleTalk للأجهزة التي لا تنفذ TCP/IP. بقي معنى وحدات PDU كما هو، وحل عنوان DDP المؤلف من شبكة وعقدة ومقبس محل عنوان UDP/IP.
  • جعلت المواصفة اسم NBP الثابت نسبياً مرجعاً للخدمة، والعنوان المتغير طريقاً إليها. وأوصت بأن تحتفظ محطة الإدارة بخريطة الاسم إلى العنوان بعد إعادة تشغيلها كي لا يقطع فشل الاكتشاف بالضرورة الاتصال المباشر.
  • لا تثبت الخريطة القديمة هوية الطرف. قد تغادر عقدة ويحصل غيرها على عنوان DDP نفسه، فيرد على SET بصيغة لا تستطيع المحطة تمييزها عن رد الوكيل المقصود. ظل الوصول والاسم والمصادقة والتفويض والأثر حقائق مستقلة.

بقي SNMP واحداً وإن تغير الطريق تحته

صدر RFC 1419 في مارس 1993 لمعالجة واقع لم يكن موحداً. وجدت عناصر شبكة تدعم AppleTalk ولا تملك TCP/IP. ولو أصبحت إضافة حزمة IP شرطاً لإدارتها، لفرض بروتوكول الإدارة على الجهاز تغيير بنيته قبل أن يستطيع المراقب رؤيته.

لذلك كان الحل خريطة نقل صغيرة لا بروتوكول إدارة جديداً. توضع رسالة SNMP المشفرة في حقل بيانات رزمة DDP. وكان RFC 1157 قد ترك هذا الباب مفتوحاً: رسالة SNMP رزمة مستقلة، ويمكن حملها على خدمة نقل معقولة أخرى إذا عُرفت عناوين تلك الخدمة. بقيت دلالات GetRequest وGetNextRequest وGetResponse وSetRequest وTrap من دون إعادة تعريف.

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

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

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

كان الاسم أطول عمراً من الموقع

استعمل NBP صيغة منطقية هي object:type@zone. لا تميز المكونات حالة الأحرف، وهي عادة مقروءة للبشر، وحد كل منها 32 ثمانية. سجل الوكيل نفسه بالنوع SNMP Agent، وسجلت المحطة القادرة على تلقي traps النوع SNMP Trap Handler.

كان جزء object يربط خدمة SNMP بالاسم الذي تعرف به الشبكة الجهاز أصلاً. وفي Macintosh اقترح RFC اسم Macintosh في System 7. بهذه الطريقة لم تظهر واجهة الإدارة ككيان منفصل تماماً عن بقية خدمات الآلة.

لكن هذا الارتباط وصف استمرارية تشغيلية، لا مصادقة تشفيرية. يمكن لعنوان AppleTalk أن يتغير في كل إعادة تشغيل أو أسرع من ذلك. أما اسم NBP فكان يفترض أن يبقى في تخزين ثابت، وألا يتغير بمعدل يزيد على عنوان مضيف TCP/IP نموذجي.

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

أصبحت الذاكرة المحلية جزءاً من الاستمرارية

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

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

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

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

لم يكن الإعلان عن استقبال الأحداث تفويضاً بإرسالها

فرضت traps علاقة أشد تحديداً. لا يرسل الوكيل الحدث إلا إلى محطة أو مجموعة محطات سُجلت أسماؤها في الإعداد. وإذا لم توجد وجهة معدة، فلا يرسل شيئاً. ومنع RFC البحث العام wildcard عن أي محطة تعلن SNMP Trap Handler.

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

كذلك لا يملأ الوكيل كل خرائطه مقدماً. عند الحاجة إلى trap يبحث عن المحطة المحددة أو يؤكدها. أما عند الرد على طلب، فيجد مقبس المرسل داخل غلاف DDP الوارد، فلا يحتاج إلى تأكيد cache قبل الرد. إدارة وكيل، وتعيين مستقبل أحداثه، والرد على طالب حاضر، ثلاث علاقات وليست خانة واحدة اسمها «جهاز معروف».

اعترف الصفر بما لا يعرفه الغلاف

احتوى Trap-PDU في SNMPv1 على agent-addr المصمم كعنوان Internet. ولا يملك الوكيل الذي يعمل على AppleTalk وحده عنوان IP مناسباً. لذلك أمر RFC بوضع أصفار في الحقل كله، بدلاً من اختراع هوية IP لاستكمال البنية.

كان trap يحمل بدلاً من ذلك قيمتي nbpObject وnbpZone المرتبطتين بتسجيل SNMP Agent. وعرّف RFC 1243 هاتين القيمتين منفصلتين إلى جانب nbpType وnbpState. أخبر مصدر DDP عن الطريق المرصود، وأعلن الحقل الصفري حدود النموذج الموروث، وقدم NBP ادعاء اسم تستطيع المحطة مقارنته بما لديها.

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

جمعت القراءة قرائن، أما الكتابة فسبقت اليقين

إذا شكت المحطة في عنوان قديم، تستطيع استخدامه كتلميح لتأكيد NBP أحادي الإرسال. وتستطيع أيضاً قراءة object وzone من الوكيل عبر SNMP، ثم مقارنة القيم بعنوان مصدر الرد وبالخريطة المقصودة. تجمع قراءة واحدة أكثر من ملاحظة من دون بث بحث جديد.

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

لم يعد الخطأ عندئذ وصفاً سيئاً في سجل. ربما تغيرت آلة أخرى فعلاً قبل أن تصل معلومة أفضل.

تطلع النص إلى أمن SNMP مستقبلي يصادق كل رزمة عند الوجهة. عندها يؤكد الرد الموثق الخريطة ضمناً ويمنع السباق. صيغة المستقبل مهمة: لم يدع RFC 1419 أن الاسم الثابت أو العنوان أو community أو تطابق الرد وفر هذه الهوية من قبل.

يظهر الحد أيضاً في سجل RFC 1157. فقد فصل SNMPv1 بين communities وMIB views وسياسات الوصول، لكن قسم الاعتبارات الأمنية قال إن قضايا الأمن لم تناقش. تغيير وسيلة النقل لا ينشئ ضماناً غائباً.

كان بوسع محطة متخصصة بناء طريق اكتشاف محلي

قدم RFC حلاً محلياً لمحطة AppleTalk مخصصة. إذا فشل مسار NBP المعتاد، يمكن للمحطة تنفيذ جزء الموجه من NBP بنفسها. وبمعرفة zones وشبكاتها، توجه الطلب إلى آخر شبكة للوكيل، وقد تستعمل multicast DDP موجهاً إلى أرقام الشبكات ذات الصلة.

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

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