الخلاصة

  • ترك RFC 3758 للخدمة تحديد متى تتوقف عن محاولة إرسال كل رسالة، ووضع FORWARD TSN كآلية عامة لتحريك التسلسل.
  • لا تلزم خدمة «الموثوقية الموقّتة» مكدّس SCTP بفحص الرسالة في اللحظة الدقيقة لانتهاء مهلتها.

وصلت الساعة إلى الصفر، لكن مكدّس SCTP كان يستطيع أن يفحص الرسالة في وقت لاحق. هذه ليست ثغرة في RFC 3758؛ بل هي الحدود التي رسمها بين معنى المهلة في الخدمة وبين توقيت عمل المكدّس.

لم يحوّل امتداد الموثوقية الجزئية SCTP إلى نقل غير موثوق بصورة عامة. أتاح للتطبيق أن يحدد، لكل رسالة، مدى استمرار النقل في المحاولة أو إعادة الإرسال. وإذا تفاوض الطرفان على دعم FORWARD TSN عند إنشاء الارتباط، أمكن للمرسل التخلي عن رسالة وإبلاغ المستقبل بتقديم نقطة أرقام تسلسل النقل التراكمية، أو TSN. وفي الرسائل المرتبة، تحمل الإشارة أيضاً معلومات عن تسلسل التدفق كي يتمكن المستقبل من تحرير رسائل بقيت عالقة خلف الفجوة.

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

يظهر الفرق عند مقارنة قاعدة الحياة في SCTP الأصلي بالخدمة الموقّتة. في RFC 2960 كان بالإمكان استخدام lifetime لمنع إرسال بيانات قديمة لم تُرسل بعد للمرة الأولى. أما إذا حصل الإرسال الأول قبل انتهاء المهلة، فكانت الرسالة تتحول إلى رسالة موثوقة عادية ويستمر التعامل معها بإعادة الإرسال. أزال RFC 3758 هذا القيد في خدمة الموثوقية الموقّتة: يمكن التخلي حتى عن رسالة سبق إرسالها إذا انتهت مهلتها.

لكن ذلك لا يعني وجود مؤقّت مستقل لكل رسالة. يجب على المرسل تقييم lifetime قبل تخصيص TSN، ثم قبل إرسال الرسالة أو إعادة إرسالها بعد تخصيصه. ويوضح RFC 3758 أن التنفيذ لا يحتاج إلى فحص مستقل عند لحظة الانتهاء نفسها؛ إذ يستطيع فحص الرسالة عند نقاط معالجة قائمة، مثل تخصيص TSN أو الإرسال أو انتهاء مؤقّت إعادة الإرسال، أو في فرصة عملية أخرى. لا يفرض النص أن يقع التقييم فوراً عند انقضاء المهلة.

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

تؤثر مرحلة الرسالة أيضاً في عواقب التخلي. إذا انتهت المهلة قبل تخصيص TSN، يستطيع المرسل إسقاطها من دون إنشاء فجوة في فضاء التسلسل. وإذا كان TSN قد خُصص، تُعلَّم البيانات بأنها متروكة وقد يحتاج النظير إلى FORWARD TSN كي يتقدم. وإذا تُرك جزء من رسالة مجزأة، يجب ترك الأجزاء الأخرى في الرسالة نفسها أيضاً. فضاء TSN مشترك على مستوى الارتباط، بينما تنتمي أرقام الرسائل المرتبة إلى التدفقات؛ وتربط الإشارة بين هذين المستويين من دون الادعاء أن الحمولة المفقودة قد وصلت.

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

التفاوض على القدرة شرط آخر. إذا لم يعلن النظير دعم FORWARD TSN، فلا يمكن استخدام الامتداد على ذلك الارتباط. على التطبيق الذي يعتمد على الموثوقية الجزئية أن يعرف النتيجة ويختار بين إيقاف البدء أو استخدام خدمة أخرى أو المتابعة من دون هذه القدرة. دعم المكدّس المحلي لا يثبت قبول الطرف البعيد.

أضاف RFC 7496 لاحقاً سياستي حدّ إعادة الإرسال والأولوية. تؤكد الإضافتان الفكرة نفسها: قد تتغير القاعدة التي تقرر التخلي، بينما تبقى آلية تحريك التسلسل عامة. الخدمة تختار متى تتوقف المحاولة؛ والنقل يحدد كيف يتجاوز الطرفان أثرها.

المصادر