الخلاصة

  • عرّف RFC 3018 فضاء عناوين موزعاً من 128 بت وتعليمات للقراءة والكتابة والحجز والتحرير وعمليات الكائنات ونقل التحكم بين آلات افتراضية على عقد مختلفة.
  • اشترطت المعاملة تنفيذ كل التعليمات معاً أو عدم تنفيذ أي منها، لكنها لم توفر الإلغاء بعد التنفيذ، وذكرت أن نقل التحكم قد يكون من الآثار التي يستحيل إبطالها.

قبل التنفيذ كانت المعاملة شيئاً يمكن الإمساك به: سلسلة مكتملة محفوظة عند الطرف المستقبل. كان ممكناً إرسال EXEC_TR فتبدأ، أو CANCEL_TR فتحذف قبل أن تعمل.

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

يرسم RFC 3018 هذا الحد بوضوح. لا ينص على إلغاء المعاملة بعد التنفيذ. وإذا لزم التعويض فعلى طبقة الآلة الافتراضية أن توفره، لأن المعاملة قد تحتوي تعليمة لا يمكن إلغاؤها، مثل نقل التحكم.

نُشر Unified Memory Space Protocol Specification في ديسمبر 2000 بصفة Experimental. لم يكن هدفه مجرد إرسال طلب إلى خدمة بعيدة. أراد أن يرى التطبيق فضاء ذاكرة واحداً بعناوين من 128 بت موزعاً بين عقد الإنترنت. تترجم VM التعليمات الموجهة إلى عقدة أخرى إلى أوامر UMSP: قراءة، كتابة، مقارنة، حجز، تحرير، نقل شيفرة، استدعاء إجراء كائن أو قفز إلى عنوان بعيد.

اختفت الشبكة من واجهة المبرمج، لكنها لم تختف من سجل الفشل.

العنوان الموحد لم يوحد الحيازة

قسّم النموذج الحساب إلى job وtask وthread of control. يمثل job التطبيق الموزع، وتمثله task واحدة في كل عقدة، ويمكن أن تضم task عدة خيوط. يتولى Job Control Point، أو JCP، متابعة بدء المهام ونهايتها وتوزيع المعرفات.

لم يمنح ذلك المركز سلطة على كل شيء. بقيت الذاكرة المحلية ومسؤولية المؤشرات وترتيب التنفيذ والموارد عند VM. يقول النص إن البروتوكول لا يتحكم في ذاكرة job ولا يتتبع خيوط المستخدم. وعندما تنتهي task يجب على VM إبطال المؤشرات التي تشير إليها.

جمع العنوان المؤلف من 16 octet معلومات الشبكة والعقدة والذاكرة المحلية. وحّد الاسم، لا الساعة ولا دفتر الأحداث ولا صاحب قرار الاستعادة. يؤدي نقل التحكم إلى عنوان بعيد إلى إنشاء thread جديد هناك، بينما لا يمكن توزيع مقطع شيفرة متصل بين عدة عقد.

لهذا كانت التعليمات القوية بحاجة إلى إثبات مستقل. شملت القائمة WRITE وMEM_ALLOC وFREE ونقل الشيفرة وتشغيلها وJUMP وCALL وإنشاء الكائنات وحذفها وتشغيل إجراءاتها. الخطأ لم يكن مجرد رسالة تالفة؛ كان قادراً على تغيير مورد أو مسار تنفيذ بعيد.

مرّت المعاملة بحالات أكثر من كلمة commit

ميّز UMSP بين sequence وtransaction. تفرض sequence اعتماداً ترتيبياً؛ إذا تعذر تنفيذ خطوة ألغيت الخطوات التالية. أما transaction فبإمكانها جمع تعليمات غير مترابطة، على أن تنفذ كلها معاً أو لا تنفذ أي منها.

كان طول المعاملة معروفاً مسبقاً كي يحدد طريقة buffering. تبدأ بـ_BEGIN_TR وتنتهي بـ_END_CHAIN. بعد اكتمال الاستلام فقط توجد سلسلة جاهزة عند المستقبل.

إذا كان TRR=1 بدأ التنفيذ عند وصول النهاية. وإذا كان TRR=0 بقيت السلسلة في الانتظار حتى تصل EXEC_TR. وقبل البدء تستطيع CANCEL_TR حذف التعليمات المحفوظة من دون استعادة.

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

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

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

الذرية حكمت البداية لا إمكانية الرجوع

قد توحي كلمة transaction بدلالات قواعد البيانات كلها. لكن RFC 3018 قدم وعداً أضيق: تدخل مجموعة التعليمات التنفيذ معاً أو لا تدخل.

لا توجد بالضرورة تعليمة عكسية بعد ذلك. قد يقرأ thread آخر كتابة بعيدة فوراً. قد تبطل FREE مؤشراً محفوظاً في مكان آخر. قد تنشئ الشيفرة المنقولة أفعالاً جديدة. وقد يغير إجراء كائن نظاماً خارج نطاق job. أما JUMP وCALL فقد ينشئان تدفقاً يستمر بعد زوال السلسلة الأصلية.

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

