Кратко

  • RFC 1041 предложил единую опцию 3270-REGIME, но RFC 1576 сообщил, что её реализовали очень немногие разработчики и поставщики. Практикой стала комбинация Terminal-Type, Binary и EOR.
  • Три согласования задавали эмуляцию, восьмибитный поток и границы блоков. Они не предоставляли конкретное имя device/LU, SNA BIND, связанный с блоком ответ обработки или единый смысл ATTN и SYSREQ.
  • TN3270E позже ввёл device-name, BIND-IMAGE и RESPONSES как отдельные функции. Само согласие на TN3270E не доказывало их наличие, аутентификацию или конечный результат.

У стандарта был один переключатель, у практики — три

Поток 3270 отличался от обычного NVT Telnet. Он использовал EBCDIC и передавал команды блоками. Модель терминала и размер экрана влияли на представление. Поэтому поверх TCP требовалось согласовать восьмибитные данные, границу сообщения и режим эмуляции.

RFC 1041 собрал эти решения в 1988 году в опции 29 3270-REGIME. Клиент предлагал упорядоченный список, сервер выбирал общий режим. Выбор подразумевал Binary и IAC EOR; пустой список возвращал NVT ASCII.

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

Чёткий механизм не стал общей установленной практикой. RFC 1576 отмечал, что RFC 1041 реализовали очень немногие. Официальная карточка относит январский документ 1994 года к Informational. Это не перепись и не утверждение о нулевом внедрении; это основание описывать то, что действительно соединяло системы.

Составной режим работал благодаря узким значениям

Traditional TN3270 использовал базовый Telnet, Terminal-Type, Binary Transmission и End of Record. Сервер запрашивал тип, клиент объявлял эмуляцию. Binary сохранял восемь бит. EOR завершал командный блок последовательностью IAC EOR.

Ни одна опция отдельно не означала TN3270. Режим возникал из их состояний. RFC 1576 не задавал обязательный порядок. После согласования подходящего типа, Binary и EOR стороны обменивались блоками. Если сервер отзывал Binary или EOR, клиент переходил к интерпретации следующих данных как NVT ASCII.

Каждая квитанция была полезна в собственных пределах. Binary говорил об октетах, EOR — о границе, Terminal-Type — о представлении. Сервер по-прежнему решал, как связать Telnet с SNA или non-SNA host application.

Тип экрана не называл Logical Unit

Terminal-Type был асимметричен. Сервер спрашивал, клиент перебирал варианты. Ответ мог переключить эмулятор клиента, но не заставлял сервер немедленно менять обработку.

Имя модели 3278 описывало экран, а не физическое устройство, пользователя или Logical Unit. Суффикс -E обычно указывал structured fields, но серверы различались в выводах об extended attributes. Это был сигнал, не исчерпывающий паспорт возможностей.

В SNA терминал обычно имел сеанс с приложением и сеанс с System Services Control Point. Клиент TN3270 видел одно Telnet-соединение. Он не мог запросить определённый 3270 device-name или узнать LU name, выделенный сервером на стороне SNA.

RFC 1576 называл IP-адрес клиента ближайшим аналогом LU name. Слова «ближайший аналог» сохраняют границу: IP указывает сетевую сторону, LU — логический ресурс, от имени которого может зависеть поведение приложения.

После EOR обработка только начиналась

У традиционного блока 3270 не было внешней длины, поэтому EOR закрывал необходимый пробел. Получатель узнавал, где кончилась команда. Он ещё не знал, успешно ли она выполнена.

RFC 1576 перечислял отсутствие SNA positive/negative response. Положительный ответ мог сообщить о завершении обработки предыдущих данных; отрицательный — об ошибочной команде или механической проблеме клиента. Traditional TN3270 не переносил такой результат: данные считались обработанными либо проигнорированными.

Получение TCP, сохранение Binary, EOR, принятие команды, изменение экрана, печать, событие приложения и внимание человека остаются разными фактами.

NOP или Timing Mark давали лишь проверку присутствия. NOP не требовал ответа приложения; аварийно завершившийся клиент мог проявиться как TCP send error. Доступность процесса не равна здоровью приложения.

ATTN и SYSREQ зависели от перевода шлюза

ATTN часто отображался в Telnet BREAK, после чего сервер переводил его в действие SNA. Non-SNA сервер мог BREAK игнорировать.

SYSREQ мог идти как Telnet Interrupt Process или 3270 Test Request. В SNA он переключал application и SSCP sessions. SSCP data нельзя было прямо передать traditional TN3270-клиенту, поэтому сервер сам обрабатывал, конвертировал или не поддерживал функцию.

Нажатие, команда Telnet, перевод, событие SNA и прерывание приложения нуждались в отдельных записях.

TN3270E добавил недостающие факты раздельно

RFC 1646 и RFC 1647 описали ранние расширения. RFC 2355, чей официальный статус относится к Standards Track 1998 года, объединил TN3270E.

Сначала согласовывались device-type и необязательный resource/device-name. Сервер возвращал выделенное имя или причину отказа: неизвестное имя, занятое устройство, несовместимость типа. Затем стороны согласовывали FUNCTIONS.

BIND-IMAGE сообщал начало и конец SNA-сеанса с host application. RESPONSES добавлял header, response policy и sequence number, связывая положительный или отрицательный результат с нужным блоком. SYSREQ и printer control были отдельными функциями. Пустой список означал basic TN3270E.

Молчание сохраняло контекст: no response, error-only или always. Без RESPONSES sequence не был квитанцией. Без BIND-IMAGE согласованный TN3270E не раскрывал BIND. При отказе одной стороны сохранялся fallback к traditional TN3270.

RFC 2355 также подчёркивал отсутствие дополнительной безопасности по сравнению с обычным Telnet. Выделение device-name не авторизовало пользователя.

Работающий код не получает власть над скрытыми слоями

RFC 1041 демонстрирует ясный документ без широкого внедрения. Traditional TN3270 — работающую совместимость без части квитанций. TN3270E — раздельное добавление квитанций при сохранении слабого режима.

Принцип Heng Lu о первичности работающего кода направляет исследование к реально действующей системе. Минимальная спецификация и локальные решения объясняют ценность малого общего слоя. Разделение слоёв реальности не позволяет смешать представление, сеанс, identity и outcome. Это современная редакционная рамка, а не утверждение о намерениях авторов RFC.

Три опции создали терминал: type назвал эмуляцию, Binary сохранил байты, EOR закрыл блок. LU, BIND, обработка, прерывание и последствия всё ещё требовали собственных свидетельств.

Источники