فينت سيرف والعمل الذي جعل الربط بين الشبكات قابلاً للنشر

الخلاصة

• يربط متحف تاريخ الحاسوب مشكلة الاتصال بين الشبكات في 1973 بفينت سيرف وروبرت كان، ويعرض تجربة 1977 عبر ثلاث بيئات شبكية بوصفها عملاً احتاج إلى مؤسسات ومنفذين متعددين. [2] [3]
• تسمي RFC 675 فينتون سيرف ويوغن دلال وكارل صنشاين مؤلفين مشاركين لمواصفة برنامج التحكم في الإرسال عبر الإنترنت الصادرة في ديسمبر 1974. تثبت هذه الوثيقة مساهمة محددة، لا اختراعاً أو تنفيذاً منفرداً. [1]
• اقترح جون بوستل في IEN 2 فصل تسليم رزم الإنترنت عن النقل بين الطرفين. ووصف سيرف في IEN 48 نموذج catenet مع حفظ نسبة المصطلح والتأثير إلى لويس بوزان. يبين ذلك أن الحد المعماري خضع للنقد والتعديل. [4] [5] [12]
• تسجل IEN 98 وIEN 175 أعمال تنفيذ لدى BBN وUCLA وSRI وMIT وUCL وNDRE ومؤسسات أخرى. جاءت قابلية النشر من كود يعمل في بيئات متعددة، لا من النشر الورقي وحده. [6] [11]
• نشرت RFC 790 أرقاماً مخصصة، بينما وثقت RFC 791 وRFC 793 في 1981 الحد الفاصل بين Internet Protocol وTransmission Control Protocol. يحافظ السجل على التفرد، ويبقى التشغيل نتيجة يجب أن يثبتها المنفذون والمشغلون. [7] [8] [9]

كانت البداية شبكات مختلفة لا شبكة واحدة

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

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

تضع مصادر متحف تاريخ الحاسوب سيرف وكان أمام هذه المسألة في 1973، ثم تسجل عرضاً عبر ثلاث بيئات لشبكات الحزم في 1977. [2] [3] تسمح هذه المصادر بالقول إن سيرف شارك في تصميم الربط بين شبكات غير متجانسة. ولا تسمح بتحويل المساهمة إلى ملكية للإنترنت أو إلى سبب وحيد لكل نتيجة لاحقة.

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

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

RFC 675 نقطة ثابتة لمساهمة مشتركة

تبدأ قيمة RFC 675 من سطر المؤلفين. تسمي الوثيقة Vinton Cerf وYogen Dalal وCarl Sunshine بوصفهم مؤلفين لمواصفة ديسمبر 1974. [1] وبذلك تثبت أن سيرف شارك في كتابة مواصفة مهمة، كما تمنع نسب كل تفاصيلها إليه وحده.

تناقش الوثيقة اتصالات بين عمليات تستخدم عناوين مركبة من معرف شبكة ومعرف TCP ومنفذ، وتتناول إنشاء الاتصال والتسلسل والإقرار وإعادة الإرسال والتحكم في التدفق وواجهة المستخدم وبنية تنفيذ مفاهيمية. [1] كانت محاولة دقيقة بما يكفي لتوجيه منفذين يعملون على أنظمة مختلفة.

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

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

وتتطرق RFC 675 إلى سلطة استخدام الاتصال ومنع انتحال TCP آخر. [1] لا تمثل هذه اللغة ضماناً أمنياً حديثاً، لكنها تبين أن الهوية والتفرد والتفويض كانت مسائل مترابطة. الرقم الصحيح لا يمنع سوء الاستخدام إن لم يطبق النظام ضوابطه، والتنفيذ الجيد لا يستطيع التنسيق إن كانت الأرقام متعارضة.

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

نقد بوستل نقل المسؤولية إلى طبقة أوضح

