الخلاصة

  • نشر متطوعون أوصافاً منظمة للحواسيب والروابط في comp.mail.maps كي يستخدمها pathalias في حساب مسارات البريد.
  • لم تكن الخريطة تمثيلاً رسمياً ومحدثاً لحظياً للشبكة؛ فقد أضاف كل موقع بياناته، وظلت الدقة رهناً بمن يبلغ عن التغييرات ويصححها.

قد يُكتب المسار كسلسلة من الحواسيب، لكن توجيه الرسالة يتطلب أولاً معرفة أي منها يمكن أن يتولى تمريرها. يذكر تاريخ لاحق لمشروع UUCP أن جلسة Birds-of-a-Feather في مؤتمر USENIX، في يناير 1984، جمعت أكثر من ثلاثين متطوعاً لبناء خريطة وصيانتها. كان pathalias موجوداً بالفعل، لكن لم تتوفر له خريطة كاملة. أطلق المشاركون على المبادرة اسم UUCP Project وبدأوا نشر التحديثات الإقليمية في مجموعة Usenet المسماة comp.mail.maps. وبعد انتهاء التمويل الأولي من USENIX، استمر المشروع بجهود تطوعية.

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

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

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

يكشف مقال أسترالي من عام 1988 جانباً من الاستخدام. فمنذ 1986، جُمعت بيانات عقد ACSnet في aus.map، وحُفظت في حاسوب محدد، ثم أُرسل جزء منها إلى خريطة UUCP العالمية. وفي جامعة سيدني، جمعت البرامج منشورات Usenet وفككت أرشيفات shell وأنشأت فهرساً محلياً قابلاً للبحث. أجابت الخريطة عن أسئلة لا توضحها ملفات حالة الشبكة، مثل الجهة التي تشغل حاسوباً أو إصدار Unix الذي يستخدمه. وقد وصفها الكاتب بأنها مكملة لتلك الملفات لا بديلة عنها.

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

في نوفمبر 1990، وصفت رسالة على Usenet دورة محلية أكثر آلية: جمع منشورات comp.mail.maps، وفك الملفات، وتشغيل pathalias يومياً عبر cron، وتحديث ملف المسارات المحلي وإرسال بريد للمسؤول عند الخطأ. قللت الأتمتة الوقت بين نشر التحديث واستخدامه، لكنها لم تجعل البيانات صحيحة تلقائياً. وفي نقاش عام 1987 عن إعادة التوجيه الديناميكي، حذر المشاركون من أن قواعد بيانات المسارات لا تتحدث بالسرعة الكافية لضمان عدم ظهور حلقات.

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

المصادر