الخلاصة

  • تبدأ كل رسالة CALL في ONC RPC بمعرّف XID من 32 بت، ويُنسخ إلى REPLY. يستطيع الطالب وصل الرد بانتظاره الصحيح، ويستطيع الخادم مقارنة المساواة لاشتباه إعادة الإرسال، لكن الحقل ليس رقماً تسلسلياً ولا دليلاً على تنفيذ وحيد.
  • كشف NFS الذاكرة الناقصة. خفّض مخزون الطلبات المكررة المتطاير في NFSv3 ضرر الإعادة ضمن نافذة محدودة؛ ثم جعل NFSv4.1 الطلبات المعلقة محدودة بجلسات وخانات وsequence ID لكل خانة وردود محفوظة.

الصمت الواحد كان يوافق تاريخين مختلفين

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

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

فصلت RFC 1050 في أبريل 1988 تنسيق رسائل RPC عن ضمان الموثوقية. واحتفظت RFC 1057، التي حلت محلها بعد شهرين، بالحد الصريح: فوق UDP لا يسمح غياب الرد بعد إعادة النداء بمعرفة عدد مرات التنفيذ؛ أما وصول رد فيثبت تنفيذاً واحداً على الأقل.

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

أجاب XID عن سؤال المطابقة الأصغر

تبدأ كل رسالة RPC version 2 بعدد غير موقّع من 32 بت. يحمل REPLY قيمة XID الموجودة في CALL الذي أنشأه. فإذا كانت طلبات عدة معلقة، أعاد العميل كل نتيجة إلى النداء المحلي الصحيح.

تقيّد RFC 5531 سلطة جهة الخدمة: يجوز لها اختبار تساوي XID للكشف عن retransmission محتملة، ولا يجوز لها تفسير الحقل كرقم تسلسلي. لا تعني القيمة الأكبر زمناً أحدث، ولا يدل التقارب العددي على ترتيب التنفيذ.

كما لا تفرض المواصفة الأساسية حفظ التاريخ. قد يختار العميل إعادة استخدام XID السابق عند إعادة الإرسال. وقد يختار الخادم حفظه بعد التنفيذ وعدم تنفيذ نداء آخر بالقيمة نفسها. ينشأ قدر من execute-at-most-once حين يجتمع الاختياران وتبقى الذاكرة متاحة؛ لا ينشأ من البتات وحدها.

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

لم تكن الوصلة الموثوقة أرشيفاً للأثر

حافظت RFC 1831 على هذا البناء، ثم صاغته RFC 5531 على مسار المعايير. تقول الوثيقتان إن وصول رد عبر نقل موثوق يتيح، في نموذج ذلك التبادل، استنتاج تنفيذ مرة واحدة بالضبط. لكن غياب الرد لا يسمح بالقول إن الإجراء لم يُنفّذ، وتظل المهلة وإعادة الاتصال ضروريتين عند انهيار الخادم.

يحفظ TCP ترتيب البايتات داخل اتصال بعينه. لا يحفظ تلقائياً دفتر قرارات عملية التطبيق إذا انهارت بعد تغيير الحالة. والاتصال الجديد لا يعرف إن كانت العملية القديمة قد بلغت نقطة الالتزام قبل الانقطاع.

ليس XID مصادقة أيضاً. يضع RPC credentials وverifiers في حقول منفصلة. تطابق الرقم يربط رسالتين وفق حالة محلية؛ لا يوقّع الوسائط، ولا يثبت هوية صاحب النداء، ولا يشهد بأن النتيجة صارت دائمة.

جعل اختيار NFS عديم الحالة كلفة الإعادة مرئية

أراد NFS المبكر خوادم عديمة حالة البروتوكول قدر الإمكان. شرحت RFC 1094 المنفعة: بعد عطل الخادم أو الشبكة يستطيع العميل تكرار الطلب حتى تعود الخدمة من دون إعادة بناء جلسة معقدة.

ولكي ينجح ذلك، صُممت العمليات لتكون idempotent ما أمكن. قد يؤدي تكرار القراءة أو كتابة البيانات نفسها في المدى نفسه إلى أثر مكافئ. لكن REMOVE وRENAME وLINK وMKDIR وغيرها وُصفت بأنها قد لا تكون idempotent؛ فنجاح النسخة الأولى يغيّر الشروط التي تستقبل النسخة الثانية.

