الخلاصة

  • ضمن RDP السعي إلى إيصال كل الرسائل، لكنه لم يفرض عرضها على التطبيق بالترتيب دائماً؛ كان نمط التسليم يختار عند Open ويبقى طوال الاتصال.
  • حفظ ACK حد التسلسل المتصل، بينما سمّى EACK المقاطع الصحيحة وراء الفجوة كي يعاد إرسال المفقود وحده.
  • لم يكن إقرار النقل دليلاً على تنفيذ التطبيق، ولم يحوّل NUL أو RST أو رقم IANA 27 حالة النقل إلى إثبات لنتيجة أعلى.

الشاهد لا يصدر الحكم

إذا أرسل المضيف المقاطع 100 ثم 101 ثم 102 ثم 103 وضاع 101، يبقى آخر تسلسل متصل عند 100. لكن 102 و103 قد يكونان قد وصلا واجتازا التحقق. تجاهل وصولهما يهدر حقيقة مفيدة؛ القفز بالحد التراكمي إلى 103 يزوّر حقيقة الفجوة.

حل RFC 908 التناقض الظاهري بسجلين. كان ACK العادي يعلن آخر مقطع وصل صحيحاً وبالترتيب. وكان EACK يضيف أرقام المقاطع التي وصلت صحيحة خارج الترتيب. يعرف المرسل عندئذ أن 101 يحتاج إلى إعادة إرسال، وأن 102 و103 لا يحتاجان إليها.

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

لماذا احتاجت التطبيقات إلى اختيار مختلف

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

إلا أن كتل الذاكرة قد تحمل عناوين مواقعها. عندئذ يمكن وضع الكتلة 102 قبل وصول 101 من دون تغيير معناها. أما أمر مصحح يثبت نقطة توقف ثم أمر يستأنف التنفيذ، فقد يصبح خطيراً إذا انعكس ترتيبهما.

لم يدّع النقل أنه يعرف حاجات التطبيقين. تضمنت مطالبة Open نمطاً مرتباً أو غير مرتب. في النمط غير المرتب، يستطيع المستقبل نسخ 102 إلى مخزن المستخدم عند قبوله. وفي النمط المرتب، يستطيع أن يرسل EACK للمقطع نفسه، لكنه يحجبه عن التطبيق حتى يصل 101.

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

بداية الاتصال جزء من معنى كل إقرار

لم يتغير نمط الترتيب بين رسالة وأخرى. ثبت عند إنشاء الاتصال وظل سارياً حتى نهايته. حمل SYN رقم التسلسل الابتدائي، والحد الأقصى للمقاطع غير المقر بها، والحجم الأقصى للمقطع، وأعلام الخيارات ومنها نمط التسليم المرتب.

لذلك لا تكفي لقطة تبدأ في منتصف الاتصال لإثبات ما رآه التطبيق. قد تعرض EACK دقيقاً للمقطع 102، لكنها لا تعرف إن كان SYN قد أجاز التسليم الفوري أو فرض الانتظار. حقبة الاتصال هي سياق الدليل.

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

حياة الاتصال ليست حياة البرنامج

عرّف RDP حالات CLOSED وLISTEN وSYN-SENT وSYN-RCVD وOPEN وCLOSE-WAIT. وعالج فتحاً متزامناً حين يتقاطع SYN من الطرفين، فيحتفظ كل منهما برقمه الابتدائي ويقر SYN الآخر.

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

عند الإغلاق، يرسل RDP ‏RST ويدخل CLOSE-WAIT ثم يزيل سجل الاتصال. حمّل RFC 908 المستخدم مسؤولية التأكد من تسليم البيانات اللازمة قبل طلب الإغلاق. لم يصنع البروتوكول إيصال إنجاز للتطبيق من نهاية النقل.

وهكذا تكون مراتب الإثبات واضحة: الفحص الصحيح يخص سلامة مقطع وفق الخوارزمية؛ ACK وEACK يخصان قبول RDP؛ النسخ إلى مخزن المستخدم يضيف خطوة؛ أما الأثر الدائم أو اكتمال العملية فله دليل آخر.

الاختبار غيّر النسخة الثانية

سجل RFC 1151 عام 1990 مشكلات كشفتها تجارب 1986 و1987. كان حساب الفحص غير الخطي ذي 32 بت في النسخة الأولى يتأثر كثيراً بتمثيل بيانات المضيف، حتى إن تطبيقين محسنين على عتاد متقارب اختلفا في الكلفة بخمسة أضعاف. استبدلت النسخة الثانية به فحص TCP ذي 16 بت.

واتسعت منافذ RDP من ثمانية إلى ستة عشر بتاً. ولأن رأس الرسالة تغير، ارتفع رقم النسخة إلى 2. وصحح النص أيضاً SND.UNA: بعد إقرار SEG.ACK يصبح أقدم غير مقر به هو SEG.ACK + 1.

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

يبقي سجل IANA لأرقام البروتوكولات القيمة 27 لـRDP. هذه مطابقة رسمية بين اسم ورقم. ليست قياساً لحركة الشبكة، ولا جرداً للتطبيقات، ولا اختياراً للنسخة، ولا دليلاً على دعم EACK.

أربع إجابات بدلاً من كلمة واحدة

هل وصل المقطع سليماً؟ هل أقره RDP؟ هل ظهر للتطبيق؟ هل أحدث التطبيق النتيجة المقصودة؟ لم يسمح RDP لكلمة «موثوق» أن تبتلع الأسئلة الأربعة.

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

المصادر