Кратко

  • RFC 1073 позволял клиенту вместе сообщать ширину и высоту в знакоместах и присылать новое состояние после локального изменения. Сервер мог согласиться на NAWS, проигнорировать значения или позднее запретить следующие обновления.
  • DO/WILL означали разрешение говорить на языке опции; четыре октета NAWS были заявлением клиента. Обновление терминала сервера, сигнал дочернему процессу, новая вёрстка приложения и то, что увидел человек, оставались самостоятельными фактами.

Базовая спецификация Telnet не задавала ширину принтера и длину страницы сетевого виртуального терминала. Такой скромный общий знаменатель помогал разным системам общаться без полного знания локального устройства партнёра. Но к концу 1980-х клиент всё чаще работал внутри графического окна, форму которого пользователь мог менять, не разрывая сеанс.

RFC 1073 назначила номер 31 опции NAWS — Negotiate About Window Size. Главное изменение касалось не только диапазона чисел. Документ вернул управление реальному владельцу. Клиент полностью контролировал своё окно и сообщал текущую геометрию. Сервер контролировал согласие на опцию и дальнейшее использование сведений.

Согласие на опцию ещё не было изменением экрана

Сервер мог отправить DO NAWS, а готовый клиент — ответить WILL NAWS. DON'T и WON'T оставляли путь отказа. По правилам RFC 855 этот обмен лишь открывал возможность более содержательной субпереговорной команды. Конкретные данные появлялись позже.

Поэтому DO/WILL подтверждает состояние разрешения, но не отправку размеров. Получение NAWS подтверждает байты на границе интерпретатора, но не сохранение значения, изменение драйвера, доставку сигнала или реакцию приложения. У каждой ступени свой наблюдатель и свой срок действия.

Субпереговоры несли два октета ширины и два октета высоты в сетевом порядке. Единицей были символы, а не пиксели; каждая ось могла достигать 65 535. Значение 255 Telnet резервировал как IAC, поэтому 255 внутри данных удваивался. Четыре логических октета возникали только после корректного разбора границ и снятия экранирования.

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

Новое значение было поколением, а не квитанцией

В примере RFC клиент сначала передаёт 80 × 24, а после изменения пользователем — 80 × 64. Повторять DO/WILL не требовалось. Локальный объект перешёл в новое состояние, и уже разрешённая опция донесла следующую версию.

Второе сообщение не подтверждало применение первого. NAWS не определял ответа «дочерняя программа перестроила вывод». Оконная система, клиент, серверный терминал и приложение могли некоторое время хранить разные поколения. Выражение «текущий размер окна» бессодержательно без указания владельца и времени.

RFC прямо называла информацию рекомендательной. Сервер мог принять NAWS и не пользоваться значениями. Некоторые операционные системы не умели менять размер в середине сеанса. Тогда сервер после первоначального согласия мог отправить DON'T NAWS и остановить следующие субпереговоры без цикла. Клиентское окно продолжало меняться; прекращался лишь удалённый поток описаний.

Такое неравенство ролей было точным распределением полномочий. Клиент владел геометрией, сервер — реакцией.

Старые опции предполагали лишнюю власть сервера

NAOL и NAOP отдельно обсуждали ширину строки и размер страницы. RFC 1073 сочла их семантику неподходящей для графических окон. Они были двунаправленными, словно сервер мог управлять размерами клиента, ограничивали каждую ось числом 253 и, по современным документу сведениям, редко применялись.

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

Размер задавался в знакоместах. Пример 300 × 24 не доказывал физически широкий монитор, число пикселей или масштаб. Для такого вывода нужны шрифт, плотность и способ отображения, которых в сообщении не было.

Тип, скорость и геометрия не сливались в один профиль

RFC 930 описывала TERMINAL-TYPE: сервер спрашивал, клиент отвечал, а получение имени не требовало немедленного изменения обработки. RFC 1091 позднее позволила перебирать несколько режимов эмуляции, сохранив запрос за сервером. Тип давал контекст возможностей, но не измерял окно.

RFC 1079 выделила номер 32 скорости терминала. После согласия запрашивающая сторона просила ASCII-строку со скоростями передачи и приёма; сообщающая сторона не могла посылать её самопроизвольно. Неподдерживаемую скорость разрешалось округлить в безопасную сторону. NAWS работал иначе: после согласия клиент сам сообщал каждое локальное изменение двумя двоичными осями.

Тип мог помочь выбрать значение по умолчанию, если NAWS прислал ноль по одной оси, но не становился измерением. Скорость могла влиять на заполнение или интерфейс, но не была числом столбцов. Раздельные опции сохраняли происхождение каждого решения.

Реестр опций Telnet IANA по-прежнему связывает 31 с NAWS, а 32 с TERMINAL-SPEED. Запись доказывает назначение кода и источник спецификации, но не современное внедрение, соответствие продукта или использование в конкретном соединении.

За четырьмя октетами следовали локальные решения

Рекомендации RFC прослеживают цепочку. Оконная среда сообщает клиенту Telnet об изменении. В 4.3BSD клиент мог перехватить SIGWINCH. Затем он отправлял NAWS. Сервер мог применить ioctl к своему терминалу и после этого послать сигнал дочернему процессу, вероятно командной оболочке.

Каждое «мог» принадлежало отдельному компоненту. Правильный NAWS не гарантировал успех ioctl. Новый терминальный статус не гарантировал доставку сигнала. Сигнал не гарантировал обработку до следующего вывода. Правильно разбитый текст не доказывал, что его увидел человек.

При неправильном переносе строк полезно сравнить локальное событие, сырые байты, обработку 255, сохранённую геометрию, сигнал дочернему процессу и поколение, прочитанное приложением. Единый флаг «размер изменён» уничтожил бы место расхождения.

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

RFC 1073 описывает предложение 1988 года и тогдашний пример из Carnegie-Mellon, а не всеобщую распространённость. RFC 854 и 855 дают рамку Telnet; RFC 930, 1079 и 1091 документируют соседние атрибуты, не доказывая применение NAWS. Реестр IANA также не является свидетельством трафика или реализации.

Нет оснований объявлять прямое происхождение псевдотерминалов SSH, адаптивной веб-вёрстки или удалённых рабочих столов. Историческое достижение уже достаточно определённо: изменчивое локальное состояние стало переносимым, не превратившись в обязательную удалённую команду.