الخلاصة

  • أظهر RFC 1307 لمزود النقل حالتين فقط، up وdown، بينما احتفظ DSLCP داخلياً بست حالات لتدبير الطلبات المتداخلة والردود المتأخرة.
  • في حالة Up كان طلب release يرسل teardown إلى المتحكم وينقل DSLCP إلى Going Down، لكنه يبلغ مزود النقل فوراً أن الوصلة down قبل اكتمال عمل المتحكم.
  • كان teardown ينجح دائماً من منظور الواجهة المحلية، وحتى رد «لا توجد معاملة مطابقة» أمكن تجاوزه كما لو نجح الطلب؛ وهذا لا يثبت تفكيك الدارة أو تحرير السعة أو توقف الفوترة أو أي نتيجة بيانات.

الإعلان الذي سبق الحدث

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

صدر البروتوكول في مارس 1992 بصفة Experimental ولغرض مواصلة البحث، لا كمعيار إنترنت. جاء من مشروع لدى Cray Research للتحكم في وصلات شبكة لاحقة يعرفها المضيف، مع حجب الفروق بين آليات المفاتيح عن مزود النقل. يشرح الوثيقة منطقاً تجريبياً وقرارات واجهة؛ ولا يثبت وجود متحكم أو دارة بعينها في الحاضر.

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

كان طريق التحكم قائماً قبل الطريق المراد إعداده

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

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

حملت الرسالة معرّفاً من 16 بت وعنواني نقطتي نهاية من 32 بت، إلى جانب الوظيفة وحالة الحدث ونص حر يفهمه المتحكم. قصد RFC أن تُستخدم هوية المعاملة من المعرّف والعنوانين معاً. لا يكفي الرقم منفرداً ليكون دارة أو جلسة أو شخصاً أو رمز سلطة عالمي. كما أن event status يصف الوصلة نسبةً إلى آخر function request؛ فإذا اقتُطع من هذا السياق فقد الزمن والفعل اللذين يمنحانه معناه.

مصباحان في الخارج وست غرف في الداخل

لم ير مزود النقل سوى up أو down. خلفه احتفظ DSLCP بست حالات: Down وComing Up وUp وGoing Down وBring Down وBring Up. لم تكن الأسماء زخرفة؛ كانت ذاكرة مؤقتة لما طلبه المستخدم الآن، وما أُرسل إلى المتحكم سابقاً، وما يزال ينتظر رداً.

في Down لا توجد نية محلية لإبقاء الوصلة فعالة. Coming Up تعني أن setup أُرسل ولم يكتمل. Up هي الحالة المستقرة التي يعرض فيها DSLCP الوصلة مفعلة. Going Down تحفظ teardown معلّقاً. أما Bring Down وBring Up فهما حالتا انعكاس: النية الجديدة تناقض العملية القديمة وهي لا تزال جارية.

طلب release أثناء Coming Up لا يستطيع محو setup الذي أصبح في الطريق. ينتقل DSLCP إلى Bring Down، وينتظر نجاح setup ثم يرسل teardown فوراً. وبالعكس، إذا جاء connect أثناء Going Down، ينتقل إلى Bring Up؛ وعند اكتمال teardown يرسل setup جديداً. في كلتا الحالتين قد يشير طلب المستخدم الحالي، وأمر المتحكم المعلق، والحالة التي يراها مزود النقل، إلى اتجاهات مختلفة.

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

كان setup خبراً وكان teardown سياسة

عامل RFC 1307 طرفي دورة الحياة على نحو غير متناظر. بالنسبة إلى setup، يُبلغ مزود النقل إن كان الطلب نجح أو فشل. أما teardown فيستطيع المزود افتراض نجاحه لأن DSLCP يعيد دائماً استجابة نجاح لطلب الإنهاء.

تظهر قوة هذا القرار في حالة Up. عندما يصل release، يرسل DSLCP teardown إلى المتحكم، يدخل Going Down، ويخبر مزود النقل في الحال أن الوصلة down. لم ينتظر هذا الإعلان نتيجة المتحكم. صار معنى down هنا: «لن يحتفظ DSLCP بالوصلة بوصفها متاحة لهذا المزود»، لا «رصدنا اكتمال تفكيك الدارة».

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

