Кратко

  • В мае 1983 года Jon Postel и Joyce Reynolds описали в RFC 860 шестую опцию TELNET — TIMING-MARK. Одна сторона посылает DO TIMING-MARK; согласившаяся сторона вставляет WILL TIMING-MARK в подходящее место обратного потока после прохождения буферов.
  • Если пользователь успел напечатать что-то после ошибочной команды, сервер может отбрасывать этот ранний ввод до возвращения метки. Затем он снова читает символы, набранные после того, как человек увидел указание на ошибку. Запросившая сторона сама управляет отбрасыванием.

Пользователь отправил команду и, пока компьютер молчит, начал следующую. Сервер находит ошибку в первой и выводит вопросительный знак. Следующие нажатия уже могли застрять в буфере терминального компьютера, лететь по сети или лежать в очереди самого сервера. Если принять их за новую осмысленную команду, одна опечатка потянет за собой чужую реплику. В RFC 860 нужен точный ответ: где заканчивается ввод, сделанный до того, как человек увидел ошибку?

Основной протокол TELNET описывал двусторонний обмен, а правила опций позволяли предложить и отклонить дополнительные действия. TIMING-MARK применял эти правила к буферам. Название звучит как обещание назвать время, однако для исправления ошибки нужен участок потока. Символы пересекают две машины; взгляд пользователя на экран не совпадает с моментом, когда сервер читает свою очередь.

Сервер посылает IAC DO TIMING-MARK. Если другая сторона согласна, она возвращает IAC WILL TIMING-MARK, поместив ответ в надлежащую точку своего потока. RFC проводит метку через выходной буфер к терминалу, а затем через входной буфер обратно. Получив WILL, сервер узнаёт о пройденной точке разворота. Ранние символы и ввод после увиденного вопросительного знака оказываются по разные стороны понятной обоим границы.

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

Мусорное ведро остаётся у запросившего. RFC 860 возлагает удаление нежелательных символов на отправителя DO. Другая машина предоставляет надёжную метку, после чего запросившая сторона разбирает собственный поток. Тот же приём работает в обратном направлении. Терминал, которому надоел устаревший вывод сервера, просит метку, скрывает старый поток до возвращения WILL и вновь показывает то, что было создано после нового запроса.

У ответов разная доказательная сила. WILL подтверждает расположение метки в нужном месте. WON'T отказывает в таком подтверждении, одновременно свидетельствуя о получении предшествующих данных. DON'T сообщает, что прежний WILL был проигнорирован. По умолчанию стороны не стремились к явной синхронизации. В RFC среди применений названо измерение задержки туда и обратно: известный разворот удобен для опыта. Для очистки очереди важна сама граница порядка.

Авторы предусмотрели даже нетерпеливого пользователя, который предчувствует запрос сервера. Его программа может поставить WILL в выбранной им точке и позволить снова печатать; позднее ей придётся правильно погасить прибывший DO. Эта маленькая хитрость показывает, как далеко друг от друга могут находиться человеческое «теперь» и состояние компьютерных буферов. Метка переносила одно к другому.

Вопросительный знак занимал на экране один символ. Чтобы безопасно продолжить после него, понадобились встречная метка и местное решение о судьбе накопленного текста. Клавиатура говорила быстрее сервера; наконец тот знал, с какой фразы слушать снова.