الخلاصة

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

الحرف نفسه يمكن أن يختفي محلياً

يستطيع لوح مفاتيح الطرفية الافتراضية في RFC 854 توليد رموز US-ASCII الثمانية والعشرين بعد المئة كلها. لذلك قد يحتاج تطبيق بعيد إلى Control-S أو Control-Q كمدخلين حقيقيين.

لكن التحكم البرمجي في التدفق يستخدم القيمتين نفسيهما عادة. يوقف XOFF، وهو غالباً Control-S، الخرج؛ ويعيد XON، وهو Control-Q، تشغيله. يلتهم مشغّل الطرفية الحرف محلياً، فلا يصل إلى البرنامج البعيد.

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

نشرت RFC 1080 في نوفمبر 1988 وأسندت الرقم 33 إلى TOGGLE-FLOW-CONTROL. لم تمنح المضيف ملكية الطرفية؛ بل أنشأت منفذاً ضيقاً لطلب حالة محلية.

الموافقة تسبق أمر الحالة

تفصل RFC 855 الخيار المركب إلى مرحلتين. يتفق الطرفان أولاً على استعماله عبر DO وWILL، ثم تبدأ المفاوضة الفرعية.

في الاستخدام المعتاد يرسل المضيف DO، وترد عملية Telnet لدى المستخدم المتصلة بالطرفية بـWILL. يعلن الأول استعداده لإرسال طلبات التشغيل والإيقاف، وتقبل الثانية تنفيذها.

يرفض DONT وWONT هذين الدورين، ولا يبلغان عن حالة التدفق الحالية. يستطيع العميل رفض التحكم البعيد مع إبقاء XON/XOFF مفعّلين وفق سياسته الخاصة.

لا يجوز إرسال ON أو OFF قبل اكتمال الاتفاق، ولا بعد سحبه. وصول الأمر لا يصنع لنفسه السلطة التي تجعله صالحاً.

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

الاتفاق صنع نقطة بدء معلومة

بعد DO/WILL يستطيع مرسل DO طلب OFF أو ON. المطلوب هو تغيير كيفية تعامل عملية Telnet المحلية مع الخرج إلى الطرفية، لا نافذة استقبال TCP ولا برنامج الخادم.

أوجبت RFC 1080 على مرسل WILL تشغيل التحكم في التدفق فور اكتمال الاتفاق. وهكذا لا يبدأ الخيار في حالة مجهولة؛ فالتفاوض نفسه يحدد أول وضع.

لكن المواصفة لا تعرّف إقراراً لكل تغيير لاحق. تثبت رزمة OFF أن طلباً مخولاً أرسل، ولا تثبت أن المشغّل طبقه أو أن الشاشة توقفت أو أن الحرف وصل إلى التطبيق.

تُهمل رموز المفاوضة الفرعية غير المعروفة. تحمي القاعدة قابلية التوسع، لكنها تمنع اعتبار الصمت دليلاً على الدعم.

سحب الخيار يعيد القرار إلى التنفيذ المحلي

يمكن لأي طرف إرسال DONT أو WONT. عندها تتوقف المفاوضات الفرعية حتى اتفاق جديد.

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

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

التحكم في الشاشة ليس تحكماً في TCP

يغطي RFC 1080 اتجاه الخرج من عملية Telnet لدى المستخدم إلى الطرفية فقط. يمكن للاتجاه المعاكس أن يتبع سياسة أخرى. وقد يستخدم التحكم العتادي إشارات مخصصة فلا يصادر أي حرف.

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

يجب أن يسمي كل ادعاء اتجاهه ونقطة رصده: الضغط على Control-S، واستهلاك XOFF في المشغّل، ورؤية OFF على السلك، وتوقف الشاشة، أربع وقائع مختلفة.

وضع السطر أبقى التحكم في آلة منفصلة

أتاحت RFC 1184 للعميل تحرير السطر ومعالجة الإشارات قرب المستخدم ثم إرسال السطر المكتمل. أفاد ذلك في الشبكات مرتفعة التأخير.

مع أن التدفق قريب من هذه الوظائف، أبقته RFC 1184 في TOGGLE-FLOW-CONTROL المستقل. لا ينبغي لخريطة أوضاع جديدة أن تعيد تعريف آلة حالة موجودة بصمت.

ويكشف هذا الفصل سلسلة الأدلة: لوحة المفاتيح تولد الحرف، والمشغّل قد يستهلكه، وعميل Telnet قد يحوله، والتطبيق قد يتلقاه. لا ترى أي نقطة مراقبة السلسلة كلها.

أضافت RFC 1372 طلباً لا يملك قناة تأكيد

حلّت RFC 1372 محل RFC 1080 سنة 1992 وأضافت RESTART-XON وRESTART-ANY. يطلب الأول أن يستأنف XON وحده الخرج، ويطلب الثاني أن يستأنفه أي حرف سوى XOFF آخر.

تبقى حالة تشغيل التدفق معلومة بعد الاتفاق، أما قاعدة الاستئناف فتبدأ بحالة تعتمد على النظام. على الخادم طلب القاعدة التي يريدها.

قد يتجاهل عميل لا يستطيع دعم القاعدتين الطلب، ولا توجد رسالة تخبر الخادم بذلك. تسجل الشبكة النية، بينما تبقى القدرة المحلية غير مؤكدة.

تستهلك المشغّلات الشائعة XON وXOFF. وفي وضع الاستئناف بأي حرف قد يعيد الحرف العادي الخرج ثم يتابع طريقه إلى التطبيق. الاستئناف وتسليم المدخل ليسا حدثاً واحداً.

المنفذ التسلسلي والجلسة سطحان آخران

عرّفت RFC 2217 لاحقاً إعدادات تدفق المنافذ التسلسلية، كما عرّفت FLOWCONTROL-SUSPEND وRESUME لتعليق بيانات جلسة Telnet وأوامرها.

ضبط الجهاز، وتعليق الجلسة، واعتراض XON/XOFF محلياً سلطات مختلفة. تشابه الاسم لا يجعل الأدلة متبادلة.

يسجل سجل IANA لخيارات Telnet الرقم 33 باسم Remote Flow Control ويحيل إلى RFC 1372. يثبت استمرار التنسيق، لا الانتشار الحالي أو التنفيذ الصحيح.

خمس طبقات بدلاً من خانة وضع واحدة

يجب فصل: موافقة الجلسة؛ والطلب المرسل أثناءها؛ والحالة المطبقة في العميل؛ ومصير الحرف، أُكل أم مُرّر؛ والنتيجة التي شاهدها المستخدم والتطبيق.

وحّدت RFC 1080 الطبقتين الأوليين ونقطة البداية. أما البقية فتحتاج إلى رصد محلي أو من طرف إلى طرف.

إرثها ليس سيطرة بعيدة على طرفية قديمة، بل تفويض محدود قابل للرفض والسحب. لم يكن Control-S أمراً إلا حين حافظ الاتفاق والآلية المحلية معاً على ذلك المعنى.

المصادر وحدود الإثبات

توفر RFC 854 سياق NVT، وRFC 855 قواعد الاتفاق، وRFC 1080 الخيار الأصلي، وRFC 1184 وضع السطر، وRFC 1372 الاستئناف، وRFC 2217 التحكم التسلسلي والجلسة، وIANA التسجيل. لا تثبت هذه المصادر انتشاراً حالياً أو هوية أو تفويضاً عاماً أو حالة مطبقة أو حادثة أو نتيجة مستخدم.