Доступ к PSPDN асинхронных устройств: рекомендации Х.3/Х.28/Х.29
До бума популярности PC в середине 1980-х многие пользователи осуществляли доступ к удаленным ресурсам, используя асинхронные терминалы. Эти устройства часто назывались «неинтеллектуальными» (dumb), т. к. они не имели основанного на использовании процессора интеллекта и небольшого по объему, если оно вообще присутствовало, устройства хранения данных (буфера).
Несмотря на это, в широком пользовании находились буквально миллионы таких устройств. В знак признания того факта, что операторы сети PSPDN могли бы обслуживать владельцев этих асинхронных устройств, если бы существовали стандарты, управляющие их подключением к сетям PSPDN, союз ITU-T одобрил набор из трех рекомендаций, касающихся использования сервисов сети PSPDN устройствами «старт-стоп» (асинхронными).
Определение функции PAD: рекомендация Х.3
Рекомендация Х.3 описывает концепцию функции сборщика/разборщика пакетов (PAD, Packet Assembler/Disassembler) в сети PSPDN. PAD является конвертером протоколов. В случае PAD интерфейса Х.3-порты, к которым подключаются пользователи, поддерживают форматы асинхронных данных, а порт, подключаемый к оборудованию ОСЕ в сети PSPDN, поддерживает форматы интерфейса Х.25. Соответственно PAD является специализированной формой оконечного оборудования DTE интерфейса Х.25, и часто используется в digital агентствах.
На передающей стороне роль PAD заключается в приеме асинхронных старт-стоповых символов от оборудования DTE, удаления стартовых и стоповых битов и помещении полученных в результате этого асинхронных символов в пакеты, соответствующие протоколу PLP Х.25. Затем эти пакеты вставляются в кадры протокола LAPB и по физическому каналу связи отправляются аппаратуре передачи данных (DСЕ). На принимающей стороне этот процесс выполняется в обратном порядке.
Пакеты интерфейса Х.25 прибывают к PAD, где во время их обработки происходит удаление служебной информации протокола PLP, восстановление первоначальных асинхронных символов и доставка их с замещенными стартовыми и стоповыми битами оконечному оборудованию DTE. Рекомендация Х.3 также определяет набор из 29 параметров сборщика/разборщика пакетов (PAD), которые гарантируют совместимость между асинхронным оборудованием DTE и PAD и систематизируют детали их взаимодействия.
Эти параметры позволяют множеству асинхронных устройств DTE осуществлять доступ к сети PSPDN. Они могут быть изменены пользователем асинхронного оборудования DTE, а также устройствами DTE стандарта Х.25 в сети. Всестороннее обсуждение каждого из параметров PAD стандарта Х.3 выходит за пределы данной книги. Для получения дополнительной информации читатель может обратиться к рекомендации Х.3.
Команды PAD и служебные сигналы: рекомендация Х.28
Рекомендация Х.28 ITU-T определяет набор команд и ответов, применяемых асинхронным оборудованием DTE для доступа к сети PSPDN и обеспечения ее транспортными услугами. Странно, но все из того, что может делать пользователь пакетного режима через интерфейс Х.25, доступно для асинхронного пользователя через интерфейс Х.28.
Операции, такие как установление виртуальных соединений, передача данных и разрыв виртуальных соединений, поддерживаются набором команд интерфейса Х.28. Во время всех фаз виртуального соединения асинхронному пользователю предоставляется информация о его состоянии через набор ответов, известных как служебные сигналы PAD (service signals). Эти служебные сигналы появляются на экране асинхронного устройства, чтобы держать пользователя в курсе того, что происходит внутри сети.
Например, асинхронный пользователь, желающий установить виртуальное соединение через сеть PSPDN, может ввести с клавиатуры своего устройства следующую командную строку Х.28: PAD Х.3 интерпретирует командную строку Х.28 как «Я хочу направить вызов (С) по адресу назначения 8026550940. Я являюсь членом замкнутой группы пользователей (G21) и хочу воспользоваться возможностью обратного вызова оборудования DTE назначения (R)». Если вызов принят вызываемым оборудованием DTE, пользователь увидит служебный сигнал «com», появившийся на экране его компьютера.
Этот служебный сигнал указывает, что виртуальное соединение было установлено в соответствии с запросом пользователя и сейчас находится в фазе передачи данных. Теперь пользователь начинает просто набирать сообщения на клавиатуре асинхронного устройства. PAD будет помещать эти сообщения в пакеты и доставлять их удаленному оборудованию DTE.
Управление РАD, осуществляемое DTE X.25: рекомендация Х.29
В некоторых случаях оборудованию DTE интерфейса Х.25 может потребоваться управлять поведением PAD интерфейса Х.3, к которому подключен асинхронный пользователь. Например, в обычных условиях PAD сконфигурирован так, чтобы обеспечивать локальное эхо для каждого набранного символа.
Поэтому, когда пользователь нажимает клавишу на клавиатуре, соответствующий ей символ через короткий промежуток времени появляется на экране. Такая операция часто используется как механизм контроля ошибок в асинхронных средах. Однако в определенное время во время сеанса желательно отключить эту функцию локального эха. Например, если у пользователя запрашивается пароль для доступа к приложению, мы обычно не хотим, чтобы пароль отображался на экране, т. к. его могут подглядеть посторонние.
В таких случаях удаленное оборудование DTE стандарта Х.25 должно иметь возможность управлять PAD, чтобы временно отключить функцию эха, а затем снова ее включить, после того как пароль будет подтвержден. Рекомендация Х.29 поддерживает этот тип операции. Рекомендация Х.29 поддерживает осуществляемое оборудованием DTE интерфейса Х.25 управление PAD Х.3, определяя для него набор сообщений. Добавленное управление PAD передается через интерфейс Х.25 в поле пользовательских данных пакетов интерфейса Х.25.
Они отличаются от обычных сообщений пользовательских данных значением Q-бита. Если содержимое пакета данных предназначено для экрана монитора асинхронного конечного пользователя, Q-бит устанавливается в 0. С другой стороны, если пакеты содержат Х.29-сообщения управления PAD, они отправляются как «специальные» с Q-битами, установленными в 1. Это одно из обычных применений Q-бита в системах сетей PSPDN.
Другие реализации PAD
Союз ITU-T ввел стандарт PAD для асинхронных устройств по причине их широкого распространения и в силу того, что протокол асинхронного обмена данными являлся всеобщим достоянием. К сожалению, стандарты PAD для других типов не пакетных устройств DTE никогда не были одобрены этим документом.
Причина этого в том, что другие сетевые протоколы были специфичными для конкретного производителя, являлись собственностью разработавших их компаний и не входили в компетенцию союза ITU-T. Однако преимущество, которое сулило использование сети PSPDN для транспортировки других типов трафика, не осталось незамеченным для пользователей этих архитектур. В результате было разработано несколько почти стандартизированных подходов для конвертации других форматов и протоколов в интерфейс Х.25.
Наиболее важным среди них был стандарт, де-факто касающийся транспортировки форматов двоичной синхронной связи (BSC, Binary Synchronous Communications) от компании IBM с использованием интерфейса Х.25. Известен как протокол DSP 3270 (Display System Protocol, протокол системы отображения № 3270), этот подход сегментировал блоки стандарта BSC в пакеты интерфейса Х.25 для дальнейшей их транспортировки через сеть PSPDN.
Восстановление блоков стандарта BSC осуществлялось PAD в месте назначения. Протокол DSP 3270, вероятно, сделал для продления жизни бисинхронной передачи больше, чем любые другие разработки фирмы IBM после их прекращения в 1973 году. Также наряду с другими были разработаны реализации PAD для поддержки архитектуры SNA (Systems Network Architecture) фирмы IBM, архитектуры опрос/выбор от Burrough и архитектуры DNA компании Digital Equipment.