Кратко

  • RFC 1116 перенёс построчное редактирование и часть обработки сигналов на клиент. Вместо обмена пакетами при каждом символе сеть требовалась главным образом для готовой командной строки, что помогало на медленных и тарифицируемых по пакетам линиях.
  • Согласие DO/WILL, MODE_ACK и SLC_ACK завершали разные согласования конфигурации. Ни одно из них не подтверждало, что приложение получило строку, разрешило команду, выполнило её или вернуло результат.
  • При установленном EDIT клиент сохранял редактируемый буфер до разделителя или иного условия пересылки. Отправленную часть уже нельзя было изменить локально, однако ей ещё предстояли транспорт, разбор Telnet и решения удалённого процесса.

Быстрый отклик возникал на ближней стороне

RFC 1116 объяснял задачу через количество пакетов. Посимвольный Telnet мог требовать примерно пару пакетов для каждого нажатия. Локальное редактирование должно было приблизить расход к паре пакетов на целую командную строку. Пользователь на канале с большой задержкой сразу видел буквы, удаления и исправления, а ожидал сеть лишь после завершения строки. Это также снижало цену в сетях с оплатой за пакет и избавляло дорогие удалённые компьютеры от обработки каждого отдельного символа.

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

Карточка RFC Editor сохраняет предложенный стандарт августа 1989 года и сведения о его замене, а IETF Datatracker — историю статуса документа. В октябре 1990 года RFC 1184 заменил RFC 1116, добавил биты режима и символы экранного редактирования, но сохранил клиентскую модель. Исторический вывод относится к этой последовательности документов, а не к распространённости механизма сегодня.

Разрешение на переговоры ещё не задавало режим

Linemode получил номер 34 среди опций Telnet. Общая схема RFC 855 разделяла два шага. Сначала стороны обменивались DO и WILL, разрешая обсуждать опцию. Затем в subnegotiation они определяли параметры. DONT или WONT могли отозвать разрешение.

Исходным состоянием RFC 1116 были WONT LINEMODE и DONT LINEMODE. Поэтому соединение TCP, приветствие Telnet или номер в реестре ничего не говорили об активном локальном редактировании. Даже успешная пара 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, пережить разделение данных и команд управления, попасть в связанный процесс, удовлетворить его синтаксису и политике и породить вывод. Локальный редактор не владел ни одним из этих последующих фактов.

Подтверждение таблицы символов не подтверждало действие

Подопция Set Local Characters, или SLC, согласовывала тройки: функцию, модификаторы и назначенный ей ASCII-символ. Уровень поддержки обозначал отсутствие функции, неизменяемую поддержку, явно заданное значение или значение по умолчанию. SLC_ACK означал согласие получателя с настройкой.

Такое подтверждение легко принять за большее. На деле оно закрывало разногласие о том, какой локальный символ соответствует функции. Оно не сообщало, что пользователь нажал этот символ. После нажатия оно не доказывало доставку соответствующей команды Telnet. После доставки — не доказывало поддержку или завершение действия подключённой системой.

RFC 1184 показывал последнюю границу. ABORT и IP могли иметь одинаковый эффект в системе с единственным способом прерывания. Неподдерживаемые функции ABORT, EOF или SUSP могли быть просто проигнорированы. SLC_FLUSHIN и SLC_FLUSHOUT носили рекомендательный характер, а интерфейс мог переопределять предложенное поведение очистки. Имя сигнала было запросом в контексте протокола, а не долговечной записью о том, что процесс остановлен или данные удалены.

У эха и управления потоком оставались свои владельцы

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 определяет сетевой виртуальный терминал и управляющие команды Telnet. Он способен доставлять данные и сигналы удалённому процессу Telnet. Linemode способен снизить издержки клиента и согласовать конфигурацию. Ни одна спецификация не превращает транспортное свидетельство в свидетельство приложения.

Надёжная запись поэтому разделяет этапы: клиентский буфер завершён; префикс переслан; TCP локально принял байты; серверный Telnet их разобрал; удалённый процесс получил строку; политика разрешила действие; выполнение началось; выполнение закончилось; вывод вернулся; пользователь связал его с правильной строкой. Для каждого утверждения требуется собственное наблюдение.

Смысл не в том, что локальный интерфейс обманывает. Linemode был успешен потому, что делал полезный локальный факт мгновенным. Ошибка начинается, когда организация сохраняет этот факт под именем, обещающим удалённый результат.

Источники