الخلاصة

  • وثق RFC 1205 واجهة لنقل تدفق بيانات محطة IBM 5250 داخل Telnet. كان على العميل والخادم الاتفاق على Binary وEnd-of-Record وTerminal-Type، ثم معالجة سجلات ورثت شكلها من تطبيق سابق لدى IBM.
  • إذا أرسل الخادم Cancel Invite رد العميل بالمثل وامتنع عن إرسال بيانات المستخدم المعتادة حتى أمر قراءة جديد. ويعرض مثال System Request حفظ الشاشة، وعرض قائمة، وتلقي الجواب، واستعادة الشاشة، ثم العودة إلى الإدخال العادي.

لوحة مفاتيح حاضرة، ودور يوزعه الخادم

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

يروي مثال System Request ما يحدث عندما يضغط المستخدم مفتاح طلب النظام. يرفع العميل علماً في سجل يرسله إلى الخادم. يلغي المضيف دعوة الإدخال القائمة، ويأمر بحفظ صورة الشاشة، ويعرض قائمة النظام. يأتي جواب القائمة من خطوة Put/Get يفتحها المضيف، ثم يعيد الشاشة المحفوظة ويصدر Invite جديداً للعودة إلى العمل السابق. يرى المستخدم قائمة ثم يرى شاشته القديمة. وراء هذا المشهد عدة تغييرات محددة في حق إرسال البيانات.

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

ثلاثة تفاهمات قبل أن تتشكل الشاشة

لم تضف IBM خياراً جديداً إلى Telnet لهذه الواجهة. اشترط RFC أن يتفق العميل والخادم، على الأقل، على Binary وEnd-of-Record وTerminal-Type. في المثال يسأل الخادم عن نوع المحطة ويجيب العميل IBM-5251-11. ثم يجري التفاهم في كلا الاتجاهين على البيانات الثنائية وعلامات نهاية السجل. هذه موافقة على إطار التبادل، وليست قراراً بشأن هوية المستخدم أو موضع كل خانة على الشاشة.

كانت أنواع 5250 مختلفة بالفعل. تورد الوثيقة شاشات من 24 سطراً و80 عموداً، وأخرى من 27 سطراً و132 عموداً، وشاشات ملونة وأحادية اللون، وبعضها يدعم محارف من بايتين. لذلك احتاج الخادم إلى اسم النوع وإلى استعلام أدق عن خصائص الجهاز؛ يعرض RFC مثال Query Device وجواب العميل. عنوان الشبكة لا يحمل قياسات الشاشة ولا قدرات المحارف.

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

حمل Telnet ترويسة أقدم من Telnet نفسه

جاءت الترويسة من 5250 Display Station Pass-Through، المستخدم على SNA مع أجهزة AS/400 وSystem/36 وSystem/38. واحتفظ السجل بنوع General Data Stream. اختارت IBM أن تنقل نحو البيانات المعروف للمضيف عبر طريق شبكة آخر. بذلك يستطيع برنامج المضيف متابعة عمله المألوف، بينما يتحمل مطور العميل عبء فهم البنية الموروثة.

يحيل RFC القارئ إلى IBM 5250 Functions Reference Manual من أجل المجموعة الكاملة لأوامر المحطة وتدفق الشاشة. وفي قسمه الخامس يصحح أخطاء في نسخة الدليل المتاحة آنذاك ويضيف وظائف لم تكن موثقة فيها. يصحح مثلاً القيمة الست عشرية لتعليمة Insert Cursor، ويوضح حدود مواقع الصفوف والأعمدة. قد تنجح الخيارات الثلاثة في Telnet كلها، ثم يفسد عرض الشاشة أو إدخال البيانات بسبب قيمة أمر واحدة خاطئة. التوافقية هنا مسألة تفسير دقيق، لا مجرد اتصال ناجح.

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

إلغاء مؤقت مع طريق واضح للعودة

في المثال القصير يرسل الخادم رمز العملية 0A ويعيده العميل تأكيداً، ثم ينتظر الإدخال المعتاد أمر القراءة التالي. المثال الطويل يضيف قراءة خاصة بجواب القائمة من Put/Get، ثم استعادة الشاشة وInvite أخيراً للرجوع إلى الوضع السابق. لهذا السبب لا يصح وصف التوقف بأنه منع مطلق لأي جواب؛ إذ يفتح المضيف بنفسه مساراً محدداً للرد على القائمة. المهم هو من يفتح ذلك المسار ومتى.

يسجل RFC الواجهة وأمثلة التبادل، ولا يقدم تتبعاً مؤرخاً لجلسة تشغيل أو عدد المحطات التي استُخدمت بهذه الطريقة. يكشف سجل تبادل من مضيف وعميل مع صور الشاشة ما وقع في موقع بعينه. أما تصميم عام 1991 فمكتوب بوضوح: Telnet يحمل السجلات، والمضيف يرتب أدوار الإدخال.

المصدر