تجادل IEN 2 لجون بوستل بأن تسليم رزمة عبر الإنترنت يجب أن ينفصل عن النقل الموثوق بين المضيفين. [4] لم يكن ذلك تغيير اسم، بل قراراً يحدد أين توجد الحالة وأي جهة تستطيع اكتشاف العطل وإصلاحه.

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

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

تثبت IEN 2 أن البنية النهائية لم تخرج كاملة من تصميم شخص واحد. انتقد بوستل الحد المجمع، وتغيرت البنية. [4] لا يلغي ذلك مساهمة سيرف؛ بل يضعها في عملية كان نجاحها مرتبطاً بقدرتها على قبول النقد ودليل التنفيذ.

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

نموذج catenet يحفظ استقلال الشبكات ومصدر الفكرة

يصف سيرف في IEN 48 catenet، أي مجموعة من شبكات الحزم المتصلة. [5] تستطيع الشبكات الاحتفاظ بتقنياتها وإدارتها المحلية، بينما تتعامل عند الحد المشترك مع داتاغرام الإنترنت والبوابات والمضيفات.

وتحفظ الوثيقة صلة المصطلح بلويس بوزان. كما تدعم صفحة بوزان لدى Internet Hall of Fame حد تأثير CYCLADES والداتاغرام. [12] ليس حفظ هذه النسبة تقليلاً من سيرف، بل تفسيراً لكيفية تطور التقنية عبر أفكار يتم تبنيها وإعادة صياغتها واختبارها.

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

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

وبالمثل، لا تجعل كتابة نموذج catenet سيرف مشغلاً لكل البوابات أو صاحباً لـCYCLADES أو ضامناً لاستمرارية كل مسار. [5] توفر الوثيقة إطاراً يمكن اختباره، وتوفر الأنظمة الجارية النتيجة.

التنفيذ المستقل جعل الغموض مرئياً

تسجل IEN 98 تقارير تنفيذ من BBN وUCLA وSRI وMIT وNDRE وغيرها. [6] وتضيف IEN 175 قائمة واسعة من المنفذين ومناقشات عن البوابات والأداء والعناوين. [11] بهذه السجلات يظهر العمل الذي لا يظهر في قصة شخص مشهور.

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

يجب فهم تجربة 1977 بالطريقة نفسها. أثبتت أن مجموعة من الشبكات والبوابات والمضيفات استطاعت في شروط التجربة تمرير اتصال عبر ثلاث بيئات. [2] ولم تثبت أن كل مضيف انتقل أو أن الأداء والأمن والاستمرارية أصبحت مضمونة.

كما توضح المصادر حدود الأدوار. مؤلف المواصفة مسؤول عن الواجهة العامة والادعاءات في النص. المنفذ مسؤول عن الكود. مشغل الشبكة مسؤول عن الأجهزة والمسارات المحلية. مدير البرنامج ينسق الأهداف والموارد. تتعاون الأدوار، لكنها لا تصبح سلطة واحدة بسبب شهرة أحد أصحابها.

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

RFC 790 حولت التفرد إلى مرفق مشترك

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

نشرت RFC 790 التي أعدها جون بوستل قائمة بالأرقام المخصصة للشبكات والبروتوكولات وغيرها. [7] لم تكن وظيفتها تشغيل الشبكات، بل منح المنفذين دفتراً مشتركاً يستطيعون الرجوع إليه بدلاً من التخمين أو التخصيص المتضارب.

سلطة الدفتر محدودة. الإدخال الصحيح لا يثبت وجود مسار. والتخصيص لا يثبت تحديث البرنامج. وتوفر قاعدة البيانات لا يضمن أن بيانات الأمان أو الاتصال صحيحة. وعلى الجانب الآخر، إعلان مسار فعلي لا يثبت أن استخدام الرقم يتوافق مع السجل والتفويض.

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

