كيف حمل حاسوب رسائل Cronus إلى شبكة أخرى

الخلاصة

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

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

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

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

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

هذا الجانب اليومي من التشغيل حاضر في RFC 947 الصادرة في يونيو 1985. كتبها Ken Lebowitz وDavid Mankins من BBN Laboratories لوصف تجربة مرتبطة بـCronus، وهو نظام تشغيل موزع يجمع خدمات تعمل على أنواع مختلفة من الحواسيب.

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

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

كانت RFC 919 لعام 1984 قد شرحت كلفة هذا الاختيار: كل مضيف يسمع رسالة بث يبذل جهدا لمعالجتها. وقدّم تطبيق Cronus لاحقا مثالا محددا على مكان ظهور ذلك الجهد.

قائمة وجهات في متناول المشغل

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

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

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

وكان هناك سبب إداري ملموس. فقد تتولى جهة تشغيل البوابات، بينما تتولى جهة أخرى تحديد مكونات Cronus. يصبح تغيير مجموعة التجربة عندها مرتبطا بتعديل معدات يديرها آخرون. وضع الوظيفة في عمليات على مضيف منح مسؤولي النظام موضعا أقرب إليهم لضبطها.

أما تضمينها في نواة Cronus فكان سيقتضي، بحسب البدائل التي ناقشها المؤلفان، معرفة المشاركين بعناوين بعضهم أو إنتاج حل خاص بالنظام. اختارا مكررا منفصلا يمكن إعداد وجهاته بصورة مستقلة، مع إمكانية استخدامه لبروتوكولات أخرى تعتمد على البث.

عنوان محفوظ وعمل إضافي

الحفاظ على عنوان المرسل تطلب إضافة قدرة خاصة إلى تطبيق TCP/IP لدى BBN، تسمح للعملية ذات الامتيازات بإرسال حزمة تحمل عنوان مضيف آخر. كانت التجربة إذن تعتمد على دعم برمجي محدد.

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

ربط الترتيب الموصوف شبكتي Ethernet تفصل بينهما شبكتان محليتان أخريان، وكانت الحزم تعبر بوابتين على الأقل. عملت الخدمة على VAX يشغل 4.2BSD UNIX وبرمجيات الشبكة الخاصة بـBBN. وأفاد المؤلفان بأنها أدت الغرض المطلوب طوال عدة أشهر. يظل هذا وصفا لتلك التجربة، لا قياسا لانتشار الحل في الإنترنت.

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

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

أصبح من الممكن تعديل نطاق الأسئلة التي يرسلها النظام من خلال إعداد يملكه مشغلوه. وفي المقابل، صار عليهم تشغيل خدمة تظل يقظة، تختار وتنقل وتعيد الاتصال. تكمن قيمة هذه التجربة في أنها أظهرت العمل الذي يحمل حرية التعديل، إلى جانب الحرية نفسها. تتناول RFC 922 سياق بث IP مع الشبكات الفرعية. أما RFC 1112 اللاحقة فحددت امتدادات للإرسال متعدد الوجهات، ولا تثبت أنها حلت محل تركيب Cronus الموصوف هنا.