كانت Usenet ترسل المقال المكرر؛ وأتاح NNTP للندّ أن يسأل أولاً

الخلاصة

• تعامل RFC 977 مع المقال المكرر بوصفه كلفة تحددها الوصلة: أمكن للمضيفين المتصلين تفاعلياً مقارنة ما لديهما قبل إرسال النص.
• وأبقى RFC نفسه الإرسال ثم إسقاط النسخ المكررة في وصلات UUCP أحادية المعاملة، حيث قد تنتهي الدفعة قبل التفاوض.

في فبراير 1986 نشر Brian Kantor وPhil Lapsley الوثيقة RFC 977، وهي مقترح بروتوكول نقل أخبار الشبكة. لم تكن فكرته الأبرز أن وسيلة نقل واحدة يجب أن تهيمن على Usenet. بل إن كلفة المقال المكرر تتوقف على الوصلة التي تحمله. عبر اتصال تفاعلي مستمر، يستطيع مضيفان مقارنة ما لديهما قبل أن يقررا ما سيرسلانه. أما إذا لم تُفتح الوصلة إلا مرة في اليوم، فقد يستغرق الحوار المطلوب لاتخاذ القرار وقتاً أطول من نقل النسخة المكررة نفسها.

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

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

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

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

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

تثبت هذه الوثائق نية التصميم لا انتقالاً شاملاً. لا يذكر RFC 977 نسبة مواقع Usenet التي تبنت NNTP في 1986، ولا يقيس مقدار النطاق الترددي الذي وُفّر، ولا يثبت أن كل تنفيذ منع التكرار. إسهامه أدق: جعل اختيار المقالات تبادلاً مباشراً بين المضيفين، كي يحدد المتلقي ما يريده وما يملكه قبل إرسال نسخة أخرى.

المصادر: RFC 977، بروتوكول نقل أخبار الشبكة؛ RFC 850، معيار تبادل رسائل USENET؛ RFC 1036، معيار تبادل رسائل USENET.