الخلاصة

  • في 27 أكتوبر 1980، قبلت IMP في ARPANET تحديثات التوجيه ذات الأرقام 8 و40 و44 وأعادت نشرها مراراً؛ إذ جعلت مقارنة الستة بتات كل قيمة أحدث من أخرى.
  • يعرض Eric Rosen في RFC 789 تفسيراً مرجحاً بدأ بإعادة إرسال غيّرها عطل عتادي؛ استهلكت الحلقة المخازن المؤقتة، وعطّلت فحوص الوصلات، وجعلت الشبكة نفسها قناة بطيئة لتمرير التصحيح.

بقيت بوابة المستخدم حية، لكن العقد لم تعد تتصل

لم تبدُ الأعراض الأولى كأن جدول توجيه واحد اختار مساراً خاطئاً. ظل بعض المستخدمين يتصلون عبر خط هاتفي بـTerminal Interface Processor، أو TIP، لكنهم كانوا يتلقون رسالة «net trouble» عند محاولة الوصول إلى مضيف متصل بـInterface Message Processor (IMP) آخر. وانقطعت اتصالات قائمة. كان TIP يرد على المستخدم عبر الهاتف، بينما لم يعد بين IMP وآخر مسار صالح للاستخدام. ساعد هذا الفرق فريق التشغيل على نقل البحث من مدخل المستخدم إلى الشبكة التي تصل العقد بعضها ببعض.

أعاد Eric C. Rosen بناء الحادثة في RFC 789 بالاستناد، ضمن أمور أخرى، إلى تفريغات ذاكرة من عدة IMP. أظهرت معظمها مخازن مؤقتة مزدحمة بتحديثات توجيه تنتظر المعالجة. وبدا أن التحديثات جاءت من IMP 50، الذي تعطل قبل الحادثة بوقت قصير وكان خارج الشبكة أثناءها. كما عانى جاره المباشر، IMP 29، خللاً عتادياً كان يُسقط بتات. لم يكفِ إعادة تشغيل IMP قريبة؛ فبعد إعادة وصلها كانت تتلقى التحديثات نفسها من جيرانها.

مقارنة تعود إلى نقطة البداية

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

استخدمت القاعدة نصف فضاء الأرقام للتعامل مع الالتفاف: تُعد القيمة أحدث إذا تقدمت بما يصل إلى 32، أو إذا تجاوزت الصفر والتفت حوله بمسافة تزيد على 32. لم يكن ذلك تاريخاً ولا ساعة. لكن القيم الثلاث المرصودة أنتجت دورة: 44 أحدث من 40، و40 أحدث من 8، و8 أحدث من 44.

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

لم يقدّم Rosen أصل هذه القيم الثلاث كحقيقة محسومة. كان تفسيره الأرجح أن تحديثاً رقمه 44 أعيد تكوينه من بيانات مخزنة لإرساله مجدداً، وأن بتات مفقودة غيّرت الرقم أولاً إلى 40 ثم إلى 8. احتوت الحزم المرسلة على مجموع تحقق، لكن حزمة الإعادة كانت تُبنى من جداول داخلية لا تُفحص باستمرار. وكان الفحص الدائم سيستهلك وقت المعالج أو الذاكرة، وهما موردان محدودان. كما ذكر Rosen احتمالاً عكسياً: ربما كان الرقم الأصلي 8 ثم أضيفت بتات. تثبت التفريغات وجود الحلقة، لكنها لا تجعل مسار الخطأ العتادي يقيناً.

تحولت حلقة التوجيه إلى استنزاف للموارد

حصلت معالجة تحديثات التوجيه على أولوية مرتفعة. ومع استمرار الدوران، استهلكت CPU والمخازن المؤقتة. ولم تعد IMP تملك مخازن لمعالجة رسائل HELLO وI-HEARD-YOU التي تستخدمها العقد المتجاورة للتحقق من حالة الوصلات. وعندما تعذّر تشغيل فحص الجوار، أعلن البرنامج الخطوط غير متاحة. وهكذا غيّرت رسائل التحكم الطوبولوجيا التي كانت IMP أخرى تحاول قياسها.

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

كان على الإصلاح عبور الشبكة المتضررة

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

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

مصادر الأدلة وحدودها

نُشر تقرير Rosen في عدد يناير 1981 من SIGSOFT Software Engineering Notes ثم وُزّع بوصفه RFC 789. وهو السجل الرئيسي للحادثة، ويميز بين المشاهدة والاستنتاج. يوثق بحث McQuillan وRicher وRosen المنشور في مايو 1980 اختبارات سابقة للخوارزمية على شبكة عاملة، لكنه لا يثبت اختبار اجتماع تلف البيانات المخزنة وحلقة أرقام التسلسل النادرة. وتسمّي مذكرة تذكارية قصيرة لـComputer History Museum الأرقام «طوابع زمنية»؛ أما RFC 789 فيصفها بدقة بأنها أرقام تسلسلية من ستة بتات.

المصادر: RFC 789؛ McQuillan وRicher وRosen، “The New Routing Algorithm for the ARPANET”؛ مدخل Computer History Museum ليوم 27 أكتوبر؛ نسخة ممسوحة ضوئياً من بحث 1980 على IPCOMPRO؛ أولوية الشيفرة العاملة لدى Heng Lu، مرجع تحريري فقط.