في SCTP، إغلاق المقبس الأصلي لا ينهي الارتباط الذي فُصل عنه

الخلاصة

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

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

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

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

عدم الحجب لا يصنع مورداً مستقلاً

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

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

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

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

الواصف الجديد يحمل التحكم أيضاً

تحدد دعوة sctp_peeloff المقبس الأصلي وهوية ارتباط سبق إنشاؤه. عند النجاح تعيد واصفاً غير سالب، وعند الفشل تعيد سالب واحد مع بيان الخطأ. وهي بهذا تختلف عن قبول ارتباط جديد يصل للتو: التطبيق يختار عملاً موجوداً لديه بالفعل.

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

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

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

سياسة الخمول مرتبطة بنطاقها

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

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

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

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

تسمح واجهة shutdown الموصوفة بالاحتفاظ بالواصف لتلقي إشعارات أثناء الإنهاء. إلا أن SHUT_WR يبدأ إنهاء بروتوكول SCTP كاملاً، وليس إغلاق نصف الاتصال كما في TCP. ولا يشكل أي من هذه الأحداث، بمفرده، إثباتاً لتسوية معاملة على مستوى التطبيق.

حدود المصدر وحدود الاستنتاج

يصنف سجل RFC Editor الوثيقة على أنها Informational منشورة في ديسمبر 2011. ليست مسحاً حالياً لما تدعمه أنظمة التشغيل جميعها. وتضم قائمة التصحيحات التي جرت مراجعتها تصحيحات متحققاً منها في مواضع أخرى، من دون تصحيح مباشر للفقرة 9.2. ولا ينبغي مساواة الملاحظات المحتفظ بها لتحديث لاحق أو المرفوضة بالتغييرات المعتمدة.

بعد هذه الوقائع يأتي التحليل الإداري. يناقش Lu Heng في مقاله عن مشكلة الوكالة العلاقة بين سلطة القرار وتحمل النتائج. هنا يصبح السؤال محدداً: هل يعرف من وافق على منفعة الفصل من سيتولى إنهاء الارتباط المستقل؟ هذا ليس حكماً على نوايا المهندسين.

وفي تفسيره لسبب وجود BTW Media يقدم الواقع القابل للملاحظة على الدفاع عن موقف. وتطبيق ذلك هنا يعني تتبع الواصفات التي ما زالت تتحكم في ارتباطات، بدلاً من اعتبار عبارة «أغلقنا المدخل» وصفاً شاملاً لكل ما انتهى.

الفصل يجعل الحد التقني أوضح. وما تحتاجه المؤسسة هو ألا تترك المسؤولية عن الإنهاء على الجانب القديم منه.