ينبغي هنا أيضاً الحفاظ على النسبة. يتضمن عمل سيرف المبكر نموذجاً للعناوين، وكان دوره جزءاً من برنامج أوسع؛ أما RFC 790 فهي سجل بوستل. [1] [7] احتاجت البنية إلى العملين ولا يصح دمجهما تحت اسم موضوع المقال.

مواصفات 1981 ثبتت تقسيماً أوضح للعمل

وثقت RFC 791 وRFC 793 في سبتمبر 1981 Internet Protocol وTransmission Control Protocol. [8] [9] تجسد الوثيقتان الانتقال من التصميم المجمع إلى فصل أكثر وضوحاً.

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

ويساعد التقسيم في التشخيص. يستطيع المشغل السؤال بالتتابع: هل شكل المضيف الداتاغرام بصورة صحيحة؟ هل العنوان صالح؟ هل مررته البوابات؟ هل عولجت التجزئة؟ هل أنشأ TCP الحالة وأقر البيانات وأعاد الإرسال؟ لا تختفي العلاقات بين الطبقات، لكن العطل لا يبقى عبارة عامة هي «الشبكة لا تعمل».

ولا يمكن نسبة كل حقول 1981 إلى سيرف. يجب حفظ دور بوستل وسياق DARPA Internet Program، وكذلك العمل الجماعي السابق. [4] [8] [9] تقدير مساهمة سيرف لا يحتاج إلى الاستيلاء على إسهام زملائه.

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

دور مدير البرنامج تنسيق لا سيادة

تدعم RFC 1160 وصفاً محدوداً لدور سيرف مديراً لبرنامج DARPA، كما تسجل هياكل مؤسسية وتسليمات لاحقة. [10] يمكن لمدير البرنامج تحديد الأهداف، ودعم البحث، وجمع المنفذين، وتمويل التجارب. هذه مساهمة شخصية قابلة للنسبة.

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

ويبين انتقال المسؤولية أن البنية خرجت من الاعتماد على شخص واحد. أصبحت المواصفات مرجعاً عاماً، وانتشرت خبرة التنفيذ، وبقيت السيطرة التشغيلية لدى المؤسسات التي تدير الأنظمة الحقيقية.

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

قابلية النشر سلسلة أدلة

تشكل المصادر سلسلة مترابطة. تسجل المصادر التاريخية المشكلة والمشاركين؛ تسجل RFC 675 مواصفة تفصيلية مبكرة؛ تسجل IEN 2 نقد الحد؛ تسجل IEN 48 نموذج catenet ونسبة الفكرة؛ تسجل IEN 98 وIEN 175 التنفيذ المتعدد؛ تحفظ RFC 790 الأرقام؛ تثبت RFC 791 وRFC 793 حد 1981؛ وتسجل RFC 1160 الدور المؤسسي المحدود والتسليم. [1]-[12]

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

تشرح السلسلة مجتمعة كيف تصبح البنية قابلة للنشر: تعرف المشكلة، وينشر التصميم، ويعدل بالنقد، ويكتب مستقلون الكود، وتكشف التجارب الفروق، ويحفظ السجل المعنى، وتثبت المواصفات المعدلة الواجهة، ثم تستطيع المسؤولية الانتقال.

هذه الصورة أكثر فائدة من لقب «أبو الإنترنت». يعطي اللقب مكانة، بينما تبين سلسلة الأدلة من فعل ماذا وما الذي لم يثبت بعد. وهي تسمح بتقدير مساهمة سيرف من دون تحويل الاحترام إلى سيطرة تقنية غير مدعومة.

من مشكلة التصميم إلى حد تشغيلي قابل للتحقق

لم تكن الفترة من 1973 إلى 1981 قفزة واحدة من فكرة مكتملة إلى بنية جاهزة. تركت كل مرحلة نوعاً مختلفاً من الدليل. وضعت السجلات التاريخية مشكلة الربط بين الشبكات والمشاركين في سياقهم؛ وثبتت RFC 675 مرحلة تفصيلية من التصميم؛ وحفظت وثائق IEN النقد والنموذج والتنفيذ؛ ثم سجلت وثائق 1981 تقسيماً أوضح. [1]-[9]

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

