متى يحتاج التخلي عن رسالة إلى رسالة أخرى في SCTP؟

الخلاصة

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

قرار الارتباط يسبق قرار الرسالة

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

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

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

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

ما الذي يجيزه إشعار واحد؟

بعد التفاوض، لا يجيز FORWARD TSN للمرسل اختيار أحدث بيانات تبدو مفيدة والقفز إليها. يحتفظ المرسل بنقطة الإقرار التراكمي الحقيقية التي أفاد بها المستقبل، وبنقطة أخرى محلية هي Advanced.Peer.Ack.Point. يمكن لهذه النقطة المتقدمة أن تمر فقط فوق أرقام TSN التالية التي جرى التخلي عنها فعلا.

يشرح مثال المرسل في RFC 3758 الحد بدقة. تبدأ النقطة عند 102؛ تُترك 103 و104؛ يبقى 105 غير مقر به وغير متروك؛ ويكون 106 مقرّا به. يجوز للنقطة المحلية أن تصل إلى 104، لكنها تتوقف أمام 105. وجود 106 الناجح وراء الفجوة لا يحول 105 إلى بيانات متروكة ولا إلى بيانات مستلمة.

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

تؤكد محاسبة الازدحام المعنى نفسه. يعامل المرسل البيانات المتروكة كمنتهية في دفتر الإرسال، لكنه لا يضيف بايتاتها إلى partial_bytes_acked ولا يستخدمها لتوسيع نافذة الازدحام. تحرير التزام محلي لا يبرهن أن المسار حمل تلك البايتات.

ما الذي لا تأذن به مدة الرسالة؟

كان للمدة معنى أضيق قبل هذا الامتداد. سمحت واجهة RFC 2960 بعدم بدء الإرسال إذا انتهت مدة البيانات وهي لا تزال في الطابور. أما إذا بدأت المحاولة في الوقت المحدد، فكان ينبغي مواصلة النقل الموثوق. واحتفظ RFC 4960 ثم RFC 9260 بهذا الفصل في الواجهة الأساسية.

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

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

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

أين يقف المستقبل بين التقدم وإعادة التجميع؟

للمستقبل مثال مختلف في RFC 3758. تكون نقطته عند 102، و103 مفقودا، و104 و105 موجودين، ثم يظل 106 مفقودا مع وجود 107. عند وصول FORWARD TSN يسمح بتجاوز 103، ينتقل الحد أولا إلى 103 بسبب الإذن، ثم إلى 105 بسبب البيانات الموجودة فعلا. لا يتجاوز 106.

إذن قد تجمع النقطة التراكمية النهائية بين دليلين غير متماثلين: استلام حقيقي لبعض البيانات، وغياب صار مسموحا لبيانات أخرى. Advanced.Peer.Ack.Point لدى المرسل لا يصبح بذلك الإقرار التراكمي الفعلي قبل أن ينفذ المستقبل الانتقال ويعبر عنه بإجراءاته المعتادة.

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

قد يضيع FORWARD TSN نفسه، لذلك تبقى آلية مؤقت إعادة الإرسال ذات الصلة عاملة ويعاد فحص التقدم. والإشعار القديم أو المساوي لا يرجع النقطة إلى الوراء، وإن كان قد يستدعي SACK جديدا لأن إقرارا سابقا ربما ضاع. أما DATA المتأخر بعد تجاوز موضعه فيعامل كنسخة مكررة ويسقط؛ ولا يمحو ذلك أي محتوى وصل إلى التطبيق قبل الانتقال.

تغيرت سياسة المرسل ولم يتسع تفويض المستقبل

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

أضاف RFC 7496 سببين محليين آخرين للتخلي. تحد سياسة عدد الإعادات محاولات إعادة إرسال DATA؛ فإذا كانت إعادة جزء واحد ستتجاوز الحد، تُترك الرسالة كلها. والحد صفر يعني التخلي عندما تصبح أول إعادة ضرورية، لا منع الإرسال الأول ولا إثبات وصوله. أما سياسة الأولوية فتختار رسائل أدنى أولوية من مخزن الإرسال عند الحاجة إلى مساحة؛ وهي ترتيب لمورد محلي، لا أولوية في الشبكة أو أمر تنفيذ لدى المستقبل.

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

مطلب WebRTC جاء فوق هذا الفصل

اشترط RFC 8831 لقنوات بيانات WebRTC دعم الاعتمادية الجزئية الزمنية والمحددة بعدد الإعادات. لكنه أبقى الترتيب والاعتمادية خيارين منفصلين، واستخدم زوجا من تدفقات SCTP المتعاكسة للقناة. وفي هذه البنية يعمل SCTP فوق DTLS، ثم ICE/UDP.

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

المصادر

• RFC 2960: واجهة الإرسال الأولى وعمر البيانات.
• RFC 3758: الاعتمادية الجزئية والتخلي وFORWARD TSN.
• RFC 4960: استمرار التمييز في المواصفة الأساسية.
• RFC 6458: الواجهة المعلوماتية لاختيار السياسة والقيمة.
• RFC 7496: حد الإعادات وأولوية الذاكرة وإحصاءات التخلي.
• RFC 8831: متطلبات قنوات WebRTC وترتيب الطبقات.
• RFC 9260: واجهة SCTP الأساسية في 2022.