الخلاصة

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

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

ينبغي تضييق المثال منذ البداية. نحن أمام جلسة قائمة أرسل عميلها طلب تحديث للائتمان وينتظر في PendingU، لا أمام جميع إجراءات دخول المستخدم لأول مرة. توضح الفقرة السابعة، الجدول الرابع، من RFC8506 أن انتهاء Tx مع RETRY_AND_TERMINATE يتيح الخدمة مع البقاء في PendingU. أما فشل الإرسال أو إشعار الخطأ المؤقت اللاحق فينقل المعالجة إلى إنهاء الخدمة والدخول في Idle. وتشرح الفقرة 5.7 إجراءات الفشل المحيطة بهذا التسلسل.

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

مهلة التطبيق ليست حكماً نهائياً

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

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

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

توصي الفقرة 13 بعشر ثوانٍ لقيمة Tx. لا تثبت هذه التوصية إعداد شبكة بعينها، ولا تضمن أن كل تعرض للاستخدام المؤقت محدود بعشر ثوانٍ. مؤقت صلاحية الوحدات Validity-Time ومؤقت الإشراف على الجلسة لدى الخادم لهما وظائف أخرى. لا يمكن اختيار رقم واحد من المواصفة وتحويله إلى التزام عام باستمرارية الخدمة أو سقف إداري للمخاطر.

ثلاثة خيارات وحدود لا تتجاوزها

تعرف الفقرة 8.14 القيم TERMINATE وCONTINUE وRETRY_AND_TERMINATE، وتكون TERMINATE هي القيمة الافتراضية إذا غابت سمة معالجة الفشل. في PendingU، تنهي هذه القيمة الخدمة عند انتهاء Tx. أما القيمتان الأخريان فتسمحان بها عند هذا الحد الأول، ثم تختلفان عند فشل الإرسال أو الخطأ المؤقت: تسمح CONTINUE بالخدمة، بينما تنهيها RETRY_AND_TERMINATE. وتتوقف إعادة المحاولة نحو بديل أيضاً على دعم التحويل وتوافر وجهة مناسبة.

لكن السماح بالاستمرار لا يلغي الرفض الصريح. فالجدول الرابع ينهي الخدمة عند END_USER_SERVICE_DENIED بغض النظر عن CCFH. كما أن الاستعلام الأول المدمج مع AA-Request له آلة حالات أخرى تفصل الاتصال عند انتهاء Tx. لا يجوز لذلك تعميم سلوك انتظار تحديث جلسة قائمة على كل إجراءات المصادقة الأولية. موضوع RFC8506 هو ترخيص الائتمان؛ أما المصادقة والتفويض الخاصان بالخدمة فخارج نطاقه. ليست سياسة الاستمرارية إذناً شاملاً بتجاوزهما.

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

للخادم البديل ذاكرة يحتاج إليها

إبقاء الخدمة متاحة أثناء انتظار الرد ليس هو نقل تدفق التحكم لجلسة قائمة. تربط الفقرتان 5.7 و8.4 هذا النقل بسمة CC-Session-Failover. وعند غيابها تسري FAILOVER_NOT_SUPPORTED، فلا يجوز تحويل تدفق رسائل التحكم الائتماني لتلك الجلسة إلى خادم بديل. اختيار خادم احتياطي لجلسة جديدة مسألة مختلفة. وكذلك تبديل النظير على مسار النقل، الذي قد ينتج طلبات مكررة من دون أن يعني السماح بنقل جلسة ذات حالة.

عند دعم تحويل الجلسة، توصي المواصفة بنقل حالة الجلسة والحساب بين الخادمين، وتلزم التنفيذ بكشف الرسائل المكررة والخارجة عن التسلسل على نحو صحيح. لكنها لا تحدد آلية الاتصال بين الخوادم التي تنجز نقل الحالة. إن Session-Id وCC-Request-Number يحددان الطلب؛ وجودهما ليس دليلاً على أن الحجوزات نُسخت بصورة سليمة. استجابة عنوان احتياطي تثبت جانباً من الوصول، لا اكتمال الاستمرارية.

ولا تختفي محاسبة الاستخدام خلال الانتظار. توصي الفقرة 5.7 بمسار احتياطي لبيانات الاستخدام، وتشترط في مثال CONTINUE مع DELIVER_AND_GRANT جمع المعلومات وتبادلها مع خادم الائتمان. لذلك لا تساوي الخدمة المستمرة خدمة بلا قياس أو بلا مقابل أو خسارة مالية مؤكدة. ويظل الاستعلام النهائي في الفقرة 5.4 معنيّاً بالإبلاغ عن الاستخدام وتسوية الحجز غير المستهلك. وفي الاتجاه الآخر، لا يثبت تحرير حجز لدى الخادم وحده أن العميل أوقف تقديم الخدمة.

ما تثبته الوثيقة وما لا تثبته

تصف الصفحة الرسمية الوثيقة بأنها Proposed Standard صادرة في مارس 2019 وتحل محل RFC4006. ولم يُظهر البحث عن التصحيحات قيوداً مطابقة عند التحقق في 8 سبتمبر 2026. لا يثبت ذلك انتشار التنفيذ أو مطابقة منتج أو وقوع حادثة. ولا تتوافر هنا أرقام عن مستخدمين متضررين أو استهلاك فعلي أو خسائر.

يوفر طرح Lu Heng عن الواقع بوصفه المنتج بدلاً من الترويج لموقف منهجاً مناسباً: شرح الآلية قبل مدح الاستمرارية أو إدانتها. ويتيح مقاله عن مشكلة الوكالة في حوكمة الإنترنت سؤالاً عن صاحب القرار ومن يتحمل النتيجة، لكنه لا يثبت دوافع أي فريق تشغيل Diameter. الحقيقة المحددة تكفي هنا: يمكن أن يكون طلب التحكم غير محسوم بينما يقع استهلاك حقيقي للخدمة.