الخلاصة

  • يقع Sent حين تمر البيانات المشتقة من الرسالة إلى أسفل المكدس أو عبره ولا تعود مسؤولية Transport Services API.
  • لا يحدد RFC 9622 إن كانت البيانات قد أرسلت بالفعل أو بقيت في مخزن واجهة الشبكة أو النواة؛ لذا لا يصبح الحدث دليلاً قابلاً للنقل عن الوصول إلى النظير.

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

في RFC 9622 يرسم Colin Perkins وبقية المؤلفين حداً أضيق. الوثيقة القياسية لعام 2025 تصف واجهة مجردة بين التطبيق ومنظومة خدمات النقل المحلية. بعد Send يحدث Sent عندما تكون بيانات الرسالة قد انتقلت إلى المكدس الكامن أو خلاله ولم تعد في عهدة الـAPI. أما موضعها الدقيق في تلك اللحظة فقد يكون إرسالاً فعلياً أو مخزناً في الواجهة أو في النواة أو حالة أخرى تحددها كل عملية تنفيذ.

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

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

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

Sources