Кратко

  • RFC 854 сделал поведение терминала предметом согласования: любая сторона могла запросить опцию, а другая — принять или отклонить её.
  • Общий Network Virtual Terminal оставался запасным режимом, поэтому разные возможности не уничтожали общую исходную точку.

Анализ

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

Устойчивый вариант этого замысла появился в мае 1983 года. Джон Постел и Джойс Рейнольдс опубликовали RFC 854, заменивший RFC 764. TELNET описывался как двунаправленное средство обмена восьмибитными байтами между пользовательской терминальной системой и удалённым сервером. В центре был Network Virtual Terminal (NVT) — набор общих правил, позволявший разным хостам начать базовый сеанс до выбора более специальных функций.

NVT был минимальной общей основой, а не утверждением, что терминалы одинаковы. RFC 854 позволял любой стороне первой запросить опцию. Четыре команды разделяли направление ответственности: DO просила другую сторону включить функцию, WILL сообщала, что отправитель будет её выполнять. DONT и WONT отзывали эти позиции. При отказе соответствующая часть сеанса оставалась в режиме NVT. Хост мог ответить отрицательно, не разрывая соединение.

Это различие было важно, поскольку опция не являлась общим переключателем всего соединения. Состояния могли различаться по направлениям. Одна сторона могла согласиться на эхо символов, другая — отказаться; первая могла запросить двоичную передачу, а её партнёр оставить режим по умолчанию. RFC 856 о двоичной передаче, RFC 857 об эхо и RFC 858 о Suppress Go Ahead показывают небольшие изменения вокруг общего потока. RFC 855 требовал описывать команды, значения по умолчанию и мотивы опций, оставляя хостам право предлагать, проверять и отвергать их. RFC 880 относил опции TELNET к необязательным.

Симметрия делала обмен гибким, но могла породить бесконечный цикл: каждая сторона принимала подтверждение за новый запрос. RFC 854 предусмотрел правила против этого. Хост должен запрашивать изменение, а не просто объявлять уже действующий режим; запрос о включении активного режима не требовал нового подтверждения. Одновременные запросы могли подтвердить друг друга. Запрос на отключение нельзя было отклонить: обе стороны должны были быть готовы вернуться к NVT.

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

Позднейшие документы не позволяют считать историю безусловным успехом. В 1989 году RFC 1123 потребовал от реализаций иметь механизм согласования, отвергать неподдерживаемые опции, продолжать переговоры на протяжении соединения и поддерживать NVT, если договориться не удалось. В документе также отмечались сохранявшиеся неоднозначности, в том числе правила окончания строки. В 1990 году RFC 1143 предложил более систематический метод управления состоянием согласования. Общий резервный режим и защита от циклов помогали, но не устранили различия между реализациями и не обеспечили безупречную совместимость всех терминалов.

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

Источники