الخلاصة

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

بروتوكول صغير لمسألة معرفية كبيرة

نُشرت RFC 2188 في سبتمبر 1997 بوصفها وثيقة Informational، لا Internet Standard. ولم تمر بمراجعة مجموعة عمل في IETF، كما أرفقت IESG تنبيهًا إلى قيود تتعلق بقابلية التوسع. هذا السياق مهم لأنه يمنع تحميل الوثيقة منزلة معيارية لا تدعيها، لكنه لا يقلل من فائدتها بوصفها وصفًا دقيقًا لنموذج عمليات بعيدة قصير ومنخفض الكلفة نسبيًا.

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

وتفصل الوثيقة بين دورين: الـ invoker، أي الطرف الذي يبدأ العملية، والـ performer، أي الطرف الذي ينفذها. هذا الفصل ليس مجرد تسمية وظيفية. فهو أساس لفهم أن كل طرف يملك أدلة مختلفة، لأن كلًا منهما يشاهد أحداثًا محلية مختلفة ويستنتج منها ما يستطيع استنتاجه عن الجانب الآخر.

المصافحة الثلاثية لا تخلق معرفة متناظرة

في نمط acknowledged تستخدم ESRO مصافحة من ثلاث مراحل. بعد أن يرسل الـ performer نتيجة RESULT أو خطأ ERROR، ينتظر إقرارًا من الـ invoker. وصول ذلك الإقرار يضيف معلومة حقيقية إلى ما يعرفه الـ performer: لم يعد يعرف فقط أنه أرسل النتيجة، بل تلقى أيضًا إشارة من الطرف الآخر مرتبطة بذلك التبادل.

لكن غياب هذه الإشارة لا يحمل معنى واحدًا. يمكن أن تظهر لدى الـ performer حالة FAILURE لأن PDU الخاصة بـ RESULT أو ERROR ضاعت، أو لأن النتيجة وصلت إلى الـ invoker بينما ضاع إقراره في الطريق المعاكس، أو بسبب فشل محلي أبلغ عنه مزود الخدمة. والنتيجة الدقيقة هي أن FAILURE لدى الـ performer لا يبرهن أن الـ invoker لم يتلق نتيجة ناجحة.

هنا تظهر اللا تماثلية المركزية: يستطيع الـ invoker أن يكون قد تلقى RESULT وسجل نجاحًا، بينما يصل الـ performer إلى FAILURE لغياب الإقرار. لا يوجد تناقض منطقي بين السجلين؛ كل سجل يصف ما أصبح معلومًا عند نقطة نهاية معينة.

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

النجاح البروتوكولي ليس إثباتًا لالتزام الأثر

حتى حين يبدو تبادل ESRO ناجحًا، تبقى طبقة أخرى منفصلة: هل نفذ التطبيق فعلًا التغيير الذي كانت العملية تطلبه، وهل أصبح ذلك التغيير هو حالة العمل المعتمدة؟

يمكن تقسيم الدليل إلى ثلاثة مستويات. الأول هو واقع النقل: ما أُرسل وما وصل وما أبلغ عنه مزود النقل. الثاني هو واقع بروتوكول العمليات البعيدة: Invoke وRESULT وERROR والإقرارات وحالات FAILURE كما تفهمها ESRO. أما الثالث فهو واقع التطبيق أو الأعمال: هل تحقق الأثر المقصود فعلًا، وهل بقي قائمًا، وهل يمثل الحالة التي ينبغي للنظام الخارجي الاعتماد عليها.

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

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

النمط الثنائي يقلل الرسائل ويقلل المعرفة أيضًا

في نمط non-acknowledged تستخدم ESRO تبادلًا ثنائيًا. هنا لا ينتظر الـ performer إقرارًا من الـ invoker على النتيجة. لذلك فإن تأكيد الـ performer لا يحتوي معلومة جديدة وردت من النظير؛ إنه يؤكد انتهاءً محليًا، لا معرفة بأن الطرف الآخر شاهد النتيجة.

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

وفي هذا النمط لا يعرف البروتوكول فشل الـ performer إلا من إشارة مزود الخدمة المحلي. أما فشل الـ invoker فقد يعني أن عودة متوقعة لم تصل أو أن مشكلة محلية حدثت لديه، لكنه لا يثبت بذاته ما إذا كانت العملية نُفذت عند الطرف الآخر أو ما إذا كان أثرها قد التزم.

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

نية هندسية موثقة بلا ادعاء انتشار

تقدم RFC 2524 مثالًا لاحقًا على استخدام ESRO في دليل لتكوين بريد فعال، وهو ما يدعم فهم النية الهندسية وراء البروتوكول: بناء خدمات تطبيقية فوق عمليات قصيرة منخفضة الكلفة. لكنه لا يكفي لإثبات انتشار ESRO على نطاق واسع، ولا ينبغي تحويل وجود دليل تطبيقي لاحق إلى حجة عن حجم التبني الفعلي.

أما RFC 1831 الخاصة بـ ONC RPC فتصلح مقارنة مجاورة في دراسة العمليات البعيدة، لا أساسًا للقول إن أحد البروتوكولين سلف مباشر للآخر أو أن أحدهما بديل حتمي له. المقارنة المفيدة هي مقارنة نماذج الإثبات ودلالات الفشل، لا إنشاء سلسلة نسب لا توفرها الحزمة المصدرية.