RFC 1235: بث واحد وإصلاح مستقل لكل محطة

الخلاصة

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

كان الخادم يعرف الملف جيداً، ومع ذلك يكرره لكل جهاز كما لو كان نسخة مختلفة. تناول John Ioannidis وGerald Maguire Jr. هذه الكلفة في RFC 1235 الصادر في يونيو 1991. اقترحا بروتوكول CFDP كي ينتقل الملف مرة عبر وسط قادر على البث، فتلتقطه محطات كثيرة. الهدف العملي في تجاربهما كان تشغيل محطات عمل بلا أقراص معاً على شبكة راديو حزم تجريبية.

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

قبل استقبال البيانات، تحتاج المحطة إلى تذكرة من 32 بت مرتبطة باسم الملف وحجمه وحجم كتلته. يمكن أن يوفرها خادم أمامي معدل من BOOTP أو TFTP؛ تحويل الاسم إلى تذكرة يقع خارج قلب بروتوكول النقل. بعد الحصول عليها، تستمع المحطة أولاً إلى رزم تحمل التذكرة نفسها، فقد يكون خادم CFDP يبث الملف بالفعل لطلب جهاز آخر. إذا انتهت المهلة بلا رزم مطابقة، ترسل FULREQ ليبدأ إرسال الملف كاملاً.

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

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

حجم الكتلة المقترح، 512 بايت، أبقى الرزمة كلها دون حد MTU الأدنى لـIP البالغ 576 بايت كما حسبته الوثيقة. ولأن رقم الكتلة من 16 بت، بلغ حد الملف المنطقي 32 ميغابايت؛ مع كتلة 1024 بايت يصبح 64 ميغابايت. الملفات الأكبر تحتاج إلى تقسيم. وأشارت الوثيقة إلى أن IP multicast سيكون أنسب حين ينتشر، لأنه يخفف البث الذي تسمعه أجهزة غير مشاركة.

تصنف بطاقة RFC Editor هذا البروتوكول Experimental. يذكر النص برامج مرجعية، لكنه لا يسجل عدد المواقع التي تبنته أو نجاح إقلاع محطة بعينها. ما يبقى واضحاً هو الفرق المحاسبي: انتهى إرسال الخادم مرة، لكن لكل محطة وقتها الخاص حتى تملأ آخر فراغ.