الخلاصة

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

تطمئن عبارة «بدعم من المورّد» الموظف الذي يوقع العقد. الحزمة المتجهة إلى آلة ثانية تبحث عن اتفاق في السلوك، لا عن ختم على الورق. في RFC 873 الصادرة في سبتمبر 1982، تناول Michael A. Padlipsky بهذه الروح نقاشاً داخل مشتريات وزارة الدفاع الأمريكية. رأى بعض المشاركين أن انتظار بروتوكولات مرتبطة بالنموذج المرجعي لـ ISO، ويوردها المصنعون، قد يوفر مال الحكومة مقارنة باستعمال مجموعة بروتوكولات ARPANET الجارية. تعامل Padlipsky مع التوفير الموعود كميزانية تحتاج إلى تفصيل.

أول بند فيها: ما الحزمة التي سيشتريها القسم فعلاً؟ قال إن X.25 يعالج جزءاً من مسار الاتصال، ولا يقدم بمفرده مجموعة الخدمات اللازمة لتقاسم الموارد بين الحواسيب. وإضافة مواصفات أخرى للوصول والعنونة لا تجمع تلقائياً كل ما كانت جهات مثل National Bureau of Standards وISO تعمل عليه؛ حتى هذان المساران اختلفا في بعض تفاصيلهما. يمكن لموظف الشراء أن يكتب «مجموعة كاملة» في خانة واحدة، بينما تبقى وظائف الطبقات وواجهاتها موزعة بين مسودات مختلفة.

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

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

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

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

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

تحتفظ RFC 873 بصورة واضحة لقرار كان مطروحاً عام 1982. على المشتري أن يسأل: ما المجموعة الكاملة التي يمكن تسليمها اليوم؟ أين تعمل بالفعل؟ أي الخيارات يشترك فيها الطرفان؟ ومن سيدفع إذا اختلف تفسيرهما؟ أمر الشراء يستطيع تحديد اسم المورّد. نجاح الاتصال يحتاج إلى سلوك متفق عليه وتجربة تُظهره.