الخلاصة

  • سمح NETRJS لمضيف بعيد بمحاكاة طرفية دفعية افتراضية لإرسال المهام إلى IBM 360/91 لدى UCLA-CCN واستعادة النتائج.
  • استخدمت وحدة التحكم ومدخلات البطاقات ومخرجات الطباعة قنوات منفصلة، وتوثق RFCs مشكلات حقيقية في التحويل والتسليم.

كان الناتج يعود بعد انقطاع المستخدم

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

أوصلت الطرفية الافتراضية العمل الدفعي بالشبكة

يصف RFC 740 لعام 1977 NETRJS بأنه بروتوكول خاص أنشأته UCLA-CCN لإرسال المهام الدفعية إلى IBM 360 Model 91. وكانت خدمة RJS نفسها تخدم أيضاً طرفيات بطاقات حقيقية عبر خطوط اتصال مباشرة. كان هذا نظام حوسبة محدداً متاحاً عبر أكثر من مسار، لا دليلاً على أن كل مهمة في ARPANET عولجت لدى UCLA.

لم تكتمل المهمة قبل وصول ناتجها

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

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

بدأ NETRJS قبل وثيقة 1977. وصفه RFC 88 في 1971، وحدّثه RFC 599 في 1973، ثم استبدل RFC 740 كلاً من RFC 189 وRFC 599. تحفظ وثيقة 1973 لقطة تشغيل نادرة: خلال أكتوبر عالجت UCLA-CCN عبر NETRJS 1,373 مهمة؛ طُبع 1,105 منها ولم تُثقب أي مهمة. وسجّلت قراءة 49,400 بطاقة وطباعة 822,900 سطر و18,907 صفحة على مدى 393.6 ساعة اتصال. هذه أرقام خدمة واحدة في شهر واحد، وليست إحصاءات ARPANET كلها. واعتبرت الوثيقة المهمة المتوسطة، ذات 360 سطراً من الإدخال («بطاقات») و745 سطراً من المخرجات في 17.1 صفحة، نموذجاً معتاداً إلى حد معقول.

لكن هذه الأعداد لم تضمن وصول النتيجة. يشرح RFC 599 خللاً سُمّي «squish»: بسبب تخزين NCP المؤقت، كان حاسوب الدفعات قد يحذف ملف طباعة قصيراً قبل وصول أول رسالة إلى المضيف البعيد. وإذا تعطل المضيف البعيد أو ألغى المستخدم الجلسة فقد تضيع النسخة الوحيدة. جعل الإصلاح NETRJS ينتظر تأكيد RFNM لنهاية البيانات قبل أن يطلب من RJS حذف المخرجات. لذلك كان إتمام المهمة يعبر حدين: إنجاز الحساب وتسليم النتيجة.

وكانت مجموعة المحارف حداً آخر. عالج IBM 360 في UCLA بيانات EBCDIC، فيما استخدمت بعض المضيفات البعيدة ASCII. في 1972 أبلغ مستخدمون من RAND وUtah وIllinois عن أوجه قصور في التحويل الأصلي؛ فعدّلت UCLA الخريطة وأضافت خياراً آخر. وأتاح RFC 740 للطرفية الافتراضية اختيار EBCDIC أو ASCII-68 أو ASCII-63 مع تحويل إدخال البطاقات ومخرجات الطباعة حين يلزم.

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

المصادر الأولية