Рисунок 4.3.2.3. Формат кадра X.25
Открывающий и закрывающий флаги для бит-ориентированного формата несут в себе код 0x7e. Когда не передается никакой информации, по каналу пересылается непрерывный поток флагов 01111110. Посылка более 6 единиц подряд воспринимается как флаг абортирования связи. Если необходимо передать информационную последовательность 01111110, после первых пяти единиц вводится дополнительный нуль, приемник восстанавливает истинную информацию, удаляя эти лишние нули. В случае байт-ориентированных кадров открывающий и завершающий флаги имеют по два байта [DLE (Символы кодов стандарта ISO 646-1973 (МТК-5, ГОСТ 13059-74). Здесь и далее используется русская терминология в соответствии со стандартом ГОСТ 26556-85, STX и DLE, ETX, соответственно, для информационного кадра и DLE, STX и DLE, ETX для управляющего]. Адрес в пакете X.25 занимает всего один байт, что определяет предельное число терминальных устройств, подключаемых к одному каналу. Кадр на уровне 2 имеет двухбайтовый заголовок, содержащий байт адреса и байт типа. Для нумерации кадров на уровне 2 используется 3 бита. При работе со скользящим окном откликов это позволяет иметь до 7 кадров в очереди. При использовании спутниковых каналов с большими задержками можно переходить в режим расширенной нумерации (7 бит), где длина очереди может достигать 128. Если удаленный партнер не способен работать в режиме расширенной нумерации, он отклонит запрос соединения. При работе в режиме расширенной нумерации возможно применение 3-байтовых заголовков вместо двухбайтовых.
Значения поля идентификатора общего формата (GFI - general format identifier) приведено в таблице 4.3.2.2. Бит 8 этого поля (Q) используется в информационных пакетах как индикатор уровня передаваемых данных. Групповой номер логического канала и номер логического канала присваиваются по соглашению с администрацией сети во время постановки на обслуживание. Поля групповой номер логического канала и номер логического канала присутствуют во всех пакетах кроме пакетов регистрации и повторного пуска, где они принимают нулевое значение.
Рисунок 4.3.2.4. Формат кадра запроса на соединение и соединение установлено
Поле опции содержит целое число октетов, но не более 109, следующее же поле может содержать до 128 байт. Опция типа fast select позволяет поместить до 64 байтов в информационном поле пользователя, во многих случаях этого оказывается достаточно и исключается необходимость переходить в режим пересылки данных.
Если вызываемое DTE не присылает сообщения вызов принят или запрос завершения (установление связи отвергнуто) за отведенное для этого время, процедура завершается и процессу, инициализировавшему запрос, присылается соответствующий код ошибки. При успешной обработке запроса (прислано сообщение соединение установлено) система переходит в режим обмена данными. DTE может в любой момент инициировать процедуру разрыва связи, послав сообщение запрос завершения. DCE сообщает о завершении соединения путем присылки пакета индикация завершения, на который DTE должно прислать отклик подтверждение завершения. Формат пакетов запроса и подтверждения завершения отображен на Рисунок 4.3.2.4. и 4.3.2.5. Байты 1 и 2 на рисунке 4.3.2.5 не показаны, так как они идентичны тому, что представлено на Рисунок 4.3.2.4.
Рисунок 4.4.5.5 Формат общего управляющего сегмента пакета XTP
Три поля общего управляющего сегмента представляют статусную информацию и содержатся во всех трех типах контрольных пакетов. Первые два поля RSEQ и alloc являются параметрами управления обменом. Поле Echo используется для идентификации контрольных пакетов, которые являются откликом на пакеты с битом SREQ=1. Поле RSEQ содержит в себе номер очередного байта, подлежащего пересылке, и определяет начало окна, управляющего обменом. Поле Alloc интерпретируется, когда разрешено управление обменом. Код поля Alloc определяет объем данных, который отправитель может послать (а получатель принять). Если бит RES=1, то поле Alloc задает размер буфера, зарезервированного для данной ассоциации. Поле Echo используется для установления соответствия между запросом статуса и контрольными пакетами. Код поля Echo равен наибольшему значению sync для полученных пакетов. Это значение хранится в контекстной переменной rcvd_sync. Когда формируется контрольный пакет, значение rcvd_sync заносится в поле Echo этого пакета.
Формат сегмента управления ошибками показан на Рисунок 4.4.5.6. Этот сегмент включает в себя все поля общего управляющего сегмента, дополнительно использовано только два поля Nspan и Spans, которые сообщают о том, какие пакеты потеряны.
Рисунок 4.3.2.13. Формат пакета диагностика
Поле код диагностики несет в себе информацию об ошибке, вызвавшей посылку этого пакета. Если же пакет диагностика передается в качестве отклика на пакет с ошибками от DTE, то поле уточнение диагностики содержит первые три байта пакета DTE.
Современные сети создаются ради доступа к определенным услугам. В протоколе X.25 предусмотрена процедура, которая позволяет получить текущие значения параметров услуг (опций) и модифицировать их. Эта процедура называется регистрацией и не является обязательной. Форматы пакетов запроса регистрации и подтверждения регистрации показаны на Рисунок 4.3.2.14 и 4.3.2.15. Максимальный размер поля регистрация составляет 109 байт. Инициатором регистрации всегда является dte, которое передает запрос регистрации. В качестве отклика dce посылает пакет подтверждение регистрации, в котором содержатся информация о параметрах доступных услуг. Для выявления доступных услуг может быть послан запрос регистрации, не содержащий списка запрашиваемых услуг.
Рисунок 4.3.2.8. Формат пакета подтверждения повторного пуска (слева) и повторной установки (справа)
Пакеты данных передаются по постоянным виртуальным каналам или через виртуальные соединения после их создания. Пакеты данных распознаются по нулевому младшему биту (бит с номером 1) в третьем октете. Остальные биты этого октета используются для управления. Форматы пакетов данных показаны на Рисунок 4.3.2.9.
Информационное поле начинается с четвертого байта (при расширенной нумерации с пятого) и может иметь длину 16-4096, хотя в рекомендациях стандарта x.25 оговорена величина 128 октетов. Если принимающая сторона не способна принять пакет данной длины, связь должна быть переустановлена, а стороне-инициатору соединения послано сообщение об ошибке. Каждому пакету данные присваивается порядковый номер N(S), значение которого при установлении соединения равно нулю.
Рисунок 4.3.2.7. Формат пакета запроса повторного пуска (слева) и повторной установки
Рисунок 4.3.2.15. Формат пакетов подтверждение регистрации
Получив список доступных услуг из сообщения подтверждение регистрации, может поменять параметры некоторых из них. Если значение какого-либо параметра услуги (опции) не разрешено, DCE должно сообщить разрешенное значение параметра и максимальное и или минимальное разрешенное значение (в зависимости от того больше или меньше допустимого оказалось значение запрошенного параметра).
Неисправность сети может привести к тому, что та или иная согласованная ранее услуга станет недоступной. В этом случае DCE должно инициировать процедуру повторного пуска, чтобы уведомить DTE о случившихся изменениях.
Кроме процедуры регистрации к необязательным процедурам относятся услуги для замкнутой группы, идентификация пользователей сети, группа поиска, ускоренный обмен, переадресация вызовов, выбор транзитной сети, сообщения о модифицированном адресе, согласование параметров управления потоком и некоторые другие.
Повторная передача пакетов согласуется на определенное время и может использоваться во всех логических каналах DTE-DCE. DTE запрашивает повторную передачу одного или нескольких пакетов данные путем посылки сообщения отказ reject), которое определяет логический канал и порядковый номер пакета N(R). Получив пакет отказ DCE, DTE начинает повторную передачу пакетов. Формат пакетов отказ для случаев нумерации по модулю 8 и 128 показан на Рисунок 4.3.2.16.
Рисунок 4.3.2.6. Формат пакетов подтверждения завершения
Для инициализации обмена информацией (первичного или повторного), а также для прерывания виртуальной связи и возвращения виртуальных каналов в исходное состояние используются запросы повторного пуска (и подтверждение повторного пуска). DTE может выдать запрос повторного пуска (к DCE) в любой момент времени, переводя логический канал в исходное состояние. DCE в ответ должно послать сообщение подтверждение повторного пуска. Инициатором повторного пуска может быть и dce, для этого оно посылает сообщение индикация повторного пуска. DTE в результате устанавливает логический канал в исходное состояние и посылает dce сообщение подтверждение повторного пуска. Форматы пакетов, несущих эти сообщения показаны на Рисунок 4.3.2.6 и 4.3.2.7. Эти пакеты не имеют полей группового номера логического канала и LCN (см. Рисунок 4.3.2.7 и .8). Процедура повторной установки во многом аналогична повторному пуску и используются всякий раз при выявлении сбоя, чтобы вернуть виртуальную связь или постоянный виртуальный канал в исходное состояние.
Рисунок 4.3.2.12. Формат пакетов прерывание и подтверждение прерывания
Идентификатор формата равен 0x1 для нумерации по модулю 8 и 0x2 при нумерации по модулю 128. Передав сообщение прерывание, DTE должно ожидать получение пакета подтверждение прерывания. Максимальный размер поля данные пользователя в пакете прерывание не должен превышать 32 байт.
Иногда в сетях для сообщения об ошибке используется пакет “диагностика”. Этот пакет посылается DCE, адресуется DTE и несет информацию о неустранимых на уровне пакетов ошибках. Пакет диагностика посылается лишь один раз сразу после выявления ошибки. Подтверждения его получения не требуется. Формат пакета показан на Рисунок 4.3.2.13.
Рисунок 4.3.2.14. Формат пакетов запрос регистрации
Рисунок 4.3.2.5. Формат пакетов запроса завершения
Коды причины завершения связи приведены в таблице 4.3.2.1. Однобайтовое поле диагностический код позволяет уточнить причину. В таблице 4.3.2.4 приведены коды причины повторного пуска. Формат пакетов подтверждения завершения представлен на Рисунок 4.3.2.6.
Рисунок 4.4.5.9 Формат полей адресного сегмента
Адресный сегмент используется в пакетах типа first и join. Протокол XTP использует параметрическую схему адресации, возможны несколько форматов адресов отправителя и места назначения. Поле Alen определяет полную длину адресного сегмента. Поле Adomain представляет собой адресный демультиплексор, допуская работу с несколькими адресными доменами. Поле Adomain используется в частности для того, чтобы обеспечить совместимость с протоколами UDP и TCP (для TCP Adomain=6, для UDP 17, а для XTP 36). Поле Aformat идентифицирует адресный синтаксис в соответствии с таблицей 4.4.5.5.
Рисунок 4.4.5.10 Формат полей сегмента данных
Размер поля Data имеет произвольное значение, первые 8 байт (поле Btag) представляют собой специальную метку (если бит опций заголовка btag=1). При Btag=0 метка отсутствует. Интерпретация поля Btag осуществляется исключительно прикладной программой и для XTP его значение безразлично.
Формат полей диагностического сегмента показан на Рисунок 4.4.5.11. Этот сегмент используется пакетами типа DIAG для информирования протокольной или прикладной программы о случаях ошибок. Поле Code определяет тип и категорию ошибки, вызвавшей отправку пакета типа DIAG. Поле val позволяет уточнить причину ошибки. Поле message является опционным и может иметь произвольную длину. Обычно это поле содержит текстовую интерпретацию полей Code и VAL.
Рисунок 4.4.5.4. Формат поля команда
btag=1 |
указывает на то, что первые восемь байт сегмента данных стали полем btag (beginning tag field - начальная метка). Служит для постановки меток для прикладных программ. BTAG имеет смысл только для информационных пакетов и должен быть обнулен для всех остальных. |
dreq=1 |
SEQ данного пакета. |
edge |
при получении пакета значение этого бита сравнивается с со значение бита edge предыдущего пакета. Если их величины отличаются, посылается управляющий пакет. Отправитель может изменять значения этого бита, чтобы вызвать присылку управляющего пакета, не привлекая механизма SREQ или DREQ. |
end=1 |
указывает на прекращение использования данного контекста, устанавливается в последнем пакете, завершающем диалог, а также при ликвидации ассоциации. |
EOM |
служит для обозначения границ сообщения в потоке данных. Если EOM=1, то этот пакет завершает сообщение. Управляющие пакеты не должны иметь EOM=1. Этот бит устанавливается прикладной, а не протокольной программой. |
fastnak |
показывает, что получатель должен обеспечивать быстрое отрицательное подтверждение (если необходимо). Этот бит устанавливается отправителем лишь тогда, когда протокольный уровень ниже XTP не меняет часто порядок пакетов. |
multi=1 |
указывает на использование режима мульткастинга. Значение этого бита должно быть идентичным для всех пакетов в период жизни ассоциации. |
noerr=1 |
информирует получателя о том, что отправитель не будет повторно присылать пакеты и рекомендует получателю отключить контроль ошибок. |
Nocheck=1 |
указывает на то, что контрольная сумма вычислена только для полей заголовка, в противном случае - для всего пакета. |
Noflow=1 |
указывает на то, что отправитель не следит за ограничениями потока данных (например, игнорирует значение alloc). |
RES=1 |
позволяет режим резервирования. Устанавливая его, отправитель обращает внимание получателя на то, что значение alloc, присланные получателем в контрольных пакетах, должно соответствовать реальному объему свободного буферного пространства. |
Sort=1 |
указывает, что значение кода в поле sort заголовка должно интерпретироваться и использоваться для приоритетного отбора пакетов. |
sreq=1 |
указывает получателю, что он должен немедленно послать контрольный пакет. Бит SREQ устанавливается отправителем в соответствии со своей политикой подтверждений или в случае возникновения ошибок. |
Wclose и Rclose |
используются при диалоге отсоединения. wclose-бит указывает на то, что не будет больше записей в выходной информационный поток. rclose-бит служит для того, чтобы сообщить, что все биты, занесенные во входной поток, доставлены. |
XTP-передатчик контролирует все биты поля опции для каждого пакета. Некоторые дополнительные данные о битах субполя опции можно найти в таблице 4.4.5.2.
Рисунок 4.4.5.8 Формат поля traffic
Поле maxdata несет в себе код максимального размера информационного сегмента, который отправитель может послать за время жизни ассоциации. Поля inrate и inburst представляют собой параметры, определяющие входной поток данных. Поля outrate и outburst являются параметрами, задающими выходной поток данных.
Информационный сегмент включает в себя пользовательскую и другую протокольную и диагностическую информацию. XTP-пакеты, содержащие информационный сегмент, называются информационными пакетами. К их числу относятся пакеты типа data, first, join и diag. Информационные пакеты могут включать в себя сегмент данных, адресный сегмент, спецификатор трафика и диагностический сегмент. Формат полей адресного сегмента показан на Рисунок 4.4.5.9.
Рисунок 4.4.5.6 Формат сегмента управления ошибками
Сегмент управления ошибками используется в пакетах Ecntl. Поле Nspan определяет число Spans в Ecntl-пакете. Так как пакет Ecntl посылается только в случае потери информации, поле Nspan несет в себе код не меньше 1. Поле Spans содержит в себе Nspan пар чисел, которые характеризуют интервалы номеров байт, переданных корректно. Речь здесь идет о данных, имеющих номера больше того, который указан в поле RSEQ. На основании этих данных можно вычислить, какая именно информация потеряна.
Формат сегмента управления трафиком показан на Рисунок 4.4.5.7. Помимо полей общего управляющего сегмента здесь присутствуют поля RSVD и XKEY, а также спецификация трафика. Поле RSVD является резервным и должно содержать нуль. Поле XKEY является обязательной принадлежностью всех Tcntl-пакетов, величина этого поля должна равняться значению ключа для контекста, посылающего пакет (бит RTN=1). Спецификация трафика используется в пакетах типа first и Tcnnl. Пакет first предлагает параметры режима обмена, а Tcntl несет в себе отклик на это предложение.
Рисунок 4.4.5.7 Формат сегмента управления трафиком
Поле tlen определяет длину спецификации трафика, включая 4-байтовый дескриптор (tlen і ). Поле service используется для задания типа транспортного сервиса на фазе установления режима обмена. Коды доступных видов сервиса представлены в таблице 4.4.5.4. Эта информация передается в пакете типа first.
Рисунок 4.4.5.11 Форматы полей диагностического сегмента
Рисунок 4.5.5.2 Форматы сообщений об ошибках
Некоторые X-запросы не нуждаются в откликах (например, связанные с перемещением манипулятора мышь), такие сообщения могут группироваться и посылаться единым потоком (batch stream). Такой подход позволяет пользователю выдать Xlib-запрос и перейти к выполнению других операций, в то время как схема запрос-отклик требует ожидания.
Сообщение типа событие посылается прикладной программе только в случае, если она запрашивала такого рода информацию.
X-Windows приложения должны установить канал связи между собой, прежде чем они смогут обмениваться сообщениями. Приложение для того, чтобы установить связь с рабочей станцией использует запрос XOpenDisplay из библиотеки Xlib. Xlib формирует структуру дисплея, которая содержит необходимую информацию, определяющую режим обмена прикладная программа <-> рабочая станция. После того как связь установлена прикладная программа и рабочая станция готовы к работе. Если была нажата клавиша мышки (событие - ButtonPress), а не известно, в каком из окон находится ее указатель, прикладная программа выдает в Xlib запрос XQueryPointer. Положение указателя будет прислано в отклике на этот запрос.
Данный протокол, строго говоря, не входит в набор TCP/IP хотя, как было сказано, он описан в RFC. Но мне представлялось важным дать в руки операторов сетей информацию, которая позволит им лучше понимать, что "гуляет" по их кабельным сегментам.
4.5.5 Протокол X-Windows
Система X-windows была разработана в Массачусетском Технологическом институте (сотрудники этого института внесли существенный вклад и в разработку всего комплекса TCP/IP-протоколов) в качестве многооконного программного интерфейса для ЭВМ с побитовым отображением графической информации. Система предполагала отображение результатов работы нескольких программ одновременно. Сегодня это одна из наиболее популярных систем. Для каждой программы выделялась отдельная область на экране - "окно". С самого начала система предназначалась для работы в различных сетях (TCP, IPX/SPX и т.д.). Система может управлять окнами как на локальной, так и удаленной ЭВМ. Для управления окнами используются специальные сообщения. Для обмена этими сообщениями разработан x-windows протокол. Система X-windows состоит из двух частей Xlib и X-сервера (RFC-1198).
4.4.5 Протокол XTP
Транспортный протокол XTP (xpress transport protocol; http://www.ca.sandia.gov/xtp/) разработан в 1992 году, является протоколом нового поколения и имеет целью преодолеть недостатки такого популярного протокола как TCP (медленный старт, неэффективная работа при возникновении потерь пакетов). В XTP функции обеспечения надежной передачи данных и управления разделены, протокол допускает управление пропускной способностью канала и успешно справляется с перегрузкой канала. Принципиальной особенностью XTP является независимость от числа участников информационного обмена (обычный режим эквивалентен мультикастингу, по этой причине XTP может использоваться и как мультикастинг-протокол) и возможность работы с MAC, IP или AAL5. Протокол призван в перспективе заменить TCP, UDP, Appletalk и IPX. Мультикастинг в XTP в отличии от других протоколов может гарантировать доставку информации, что может оказаться важным при многоточечном управлении или в некоторых распределенных базах данных.
При передаче больших массивов информации последовательные пакеты нумеруются. В случае потери принимающая сторона посылает отправителю список не доставленных пакетов (TCP повторяет пересылку всех пакетов, начиная с потерянного). Именно алгоритм селективной ретрансмиссии и позволяет повысить эффективность использования канала. Длина пакетов XTP кратна 64 бит. Совокупность информации, описывающей состояние XTP, называется контекстом. Каждый контекст управляет как входящим, так и исходящим потоками данных. Два активных контекста и поток данных образуют ассоциацию. В исходном состоянии контекст оконечной системы пассивен и находится в состоянии ожидания. Первый передаваемый пакет содержит полную адресную информацию. После получения первого пакета контекст становится активным. С этого момента ассоциация сформирована и обмен может происходить в обоих направлениях. Каждый последующий пакет несет в себе ключевой код, определяющий его принадлежность к данному контексту. При завершении передачи устанавливаются соответствующие биты опций, связь разрывается, а контексты возвращаются в пассивное состояние. Все виды XTP-пакетов имеют один и тот же формат заголовков. Управление контекстом осуществляется с помощью флагов, содержащихся в заголовке. Всего предусмотрено 15 флагов.
На Рисунок 4.4.5.1 показана зависимость пропускной способности канала для сети ATM при использовании транспортных протоколов TCP и XTP, в обоих случая использовался в качестве базового протокол IP. Измерения производились для приложений типа FTP. Из рисунка видно, что даже 1% потерянных или поврежденных пакетов понижает пропускную способность на 30% при работе с протоколом TCP. XTP требует только три пакета, чтобы сформировать виртуальный канал, в то время как XTP требует для тех же целей семь пакетов. Благодаря своей простоте XTP может легко подменить любой транспортный протокол в любом существующем телекоммуникационном приложении. Протокол предоставляет некоторые услуги недоступные в других протоколах, что оказывается особенно привлекательным для приложений мультимедиа.
4.3.2 Протоколы сетей X.25
В 1976 году был принят стандарт X.25, который стал основой всемирной системы PSPDN (Packet-Switched Public Data Networks), базирующейся на 7-уровневой модели ISO OSI. Стандарт X.25 был усовершенствован в 1984. X.25 - протокол (ISO 8208:1989; RFC-887, -1381, -1382, -1461, -1598, -1613), который определяет синхронный интерфейс между терминальным оборудованием (DTE - Data Terminal Equipment) и оборудованием передачи данных (DCE - Data Communication Equipment) для терминалов, работающих в пакетном режиме. По существу это протокол связи оборудования с сетью. Главный недостаток протокола X.25 - большие задержки отклика (типовое значение 0.6 сек). Терминалом может служить ЭВМ или любая другая система, удовлетворяющая требованиям X.25. Соединение DTE - DTE осуществляется через DCE. В протоколе X.25 DCE и DTE используют статистическое мультиплексирование с делением по времени. Одновременно могут реализовываться несколько обменных процессов. Схема взаимодействия DTE и DCE выглядит как:
DTE - - DCE - DCE - - DTE
Асинхронный старт-стопный терминал подключается к сети коммутации пакетов через пакетный адаптер данных ПАД (PAD - packet assemble/disassemble) и отвечает рекомендациям X.3, X.28 и X.29. Один ПАД обеспечивает интерфейс для 8, 16 или 24 асинхронных терминалов. Пакет данных состоит обычно из 128 байтов, которые передаются по адресу, содержащемуся в пакете. Но длина пакета может лежать в пределах 64-4096 байтов. Размер пакета также как и величина окна (число пакетов, принимаемых без подтверждения) определяются на фазе установления канала. Прежде чем пакет будет передан, необходимо установить связь между исходными ЭВМ/ПАД и адресуемыми ЭВМ/ПАД. Существуют два вида соединений: коммутируемый виртуальный канал (SVC) и постоянный виртуальный канал (PVC). Предусмотрены две процедуры доступа к каналу:
Процедура доступа к каналу (LAP - link access procedure), в основе которой лежат симметричные операции режима асинхронного ответа (ARM - asynchronous response mode) протокола HDLC.
Рис 4.3.2.10. Формат пакетов готовность к приему и неготовность к приему при нумерации по модулю 8.
Рис 4.3.2.11. Формат пакетов готовность к приему и неготовность к приему при нумерации по модулю 128.
Код N(R) на входе DCE должен лежать в пределах между N(R) последнего принятого пакета и N(S) следующего пакета, который должен быть послан из DCE к DTE. При невыполнении этого условия связь будет переустановлена и передача повторена. Пакеты готовность к приему используются для сообщения о готовности принять пакеты, с номерами, начиная с номера N(R), приведенного в пакете. Пакеты неготовность к приему служат для того, чтобы сообщить о временной неспособности принять данные. При поступлении этого сообщения отправитель должен прервать передачу до получения сообщения готовность к приему. DTE может передавать данные удаленному DTE, не следуя правилам управления потоком данных. Для реализации такой возможности предусмотрена операция прерывания. Эта операция не влияет на передачу данных и управление. Формат пакета прерывание и подтверждение прерывания показан на Рисунок 4.3.2.12.
Рисунок 4.5.5.1. Схема взаимодействия различных частей X-windows
xlib является интерфейсом для любого прикладного процесса и обычно представляет собой программу, написанную на C. Xlib отвечает за обмен информацией между сервером и терминалом пользователя (X-клиент). Под приложениями здесь подразумеваются независимые процессы. Для каждого терминала инсталлируется отдельный X-сервер. Один X-сервер может обслуживать несколько клиентов. X-сервер осуществляет отображение на экране всех окон, в то время как функция клиентов - управление окнами. Для управления окнами используются структуры типа стеков.
Прикладная программа-клиент и сервер взаимодействуют друг с другом через системный протокол X-windows (RFC-1013 и RFC-1198). При этом используется четыре вида сообщений:
Запрос: инструкция, направляемая серверу рабочей станции, например, нарисовать окружность.
Отклик: направляется от сервера в ответ на запрос.
Событие: используется сервером, чтобы сообщить прикладной программе об изменениях, которые могут повлиять на ее работу (например, нажатие клавиши на терминале или мышке, запрос из сети и т.д.).
Ошибка: посылается сервером прикладной программе, если что не так (переполнение памяти, неправильно заданные параметры делают выполнение задания невозможным и пр.).
Форматы таких сообщений представлены на Рисунок 4.5.5.2.
Рисунок 4.4.5.3 Структура поля ключ
32-разрядное поле команды содержит в себе субполе опции. Названия различных бит этого поля показаны на Рисунок 4.4.5.4.
Адрес сервера при доступе через Telnet (login) | Адрес X.25 (login) | Страна |
jethro.ucc.su.oz.au (fred) | Австралия | |
elem4.vub.ac.be (dua) | 222100611 | Бельгия |
x500.denet.dk (de) | Дания | |
login.dkuug.dk (ds) | Дания | |
nic.funet.fi (dua) | Финляндия | |
20800603053201 (login: dua, password: ucom.x) 26245050230303 |
Франция Франция Германия |
|
x500.ieunet.ie (de) | 272432590024 | Ирландия |
dir.ulcc.ac.uk (dua) | UK | |
ashe.cs.tcd.ie (de) | Ирландия | |
jolly.nis.garr.it (de or fred) | 22225010083212 | Италия |
zoek.nic.surfnet.nl (zoek) | Нидерланды | |
elc1.mat.torun.edu.pl (de или dish) | Польша | |
chico.rediris.es (directorio) | 2142160234013 | Испания |
hypatia.umdc.umu.se (de) | 240374810306 | Швеция |
nic.switch.ch (dua) | 22847971014540 | Швейцария |
paradise.ulcc.ac.uk (dua) | 23421920014853 | Англия |
?<тема> | Выдает справочную информацию по данной теме (help). |
^C | (Ctrl-C) команда прерывания (например, поиска). |
* | Выдает все записи для выбранного поля. Этот же символ представляет собой подстановку для строк по умолчанию. В том качестве * может появиться где угодно, например, smit* и *smit*. |
- | Заменяет значение по умолчанию на пустую строку. |
Таблица 4.3.2.8. Коды параметров PAD
Код параметра |
Описание |
1 |
Обращение к ПАД с использованием управляющего символа |
2 |
Эхо-контроль |
3 |
Выбор сигнала посылки пакета |
4 |
Выбор продолжительности ожидания для таймера |
5 |
Управление вспомогательным устройством |
6 |
Подавление управляющих сигналов ПАД |
7 |
Выбор действий ПАД при получении сигнала разрыва |
8 |
Прерывание вывода |
9 |
Кодовая последовательность после сигнала "возврат каретки" |
10 |
Перенос строки, длина которой ограничена размерами экрана дисплея |
11 |
Скорость работы старт-стопного терминала |
12 |
Управление потоком ПАД |
13 |
Вставка символа "перевод строки" после символа "возврат каретки" |
14 |
Заполнение после сигнала "перевод строки" |
15 |
Редактирование |
16 |
Стирание символа |
17 |
Стирание строки |
18 |
Вывод строки на экран дисплея |
19 |
Редактирование сигналов управления ПАД |
20 |
Маскирование эхо-контроля |
21 |
Обработка символов контроля на четность |
22 |
Ожидание страницы |
При работе TCP/IP сети через каналы X.25 и наоборот следует учитывать некоторые отличия кодов предпочтения в полях TOS.
Таблица 4.4.5.4. Коды поля тип сервиса (service)
Код типа сервиса |
Описание |
0x00 |
Не специфицировано |
0x01 |
Традиционная передача дейтограмм без подтверждения |
0x02 |
Передача дейтограмм с подтверждением |
0x03 |
Реализация транзакций |
0x04 |
Традиционная передача потока данных с гарантированной доставкой |
0x05 |
Передача потока данных в мультикастинг-режиме без подтверждения |
0x06 |
Мультикастинг режим передачи потока данных с гарантированной доставкой |
Поле tformat определяет формат поля traffic. Код tformat=0 используется тогда, когда не нужно ни какой спецификации трафика, в 4-байтовое поле traffic в этом случае записываются нули. В противном случае используется код tformat=0x01. Формат поля traffic для этого арианта показан на Рисунок 4.4.5.8.
Таблица 4.3.2.4. Коды причин повторного пуска
Код причины |
Причина повторного пуска |
0x1 |
Ошибка локальной процедуры |
0x3 |
Перегрузка сети |
0x7 |
Сеть работоспособна |
Таблица 4.3.2.5. Коды причин повторной установки
Причина повторной установки |
Код причины |
Установка по инициативе dte |
0x0 |
Повреждение постоянного виртуального канала |
0x1 |
Ошибка при исполнении удаленной процедуры |
0x3 |
Ошибка при выполнении локальной процедуры |
0x5 |
Перегрузка сети |
0x7 |
Удаленное DTE работоспособно (постоянный виртуальный канал) |
0x9 |
Сеть работоспособна (постоянный виртуальный канал) |
0xf |
Несовместимость партнеров |
0x11 |
Партнер - получатель этого запроса должен прислать сообщение подтверждение повторной установки (Рисунок 4.3.2.8). При этом возможны потери информации (также как и в случае повторного пуска), так как некоторые пакеты, находящиеся в сети в момент реализации запроса повторной установки или повторного пуска будут потеряны.
Инициатором посылки запроса повторной установки может быть dte и dce. Коды причин повторной установки представлены в таблице 4.3.2.5.
Таблица 4.3.2.1. Коды причины ошибки
Код причины |
Причина |
0x0 |
Удаленный сброс (remote cleared) |
0x1 |
Адресат занят (number busy) |
0x3 |
Нелегальный запрос (invalid facility request) |
0x5 |
Перегрузка сети (network congestion) |
0x9 |
Нарушен порядок (out of order) |
0x11 |
Ошибка при выполнении удаленной процедуры |
0xb |
Доступ блокирован (access barred) |
0xd |
Не доступно, нет в наличии (not obtainable) |
0x21 |
Несовместимость у адресата (ошибка при выполнении удаленной процедуры) |
0x23 |
Ошибка при выполнении местной процедуры |
0x29 |
Сигнал быстрой выборки не воспринят (fast select not accepted) |
Один физический канал связи X.25 может поддерживать несколько коммутируемых виртуальных каналов. Постоянный виртуальный канал подобен выделенной линии - обмен возможен в любой момент. X.25 определяет первые три уровня соединения открытых систем (см. Рисунок 4.3.2.2).
- физический x.21 (X.21bis)
- канальный (HDLC - high data link communication - протокол высокого уровня управления каналом). Этот уровень и последующие реализуются программным образом.
- сетевой (пакетный)
X.21 - универсальный интерфейс между оконечным оборудованием (DTE) и аппаратурой передачи данных (DCE) для синхронного режима работы в сетях общего пользования. X.21bis – тоже, но для модемов, удовлетворяющих рекомендациям серии V. Для канального уровня используется подмножество протокола HDLC (являющегося развитием стандарта SDLC IBM), обеспечивающее возможность автоматической повторной передачи в случае возникновения ошибок в линии.
Таблица 4.4.5.3. Коды типов пакетов XTP (Pformat)
Формат пакета |
Код типа |
Описание |
data |
0 |
Информационный пакет пользователя |
cntl |
1 |
Пакет управления состоянием |
first |
2 |
Исходный пакет ассоциации (содержит адресный сегмент) |
ecntl |
3 |
Пакет управления (ошибка) |
tcntl |
5 |
Пакет управления трафиком |
join |
6 |
Мультикастинг-пакет включения в группу |
diag |
8 |
Диагностический пакет |
Младший байт поля команда содержит субполе типа пакета
(ptype). Биты 0-4 этого субполя содержат код формата пакета (Pformat, см. таблицу 4.4.5.3). Биты 5-7 определяют версию протокола (ver). Для XTP 4.0 код версии равен 001.
Поле DLEN содержит число байт в массиве данных пакета, следующем непосредственно за заголовком. Так как информационные пакеты с нулевым объемом данных запрещены, код dlen не может быть равен нулю.
Поле Check содержит контрольную сумму. Если бит nochek=1, то в поле записана контрольная сумма только заголовка, в противном случае - всего пакета.
Поле приоритет (sort) предназначено для задания приоритета пересылаемой информации. Это поле интерпретируется лишь в случае, если бит sort=1. При sort=0 поле приоритет должно быть обнулено. Контексты с приоритетным трафиком посылают пакеты с sort=1 и с определенным кодом в поле приоритет. Бесприоритетные контексты шлют пакеты с sort=0 и нулевым полем приоритета. На приемной стороне информация доставляется в соответствии с кодом приоритета. Поле приоритет характеризуется беззнаковым 16-разрядным числом. Код приоритет, равный нулю, указывает на самый низкий приоритет, чем больше этот код, тем выше приоритет. XTP обслуживает активные контексты в соответствии с присвоенными им приоритетами. Высокоприоритетная информация посылается раньше низкоприоритетной. Аналогичный порядок обслуживания работает и на принимающей стороне.
32-битовое поле синхронизация (Sync) служит для синхронизации диалога. Каждый контекст хранит код последнего посланного значения Sync в переменной Saved_sync. Когда пакет послан с Sreq=1, значение переменной Saved_sync увеличивается на единицу и этот код заносится в поле Sync отправляемого пакета.
Получатель запоминает последний полученный код Sync в контекстной переменной Rcvd_sync. Значение этой переменной записывается в поле эхо каждого посылаемого управляющего пакета. Когда управляющий пакет получен, код поля sync сравнивается со значением Rcvd_sync. Если sync і Rcvd_sync, то управляющий пакет обрабатывается нормально. В противном случае управляющий пакет содержит информацию, которая старее полученной с предыдущими пакетами, и обрабатываться не должен.
Поле номер по прядку (SEQ) характеризуется 64-разрядным числом без знака и представляет собой порядковый номер байта в передаваемом потоке. Для первого пакета (first) поле SEQ характеризует объем буферов для потока откликов, а для пакетов Join это поле содержит дентификатор получателя (ключ контекста). Join-пакет отклик на запрос содержит в поле SEQ порядковый номер байта для текущей ассоциации. Диапазон значений поля номер по порядку для информационных пакетов начинается с SEQ и простирается вплоть до SEQ+ DLEN - 1. Для DIAG пакетов поле SEQ содержит код SEQ входного пакета, который вызвал ошибку. Если посылка пакета DIAG вызвана не входным пакетом, код SEQ должен быть равен нулю.
Вслед за заголовком обычно следует его расширение (сегмент), формат которого зависит от типа пакета. Используются управляющие и информационные сегменты.
Управляющие сегменты несут в себе информацию о состоянии контекста, его приславшего. XTP пакеты, содержащие управляющие сегменты называются контрольными пакетами. Управляющие сегменты содержат пакеты типа Cntl, Ecntl и Tcntl. Управляющий сегмент Cntl-пакета несет в себе информацию об управлении обменом. Ecntl-пакеты включают в себя сегменты управления ошибками, а Tcntl-пакеты - сегменты управления трафиком. Формат управляющего сегмента показан на Рисунок 4.4.5.5.
Таблица 4.3.2.7 Коды типов сообщений
Код типа сообщения |
Команда PAD |
Отправитель |
0001 |
Команда разъединения |
ЭВМ |
0010 |
Установление параметров |
ЭВМ |
0011 |
Индикация разъединения |
ЭВМ или PAD |
0100 |
Чтение параметров |
ЭВМ |
0101 |
Ошибка |
PAD |
0110 |
Установка и чтение параметров |
ЭВМ |
В поле управляющего сообщения PAD может быть включено любое число параметров, которое допускает максимальный размер пакета. Каждый параметр имеет свой код-номер, за которым в пакете следует значение параметра (таблица 4.3.2.8):
Таблица 4.3.2.9 содержит соответствие этих кодов для этих сетей.
Таблица 4.3.2.9. Соответствие кодов TOS для сетей TCP/IP и X.25
IP |
X.25 |
IP |
X.25 |
000 |
00 |
001 |
01 |
010 |
10 |
011 - 111 |
11 |
Для реализации работы сетей ISDN по существующим каналам сети X.25 разработан протокол X.31. X.31 организует канал пользователь-маршрутизатор X.25 (через посредство ISDN) и регламентирует работу ISDN с пакетами X.25.
Для решения первой задачи используется сообщение SETUP. Вторая задача решается, когда канал до маршрутизатора сформирован. На этом этапе привлекается набор протоколов X.25, возможно применение протокола X.75 (ISO 8208), который является расширением X.25 для межсетевых связей.
Таблица 4.4.5.1. Сравнительные характеристики протоколов TCP, UDPи XTP
Название протокола |
Пропускная способность в Мбит/с |
TCP |
89-93 |
UDP |
93-94 |
XTP |
112-115 |
Из таблицы видно, что в нормальных условиях протокол XTP гарантирует пропускную способность на 25% выше, чем TCP или UDP.
Все поля в XTP-пакетах передаются так, что наиболее значимый байт передается первым (порядок байт - “big-endian”). Формат заголовка XTP-пакета показан на Рисунок 4.4.5.2. Поле ключ определяет принадлежность пакета к тому или иному контексту, поле команда (CMD) задает процедуру обработки пакета. Поле длина (DLEN) определяет объем данных в пакете, а поле номер по порядку (SEQ) представляет собой порядковый номер пакета в последовательности. Поля контрольная сумма и синхронизация используются для проверки корректности доставки. Старший бит поля ключ (RTN - возврат, Рисунок 4.4.5.3) зарезервирован в качестве флага, указывающего на контекст передающей (=0) или принимающей стороны (принимающая сторона, посылая пакеты, ставит RTN=1). Код поля ключ должен быть уникальным. Для обеспечения этого остальная часть поля делится на два субполя: индекс и инстанция (распределение бит между ними зависит от реализации и реальных потребностей). Индекс служит для выбора контекста, а инстанция подтверждает корректность кода индекс. Так при получении пакета сначала по индексу определяется контекст, а затем производится сравнение кодов инстанции в пакете и в таблице контекстов.
Таблица 4.3.2.6. Управление фрагментацией и сборкой пакетов с помощью битов M и D
Бит m |
Бит d |
Выполнение объединения с последующим пакетом (реализуется сетью) |
0 |
0 |
Нет |
0 |
1 |
Нет |
1 |
0 |
Да |
1 |
1 |
Нет |
Таким образом, при фрагментации исходного сообщения все пакеты кроме последнего должны иметь бит m=1. Нумерация пакетов по модулю 8 означает, что им последовательно присваиваются номера 0,1,2,3,4,5,6,7,0,1,2 и т.д. Аналогично при нумерации по модулю 128 - 0,1,2,...127,0,1,2,3 и т.д. Форма нумерации пакетов определяет также размер “окна”, то есть число пакетов, которые могут быть переданы, не дожидаюсь подтверждения получения. По умолчанию размер окна равен 2, другие значения могут быть согласованы на фазе установления соединения. Принцип использования окон при передаче пакетов более подробно описан в разделе “3.6.2
Протокол TCP”.
Для управления процессом передачи данных используются сообщения “готов к приему” и “не готов к приему”. Форматы этих пакетов показаны на Рисунок 4.3.2.10 и 4.3.2.11.
Таблица 4.4.5.2. Значения битов субполя опции
Бит поля опции |
Маска |
Возможность изменения |
Использование |
Описание |
0x800000 |
Не используется, должно обнуляться | |||
nocheck |
0x400000 |
по-пакетно |
Раз на контекст | Отключение контрольной суммы |
edge |
0x200000 |
по-пакетно |
Пограничный запрос статуса |
|
noerr |
0x100000 |
по-пакетно |
Раз на контекст | Отключение контроля ошибок |
multi |
0x080000 |
Раз на ассоциацию | Режим мультикастинга |
|
res |
0x040000 |
по-пакетно |
Раз на контекст | Режим резервирования |
Sort |
0x020000 |
по-пакетно |
Раз на контекст | Допускает сортировку |
Noflow |
0x010000 |
по-пакетно |
Раз на контекст | Отключает управление потоком данных |
Fastnack |
0x008000 |
по-пакетно |
Раз на контекст | Разрешает жесткий контроль ошибок |
SRREQ |
0x004000 |
по-пакетно |
Запрос статуса |
|
DREQ |
0x002000 |
по-пакетно |
Запрос доставки статуса |
|
Rclose |
0x001000 |
по-пакетно |
Получатель отключен |
|
Wclose |
0x000800 |
по-пакетно |
Отправитель отключен |
|
EOM |
0x000400 |
по-пакетно |
Конец сообщения |
|
End |
0x000200 |
один раз |
Конец контекста или ассоциации |
|
Btag |
0x000100 |
по-пакетно |
Начало метки поля данных |
“По-пакетно” означает, что бит может изменяться от пакета к пакету. “Раз на ассоциацию” означает, что все контексты ассоциации должны иметь этот бит идентичным. “Один раз” означает, что бит может быть установлен один раз за время жизни контекста
Таблица 4.3.2.2. Значения кодов идентификатора общего формата (GFI)
Тип пакета |
Модуль нумерации |
Номера битов |
|||
|
|
8 |
7 |
6 |
5 |
Установка соединения |
8 |
0 |
x |
0 |
1 |
Разрыв соединения, управление потоком, повторный пуск, регистрация, диагностика |
8 |
0 |
0 |
0 |
1 |
Данные |
8 |
x |
x |
0 |
1 |
Расширение |
- |
0 |
0 |
1 |
1 |
x - бит может принимать значения 0 или 1.
Допустимые значения кодов в поле тип пакета приведены в таблице 4.3.2.3.
Таблица 4.4.5.5. Значения кодов поля Aformat
Код поля aformat |
Синтаксис адреса |
0x00 |
Нулевой адрес |
0x01 |
ip-адрес |
0x02 |
ISO адрес протокольного сетевого уровня для передачи без установления связи |
0x03 |
Адрес сети Ксерокс |
0x04 |
IPX-адрес |
0x05 |
Локальный адрес |
0x06 |
IP-адрес версии 6 |
Поле адрес несет в себе адреса отправителя и получателя пакетов, форматы которых заданы полем Aformat.
Формат полей сегмента данных показан на Рисунок 4.4.5.10. Эти сегменты предназначены для применения на прикладных пользовательских уровнях и программами поддержки протокола XTP не интерпретируются. Сегмент включается в пакеты типа first и data.
Таблица 4.3.2.3. Значения кодов тип пакета
Тип пакета |
Октет 3 |
Биты |
8 7 6 5 4 3 2 1 |
Запрос |
0 0 0 0 1 0 1 1 |
Запрос принят |
0 0 0 0 1 1 1 1 |
Запрос завершения |
0 0 0 1 0 0 1 1 |
Подтверждение завершения |
0 0 0 1 0 1 1 1 |
Данные |
x x x x x x x 0 |
Прерывание |
0 0 1 0 0 0 1 1 |
Подтверждение прерывания |
0 0 1 0 0 1 1 1 |
Готовность к приему по модулю 8 (RR) |
x x x 0 0 0 0 1 |
Готовность к приему по модулю 128 (RR) |
0 0 0 0 0 0 0 1 |
Неготовность к приему по модулю 8 (RNR) |
x x x 0 0 1 0 1 |
Неготовность к приему по модулю 128 (RNR) |
0 0 0 0 0 1 0 1 |
Запрос повторной установки |
0 0 0 1 1 0 1 1 |
Подтверждение повторной установки |
0 0 0 1 1 1 1 1 |
Запрос повторного пуска |
1 1 1 1 1 0 1 1 |
Подтверждение повторного пуска |
1 1 1 1 1 1 1 1 |
Диагностика |
1 1 1 1 0 0 0 1 |
Запрос регистрации |
1 1 1 1 0 0 1 1 |
Подтверждение регистрации |
1 1 1 1 0 1 1 1 |
x - отмечет разряды, которые могут принимать значения 0 или 1.
Четырехбитовые поля длина адреса отправителя и длина адреса получателя характеризуют длины последующих полей переменной длины. Длина выражается в полуоктетах. Далее следуют соответствующие адреса. В каждом полуоктете записывается десятичная цифра адреса, при необходимости поле адреса дополняется нулями до целого числа октетов. Для пакетов установления связи кадры имеют формат, показанный на Рисунок 4.3.2.4.
Рисунок 4.3.2.2. Три уровня X.25
Формат кадра для протокола HDLC показан на Рисунок 4.3.2.3 (байты передаются, начиная с младшего бита):
Рисунок 4.3.2.1. Возможная топология сети X.25
Сетевой адрес пользователя состоит из 12 десятичных цифр. 1-4 - идентификатор сети передачи данных (3 - страна, 4 - сеть); 5-12 - национальный номер (5-7 местная область, 8-12 - местный номер). Международная система адресации для систем передачи данных общего пользователя описана в рекомендациях X.121 международного комитета по телефонии и телеграфии. Каждое подключение к сети коммутации пакетов имеет свой национальный номер. Протокол X.25 не определяет технику маршрутизации пакетов по сети. Для целей управления в сетях X.25 используется протокол snmp и база данных MIB (как и в сетях Интернет). Три базовых уровня протокола X.25 и схема потоков информации отображены на Рисунок 4.3.2.2.
Для подключения по виртуальному каналу ЭВМ/ПАД посылается пакет (call request), содержащий сетевой адрес пользователя. После подтверждения соединения и передачи/приема данных виртуальное соединение может быть разорвано путем передачи пакета (clear request), инициатором в этом случае выступает удаленная ЭВМ. При невозможности установить связь clear request посылается сетью. Такой пакет содержит два информационных октета. Первый содержит код причины, второй является диагностическим кодом. Ниже в таблице 4.3.2.1 приведены коды причин ошибки.
Рисунок 4.4.5.1. Зависимость пропускной способности канала при использовании протоколов TCP и XTP (
www.mentat.com/xtp.xtp.html и xtpdata.html XTP 95-20, Xpress Transport Protocol Specification (XTP revision 4.0), 1995, XTP Forum, Santa Barbara, CA 93108 USA )
При 5% потерях пакетов XTP обеспечивает в 6 раз большую пропускную способность, чем TCP. В таблице 4.4.5.1 приведены сравнительные результаты измерения пропускной способности канала ATM (155 Мбит/с) при использовании протоколов TCP, UDP и XTP (использовались пакеты длиной 8190 байт).
2.6.1 Алгоритм Зива-Лемпеля
Большинство алгоритмов сжатия базируется на последовательной схеме сжатия Лемпеля-Зива (Lempel-Ziv, 1977). Этот алгоритм используется, в частности, стандартной процедурой UNIX Compress. Методики со статистическим моделированием могут обеспечить лучшее сжатие, но они заметно медленнее. Но существует алгоритм, который совмещает в себе лучшие из черт названных выше. Этот алгоритм не предусматривает последовательной обработки входных данных, а обрабатывает текст по-блочно. Здесь используется обратимое преобразование блока данных к виду, который позволяет эффективно сжать данные с помощью простых алгоритмов. Преобразование имеет целью сгруппировать символы так, чтобы вероятность появления последовательностей идентичных символов значительно возросла. Такой текст может быть легко сжат посредством локально-адаптивных алгоритмов в сочетании с кодировкой Хафмана и арифметической кодировкой.
Последовательность S, содержащая N символов ({S(0),… S(N-1)}), подвергается N циклическим сдвигам (вращениям), лексикографической сортировке, а последний символ при каждом вращении извлекается. Из этих символов формируется строка L, где i-ый символ является последним символом i-го вращения. Кроме строки L создается индекс I исходной строки S в упорядоченном списке вращений. Существует эффективный алгоритм восстановления исходной последовательности символов S на основе строки L и индекса I. Процедура сортировки объединяет результаты вращений с идентичными начальными символами. Предполагается, что символы в S соответствуют алфавиту, содержащему K символов.
Для пояснения работы алгоритма возьмем последовательность S= “abraca” (N=6), алфавит X = {‘a’,’b’,’c’,’r’}.
1. Формируем матрицу из N*N элементов, чьи строки представляют собой результаты циклического сдвига (вращений) исходной последовательности S, отсортированных лексикографически. По крайней мере одна из строк M содержит исходную последовательность S. Пусть I является индексом строки S. В приведенном примере индекс I=1, а матрица M имеет вид:
Номер строки | |
0 | aabrac |
1 | abraca |
2 | acaabr |
3 | bracaa |
4 | caabra |
5 | racaab |
Строка | M | M’ |
0 | aabrac | caabra |
1 | abraca | aabraс |
2 | acaabr | racaab |
3 | bracaa | abraca |
4 | caabra | acaabr |
5 | racaab | bracaa |