Материал из PL Engineering

TELNET (англ. TELecommunication NETwork) — сетевой протокол для реализации текстового интерфейса по сети (в современной форме — при помощи транспорта TCP).

Назначение протокола TELNET в предоставлении достаточно общего, двунаправленного, восьмибитного байт-ориентированного средства связи. Его основная задача заключается в том, чтобы позволить терминальным устройствам и терминальным процессам взаимодействовать друг с другом.

ОПИСАНИЕ

Соединение TELNET - это TCP соединение, используемое для передачи данных, с различной управляющей информацией.

Протокол TELNET базируется на трех основных идеях: первая, концепция "Виртуального Сетевого Терминала" (англ. Network Virtual Terminal, NVT); вторая, принцип оговоренных опций; третья, симметричный вид терминалов и процессов.

1. Когда устанавливается TELNET соединение, предполагается, что на каждом конце соединения порождается и завершается "Виртуальный Сетевой Терминал" или ВСТ. ВСТ - это воображаемое устройство которое предоставляет стандартное, доступное через cеть, промежуточное представление классического терминала. Это устраняет необходимость в "серверном" и "клиентском" узлах для хранения информации о характеристиках каждого терминала и договоренностей о взаимодействии. Все узлы, как клиентский, так и серверный, отображают свои локальные характеристики устройства с тем, чтобы выступать в сети как ВСТ, и каждый мог принять похожее отображение с другой стороны. ВСТ предназначен для сведения баланса между чрезмерным ограничением и чрезмерными возможностями.
Примечание: "Пользовательский" хост - это обычно хост с привязанным к нему физическим терминалом, а "серверный" хост - это обычно хост предоставляющий некий сервис. Как альтернативную точку зрения, можно рассматривать случай когда соединяются равные хосты: терминал-терминал или процесс-процесс. Таким образом будем считать "пользовательским" хостом тот хост который инициирует соединение.
2. Принцип оговоренных опций охватывает тот факт, что многие хосты скорее всего будут хотеть предоставить дополнительные сервисы до или после их доступности в ВСТ, и многие пользователи захотят иметь сложные терминалы с элементами изысканности, вместо минимальных, для получения таких дополнительных сервисов. Независимые от, но структурированные в TELNET протоколе различные "опции" санкционированы и могут быть использованы с "DO, DON'T, WILL, WON'T" структурой для того, чтобы позволить пользователю и серверу сходиться в использовании более продуманного (или отличного) набора соглашений для их TELNET соединения. Такие опции включают изменение набора символов, режима эха, и т.д.
Базовая стратегия для налаживания использования опций - это на одной из сторон (или на обеих) инициировать запрос: будет ли определённая опция иметь какой либо эффект. Другая сторона может либо принять, либо отвергнуть запрос. Если запрос принимается, то опция немедленно вступает в силу; если же опция отвергается, то связанный аспект соединения остается как специфицировано для ВСТ. Очевидно, что сторона может всегда отвергать запрос на включение, и никогда не должна отвергать запрос на отключение некоторой опции начиная с момента когда стороны договорились о поддержке ВСТ.
Синтаксис оговоренной опции должен быть таким, чтобы если обе стороны запросят одновременно опцию, то каждый будет рассматривать запрос с другой стороны как положительное подтверждение этой опции.
3. Симметричность синтаксиса согласования может потенциально привести к бесконечному циклу согласования - когда каждая сторона видит входящие команды не подтверждает их, но для подтверждения посылает новый запрос. Для предотвращения таких циклов, необходимо придерживаться следующих правил:
Стороны могут запрашивать только изменение статуса опции; т.е. сторона может не посылать "запрос" только для того, чтобы сообщить, что данная опция поддерживается.
Если сторона получает что-то, что интерпретируется как запрос переключения в некоторый режим в котором эта сторона уже находится, то на такой запрос не нужно отправлять подтверждения.
Всякий раз, когда одна сторона отправляет команду опции на другую сторону, не важно запрашивая или подтверждая, и использование опции должно иметь какой либо эффект на обработку данных, отсылаемых первой стороной второй стороне, то команда опции должна быть вставлена в потоке данных в том месте, с которого желательно, чтобы опция вступила в силу. (Следует отметить, что пройдет некоторое время между передачей запроса и получением подтверждения, и оно может быть отрицательным. Таким образом, хост может буферизовать данные, после отправки запроса опции и до получения ответа с принятием или отвержением опции, для того, чтобы скрыть "период неопределённости" от пользователя.)