الخلاصة

  • يعرّف RFC 938 PORT NAK لحزمة DATA يقع رقمها ضمن نافذة الإقرار لكن منفذها مجهول: يعيد المستقبل قيمة rcv_nxt الحالية ويتخلص من البيانات.
  • يقر الرد باستلام أرقام الحزم حتى حدّ التسلسل المذكور، لكنه يرفض رقم المنفذ. ولا يثبت أن تطبيقاً قرأ الحمولة أو فسرها أو أجازها أو خزنها أو أكمل عملاً بها.

تبدو كلمة «تسليم» بسيطة إلى أن يُطلب تحديد الفاعل الذي سلّم وماذا قُبل بالفعل. RFC 938، وهو مواصفة Internet Reliable Transaction Protocol، لا يختصر هذه السلسلة. فقد نصّ بوضوح على أن PORT NAK يرفض رقم المنفذ، لا رقم الحزمة. يستطيع المضيف، إذن، أن يحتفظ بحقيقة تقدم استلامه المتسلسل، من دون أن يدّعي وجود مستقبل محلي للبيانات.

وتصف صفحة معلومات RFC 938 الوثيقة الصادرة في فبراير 1985 بأنها experimental/proposed. لهذا فهي دليل على تصميم مقترح، لا على انتشار أو حركة مرور أو استعمال راهن. كما أن RFC 791 يحدد أن حقل Protocol في IP يعرّف بروتوكول الطبقة التالية، فيما يسجل IANA الرقم 28 لـ IRTP. التسجيل تنسيق لاسم ورقم، لا شهادة تشغيل.

سؤالان في رأس قصير

يتكون رأس IRTP من ثمانية ثمانيات: نوع الحزمة، رقم المنفذ، رقم التسلسل، الطول، والمجموع الاختباري. والأنواع هي SYNCH وSYNCH ACK وDATA وDATA ACK وPORT NAK. رقم التسلسل يخص العلاقة الموثوقة بين المضيفين؛ أما المنفذ فيشير إلى البروتوكول الأعلى أو العملية المحلية المقصودة.

يمكن لعملية أن تطلب عدة منافذ، لكن لا يمكن إلا لعملية واحدة طلب منفذ بعينه. وكانت علاقة IRTP منظَّمة بحسب عنوان Internet البعيد، لا بحسب كل زوج مضيف-منفذ. وتحمل جدول الاتصال متغيرات منها snd_nxt وrcv_nxt وsnd_una، بينما ينشئ SYNCH وSYNCH ACK حالة المضيفين أو يعيدان مزامنتها. فالمنفذ ليس اسم الاتصال الموثوق؛ بل سؤال توجيه محلي يظهر عندما تبحث البيانات عن صاحب لها.

يبين إجراء الاستقبال الترتيب. عند DATA يفحص المكوّن أولاً ما إذا كان رقم التسلسل داخل نافذة الإقرار. وللحزمة الداخلة فيها يعيد حساب rcv_nxt ثم يسأل إن كان المنفذ معروفاً. إن كان معروفاً، يمكنه بعد DATA ACK وضع البيانات في طابور العملية. وإن لم يكن معروفاً، يرسل PORT NAK ويتخلص من البيانات. يحمل الردان rcv_nxt الحالي، لكن أحدهما فقط يقول إن تعيين المنفذ نجح.

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

من الأفضل حفظ ثلاثة أنواع من الدليل: دليل التسلسل عن علاقة وحدتي المضيفين، ودليل طلب المنفذ عن الخريطة المحلية، ودليل التطبيق – إن وُجد – عن التحليل والهوية والسياسة والمعاملة والاستدامة. هذه طبقات قرار مختلفة. وتساعد Note 64 لدى Heng Lu في قراءة هذا الحد: القاعدة المشتركة قد تكون حتمية وقابلة للتحقق محلياً، لكنها لا تتولى الاختيار اللاحق لفاعل محلي ولا تمنح نفسها سلطة تفسير الحمولة.

ولم تجعل RFC 938 كلمة reliable سياسة تشغيل موحدة. فقد ألزمت التنفيذ بآلية لإطلاق إعادة الإرسال وإعادة snd_una، وتركـت استراتيجية المؤقتات وإعادة الإرسال للمحلي. وإشارتها إلى فترة صمت مدتها دقيقتان وإلى RFC 793 مقارنة تصميمية محدودة، لا تجعل IRTP هو TCP ولا تثبت تاريخ نشر مشتركاً.

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

يدعم RFC 938 دلالة الرأس وPORT NAK، وتدعم صفحة المعلومات الحالة، ويدعم RFC 791 دور حقل IP، ويستخدم RFC 793 لمقارنة فترة الصمت فقط، وتؤكد IANA تخصيص الرقم 28. لا تقيس هذه المصادر اعتماداً أو أداءً أو استخداماً معاصراً. كما لا تجعل NAK دليلاً أمنياً أو تجارياً: قد تكون حقيقة الاستلام صحيحة في طبقتها، فيما يكون رفض المستقبل المحلي صحيحاً في الطبقة التالية.