الإلغاء قرار يخص ما لم يبدأ. التعويض فعل يخص عالماً تغير، ويحتاج معرفة خاصة بالتطبيق. لا يستطيع البروتوكول توليد التعويض الصحيح لكل opcode.

وبالتالي تثبت EXEC_TR إرسال قرار تنفيذ سلسلة معينة. لا تثبت وحدها اكتمال كل فعل VM، ولا وقوع الأثر الخارجي مرة واحدة، ولا بلوغ الغاية العملية للـjob.

أقر TCP البايتات لا تنفيذ الآلة الافتراضية

اشترط UMSP إتاحة TCP للتبادل الموثوق، وسمح بـUDP للبيانات التي لا تحتاج acknowledgement. يقدم RFC 793 تدفق octet مرتباً وموثوقاً ويعالج الفقد والتكرار والتلف وإعادة الترتيب. يقدم RFC 768 عقد datagram أرق.

هذه ضمانات حقيقية في طبقتها. لكن ACK من TCP لا يقول إن UMSP تحقق من التعليمة، أو ألحقها بالسلسلة الصحيحة، أو أطلقها صاحب السلطة المقصود، أو نفذتها VM على نسخة الذاكرة المتوقعة.

يعرض RFC 1831 حدوداً مشابهة في ONC RPC. عند وصول reply فوق TCP يمكن استنتاج التنفيذ وفق نموذجه. أما غياب reply فلا يثبت عدم التنفيذ، فقد ينفذ server ثم تنقطع الوصلة. ويحذر النص من أن النداء البعيد يختلف عن المحلي في الفشل والآثار الجانبية والأداء والمصادقة.

جعل UMSP الفعل البعيد أقرب إلى تعليمة processor. سهولة الواجهة لم تجعل الدليل محلياً.

كان JCP مركز تنسيق لا شاهداً على كل شيء

وزع JCP معرف job العالمي وتابع بدء tasks ونهايتها، واقترح النص استخدامه للتعريف المركزي بالمستخدم والحماية من الهجمات.

مع ذلك بقيت الذاكرة والمؤشرات لدى VM. أمكن لـthread بعيد إحداث أثر لا يراه JCP مباشرة. قد يفشل الاتصال بعد التنفيذ وقبل الرد. وبعد node reload كان لا بد من تمييز segments التابعة إلى sessions قديمة.

نهاية task حقيقة عن دورة الحياة. استمرار الكتابة حقيقة عن الذاكرة. حدوث فعل خارجي مرة واحدة حقيقة عن التطبيق. وحتى JOB_COMPLETED لا يدمج هذه الحقائق تلقائياً.

تركت السلامة خارج النواة الأولى صراحة

تقول Security Considerations إن مسائل السلامة لم تدخل في الوظائف الدنيا لتقليل التعقيد الأولي، وإن ما يلي توصيات لتطوير البروتوكول.

يقترح النص حماية من TCP/IP، وchains ذات special processing لضبط integrity أو encryption، ومعاملات authentication في extension headers. كما يتصور مصادقة بين العقدتين وJCP. ولمقاومة man-in-the-middle يعتمد على مسارات غير متقاطعة، ويقر بأن gateway مشتركة تضعف الحماية.

ويعد JUMP وCALL مصدراً محتملاً لـdenial-of-service، ويترك قرار الموارد للـVM. تنزيل active code إلى client يزيد خطره، وتشغيل code العميل على server يفرض حماية أقوى على الخادم.

هذه خريطة للمخاطر، وليست بناء أمنياً كاملاً. لا تحدد الخوارزميات والمفاتيح والتفويض ومنع replay والإبطال والتدقيق.

قدم RFC 3552 لاحقاً نموذجاً يفترض قدرة المهاجم على قراءة المرور وحذفه وتغييره وحقنه. لا ينبغي جعله التزاماً بأثر رجعي على وثيقة 2000. لكنه يوضح لماذا لا تكفي مسارات منفصلة أو headers مستقبلية كإيصال أمن مكتمل.

Experimental سجل اقتراحاً ولم يثبت تشغيله

يضع RFC 2026 صفة Experimental خارج standards track ويقول إن وثائقها ليست Internet Standards. قد تحفظ عملاً بحثياً أو تطويرياً. قدم RFC 2119 الكلمات المعيارية وRFC 2234 صيغة ABNF.

تثبت المصادر تصميم UMSP وحدوده. لا تثبت منتجاً أو deployment أو interoperability أو حادثة أو adoption. لا يجوز تحويل دقة المواصفة إلى تاريخ تشغيل لم توثقه المصادر.

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

تصلح أفكار Lu Heng هنا كعدسات معلنة. تفصل Running-Code Primacy بين التعليمة المنشورة وما يفعله النظام الجاري. تمنع Reality Layers الرسالة وbuffer والقرار والتنفيذ والنتيجة من استعارة أدلة بعضها. وتفسر Minimum Initial Specification قيمة النواة الصغيرة مع إبقاء عقود الأمن والتعويض والرصد الغائبة واضحة.

ليست هذه ادعاءات عن نية مؤلف RFC.

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

Sources