الاختبار الذي نجح بلا كلمة: ما الذي كان Discard يثبته فعلاً

الخلاصة

• عرّف RFC 863 خدمتي TCP وUDP على المنفذ 9 بحيث ترميان كل ما يصل ولا ترسلان جواباً تطبيقياً؛ وفي TCP ينهي المتصل الجلسة.
• إنشاء اتصال TCP وإقراراته يعطيان دليلاً على مسؤولية طبقة النقل، لا شهادة بأن عملية Discard نفذت قراءة محددة أو سجّلت كل بايت.
• صمت UDP ينسجم مع الاستلام الصحيح والفقد والحجب وغياب الخدمة. لا يمكن تحويله إلى نسبة تسليم دون مراقبة مستقلة عند المستقبل.

حين يكون الفراغ جزءاً من العقد

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

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

TCP يحتفظ بأثر محدود

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

يثبت المصافحة أن طرف TCP بعيداً قبل تركيبة الاتصال في تلك اللحظة. وقد تكشف أرقام التسلسل والإقرار وإعادة الإرسال وRST والمهلة مقدار تقدم الدفق. إلا أن RFC 9293 يضع الحد: يقر TCP المستقبل حين يتحمل مسؤولية تسليم البيانات إلى مستخدمه. هذا ليس تصريحاً من عملية Discard بأن استدعاء القراءة اكتمل.

وقد يكون نجاح الإرسال المحلي أضيق. يناقش RFC 9293 واجهة تعيد إقراراً محلياً لـ SEND قبل إقرار TCP البعيد للمقطع. لذلك قد يثبت write أن المكدس المحلي قبل الذاكرة فقط.

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

أسباب متعددة تصمت بالطريقة نفسها في UDP

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

ولا يصلح غياب ICMP كشهادة. يوضح RFC 8085 أن الوسطاء يرشحون رسائل ICMP وأن تطبيق UDP يجب ألا يعتمد على وصولها ليعمل بصورة صحيحة وآمنة. الخطأ المتحقق منه معلومة؛ عدم الخطأ ليس إثباتاً عكسياً.

تحتاج تجربة التسليم إلى نقطة ثانية: عداد وصول، موضع التقاط معلوم، مقام إرسال ونافذة زمنية. من طرف واحد، «لم يصل رد» يقيس الردود لا وصول الطلبات.

لماذا لا يكرر هذا حلقة Echo وChargen

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

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

السجل يسمي الرقم ولا يشغل العملية

يسجل IANA اسم discard على المنفذ 9 لـTCP وUDP، ويحتفظ بصفوف SCTP وDCCP بمراجع أخرى. يعرّف RFC 863 الشكلين الأولين مباشرة. التسجيل يحفظ معنى مشتركاً للرقم، ولا يثبت وجود مستمع.

يصنف RFC 6335 المنفذ ضمن System Ports ويفصل بين المعين وغير المعين والمحجوز. حالة «معين» حقيقة إدارية، لا مصادقة للبرنامج أو المطابقة أو الإتاحة أو الإذن بإرسال حمل.

لذلك لا يملأ السجل فراغ UDP. وفي TCP يضيف الاتصال دليلاً على طرف نقل، لكن رقم المنفذ وحده لا يحدد العملية. سلطة الاسم ودليل التنفيذ منفصلان.

صياغة الادعاء قبل القياس

قبول المخزن محلياً، وتحمل TCP البعيد للمسؤولية، وقراءة العملية، ونسبة تسليم UDP أربعة ادعاءات تحتاج أربعة مصادر. يجب حفظ النقل والعناوين والزمن والبايتات والإقرارات وإعادة الإرسال والأخطاء ومن بدأ الإغلاق ومكان المراقبة.

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

المصادر والحدود

يأتي السلوك من RFC 863، والتصنيف elective من RFC 880. حدود TCP في RFC 9293، وعدم ضمان UDP في RFC 768، وإرشادات ICMP الحديثة في RFC 8085.

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