‏RFC 2357: قبل أن يصبح البث المتعدد الموثوق معياراً، كان عليه أن يثبت أنه لن يحمّل الشبكة كلها كلفة الإكمال

الخلاصة

• لم يحدد RFC 2357 بروتوكول نقل موثوقاً واحداً؛ بل حدد كيف تراجع منطقة النقل في IETF المقترحات الراغبة في أن تصبح RFC.
• نشأ الخطر من الاتساع: قد يغطي تدفق واحد شجرة عالمية، ويستمر بين أجهزة بلا مراقبة حتى يكتمل كل مستقبِل، ويولّد انفجاراً من ACK وNACK ورسائل الحالة أو إعادة الإرسال.
• التحليل والمحاكاة والتجربة والتنفيذ والنشر التشغيلي وحالة RFC إيصالات مختلفة. لا يثبت أي منها منفرداً السلامة على نطاق الإنترنت.

التوفير في اتجاه واحد قد يصنع عاصفة في الاتجاه الآخر

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

ركز RFC 2357 على ما يعود من الأطراف. فالموثوقية تعني أن يبلغ المستقبلون عما وصل وما فُقد ومتى يلزم الإصلاح. ومع نمو المجموعة قد تتكاثر الرسائل الصغيرة أسرع من البيانات. وقد يحول طلب واحد لإصلاح خسارة محلية إلى إعادة إرسال تخاطب مجموعة أوسع بكثير من صاحب الطلب.

صدر المستند في يونيو 1998 بصفة Informational، وشارك في تأليفه Allison Mankin وAllyn Romanow وScott Bradner وVern Paxson مع TSV Area Directorate. ونص صراحة على أنه لا يحدد معيار إنترنت. كان موضوعه معايير وإجراءات مراجعة Internet-Drafts الخاصة بالبث المتعدد الموثوق.

اجتمعت أربعة أسباب للخطر. يمكن للتدفق أن ينتشر في شجرة كبيرة عابرة للعالم. ويمكن لنقل الملفات أن يجري بين حواسيب بلا شخص ينسحب حين تصبح الجودة سيئة. وقد يستمر العمل حتى تصل جميع البيانات إلى جميع المستقبلين المقصودين، فلا تكون له مدة طبيعية. وفوق ذلك قد تتشكل أنماط معقدة من ACK وNACK وتقارير الحالة.

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

لم تكن «الموثوقية» وعداً واحداً

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

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

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

أصبح وضع النشر حداً لما يمكن ادعاؤه

إذا طلب مقترح مسار Standards Track ولم يستوف المعايير، أمكن لمديري المنطقة حجب الدعم، وكان ذلك كافياً لمنع نشره في ذلك المسار. أما المستند Experimental أو Informational فكان له مسار آخر: يمكن على الأقل نشره مع ملاحظة من IESG تقول إن البروتوكول لا يطابق المعايير.

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

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

وفر RFC 2026 الإطار الذي يميز Standards Track وExperimental وInformational. واستخدم RFC 2357 هذا التمييز ليفصل السجل المنشور عن نضج الدليل وعن التشغيل الفعلي.

كان على المقترح أن يبين أين يتوقف الضرر

لم تكن صيغة الحزم كافية. طُلب تحليل ومحاكاة أو تجارب بمقياس يناسب الادعاء. وكان على المقترح شرح السلوك مع ازدياد المرسلين والأعضاء، وطريقة اكتشاف الازدحام وخفض الحمل، والتعايش مع حركة أخرى، والاستجابة لفشل عضو أو مسار أو رسالة تحكم، واحتواء السلوك الضار.

مثّل RFC 2001 مرجعاً معاصراً لأن استجابة TCP للفقد ساعدت في منع انهيار الازدحام. لكن RFC 2357 لم يفرض نسخ TCP. السؤال كان التعايش: هل يستطيع التطبيق متابعة وعد الإكمال من دون حرمان التدفقات المنافسة من التقدم؟

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

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

كما أوصى RFC 2357 بإهمال RFC 1301 وRFC 1458 لأنهما نُشرا قبل تقدير أثر الازدحام بما يكفي. لم يثبت أنهما سببا انهياراً موثقاً. أظهر فقط أن رقم RFC ليس شهادة دائمة، وأن المعرفة اللاحقة تستطيع تغيير وزن سجل قديم.

التجربة إيصال ضمن شروطها، وليست جواز مرور

يفصل Running-Code Primacy طبقات الواقع. تصف المواصفة ما يفترض أن يحدث. يكشف التنفيذ سلوك نسخة معينة من الشيفرة. تجيب المحاكاة داخل نموذجها. وتتقيد التجربة بطوبولوجيا وحمل وعدد أعضاء وحالات فشل وطريقة قياس. أما النشر التشغيلي فيضيف إصدارات وسياسات وتفاعلات أخرى.

اكتمال مستقبِل واحد لا يثبت اكتمال الجميع. تجربة صغيرة لا تثبت المقياس العالمي. NACK موقّع لا يمنح تلقائياً سلطة إعادة الإرسال إلى كل المجموعة. RFC تجريبي ليس إحصاء انتشار. ووضع Standards Track لا يثبت تبنياً شاملاً أو تشغيلاً بلا أخطاء.

كانت سلطة المراجعين محدودة أيضاً. يستطيعون تحديد المعنى الذي تربطه IETF بالنشر، لكنهم لا يديرون الشبكات التي قد تستخدم الآلية لاحقاً. يبقى التنفيذ والقبول والقياس والسحب لدى المطورين والمشغلين.

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

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

تأتي وقائع النشر والمعايير من سجل RFC 2357 ونص RFC 2357. يأتي إطار الحالات من RFC 2026، وسابقة المراجعة من RFC 1264، ومرجع ازدحام TCP من RFC 2001. والمستندان اللذان أوصى بإهمالهما هما RFC 1301 وRFC 1458. وتتبع حدود الاستنتاج مقالات Lu Heng عن Running-Code Primacy وMinimum Initial Specification وReality Layers. لا تثبت هذه المصادر حصة انتشار حالية، ولا انهياراً سببته الوثيقتان الأقدم، ولا سلامة عامة لأي بروتوكول لاحق.