الخلاصة

  • عندما تنفد قيمة reportAfter في RFC 3342، يُنشأ تقرير توقيت مؤقت، لكن البيانات الأصلية تُرسل إلى المرحّل التالي رغم ذلك.
  • يستطيع noLaterThan إيقاف التسليم، بينما يحد returnTrip من عودة التقرير النهائي؛ لذلك يبقى الإنذار والمنع ووصول الإيصال ونتيجة التطبيق أدلة منفصلة.

كان جوهر APEX يقدم خدمة رزم تطبيقية فورية وبأفضل جهد. وفي غياب الخيارات قد يؤدي تعذر المرحّل إلى إسقاط صامت. أضاف RFC 3342 الانتظار المنضبط والحدود والتقارير، لكنه لم يمنح كل مؤقت السلطة نفسها على حالة الرسالة.

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

عتبة المراقبة لم تكن أمراً بالإلغاء

كانت كل قفزة تعالج dataTiming، ولهذا وجب على المنشئ ضبط targetHop="all" وmustUnderstand="true". وقبل الإرسال إلى المرحّل التالي، يطرح المرحّل من reportAfter زمن المعالجة المحلي اللازم لاختيار المسار وإتمام الربط والاستعداد للإرسال.

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

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

الحد الصلب غيّر مسار التنفيذ

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

الفارق مباشر: reportAfter يعني أبلغ ثم واصل، وnoLaterThan يعني لا تتجاوز هذا الحد. إذا خُزن الحدثان تحت حالة timeout واحدة فلن يعرف المدقق هل المحاولة الأولى ما زالت قادرة على الوصول.

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

كان على الإيصال أن يُسلّم أيضاً

بعد نجاح الإرسال إلى المتلقي، تؤدي قيمة returnTrip غير الصفرية إلى إنشاء تقرير القفزة الأخيرة. لا يظهر التقرير مباشرة في سجل المرسل، بل يعود كعملية بيانات APEX جديدة. وتحمل هذه العملية dataTiming.noLaterThan مساوياً لقيمة returnTrip الأصلية.

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

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

للطابور وعدد القفزات حدود أخرى

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

أما dataHopping فحد عدد المرحّلات بآلية تشبه TTL في IP لاكتشاف الحلقات. هو يقيس القفزات لا الزمن. قد تنفد ميزانية الوقت مع بقاء قفزات، أو يحدث العكس؛ وكل حد يصف خطراً مختلفاً.

أتاح attachOverride لتطبيق جديد أن يحل محل التطبيق السابق عند نقطة النهاية نفسها. ملكية البيانات المتأخرة تخص حدود RFC 3340 ولها تغطية مستقلة. تقرير التوقيت لا يعيّن من يملك حق تنفيذ العمل القديم.

ما الذي يثبته السجل التاريخي

نُشر RFC 3342 في يوليو 2002 ضمن مسار المعايير، وهو اليوم Historic، ولا يُظهر بحث RFC Editor أخطاء مطابقة. ويسجل تاريخ IETF في 29 يوليو 2012 أنه، بحسب علم IETF، لم تكن تطبيقات RFC 3340–3343 منشورة، وأن الوظائف كانت تقدمها XMPP واسعة الانتشار وفق RFC 6120 وRFC 6121.

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

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

المصادر