الخلاصة

  • مكّنت RFC 1073 العميل من إرسال العرض والارتفاع بوحدات المحارف معاً، ثم إرسال قيم أحدث كلما تغيّرت نافذته المحلية. وكان بوسع الخادم قبول NAWS ثم عدم استخدام البيانات، أو وقف التحديثات اللاحقة.
  • يثبت DO وWILL الإذن باستعمال الخيار، وتثبت رسالة NAWS أن العميل صرّح بهندسة معينة. أما حالة الطرفية في الخادم وإشارة العملية التابعة وإعادة تنسيق التطبيق وما رآه الإنسان فحقائق مستقلة.

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

أعطت RFC 1073 الخيار 31 اسم NAWS، أي التفاوض حول حجم النافذة. غير أن جوهرها لم يكن تفاوض طرفين على من يختار المقاس. العميل يملك السيطرة الكاملة على نافذته ويخبر الخادم بحالتها الحالية؛ والخادم يقرر إن كان يريد الخبر وكيف يتصرف بناء عليه.

الإذن يفتح الصيغة ولا يثبت استعمال القياس

يرسل الخادم DO NAWS ليطلب استعمال الخيار، ويجيب العميل الراغب بـWILL NAWS. ويحافظ DON'T وWON'T على الرفض. فصلت RFC 855 بين هذه البوابة الأولية وبين التفاوض الفرعي الذي يحمل بيانات الخيار التفصيلية.

لذلك لا يعني ظهور DO/WILL أن العرض والارتفاع أُرسلا لاحقاً. ووصول NAWS لا يعني أن الخادم خزّن القيم. والتخزين لا يثبت أن برنامج تشغيل الطرفية تغيّر أو أن عملية تابعة تلقت إشارة أو أن التطبيق أعاد بناء مخرجاته. الإذن وبيان الحالة والنتيجة ليست اسماً واحداً.

يحمل التفاوض الفرعي بايتين للعرض وبايتين للارتفاع بترتيب الإنترنت، والوحدة هي المحارف لا البكسلات. يصل كل محور إلى 65,535. ولأن Telnet يحجز القيمة 255 للمحرف IAC، يجب مضاعفة أي 255 يظهر داخل البايتات الأربعة. لا تصبح الأرقام منطقية إلا بعد تحديد حدود الرسالة وفك هذا الهروب على الوجه الصحيح.

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

القياس الثاني جيل جديد لا إقرار بالأول

يعرض المثال في RFC نافذة 80×24 ثم 80×64 بعد أن يغيّر المستخدم حجمها. لا يعاد تبادل DO/WILL. ما دام الخيار مفعلاً، يرسل العميل تقريراً جديداً حين تتغير حالته المحلية.

لا يقول التقرير الثاني إن الأول طُبّق. ولا يحدد NAWS جواب نجاح من التطبيق البعيد. قد يعرف مدير النوافذ الحجم الجديد بينما لم يرسله العميل بعد؛ وقد يستلمه الخادم بينما تبقى حالة الطرفية قديمة؛ وقد تتغير الحالة بينما لم تعالج العملية التابعة الإشارة. عبارة «حجم النافذة الحالي» ناقصة ما لم تحدد صاحب القيمة وزمنها.

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

هذا توزيع للسلطة، لا تناقض: العميل يملك حقيقة النافذة، والخادم يملك قرار الاستماع والاستعمال.

الخيارات الأقدم منحت الخادم سلطة غير واقعية

تعامل NAOL وNAOP سابقاً مع عرض السطر وحجم الصفحة كلٌّ على حدة. رأت RFC 1073 أن دلالتهما لا تلائم النافذة الرسومية: كانتا ثنائيتَي الاتجاه، بما يوحي أن الخادم قد يتحكم بعرض أو ارتفاع العميل، وتقف كل قيمة عند 253، ولم تكونا شائعتين وفق السجل المعاصر.

يرسل NAWS المحورين معاً لأن النافذة تتغير كمستطيل. والأهم أنه يستبدل فكرة «التفاوض على الحجم» بفكرة «إبلاغ الحجم الحالي». يستطيع الخادم طلب التقارير، لكنه لا يغيّر النافذة المحلية من خلال هذا الخيار.

القيم شبكة محارف وليست أبعاد الشاشة الفيزيائية. المثال 300×24 لا يثبت شاشة عريضة ولا دقة معينة. تحويله إلى بكسلات يحتاج إلى خطّ وتحجيم وآلية عرض لا تحملها الرسالة.

النوع والسرعة والهندسة ثلاث حقائق مختلفة

تصف RFC 930 خيار نوع الطرفية: يطلب الخادم ويجيب العميل، ولا يفرض وصول الاسم تغييراً فورياً في المعالجة. ثم أتاحت RFC 1091 المرور بين أنماط محاكاة متعددة مع بقاء الخادم صاحب الطلب. النوع سياق قدرة واختيار، لا قياساً للحجم الراهن.

أما RFC 1079 فخصصت الخيار 32 للسرعة. بعد الإذن، يطلب طرف سلسلة ASCII لمعدلي الإرسال والاستقبال، ولا يرسلها الطرف الآخر تلقائياً. وقد تُقرَّب قيمة غير مدعومة في اتجاه آمن. في NAWS يستطيع العميل، بعد الإذن، إرسال كل تغيير من تلقاء نفسه في محورين ثنائيين.

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

يسجل سجل IANA لخيارات Telnet الرقم 31 لـNAWS والرقم 32 لـTERMINAL-SPEED. يثبت السجل التخصيص ومرجع الوثيقة، لا التنفيذ الحالي ولا مطابقة منتج ولا استعمال جلسة بعينها.

أربعة بايتات تعبر سلطات محلية متعددة

تقترح RFC سلسلة تنفيذ واضحة. يبلغ نظام النوافذ عميل Telnet بالتغيير. وفي 4.3BSD قد يلتقط العميل SIGWINCH. يرسل NAWS. وقد يستخدم الخادم ioctl لتحديث حالة الطرفية، ثم قد يرسل إشارة إلى العملية التابعة، وهي غالباً shell.

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

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

المصادر والحدود

توثق RFC 1073 اقتراحاً من 1988 واستعمالاً معاصراً في Carnegie-Mellon، ولا تقيس الانتشار العام. تضع RFC 854 وRFC 855 إطار Telnet، وتشرح RFC 930 وRFC 1079 وRFC 1091 صفات مجاورة من دون إثبات تطبيق NAWS. ولا يحوّل سجل IANA التسجيل إلى دليل حركة أو امتثال.

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