الخلاصة

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

مشكلة الحدود التي تكشفها النمطية

بدأ Reliable Multicast Transport (RMT) من اختلاف عملي بين المتطلبات. فتوزيع الملفات بالجملة والتعاون التفاعلي والبث المستمر لا تتطلب النوع نفسه من الاعتمادية؛ وتختلف في حجم المجموعة والتأخير والترتيب وعدد المرسلين وقبول التسليم غير المكتمل. وكان RFC 2357 قد جعل هذا الاختلاف وآثار الازدحام الخارجية سببين لمراجعة المقترحات. أما RFC 3269 فسأل سؤالاً آخر: إذا لم يصلح بروتوكول واحد لكل حاجة، فما الذي يجب أن تكشفه المواصفة قبل إعادة استخدام أحد أجزائه؟

لم تكن الإجابة ادعاء أن كل كتلة مستقلة. أقر RFC 3269 بأن بعض كتل البناء تعتمد على السياق. قد يعمل A مع B، ويعمل B مع C، لكن يفشل جمع A وB وC. وقد تتحول تبعية غير ظاهرة في تركيب ثنائي إلى تعارض عند إضافة كتلة أخرى. وجود مربع أنيق في مخطط معماري لا يثبت أن حدوده حقيقية.

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

الكتلة ليست البروتوكول المركّب

رسم RFC 3269 حداً آخر حول «تطبيق البروتوكول»، أي الوثيقة التي تجمع الكتل لصنع بروتوكول كامل. وكان عليها أن تحدد التطبيق والحجم المستهدفين، والبيئات المقبولة والمستبعدة، ونقاط الضعف المعروفة، والمعمارية، والكتل المختارة وطريقة وصلها والمفاضلات التي حكمت الاختيار. كما لزم تحديد الخوارزميات وتنسيقات الحزم كاملة، لا ترك التنفيذ يخمّن التفاصيل التي لم تذكرها مواصفة مجردة لكتلة ما.

وجعل بيان المطابقة وحدة الادعاء واضحة: يجب أن يحدّد تطبيق البروتوكول، مع وثائق كتل البناء التي يشير إليها، بروتوكول RMT عاملاً بصورة كاملة وفق متطلبات RFC 2357 السابق. لم يحوّل هذا RFC 3269 إلى تقرير اختبار، ولم يضمن التوافق بين التطبيقات. بل حدّد ما ينبغي أن يتمكن القارئ من فحصه قبل تقييم وصف «بروتوكول عامل».

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

كان RFC 3048 قد وصف الفصل بين كتل قابلة لإعادة الاستخدام ونواة خاصة بكل بروتوكول. وأضاف RFC 3269 التزامات للمؤلفين حتى يصبح هذا الفصل واضحاً للقارئ. وفي 2009، أعلن RFC 5651 صراحة اتباع إرشادات RFC 3269 عند تحديث مواصفة LCT السابقة؛ وهذا مثال يمكن تتبعه على انتقال النهج بين الوثائق. لكنه لا يثبت امتثالاً عاماً أو نتيجة نشر.

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

المصادر