الخلاصة

  • لا تنشئ URG والمؤشر العاجل قناة بيانات منفصلة؛ فالمعلومات العاجلة تبقى داخل فضاء تسلسل TCP العادي.
  • وصفت RFC 793 موضع الحد بصيغتين متعارضتين، ثم اختارت RFC 1122 «آخر بايت عاجل»، قبل أن توحّد RFC 6093 القاعدة مع الممارسة المنتشرة على «البايت التالي للبيانات العاجلة».
  • تحتفظ RFC 9293 بدعم الآلية وبالقاعدة الحالية، لكنها لا تجعلها مسار أولوية وتثني التطبيقات الجديدة عن الاعتماد عليها.

عندما تُضبط راية URG يصبح المؤشر العاجل، وهو إزاحة موجبة من رقم تسلسل المقطع، جزءًا من فضاء التسلسل نفسه الذي يحمل البيانات العادية. يدخل المستقبل الوضع العاجل ما دام موضع الحد أمام RCV.NXT، ثم يعود إلى الوضع العادي عندما يلحق تقدم الاستقبال بذلك الموضع. لذلك تظل البايتات داخل التدفق؛ أما تقديم إحدى واجهات المقابس لبايت واحد كما لو كان «خارج النطاق» فهو سلوك واجهة، لا خدمة نقل ثانية.

كان التناقض الأصلي دقيقًا لكنه مؤثر. قال وصف الترويسة في RFC 793 إن المؤشر يحدد البايت التالي للبيانات العاجلة، بينما جعلت معالجة الإرسال SND.UP مساويًا لـ SND.NXT-1، أي آخر بايت عاجل. اختارت RFC 1122 تفسير آخر بايت، وطلبت دعم تسلسل عاجل بأي طول وإشعار التطبيق بصورة غير متزامنة. لكن RFC 6093 وجدت أن التنفيذات المنتشرة التي درستها اتبعت تفسير البايت التالي؛ لذلك حدّثت RFC 793 وRFC 1011 وRFC 1122 لتثبيت ذلك التفسير. وتحافظ RFC 9293 عليه كمتطلب حالي.

لا يساوي عدد طلبات الإرسال العاجلة عدد إشعارات الاستقبال بالضرورة؛ فقد يتغير المؤشر أثناء بقاء المستقبل في الوضع العاجل من دون إشعار جديد. كما وثقت RFC 6093 أن بعض الوسطاء كانوا يمسحون راية URG ويصفّرون المؤشر، لا أن جميعهم يفعلون ذلك. ولا تثبت المصادر نسب الاستخدام الحالية أو الإعدادات الافتراضية الحالية لأنظمة التشغيل أو تواتر الهجمات.

المصادر