الخلاصة

  • أتاح RFC 977 للقارئ طلب المقالات التي يريدها من قاعدة أخبار مركزية على خادم محلي واحد أو عدد قليل من الخوادم، من دون نسخ المجموعة كاملة إلى كل محطة عمل.
  • فصل Kantor وLapsley بين مسار القراءة هذا وبين تبادل المقالات بين خوادم الأخبار. واقترحا خوادم وسيطة للتخزين المؤقت، لكنهما استثنيا تشغيلها من المواصفة.
  • يثبت النص نية تقليل التخزين المكرر، لا مقداراً مقاساً للتوفير أو انتشاراً شاملاً. تركيز القراءة داخل شبكة محلية لا يعني جعل Usenet كلها نظاماً مركزياً واحداً.

محطة العمل لا تحتاج إلى حمل الأرشيف

يبدأ RFC 977 من مجموعة أجهزة متصلة بشبكة محلية، قد تضم محطات عمل ذات مساحة محدودة على القرص. إذا خزّن كل جهاز جميع المقالات، فسيحتفظ المستخدم بنسخ من مواد قد لا يقرأها قط. السؤال الذي تناوله Brian Kantor من UC San Diego وPhil Lapsley من UC Berkeley في مقترحهما الصادر في فبراير 1986 كان أكثر تحديداً من سؤال مركزية الشبكة: هل يمكن إتاحة القراءة من دون تحويل كل جهاز إلى أرشيف مستقل؟

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

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

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

القراءة والتوزيع مساران منفصلان

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

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

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

التخزين المؤقت اقتراح لا مواصفة مكتملة

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

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

العبء ينتقل إلى الخدمة

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

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

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

امتداد المواصفة عبر الزمن

في أكتوبر 2006، أعلن RFC 3977 أن RFC 977 أصبح متقادماً وقدّم نفسه بديلاً يوضح بعض الغموض ويضيف وظائف أساسية. وظل يصف استرجاع القارئ للمقالات من قاعدة بيانات مركزية. وفي الشهر نفسه، نظم RFC 4644 نقل المقالات غير المتزامن بين الخوادم باستخدام CHECK وTAKETHIS.

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

إسهام Kantor وسياقه

تذكر صفحة تأبين من UC San Diego أن Kantor عمل في الجامعة 47 عاماً، وكان مسؤولاً عن البريد الجامعي ومشغلاً لخوادم الأسماء ومشاركاً في إدارة البنية التحتية للشبكة. وتنسب إليه تصميم NNTP. أما RFC 977 فيسجل التأليف المشترك مع Phil Lapsley. تضع السيرة البروتوكول ضمن مسيرة تشغيل خدمات الشبكة، بينما تحفظ الوثيقة حدود المساهمة الجماعية.

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

المصادر