الخلاصة

  • نقلت RFC 1116 تحرير السطر وبعض معالجة الإشارات إلى العميل. خفّض ذلك عدد الحزم من حزم لكل محرف إلى حزم لكل سطر أو أمر، وأتاح استجابة محلية على المسارات البطيئة أو الشبكات التي تحاسب على الحزمة.
  • كانت موافقة DO/WILL وإشارتا MODE_ACK وSLC_ACK تغلق كل واحدة منها جولة مختلفة من ضبط الإعدادات. لم تكن أي منها إقرارًا بوصول الأمر إلى التطبيق أو السماح به أو تنفيذه أو إنتاجه نتيجة.
  • عند تفعيل EDIT ظل الإدخال في مخزن قابل للتعديل حتى يحرره فاصل سطر أو شرط توجيه. ما أُرسل لم يعد قابلًا للتصحيح محليًا، لكنه بقي أمام سلسلة من النقل والتحليل وقرارات العملية البعيدة.

السرعة الظاهرة نشأت قبل الشبكة

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

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

يحفظ سجل RFC Editor للوثيقة RFC 1116 اقتراح أغسطس 1989 وعلاقة الاستبدال، بينما يوثق سجل IETF Datatracker تاريخها المعياري. وفي أكتوبر 1990 حلّت RFC 1184 محلها، وأضافت أعلامًا للحالة ومحارف للتحرير المرئي، مع الإبقاء على مبدأ التحرير عند العميل. لذلك يتعلق الاستنتاج بتطور التصميم في هاتين الوثيقتين، لا بادعاء عن مدى استعماله اليوم.

السماح بالتفاوض لم يكن اختيارًا للحالة

حمل Linemode رقم خيار Telnet 34. تفصل القواعد العامة في RFC 855 بين مرحلتين: يتبادل الطرفان DO وWILL أولًا للسماح بالتفاوض على الخيار، ثم يناقشان معلماته ضمن subnegotiation. ويمكن لـ DONT أو WONT سحب ذلك السماح.

كانت البداية في RFC 1116 هي WONT LINEMODE وDONT LINEMODE. ولذلك لا يكشف اتصال TCP أو تحية Telnet أو وجود الرقم 34 في سجل أن التحرير المحلي نشط. وحتى اكتمال زوج DO/WILL لا يقول إلا إن الطرفين قبلا التفاوض على موضع التحرير ومعالجة الإشارات.

بعد ذلك جاءت MODE. في الحالة المعتادة يقترح الخادم قناعًا ويؤكده العميل. يحدد EDIT موضع معالجة السطر، فيما يحدد TRAPSIG موضع تفسير المحارف المرتبطة بالمقاطعة وbreak والإلغاء ونهاية الملف والتعليق. يعلن MODE_ACK اتفاق عمليتي Telnet على القناع. لكنه لا يشير إلى السطر التالي، ولا يعرف شيئًا عن التطبيق الموصول بالخادم.

لهذا لا تمثل عبارات مثل «قُبل Linemode» و«EDIT فعال» و«اكتمل الأمر البعيد» درجات تفصيل لفعل واحد. كل عبارة صادرة عن حالة مختلفة وسلطة إثبات مختلفة.

كان السطر المكتمل كائنًا محليًا

مع تفعيل EDIT كان العميل يحرر الإدخال ثم يرسل الأسطر المكتملة. شرحت RFC 1184 الحد المعتاد بوضوح: بعد التحرير المحلي يطلق CR LF أو محرف خاص آخر البيانات المحررة. وقبل تلك اللحظة يستطيع المستخدم تغيير المخزن من دون أن يطلب من المضيف البعيد التراجع عن شيء.

جعل FORWARDMASK الصورة أقل بساطة. يستطيع الخادم أن يطلب إطلاق الإدخال المخزن عند ظهور محارف ASCII محددة، ويضيف SLC_FORW1 وSLC_FORW2 محرفي توجيه آخرين. وإذا عجز برنامج تشغيل الطرفية عن تمثيل المجموعة المطلوبة بدقة، جاز للعميل قبول مجموعة أوسع من محارف التحكم والتوجيه عند أي منها.

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

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

الإقرار بخريطة المحارف لم يكن إقرارًا بأثرها

كانت suboption المسماة Set Local Characters، أو SLC، تتفاوض على ثلاثيات تضم الوظيفة والمعدِّلات ومحرف ASCII المسند إليها. ويبين مستوى الدعم إن كانت الوظيفة غير مدعومة، أو مدعومة بقيمة ثابتة، أو ذات قيمة صريحة، أو مضبوطة على الافتراضي. يعني SLC_ACK أن المستقبل وافق على الضبط.

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

أظهرت RFC 1184 نهاية سلطة البروتوكول. قد يؤدي ABORT وIP إلى الأثر نفسه في نظام لا يملك إلا وسيلة مقاطعة واحدة. وقد تُهمل وظائف ABORT أو EOF أو SUSP غير المدعومة. أما SLC_FLUSHIN وSLC_FLUSHOUT فكانا توجيهين استشاريين، ويمكن لواجهة المستخدم أن تتجاوز سلوك المسح المقترح. اسم الإشارة طلب ضمن سياق Telnet، لا سجل دائم يثبت توقف عملية أو اختفاء بيانات.

للصدى والتحكم في التدفق سلطتان منفصلتان

توضح RFC 857 لماذا لا يكفي ظهور محرف على الشاشة دليلًا على الطرف الآخر. ينسق خيار Echo ما إذا كان أحد الجانبين سيردد نيابة عن الآخر، لكنه لا يتحكم في ترديد النظام لنفسه. لذلك يستطيع Linemode إظهار استجابة محلية فورية بينما لم يصدر عن مسار الشبكة أي جواب بعد.

وبقي التحكم في التدفق منفصلًا رغم قربه من الموضوع. لم تضع RFC 1116 أو RFC 1184 العلم FLOW داخل قناع Linemode، بل استخدمتا خيار Telnet Remote Flow Control الوارد في RFC 1080. يتعلق ذلك الخيار بالسماح، بعد تفاوض مستقل، بتغيير استهلاك XON/XOFF محليًا في خرج الطرفية. وهو ليس تحرير لوحة المفاتيح ولا تعليق التطبيق ولا تحكم TCP في التدفق أو الازدحام.

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

الإقرار الناقص كان يجب أن يصدر عن التطبيق

ما زال سجل خيارات Telnet لدى IANA يربط الرقم 34 بـ Linemode ويحيل إلى RFC 1184. تفيد تلك الخانة برنامج التحليل في تسمية الرقم، لكنها لا تثبت أن جلسة حالية فاوضت عليه، أو أن تنفيذًا برمجيًا مطابق، أو أن أمرًا قد جرى.

تقدم RFC 854 أساس NVT وأوامر تحكم Telnet. يستطيع البروتوكول حمل البيانات والإشارات إلى عملية Telnet البعيدة. ويستطيع Linemode تقليل التكلفة وتوحيد حالة الضبط بين الطرفين. لكن لا أحد منهما يحول دليل النقل إلى دليل من التطبيق.

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

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

المصادر