Кратко

  • RFC 1080 позволял одному процессу Telnet просить другой включить или выключить программное управление потоком, но только после согласия DO/WILL.
  • Опция касалась локального вывода от пользовательского Telnet к подключённому терминалу. Она не останавливала TCP или удалённое приложение и не подтверждала применение запроса драйвером.
  • Согласие создавало известное начальное состояние с включённым управлением; отзыв прекращал команды и мог вернуть клиент к реализации-зависимому значению по умолчанию.

Один код мог не покинуть клавиатуру

Клавиатура NVT из RFC 854 умела порождать все 128 кодов US-ASCII. Удалённый редактор мог считать Control-S или Control-Q полноценной командой и ожидать этот ввод.

Локальный драйвер часто использовал те же значения иначе. XOFF, обычно Control-S, приостанавливал вывод; XON, обычно Control-Q, возобновлял его. Драйвер поглощал символ, и серверная программа его не видела.

Перехват защищал буфер и помогал пользователю читать медленный экран. В редакторе он мог уничтожить нужную команду. Значение определялось не одним байтом, а местом интерпретации и действующим состоянием.

RFC 1080, опубликованный в ноябре 1988 года, присвоил TOGGLE-FLOW-CONTROL номер 33. Это был узкий канал просьбы, а не передача терминала во владение удалённой стороне.

Сначала право, затем режим

RFC 855 делил сложную опцию на согласие и подпереговоры. Обычно хост посылал DO, а пользовательский Telnet рядом с терминалом отвечал WILL.

DO означал готовность отправлять просьбы включения и выключения. WILL принимал роль их исполнителя. DONT и WONT отказывались от ролей, но не сообщали текущий локальный режим. Клиент мог отвергнуть удалённое управление и продолжить собственный XON/XOFF.

До полного обмена ON и OFF были запрещены; после отзыва — тоже. Команда не могла одним фактом доставки создать полномочие для себя.

Хотя опция допускала два направления, обычно она была асимметрична. Удалённое приложение знало, когда ему нужен буквальный символ; локальный клиент владел путём к экрану.

Согласие задавало известную отправную точку

После DO/WILL отправитель DO мог запросить ON или OFF. Менялась обработка вывода между пользовательским Telnet и терминалом, а не окно TCP, маршрут или процесс на сервере.

RFC 1080 требовал сразу после согласия включить управление потоком на стороне WILL. Поэтому новый режим не начинался с неизвестности: сам обмен устанавливал первую позицию.

Для последующих изменений подтверждение не определялось. Захваченный OFF доказывал разрешённую просьбу, но не состояние драйвера, паузу на экране или доставку символа приложению.

Неизвестные подкоды игнорировались. Это сохраняло расширяемость и одновременно запрещало считать молчание доказательством поддержки.

Отзыв возвращал локальное значение по умолчанию

Каждая сторона могла завершить опцию через DONT или WONT. До нового согласия подпереговоры становились недопустимы.

Последний ON или OFF не обязан был сохраняться. Реализация могла вернуться к своему стандартному режиму. Журнал, содержащий только последнюю команду, ошибается после отзыва, переподключения или перезапуска.

Удалённое полномочие жило внутри принятого сеанса. Его окончание возвращало решение локальной политике, а не закрепляло чужое предпочтение навсегда.

Поток к экрану не был потоком TCP

RFC 1080 охватывал вывод от пользовательского Telnet к терминалу. Ввод в обратном направлении мог иметь другую политику. Аппаратное управление потоком пользовалось отдельными сигналами и не отнимало символы.

Это не было управлением перегрузкой. Приложение могло продолжить формировать вывод, TCP — принимать байты, буферы — хранить их. Остановившийся экран не означает остановившуюся сеть.

Нажатие Control-S, поглощение XOFF драйвером, сетевой OFF и видимая пауза — разные наблюдения, требующие направления и точки измерения.

Linemode сохранил отдельную машину состояния

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 — разные поверхности. Общее слово не делает их доказательства взаимозаменяемыми.

Реестр опций Telnet IANA сохраняет номер 33 за Remote Flow Control и ссылается на RFC 1372. Это непрерывность координации, не доказательство нынешнего применения.

Пять записей вместо одного флага

Следует отдельно хранить согласие в данном сеансе, отправленный запрос, применённое локальное состояние, судьбу конкретного символа и результат на экране и в приложении.

RFC 1080 стандартизировал первые два слоя и начальную точку. Остальные требуют местного или сквозного наблюдения.

Исторический урок — не удалённое господство над терминалом, а ограниченное и отзывное делегирование. Control-S был командой только пока согласие и локальный механизм вместе поддерживали этот смысл.

Источники и пределы

RFC 854 задаёт NVT, RFC 855 — согласие, RFC 1080 — исходную опцию, RFC 1184 — Linemode, RFC 1372 — возобновление, RFC 2217 — последовательное и сеансовое управление, IANA — регистрацию. Они не доказывают современную распространённость, идентичность, общую авторизацию, применённое состояние, реальный инцидент или пользовательский результат.