الخلاصة

  • وضع RFC 869 صيغة مشتركة تتيح لمركز المراقبة استطلاع المضيفين، وربط الردود بطلباتها، وقراءة الحالة والإحصاءات، وتلقي التنبيهات التي يرسلها المضيف من تلقاء نفسه. لكنه لم يجعل جميع الأجهزة تصف نفسها بالبيانات ذاتها.
  • يوضح RFC 823 كيف ظهرت هذه الحدود في البوابة: واجهاتها، والبوابات المجاورة، والشبكات التي تصل إليها، ومصفوفة الحركة، وعدّادات الإسقاط؛ أما تفاصيل التقارير والتحكم فظلت مرتبطة بنوع الجهاز.

التحليل

البوابة لم تكن مجرد نقطة عبور

لم يكن بروتوكول مراقبة المضيف (Host Monitoring Protocol أو HMP) مجرد اختبار لمعرفة ما إذا كان الجهاز يرد. فمواصفة بوابة إنترنت DARPA الصادرة عام 1982 تصف استخدام HMP لجمع القياسات والحالة من البوابات. شملت رسالة الحالة واجهات البوابة، والبوابات المجاورة، والشبكات التي تستطيع الوصول إليها. أما مصفوفة حركة المضيفين (Host Traffic Matrix) فكانت تعدّ مخططات البيانات وفق عنوان IP للمصدر والوجهة ورقم البروتوكول. ورسالة الإنتاجية جمعت عدّادات للبيانات المستقبلة والممررة والمرسلة والمُسقطة، مع تفصيل بحسب الواجهة والجار.

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

إطار الرسالة مشترك، أما قاموس الجهاز فمحلي

نشر روبرت هيندن RFC 869 في ديسمبر 1983 ليحل محل وثيقة IEN 197 السابقة. عرّف HMP بأنه بروتوكول نقل قائم على المعاملات ومن دون اتصال. تضمن رأس الرسالة نوع النظام، ونوع الرسالة، ورقم تسلسل، وحقل «كلمة مرور أو رقم التسلسل المعاد»، ومجموع تحقق. ويحدد الجمع بين نوع النظام ونوع الرسالة كيفية تفسير البيانات. وشملت الأنواع أجهزة IMP، ومتحكمات الوصول إلى الطرفيات (TAC)، والبوابات وغيرها؛ وكان رقم بروتوكول HMP في IP هو 20.

جعل هذا الإطار المشترك الاستطلاعات والردود قابلة للتعرّف والربط. لكنه لم يحوّل عدّادات إنتاجية البوابة إلى وصف موحد لكل مضيف. يذكر RFC 869 أن أنواع الرسائل تُعرّف لكل نوع نظام بحسب حاجته. وتعرض الملاحق أمثلة لرسائل IMP وTAC والبوابات، لكن المقدمة تؤكد أن تلك الأمثلة ليست جزءاً من بروتوكول HMP. وحّد البروتوكول طريقة السؤال ومطابقة الرد؛ أما معنى الرد فظل رهناً بتنسيق الجهاز نفسه.

التنبيه والحالة والإحصاء أدلة مختلفة

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

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

مركز المراقبة كان يستطيع تغيير المضيف أيضاً

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

يصلح RFC 1157 الخاص بـSNMP، المنشور عام 1990، للمقارنة لا لإثبات أن HMP كان سلفه المباشر. يسمي RFC 1157 بروتوكول Simple Gateway Monitoring Protocol (SGMP) سلفاً لـSNMP، ويعرض نموذجاً يدور حول قراءة المتغيرات أو تعديلها، مع عدد محدود من التنبيهات غير المطلوبة. ينبغي قراءة تاريخ HMP في حدوده الخاصة: إطار الرسالة المشترك أتاح لمضيفين مختلفين إرسال تقاريرهم وتلقي بيانات تحكم تختلف بحسب نوعهم.

في أبريل 1983، صنّف دليل البروتوكولات الرسمية، RFC 840 بروتوكول HMP على أنه “Elective”، وقال إنه مستخدم لمراقبة بوابات الإنترنت ومتحكمات الوصول الطرفي ولتصحيح تنفيذ البروتوكولات على الحواسيب البعيدة الصغيرة. وذكر RFC 869 أيضاً استخدامه مع البوابات وTAC، في حين كانت تطبيقات مضيفين آخرين لا تزال قيد التصميم. تثبت هذه السجلات استخداماً محدوداً في ذلك الوقت، لا انتشاراً في الإنترنت كله. وتكمن دلالتها التاريخية في الحد الذي أظهرته: قواعد الرسائل المشتركة جعلت المراقبة عن بُعد ممكنة، لكن معنى التقرير ظل متصلاً بالمضيف الذي أرسله.

المصادر