الخلاصة

  • اقترح James E. White في RFC 707 بروتوكولًا مشتركًا لاستدعاء الإجراءات وبيئة تشغيل تقلل تكرار الأوامر والردود في بروتوكولات تطبيقات ARPANET.
  • يذكر النص نموذجًا أوليًا لحاسوب PDP-10 يعمل بنظام TENEX، لكنه يوضح أن الاستدعاء البعيد يحتاج إلى رسائل اتصال بين العمليات، ويكلف أكثر من المحلي، ولا يلائم كل أنماط الاتصال.

أمر واحد وراءه حوار

قد تبدو إعادة تسمية ملف خطوة واحدة، إلا أن مواصفة FTP لعام 1973 طلبت إرسال RENAME FROM ثم RENAME TO. على العميل أن يدير سلسلة من الأوامر والردود قبل أن ينهي العملية التي يريدها. وكان لدى Remote Job Entry تدفقه الخاص من الأوامر والإجابات، بما في ذلك رسائل تقدم تُرسل بينما يواصل العمل تنفيذه. بذلك كانت كل تطبيقات الشبكة تعيد بناء نحوٍ خاص بها للتخاطب، إلى جانب منطق الخدمة نفسها.

تناول RFC 707، المعنون A High-Level Framework for Network-Based Resource Sharing، هذا التكرار باعتباره عبئًا معماريًا. كتب James E. White من مركز Augmentation Research Center في Stanford Research Institute (SRI) مقترحًا وضع الآليات المتكررة في بروتوكول عام، حتى يصف البرنامج عمليته ومعاملاتها بدلًا من صياغة حوار مختلف لكل خدمة.

ما الذي يفعله بروتوكول الاستدعاء؟

اقترح Procedure Call Protocol، أو PCP، رسالتي CALL وRETURN، ومعرّفات للمعاملات تربط الطلب بالنتيجة، ومعالجة للمعاملات والنتائج، مع السماح بوجود أكثر من طلب قيد التنفيذ. وكانت بيئة تشغيل في كل موقع ستجهز الاستدعاء، وتتبادل الرسائل مع الطرف البعيد، ثم تعيد النتيجة إلى البرنامج. وشمل التصميم استدعاءات متزامنة وغير متزامنة، وإمكانية أن يستدعي الخادم العميل من جديد.

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

ماذا يثبت نموذج TENEX؟

يقول RFC 707 إن أبحاث ARC بدأت في يوليو 1974 ومرت بثلاث جولات تصميم على مدى 12 شهرًا، ثم صُممت ووُثّقت ونُفذت بيئة تشغيل نموذجية لحاسوب PDP-10 يعمل بنظام TENEX. ويذكر النص أن تطبيق TENEX نفذ المواصفة وقدم نطاقًا من الإمكانات أوسع مما وصفته الوثيقة وملاحقها.

هذا تقرير ملموس عن نموذج على منصة محددة، وليس مجرد تصور نظري. لكنه لا يقدم تعدادًا للأجهزة التي شغّلته، ولا يثبت التشغيل البيني بين منصات مختلفة أو الانتشار في ARPANET كلها. يصنف RFC Editor الوثيقة اليوم ضمن Legacy وبحالة UNKNOWN؛ ويذكر IETF Datatracker أنها سبقت تسجيل المصادر رسميًا ولا تتمتع بمكانة رسمية في عملية معايير IETF الحالية. وهذه الأوصاف الإدارية الراهنة لا تكشف حجم الاستخدام التاريخي.

المسافة باقية بعد التجريد

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

ما يدعمه السجل إذن أضيق من قصة شائعة عن «اختراع RPC»: فقد رصد RFC 707 تكرار حوارات التطبيقات، واقترح نقل هذا التكرار إلى بيئة تشغيل مشتركة، وأبلغ عن نموذج TENEX أولي. لا تثبت المصادر المتاحة انتشارًا عامًا أو علاقة سببية بأنظمة RPC اللاحقة. أهمية الوثيقة أنها تعرض التجريد وتكلفته في الوقت نفسه.

المصادر