Кратко

  • RFC 1921 вёл на одном Telnet-соединении три адресных потока: экран 0x60, принтер 0x68 и печать копии экрана 0x69; на каждом мог ждать ответа только один запрос.
  • Второй запрос по тому же адресу удалялся, но его PROTOCOL-VIOLATION нельзя было послать раньше ответа на первый запрос: при отсутствии общего номера транзакции принадлежность ответа сохранял порядок.
  • Terminal-Type, Mailbox, EOR, ACK, BUSY, READY и PURGED подтверждали только ограниченные этапы. Они не доказывали полномочия пользователя, успех приложения, появление изображения или лист бумаги.

Живое соединение допускало предписанную потерю

LOCAL был не сбоем транспорта, а состоянием терминала для местной настройки или проверки. Перед переходом клиент посылал запрос LOCAL-STATE. Сервер подтверждал его и должен был прекратить передачу данных экрану и принтеру, пока клиент не сообщит indication ONLINE-STATE.

Если сервер всё-таки присылал экранный или принтерный блок, клиент его удалял. Если это был request, допустимым ответом служил BUSY. Таким образом, успешное TCP-соединение, согласованная Telnet-грамматика и правильная граница записи могли завершиться не исполнением, а предусмотренным уничтожением данных.

Это не останавливало всё соединение. Экранные сообщения от клиента и сообщения по другим адресам сохраняли допустимость. Фраза «терминал занят» стирает важное: запрет имел направление, адрес и начало во времени.

Так RFC 1921, опубликованный в марте 1996 года со статусом Informational, превращал одну сессию не в один статус, а в несколько локально проверяемых решений.

Один TCP-поток содержал три очереди без очередей

TNVIP был профилем Telnet для эмуляции терминалов Bull VIP. Устройства семейств P200 и 7800 работали блоками и могли иметь связанный принтер. Terminal Manager представлял физические устройства приложениям как логические станции и логические устройства; один принтер мог обслуживать несколько логических станций.

Спецификация не свела их к безымянной последовательности байтов. Каждое TNVIP-сообщение начиналось обязательным двухбайтовым заголовком. Первый байт определял адрес: 0x60 для экрана, 0x68 для принтера, 0x69 для печати копии экрана. Второй задавал команду, а два его младших бита различали indication, request, response и response-and-request.

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

Можно было выбрать другой путь — нумеровать операции и разрешить свободное чередование. Позднейший LDAP показывает такую модель с Message ID. TNVIP отказался от универсальной метки и заплатил ограниченной параллельностью. Взамен каждой стороне хватало трёх небольших локальных состояний; общего реестра транзакций не требовалось.

Второй запрос исчезал, а сообщение об ошибке ждало

Если до ответа по адресу приходил второй запрос, принимающая сторона должна была удалить его. Но немедленно сообщить о нарушении она не могла. Сначала следовал ответ на исходный запрос, затем — PROTOCOL-VIOLATION для удалённого второго.

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

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

Поэтому BUSY не означал скрытую очередь. Молчание до первого ответа не означало приём. После явной потери отправитель должен был заново решить, допустим ли повтор. Протокол не мог знать, идемпотентно ли действие за его пределами.

EOR находил конец записи, но не её судьбу

До обмена TNVIP-сообщениями стороны обязаны были согласовать подходящий Terminal-Type и Telnet End-of-Record. Строка терминала указывала поддерживаемую модель и могла содержать @Mailbox-name. В DSA-шлюзе Mailbox выбирал конкретную точку доступа; без него сервер мог предоставить общий вход. Имя было ограничено, строчные буквы обрабатывались как прописные.

Это маршрутизация внутри терминальной среды, а не удостоверение личности. Согласие с названием модели не доказывало подлинность физического терминала. Mailbox не доказывал право человека им пользоваться. В Security Considerations RFC прямо говорилось, что безопасность не рассматривается, и ожидалась будущая аутентификация, в том числе для этого вопроса.

Binary Transmission можно было согласовать при необходимости восьмибитных значений. Suppress-Go-Ahead был необязателен, если GA не требовался для синхронизации передачи терминала с DSA-ходом или ISO-токеном сессии. Эти опции меняли передачу байтов и очередность ходов, а не полномочия.

Каждый блок завершался IAC EOR. Получатель видел целую запись, но её целостность не сообщала, была ли она обработана, удалена или напечатана. Для результата существовал отдельный словарь TNVIP.