تضع المصادر سيرف وروبرت كان عند مشكلة البروتوكول بين الشبكات في 1973. [2] [3] يثبت هذا مساهمة شخصية محددة، لكنه لا ينسب إلى شخص واحد تبديل الرزم والداتاغرام والبوابات وبرامج المضيفين وتشغيل كل شبكة. التصميم نفسه افترض أن تحوله مؤسسات مستقلة إلى كود يعمل.

تمثل RFC 675 القرار التالي: نشر تفصيل كافٍ لكي يستطيع الآخرون البناء والاعتراض. [1] يحدد ذكر سيرف ودلال وصنشاين التأليف بدقة. وتقدم الوثيقة الاتصالات والتسلسل والتأكيد وإعادة الإرسال والتدفق والمعرفات كنقاط يمكن مقارنتها بالكود. لا يشغل النشر البروتوكول، لكنه يجعل نقده وتصحيحه ممكنين.

لا ينبغي قراءة TCP المجمع في 1974 كأنه يصف الحد النهائي بين IP وTCP. ستمحو هذه القراءة المراجعة التي جاءت بعده. قيمة المواصفة المبكرة أنها صارت جسماً عاماً للتنفيذ والنقد، لا أنها كانت كاملة منذ البداية. تنشأ قابلية النشر من القدرة على تعيين المسؤولية الموضوعة في الطبقة الخطأ واختبار التصحيح.

تظهر IEN 2 هذه القابلية للتعديل. [4] نقل اقتراح بوستل مهاماً بين رزمة الإنترنت المشتركة والنقل الموثوق من طرف إلى طرف. يغير هذا النقل عمل المشغل. البوابة التي تحفظ حالة كل اتصال لها حدود توسع وأعطال مختلفة عن بوابة تمرر الرزم فقط.

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

تضيف IEN 48 نموذج catenet وتحفظ في الوقت نفسه النسب الفكري إلى لويس بوزان. [5] [12] ليس هذا مجرد هامش للمجاملة. يوضح أن أفكار الداتاغرام وcatenet دخلت في سلسلة من التبني وإعادة التركيب والتوثيق. تثبت الوثيقة دور سيرف في وصف النموذج، لا ملكيته لكل مصدر فكري أو تشغيلي.

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

تظهر IEN 98 وIEN 175 كيف وضعت التنفيذات المستقلة هذا الحد تحت الضغط. [6] [11] كانت لدى المؤسسات أنظمة تشغيل وشبكات محلية وخيارات برمجية مختلفة. قد يفسر فريقان المهلة الزمنية أو انتقال الحالة أو حد الرزمة بطريقتين متعارضتين. لا يظهر الفرق إلا عندما يحاول البرنامجان التواصل.

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

تحتل تجربة 1977 موقعاً محدداً في هذه السلسلة. [2] أظهرت أن مضيفين وبوابات وفرقاً وثلاث بيئات شبكية استطاعت نقل الحركة تحت الشروط المجربة. هذا دليل مهم على أن التصميم أمكنه عبور تنوع حقيقي. لكنه ليس دليلاً على كل مضيف وكل مسار، ولا وعداً بالأداء أو الأمان أو التوفر الدائم.

تضيف RFC 790 سجل الأرقام المشترك إلى الحد الجاري. [7] قد تصل الرزمة إلى وجهتها وتفسر خطأ إذا اعتبر تنفيذان الرقم نفسه لمعنيين مختلفين. يسجل الدفتر الحالة المتوقعة ويقلل التصادم. وهو لا يثبت كوداً ولا يكون مساراً؛ تأتي سلطته من دقة يمكن التحقق منها.

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