عرضت RFC 1813 الخطر في NFSv3 بوضوح أكبر. قد تكون إعادة إجراء غير idempotent مدمرة، مثل truncate ثانٍ يمحو كتابات جاءت بعد الأول. وحتى النقل القائم على اتصال لا يلغي الأمر: كسر الاتصال ثم إقامته من جديد قد يدفع العميل إلى إعادة طلب لا يعرف نتيجة نسخته الأولى.

لم تكن الملفات عديمة الحالة. كان المقصود تخفيف حالة المحادثة. لذلك انتقلت المسؤولية إلى خصائص كل عملية وإلى ذاكرة مساعدة عند المنفّذ.

اشترى مخزون التكرار نافذة زمنية فقط

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

كان هذا جزءاً من الصحة لا مجرد تسريع. بقي الحكم عند الجهة التي نفّذت العملية الأولى. إلا أن RFC 1813 سجّلت الحد: غالباً ما عاش المخزون في RAM فضاع مع الانهيار. وحجمه محدود، فتستطيع partition طويلة أن تتسبب في إخراج المدخل قبل أن يصل الرد إلى العميل. تبدو إعادة الإرسال التالية طلباً جديداً.

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

قدّم EXCLUSIVE CREATE في NFSv3 مثالاً مضاداً. استخدم verifier مرتبطاً بالكائن المنشأ لأن المخزون المتطاير العادي لم يكف للمعنى المطلوب. وُضعت الذاكرة الأقوى قرب الحالة التي تحميها، لا في سلطة عامة لكل XID.

جعلت الخانات دين الذاكرة محدوداً

لم يحاول NFSv4.1 حفظ تاريخ كل XID. أدخلت RFC 5661 الجلسات، وتحدد المواصفة الحالية RFC 8881 جدولاً محدوداً من slots. يحمل كل slot sequence ID والرد المحفوظ للطلب الجاري.

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

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

تقارن RFC 8881 ذلك بـ XID المعتم. يمكن تنفيذ نداءات RPC بأي ترتيب، ولا يضع الحقل حداً طبيعياً لما هو معلق. حفظ رد لكل احتمال في فضاء 32 بت غير عملي. حوّل جدول الخانات تاريخاً مفتوحاً إلى التزامات حالية محددة ومتفق عليها.

ظل exactly once مربوطاً بحد الاستعادة

إذا اختفى جدول الخانات ومخزون الردود عند restart، فلا يستطيع الخادم الشهادة بما نسيه. لذلك تتطلب EOS كاملة عبر الانهيار والتعافي حفظ حالة الاستعادة والردود ذات الصلة في تخزين مستمر. يحسن التنفيذ المتطاير retries العادية، لكنه لا يمد ادعاءه إلى تاريخ فُقد.

ولم يلغ NFSv4.1 حقل XID. ما زالت طبقة RPC تستخدمه لمطابقة CALL مع REPLY، بما في ذلك عمليات خارج مسار SEQUENCE المعتاد. أضاف session ID وslot ID وsequence ID سياقاً أقوى للتنفيذ من دون إنشاء رقم مركزي يحكم كل الوظائف.

كانت المراحل إذن مختلفة: XID يربط الرسالة. المخزون يحتفظ بعاقبة مؤقتة. slot يضع سقفاً للعمل والذاكرة. والاستمرار يحدد أي عطل تستطيع عبارة «مرة واحدة» عبوره.

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

لا يثبت XID متساوٍ أن الوسائط أو principal أو instance الخادم أو boot epoch متساوية. cache miss لا يثبت أن الطلب جديد، وcache hit لا يثبت أن الأثر صار على تخزين مستقر. وحتى idempotence لا تحل ترتيب التنفيذ: تعرض RFC 8881 حالة WRITE قديمة متأخرة تنفّذ بعد WRITE أحدث فتغطيها.

الاستنتاج الصحيح أضيق. يوفّر الرقم نقطة مقارنة. أما التنفيذ مرة واحدة فينشأ حين يحفظ المنفّذ الصلة بين الرقم والعمل والنتيجة والنطاق وحقبة الاستعادة طوال مدة شك العميل.

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

تسجل RFCs 1050 و1057 و1831 و5531 تطور RPC. وتشرح RFC 1094 خيار NFS عديم الحالة، فيما توثق RFC 1813 مخزون التكرار وحدوده. ظهرت جلسات NFSv4.1 في RFC 5661، وترد صيغتها الحالية في RFC 8881. تثبت هذه الوثائق القواعد ونماذج الفشل الموثقة، لا أحجام المخابئ الحالية أو سياسات استمرارها أو انتشارها أو التزام كل منتج.