الخلاصة

  • يبدأ IHAVE بعرض Message-ID لا بمتن المقال. يستطيع المستقبل أن يعلن وجود نسخة، أو يطلب إعادة المحاولة، أو يطلب إرسال المقال كاملًا.
  • طلب المتن هو البوابة الأولى فقط. بعد فحص المقال يستطيع الخادم تأكيد النقل أو تأجيله أو رفضه، وحتى الرد الإيجابي لا يضمن أن تبقى النسخة محفوظة بعد المعالجة.
  • وزّع CHECK وTAKETHIS الخطوتين على عمليات قابلة للتوازي. ازدادت كفاءة الوصلة، لكن قرار التخزين والسياسة ظل عند المستقبل.

بطاقة صغيرة أمام حمولة كبيرة

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

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

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

سلف من رسائل العرض والطلب

تصف RFC 1036 رسالتي التحكم الأقدم ihave وsendme. كان نظام يعلن قائمة Message-ID لمقالات يملكها، ثم يطلب النظام الآخر ما ينقصه. أمكن جمع هويات عديدة في دفعة واحدة، لأن كلفة عرض هوية منفردة قد تقترب من كلفة مقال قصير.

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

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

جواب قبل المتن وآخر بعده

حوّلت RFC 977 الفكرة إلى أمر NNTP باسم IHAVE. يرسل العميل Message-ID. يرد الخادم بـ 335 إذا أراد المقال، وبـ 435 إذا لم يرده، وبـ 436 إذا كان ينبغي إعادة المحاولة في وقت لاحق.

بعد 335 وحده يرسل العميل المقال. ثم تأتي مجموعة ثانية من النتائج: 235 لنجاح النقل، و436 لفشل مؤقت، و437 لرفض لا يطلب إعادة المحاولة. وتذكر الوثيقة أسبابًا قد لا تظهر إلا بعد الفحص، مثل مجموعات أو توزيع غير مرغوبين، أو نقص المساحة، أو الطول المفرط، أو ترويسات مشوشة.

وهكذا فإن 335 يعني «أرني المقال»، لا «وضعت المقال في عهدتي». ويسجل الرد الثاني ما حدث عند البوابة التي تملك معلومات أكثر. حذف أحد الردين من السجل يمحو إما سبب توفير الحركة أو سبب رفض الجسم.

لا نجاح مستنتجًا من الصمت

تحافظ RFC 3977 على المرحلتين. لا يقبل IHAVE إرسال أوامر متتابعة من دون انتظار؛ ينتظر العميل الرد الأول، ثم يرسل المقال إذا طُلب، ثم ينتظر النتيجة النهائية. إذا غاب رد متوقع، تُعامل الحالة بوصفها فشلًا مؤقتًا، لا نجاحًا ضمنيًا.

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

وتفصل المواصفة أيضًا بين العبور عبر IHAVE وإدخال مقال جديد عبر POST. المستقبل في مسار العبور يحكم داخل علاقة نظيرين؛ لا يصدر شهادة عالمية عن الكاتب أو عن وصول المقال إلى كل الشبكة.

الرد الإيجابي له حدود زمنية

تحذر RFC 977 من أن خادمًا أعاد 235 قد يكتشف لاحقًا أن المقال غير مقبول ثم يتخلص منه بصمت. يثبت الرمز نجاح معاملة النقل التي عرّفها NNTP، لكنه لا يثبت أرشفة دائمة.

يتكرر الحد نفسه في RFC 4644. فحتى 239 الإيجابي بعد TAKETHIS قد تتبعه إزالة في معالجة لاحقة. ولإثبات الحيازة المستمرة يلزم رصد منفصل: وجود في مخزن الأخبار، أو إتاحة للقراء، أو عرض على نظير تالٍ.

هناك إذن سلم للأدلة: إرسال البايتات، ثم تأكيد المعاملة، ثم إثبات الاحتفاظ، ثم إثبات التوجيه التالي. لا يختصر رد واحد هذا السلم كله.

CHECK فصل السؤال عن الإرسال السريع

فرض IHAVE التقليدي انتظار ردين لكل مقال، وهو مكلف في الوصلات بعيدة المدى. قدمت RFC 4644 الأمر CHECK للسؤال عما إذا كان Message-ID مرغوبًا، والأمر TAKETHIS لإرسال المقال والحصول على الحكم النهائي. أمكن إبقاء عروض ونقول عديدة قيد العمل في الوقت نفسه.

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

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

اتفاق الموقعين خارج صيغة الأمر

تضع RFC 5537 هذه الآليات في عمارة Netnews الأوسع. كانت رسالتا ihave وsendme القديمتان قد صارتا شبه مهجورتين على الإنترنت، مع بقاء بعض الاستخدام في بيئات UUCP. أما المواقع الحديثة فتتفق فيما بينها على المواد ووسيلة النقل قبل التبادل.

يحدد ذلك الاتفاق المجموعات والتوزيعات والمرشحات المقبولة. لا يحمله Message-ID ولا ينشئه رد 335. يوفر الأمر لغة قابلة للتشغيل البيني لعرض بعينه، داخل علاقة تشغيلية يملكها الموقعان.

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

المصادر