Даже Telnet-команды внутри TNVIP-записи могли нарушить однозначность. Кроме экранированного IAC IAC, такую команду требовалось обработать, однако реализация могла сделать это сразу либо после текущего сообщения. Поэтому RFC настоятельно советовал размещать команды между записями: одинаковый порядок байтов не должен был оставлять спор о порядке управления и данных.

Четыре типа сообщений заменяли общий чек

Indication не ожидала ответа. Request занимал единственный ответный слот своего адреса. Response закрывал его и разрешал следующий запрос. Response-and-request одновременно положительно отвечал на текущий запрос и открывал новый в противоположную сторону.

Отсюда зависимость каждого результата от контекста. Экранный ACK мог подтвердить обработку данных либо принятие LOCAL-STATE — это определял текущий request. Экранный BUSY означал удаление серверных данных в LOCAL. Принтерный BUSY означал удаление новых данных, пока предшествующая печать не завершилась.

Принтерный READY отвечал на запрос состояния устройства. Он не был ACK принтерных данных и не подтверждал готовый лист. ERROR сообщал неуспех обработки, ABORTED — прерывание оператором или reset, PURGED — остановку ещё не подтверждённого запроса, NOT-AVAILABLE — отсутствие поддерживаемого устройства, UNKNOWN-COMMAND — неизвестную операцию, PROTOCOL-VIOLATION — недопустимый переход.

Неизвестная indication могла быть удалена без ответа: отправитель ответа не ждал. Неизвестный request требовал ограниченного отрицательного ответа. Журнал, оставляющий лишь ACK или «ошибка», выбрасывает адрес и причину — то есть саму доказательную связь.

Разрешение на копию не было результатом копирования

Поток печати копии экрана имел собственный адрес. Поскольку локальный принтер мог быть под управлением сервера, пользователь не начинал копирование без согласования. Клиент посылал COPY-REQ. Если сервер разрешал локальную копию, он отвечал LOCAL-COPY.

Эта команда была response-and-request. Она закрывала вопрос о разрешении и одновременно открывала требование сообщить итог. Клиент затем возвращал один из предусмотренных результатов: ACK, ERROR, BUSY, ABORTED, PURGED или NOT-AVAILABLE.

Архитектура ясно разделяла власть. Сервер мог выделить общее устройство. Клиент мог попытаться совершить локальное действие. Его поздний response мог описать протокольный исход попытки. Но ни разрешение, ни ACK сами по себе не показывали, что именно оказалось на бумаге и кто взял лист. История RFC 1318 подчёркивает нижнюю границу: даже физический сигнал принтера не равен результату документа.

После ответа purge терял власть

Для экрана, принтера и копии экрана были определены purge indications. До подтверждения запроса получатель пытался остановить обработку и отвечал PURGED. После уже отправленного ответа purge игнорировался и удалялся.

Это запрещало поздней отмене переписать состоявшуюся протокольную историю. Однако правило не обещало обратить физический эффект. PURGED описывал ту часть обработки, которую ещё удавалось прервать. Если действие уже вышло за эту границу, универсального undo у RFC не было.

Running-Code Primacy полезен здесь как поздняя аналитическая дисциплина, а не свидетельство намерений авторов. Опубликованная команда и эффект устройства — разные факты. Реальный код придаёт ответу силу внутри реализованного автомата; он не даёт власти над тем, что автомат не наблюдает и не может вернуть.

Документы доказывают правила, а не внедрение

Основные факты TNVIP находятся в RFC 1921. RFC 854 задаёт базовую модель Telnet. RFC 885, RFC 856, RFC 858 и RFC 1091 дают контекст EOR, Binary, Go-Ahead и Terminal-Type. RFC 1576 описывает другой терминальный профиль и очерчивает границу с уже опубликованным материалом о TN3270.

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

Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption помогает читать конструкцию сегодня: общий обязательный слой должен быть тонким и локально проверяемым, а политика устройства и подтверждение поздних последствий остаются у тех, кто способен их наблюдать. Это аналитическая рамка, не приписывание авторам RFC более поздней доктрины.

Самый прочный урок RFC 1921 — отказ от лишнего знания. Один ответ не мог законно объяснять два запроса. Три маленьких состояния, явное удаление и порядок ошибок делали свидетельство уже, зато пригодным.