الرسالة المتأخرة قد تكون صحيحة وغير صالحة للعمل

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

قد تنتج الطلبات المعادة ردوداً غير متوقعة أو مكررة، وقد يعيد ترتيب الرزم نجاحاً بعد أن تغيرت نية المضيف. إذا وصل setup succeeded وDSLCP في Down، اعتبر RFC ذلك محتملاً من طلبات مكررة وإعادة ترتيب، وأرسل teardown تعويضياً. الرسالة يمكن أن تصف نجاح setup حقيقياً في سياق سابق، لكنها أصبحت قديمة بالنسبة إلى الوضع المحلي الحالي.

وفي Bring Down يؤدي نجاح setup أيضاً إلى إرسال teardown والدخول في Going Down. لا تُلغى الواقعة القديمة، بل تُقابل بفعل جديد يعيد النظام نحو النية الأحدث. لذلك لا يجوز ضغط «نجاح ثم إنهاء» إلى «لم يحصل setup». الأول يصف تسلسلاً، والثاني يمحو ما قد يكون حدث عند المتحكم.

الانعكاس الآخر يكشف عدم التزامن بصورة أشد. إذا وصل teardown succeeded بينما DSLCP في Up، قال RFC إن خطأ ما وقع. اقترح النهج المحافظ: إنزال الاتصال وإعادة المزامنة، مع الإشارة إلى أن تجاهل الرسالة قد يكون مرضياً أيضاً. لم يفرض السجل تفسيراً وحيداً للحالة المادية؛ احتفظ بالشك وقدم خيارين تشغيليين.

غياب المعاملة لم يصبح فشلاً لدى المستخدم

في Up قد يرد المتحكم بأن teardown فشل لأن الطلب حمل معاملة غير صالحة: لا سجل لديه يطابق المعرّف وعنواني النهاية. الإجراء المقرر كان الاستمرار كما لو نجح الطلب.

هذه قاعدة تقارب محلي، لا اتفاقاً بين الطرفين. قد يكون السجل فُقد، أو لم يوجد، أو سبق حذفُه؛ ولا يعيد رد unknown transaction بناء تاريخ الدارة. «تابع كما لو نجح» يحدد ما يفعله DSLCP بعد الرد، ولا يثبت أي حدث مادي وقع قبل أن يعجز المتحكم عن المطابقة.

ويجب فصل ذلك عن asynchronous network down. يستطيع المتحكم إرسال إشعار مستقل بأن الشبكة انخفضت. عند وروده في Coming Up أو Bring Up أو Up، ينتقل DSLCP إلى Down ويبلغ مزود النقل. هذا رصد صادر عن المتحكم، لا طلب release من المضيف ولا teardown succeeded. قد تنتهي الحالات الثلاث إلى الكلمة الخارجية نفسها، لكن طرق الإثبات مختلفة.

ما لم يناقشه البروتوكول

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

كما أن هذا ليس امتداداً لمقال RFC 1306 المنشور. هناك كانت القضية طلب التفعيل المرتبط بمسار، وقاعدة عدم البيانات قبل اكتمال الدارة، وأسماء المسارات والمؤقت السابق لأول بايت. هنا القضية آلة RFC 1307 نفسها: ست حالات مخفية، نية تنعكس، نجاح teardown محلي، معاملة مجهولة، وردود مكررة أو معاد ترتيبها. الخلط بينهما يبدد الفجوة الدقيقة بين طلب الوصلة والسيطرة على دورة حياتها.

المصدر وحدود الدليل

يعتمد المقال حصراً على RFC 1307، الصادر في مارس 1992 كبروتوكول Experimental للبحث الإضافي. يثبت المصدر حقول الرسالة وآلة الحالات وسلوك المهلات والردود وحدود التجريد الموصوفة. لا يثبت دارة أو متحكماً أو تبادلاً حياً، ولا أمناً أو تحرير سعة أو توقف فوترة أو نقل بيانات أو نتيجة تطبيق.