تقدم RFC 791 وRFC 793 في 1981 تقسيماً عاماً أوضح للمنفذين المستقلين. [8] [9] يعالج IP الداتاغرام والعنونة والتمرير والتجزئة من دون وعد بتسليم موثوق من طرف إلى طرف. ويحفظ TCP التيار المرتب الموثوق عند الطرفين. لا يلغي التقسيم التعقيد، لكنه يتيح أسئلة تشغيلية أدق.

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

تقدم RFC 1160 رؤية مؤسسية محدودة لدور سيرف في البرنامج ولانتقال المسؤوليات بعده. [10] يستطيع مسؤول البرنامج ربط الأهداف ودعم البحث وجمع المنفذين وإبقاء المشكلات مرئية. لا يصبح بذلك مشغل كل مضيف أو مالك الأرقام. تكتسب البنية دوامها عندما تتيح الوثائق والاختبارات والمسؤوليات لآخرين متابعة العمل.

تنتج عن هذه السلسلة صورة دقيقة للقيادة. يظهر سيرف في التصميم مع كان، وفي التأليف مع دلال وصنشاين، وفي توثيق catenet، وفي التنسيق البرنامجي. [1] [2] [5] [10] ويظهر بوستل وبوزان وفرق التنفيذ في مواضع أخرى لا غنى عنها. تربط النسبة الدقيقة كل ادعاء بمن يمكنه تفسيره.

وبذلك تصبح «قابلية النشر» قدرة متراكمة، لا تاريخ نشر وثيقة. تفهم أنظمة مستقلة الرزمة نفسها، وتستخدم قيماً من دون تصادم، وتكشف الخلاف وتصحح الحد وتسلم المسؤولية بسجل كافٍ. تثبت المواصفة التوقع، ويثبت السجل والكود والمسار والمشغل ما حدث فعلاً.

حدود الادعاء ومعنى الاستمرارية

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

في RFC 675، يثبت سطر التأليف مشاركة سيرف ودلال وصنشاين في كتابة المواصفة. [1] ولا يثبت من كتب كل برنامج مضيف أو من شغل كل بوابة. وفي IEN 98 وIEN 175، تظهر الفرق والمؤسسات المنفذة من دون أن تصبح كل نتيجة لها فعلاً شخصياً لسيرف. [6] [11]

وينطبق الحذر نفسه على الأرقام. تثبت RFC 790 حالة سجل منشور، لكن التحقيق في حادث محدد يحتاج إلى حالة السجل في زمنه، وإعداد النظام، والسلوك المرصود. [7] بدون هذه الأجزاء لا يمكن الفصل بين خطأ السجل وتأخر الإعداد والاستخدام غير المفوض.

لا يجعل الفصل بين IP وTCP التشخيص آلياً. [8] [9] قد يرتبط تيار غير مؤكد بحالة النقل أو رزمة مفقودة أو تجزئة أو عنوان أو مرشح. فائدة الفصل أنه يتيح رصد كل عقد وإرسال الإصلاح إلى المسؤول المناسب. ينظم الحد السؤال؛ ويجيب الكود والشبكة.

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

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

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

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

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

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

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

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

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

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

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

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

المصادر

1. RFC Editor، RFC 675: Specification of Internet Transmission Control Program.
2. Computer History Museum، 1973 timeline.
3. Computer History Museum، Internet History: the 1970s.
4. RFC Editor History، IEN 2.
5. RFC Editor History، IEN 48.
6. RFC Editor History، IEN 98.
7. RFC Editor، RFC 790: Assigned Numbers.
8. RFC Editor، RFC 791: Internet Protocol.
9. RFC Editor، RFC 793: Transmission Control Protocol.
10. RFC Editor، RFC 1160: Internet Activities Board.
11. RFC Editor History، IEN 175.
12. Internet Hall of Fame، Louis Pouzin.
13. Wikimedia Commons، صورة Vint Cerf بعدسة Joi، بترخيص CC BY 2.0.