Формат кадра X

Рисунок 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.

Формат общего управляющего сегмента пакета XTP

Рисунок 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.

Формат поля traffic

Рисунок 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.3.2.9. Форматы пакетов данные. Слева - по модулю 8, справа - по модулю 128

Q -бит определяет тип кадра-пакета, Q=1 - управляющий пакет для PAD, Q=0 - информационный пакет. Бит D используется для запроса специального отклика на пакет со стороны удаленного конца виртуального канала. Бит M указывает на то, что данный пакет является частью более крупного пакета, который должен быть воссоздан позднее.

Индекс S (send) соответствует отправке, а индекс R - приему (receive). Если используется нумерация пакетов по модулю 8, N(S) занимает биты 2-4 включительно, при нумерации по модулю 128 для этого отводятся биты 2-8. Нумерация пакетов позволяет выявить потерю пакетов или изменение порядка их доставки. N(R) является номером пакета с принимающей стороны. Бит подтверждения доставки D (идентификатор формата) служит для указания необходимости сообщения о доставке данных получателем. Если D=1, то DTE обязано подтвердить доставку. Обязательность процедуры подтверждения определяется уже на фазе установления связи (сообщение запрос на установление связи принят). Если какой-либо узел по пути пересылки пакета не поддерживает процедуру подтверждения доставки, он пошлет сообщение запрос завершения (причина - несовместимость у адресата) и связь должна быть сформирована заново с учетом необходимости подтверждения во всех узлах-участниках. Размер поля данные в пакете может быть разным для разных узлов, участвующих в обмене. По этой причине число полученных пакетов может оказаться больше (или меньше) числа посланных. Для таких случаев предусмотрен флаг m (дополнительные данные). Возможность фрагментации и последующей сборки пакетов определяется управляющими битами M и D (см. таблицу 4.3.2.6).

и передающей сторон должно иметь

Рисунок 4.3.2.16. Форматы пакетов типа отказ для нумерации по модулю 8 (слева) и 128

Программное обеспечение принимающей и передающей сторон должно иметь переменные состояния V(R) и V(S), содержащие, соответственно, номера пакетов, которые предстоит получить и послать (см. описание процедуры HDLC). После посылки очередного пакета с N(S) значение V(S) увеличивается на 1. Принимающая сторона сравнивает V(R) с N(S) полученного пакета, при совпадении укладывает N(S) в поле N(R) пакета-отклика и инкрементирует V(R). Отправитель при получении пакета проверяет равенство переменной V(S) и кода поля N(R) в пакете-отклике. Если при получении пакета выясняется, что V(R) не равно N(S), V(R) не инкрементируется, а принимающая сторона отправляет отклик с N(R)=V(R). Отправитель, получив этот отклик и обнаружив, что V(S) не равно N(R), узнает о происшедшем сбое. Номер логического канала (LCN) служит для того, чтобы определить соответствие межу DTE и местным DCE. LCN вместе с полем группового номера логического канала занимают 12 бит, что позволяет иметь до 4095 логических каналов (LCN=0 зарезервировано для использования DCE).

4 бита первого байта управляющего пакета содержат в себе код типа сообщения (таблица 4.3.2.7):

Форматы полей диагностического сегмента

Рисунок 4.4.5.11 Форматы полей диагностического сегмента

Форматы сообщений об ошибках

Рисунок 4.5.5.2 Форматы сообщений об ошибках

Некоторые X-запросы не нуждаются в откликах (например, связанные с перемещением манипулятора мышь), такие сообщения могут группироваться и посылаться единым потоком (batch stream). Такой подход позволяет пользователю выдать Xlib-запрос и перейти к выполнению других операций, в то время как схема запрос-отклик требует ожидания.

Сообщение типа событие посылается прикладной программе только в случае, если она запрашивала такого рода информацию.

X-Windows приложения должны установить канал связи между собой, прежде чем они смогут обмениваться сообщениями. Приложение для того, чтобы установить связь с рабочей станцией использует запрос XOpenDisplay из библиотеки Xlib. Xlib формирует структуру дисплея, которая содержит необходимую информацию, определяющую режим обмена прикладная программа <-> рабочая станция. После того как связь установлена прикладная программа и рабочая станция готовы к работе. Если была нажата клавиша мышки (событие - ButtonPress), а не известно, в каком из окон находится ее указатель, прикладная программа выдает в Xlib запрос XQueryPointer. Положение указателя будет прислано в отклике на этот запрос.

Данный протокол, строго говоря, не входит в набор TCP/IP хотя, как было сказано, он описан в RFC. Но мне представлялось важным дать в руки операторов сетей информацию, которая позволит им лучше понимать, что "гуляет" по их кабельным сегментам.

Протокол X-Windows

4.5.5 Протокол X-Windows

Система X-windows была разработана в Массачусетском Технологическом институте (сотрудники этого института внесли существенный вклад и в разработку всего комплекса TCP/IP-протоколов) в качестве многооконного программного интерфейса для ЭВМ с побитовым отображением графической информации. Система предполагала отображение результатов работы нескольких программ одновременно. Сегодня это одна из наиболее популярных систем. Для каждой программы выделялась отдельная область на экране - "окно". С самого начала система предназначалась для работы в различных сетях (TCP, IPX/SPX и т.д.). Система может управлять окнами как на локальной, так и удаленной ЭВМ. Для управления окнами используются специальные сообщения. Для обмена этими сообщениями разработан x-windows протокол. Система X-windows состоит из двух частей Xlib и X-сервера (RFC-1198).

Протокол XTP

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 может легко подменить любой транспортный протокол в любом существующем телекоммуникационном приложении. Протокол предоставляет некоторые услуги недоступные в других протоколах, что оказывается особенно привлекательным для приложений мультимедиа.

Протоколы сетей X

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.

Балансная процедура доступа к каналу (LAPB - link access procedure balanced) на основе асинхронного балансного режима (ABM - asynchronous balanced mode) протокола HDLC. Сетевой уровень реализуется с использованием 14 различных типов пакетов.

Виртуальный канал описывается в общем формате пакета, как "логический канал". Логический канал имеет идентификатор, состоящий из 12 бит. Этот идентификатор обычно состоит из номера группы (4 бита) и номера логического канала (8 бит). В группе может быть до 256 логических каналов (за исключением группы 0, которая может иметь только 255 логических каналов). Возможное число групп - 16, поэтому теоретически возможное число виртуальных каналов для каждого соединения x.25 равно 4095 (16x256-1).

Постоянный виртуальный канал (PVC - permanent virtual circuit) является аналогом выделенного канала.

Коммутируемый виртуальный канал (SVC - switched virtual circuit - напоминает традиционный телефонный вызов) реализует обмен данными. Имеются три типа коммутируемых виртуальных каналов, работающие в дуплексном режиме, но отличающиеся направлением устанавливаемых соединений: входящий SVC, двунаправленный SVC и выходящий SVC. Адресат каждого пакета распознается с помощью идентификатора логического канала (LCI) или номера логического канала (LCN).

SVC используются только на время соединения и становятся доступными для повторного использования после разъединения. Все типы пакетов, за исключением пакетов запроса повторного пуска, содержат идентификатор логического канала. Пакет запрос соединения в SVC является единственным типом пакетов, которые содержат адреса в соответствии с рекомендацией X.121.

Для установки выходящего соединения через svc ЭВМ выбирает логический канал с наибольшим номером в группе и посылает пакет запрос соединения, содержащий выбранный номер группы канала, адрес получателя (в соответствии с рекомендацией X.121) и в отдельных случаях свой собственный адрес. При установлении входящего соединения центр коммутации пакетов (ЦКП) выбирает свободный логический канал с наименьшим номером в группе каналов порта адресуемой ЭВМ и помещает этот логический номер группы и канала в пакет входящий запрос соединения.

После того как соединение через svc установлено, ЭВМ направляют свои пакеты, используя номера своих логических групп/каналов, а ЦПК в сети осуществляет транспортировку пакетов и преобразование номеров логических групп/каналов. Как только установленное по svc логическое соединение разъединяется, номера логических групп/каналов на обоих концах соединения освобождаются и становятся доступными для повторного использования. Соответствие между ЦКП/портом, выделенным для терминального оборудования, адресами (согласно рекомендациям x.121) и номерами логических каналов известно в сети только ЦКП.

Выбор ЭВМ свободного канала с наибольшим номером при каждом выходящем соединении и выбор в ЦКП свободного канала с наименьшим номером для каждого входящего позволяют избежать конфликтов. С этой же целью используются две логические группы: одна только для входящих соединений, а другая только для выходящих. Перед подключением к сети пользователь должен определить, сколько pvc и svc требуется на каждую точку физического интерфейса x.25. Асинхронные терминалы подключаются к сети коммутации пакетов через встроенные или удаленные пакетные адаптеры данных (ПАД).

Встроенный ПАД обычно располагается вместе с ЦКП в его стойке. В этом случае каждый асинхронный терминал, расположенный в удаленном месте, подключается к своему встроенному ПАД через отдельный канал связи (протокол Х.28). В альтернативном случае удаленный ПАД (небольшое отдельное устройство) может быть расположен в удаленном месте и подключается к своему ЦКП через канал связи (X.25). С помощью удаленного ПАД к ЦКП подключается 8-16 асинхронных терминалов.

Встроенный ПАД может быть совместно использован несколькими терминалами, расположенными в различных местах, в то время как удаленный ПАД обслуживает терминалы, расположенные обычно в одном месте. Существует еще один аспект размещения ПАД, связанный с помехами в каналах связи и использованием протоколов. Удаленный ПАД подключается к ЦКП на канальном уровне в соответствии с рекомендацией X.25.

В качестве протокола канала данных в рекомендации X.25 реализуется подмножество HDLC, обеспечивающее автоматическую повторную передачу данных в случае их искажения при возникновении помех в линии. Асинхронный терминал использует для диалога с групповым ПАД процедуры, описанные в рекомендации X.28, в которых не предусмотрена возможность повторной передачи в случае ошибки. Поэтому канал между синхронным терминалом и групповым ПАД не защищен от возникновения ошибок данных в результате линейных помех. Процедуры ПАД определены в рекомендациях МККТТ (см. приложение 10.1).

Рекомендация X.3: "Пакетный адаптер данных (ПАД) в сети передачи данных общего пользования".

Рекомендация X.28: "Интерфейс между терминальным оборудованием и оборудованием передачи данных (DCE) для старт-стопного оконечного оборудования, осуществляющего доступ к пакетному адаптеру данных в сетях общего пользования".

Рекомендация X.29: "Процедуры обмена управляющей информацией между терминальным оборудованием пакетного типа и пакетным адаптером (ПАД)".

Основные функции ПАД соответствуют рекомендациям X.3:

сборка символов (полученных от асинхронных терминалов) в пакеты;

разборка полей данных в пакетах и вывод данных на асинхронные терминалы;

управление процедурами установления виртуального соединения и разъединения, сброса и прерывания;

обеспечение механизма продвижения пакетов при наличии соответствующих условий, таких как заполнение пакета, получение символа (сигнала) на передачу пакета, истечение времени ожидания;

передача символов, включающих стартстопные сигналы и биты проверки на четность, по требованию подключенного асинхронного терминала;

обнаружение сигнала разрыв соединения от асинхронного терминала;

редактирование последовательностей команд ПАД.

В постоянном запоминающем устройстве ПАД хранятся параметры. Эти параметры могут быть установлены либо асинхронным терминалом, подключенным к ПАД, либо любой ЭВМ в сети, которая удовлетворяет условиям рекомендации X.29.

В рекомендации X. 29 МККТТ эти параметры названы управляющей информацией. Поэтому необходимо квалифицировать данные, проходящие между ЭВМ и ПАД, либо как управляющую информацию (сообщения ПАД), либо как собственно данные от асинхронного терминала.

Сеть X.25 предоставляет пользователю старт-стопного терминала средства, позволяющие выбрать параметры ПАД с заранее определенными значениями. Пользователь посылает в ПАД команду выбора профайла, которая включает идентификатор профайла. Этим определяется один из нескольких стандартных профайлов, хранящихся в ПАД.

Идентификатор профайла и параметр 11 ПАД (скорость терминала) включаются в "поле данных пользователя" пакетов типа запрос соединения, посылаемых ПАД. ЭВМ (ПАД) использует это поле, извлекая из него информацию о терминале, пославшем запрос.

Пакетный терминал является интеллектуальным устройством (например, ЭВМ, или внешним ПАД’ом), которое обеспечивает синхронный обмен с сетью на скорости 2400, 4800, 9600 бит/c или 48 Кбит/с, используя трехуровневый протокол X.25. Возможная схема подключения терминальных устройств к сети X.25 показана на Рисунок 4.3.2.1.

Из рисунка 4.3.2.1 видно, что подключение ЭВМ и другого терминального оборудования возможно как к встроенному, так и удаленному ПАД (протокол X.28), а также непосредственно к ЦКП (протокол X.25, X.29). Связи с удаленными объектами осуществляются через соответствующие модемы (на рисунке не показаны).

Для международного соединения необходимо указать код страны из трех цифр, а также набрать одну цифру 9 перед сетевым адресом пользователя. Таким образом, всего требуется не более 15 цифровых символов. Для установления коммутируемого соединения оператор вначале вручную набирает номер ПАД и ждет подтверждения соединения с телефонным узлом общего пользования. Как только соединение установлено, оператор набирает 12-символьный код "сетевого идентификатора пользователя". ПАД обеспечивает операцию эхо-контроля, которая позволяет оператору терминала визуально проверять данные, посылаемые в ПАД.Наиболее серьезным недостатком встроенного ПАД является отсутствие какого-либо линейного протокола, предусматривающего устранение ошибок в данных, посылаемых от ПАД к терминалу. В удаленном ПАД предусмотрена процедура восстановления ошибочных данных, однако он подключается к сети как "пакетный терминал".

Формат пакетов готовность к приему и неготовность к приему при нумерации по модулю

Рис 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.

Схема взаимодействия различных частей X-windows

Рисунок 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.

Адрес сервера при доступе через

Таблица 4.5.8.3.1

Адрес сервера при доступе через 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	Англия

Локальный клиент-серверы (Directory User Agent - DUA) имеются в общедоступном и коммерческом вариантах. Для получения более полного списка DUA, их описаний и места расположения рекомендуется обратиться к RFC 1292 / FYI 11 - "A Catalog of Available X.500 Implementations".
Существует три варианта интерфейсов для доступа к X.500 в интерактивном режиме:
строчные (de, dish, fred);
управляемые через меню (sd, ранее известные как widget)
базирующиеся на X-Windows (Xdi, Xlookup (или xlu), pod)
Сервер de (directory enquiries) рекомендуется в силу своей простоты для начинающих пользователей. Выход из de по команде q. Приведем перечень команд X.500.

?<тема>	Выдает справочную информацию по данной теме (help).
^C	(Ctrl-C) команда прерывания (например, поиска).
*	Выдает все записи для выбранного поля. Этот же символ представляет собой подстановку для строк по умолчанию. В том качестве * может появиться где угодно, например, smit* и smit.
-	Заменяет значение по умолчанию на пустую строку.

После выдачи команды de пользователь должен заполнить четыре поля запроса (поиск не зависит от строчных или заглавных букв):

Коды параметров PAD

Таблица 4.3.2.8. Коды параметров PAD

Код параметра

Описание

Обращение к ПАД с использованием управляющего символа

Эхо-контроль

Выбор сигнала посылки пакета

Выбор продолжительности ожидания для таймера

Управление вспомогательным устройством

Подавление управляющих сигналов ПАД

Выбор действий ПАД при получении сигнала разрыва

Прерывание вывода

Кодовая последовательность после сигнала "возврат каретки"

Перенос строки, длина которой ограничена размерами экрана дисплея

Скорость работы старт-стопного терминала

Управление потоком ПАД

Вставка символа "перевод строки" после символа "возврат каретки"

Заполнение после сигнала "перевод строки"

Редактирование

Стирание символа

Стирание строки

Вывод строки на экран дисплея

Редактирование сигналов управления ПАД

Маскирование эхо-контроля

Обработка символов контроля на четность

Ожидание страницы

При работе TCP/IP сети через каналы X.25 и наоборот следует учитывать некоторые отличия кодов предпочтения в полях TOS.

Коды поля тип сервиса (service)

Таблица 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), обеспечивающее возможность автоматической повторной передачи в случае возникновения ошибок в линии.

Коды типов пакетов XTP (Pformat)

Таблица 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 содержит соответствие этих кодов для этих сетей.

Соответствие кодов TOS для сетей TCP/IP и X

Таблица 4.3.2.9. Соответствие кодов TOS для сетей TCP/IP и X.25

X.25

000

001

010

011 - 111

Для реализации работы сетей ISDN по существующим каналам сети X.25 разработан протокол X.31. X.31 организует канал пользователь-маршрутизатор X.25 (через посредство ISDN) и регламентирует работу ISDN с пакетами X.25.

Для решения первой задачи используется сообщение SETUP. Вторая задача решается, когда канал до маршрутизатора сформирован. На этом этапе привлекается набор протоколов X.25, возможно применение протокола X.75 (ISO 8208), который является расширением X.25 для межсетевых связей.

Сравнительные характеристики протоколов TCP, UDPи XTP

Таблица 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). Код поля ключ должен быть уникальным. Для обеспечения этого остальная часть поля делится на два субполя: индекс и инстанция (распределение бит между ними зависит от реализации и реальных потребностей). Индекс служит для выбора контекста, а инстанция подтверждает корректность кода индекс. Так при получении пакета сначала по индексу определяется контекст, а затем производится сравнение кодов инстанции в пакете и в таблице контекстов.

Управление фрагментацией и сборкой пакетов с помощью битов M и D

Таблица 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	по-пакетно		Начало метки поля данных

“По-пакетно” означает, что бит может изменяться от пакета к пакету. “Раз на ассоциацию” означает, что все контексты ассоциации должны иметь этот бит идентичным. “Один раз” означает, что бит может быть установлен один раз за время жизни контекста

Значения кодов идентификатора общего формата (GFI)

Таблица 4.3.2.2. Значения кодов идентификатора общего формата (GFI)

Тип пакета	Модуль нумерации	Номера битов
		8	7	6	5
Установка соединения	8 128	0 0	x x	0 1	1 0
Разрыв соединения, управление потоком, повторный пуск, регистрация, диагностика	8 128	0 0	0 0	0 1	1 0
Данные	8 128	x x	x x	0 1	1 0
Расширение	-	0	0	1	1

x - бит может принимать значения 0 или 1.

Допустимые значения кодов в поле тип пакета приведены в таблице 4.3.2.3.

Значения кодов поля Aformat

Таблица 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.

Три уровня X

Рисунок 4.3.2.2. Три уровня X.25

Формат кадра для протокола HDLC показан на Рисунок 4.3.2.3 (байты передаются, начиная с младшего бита):

Возможная топология сети X

Рисунок 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 приведены коды причин ошибки.

500 представляет собой протокол OSI

4.5.8.3 X500

X. 500 представляет собой протокол OSI для распределенных каталогов (индексов-оглавлений), разработанный CCITT. X.500 - протокол для работы с каталогами. X.500 предлагает распределенный каталог пользователей сети Интернет. X.500 поддерживает систему просмотра, а также добавления, модификации и удаления объектов в базе данных о людях (почтовый адрес, номер телефона, электронный адрес и пр.). Основным полем при поиске является фамилия, название организации, отдела, страны. Треугольные скобки служат для выделения имени параметра, а вертикальная черта - для указания значения параметра.

Каждая секция каталога содержит часть глобальной базы данных и является доступной через сервер (именуемый Directory System Agent - DSA). Каждая база данных поддерживается локально. Для пользователя же доступна вся база данных. Хотя информация, доступная через X.500, относится к людям и организациям, данная база пригодна для хранения и другой информации, например, о ресурсах сети, приложениях или оборудовании. Каждый вход в базу (объект хранения, запись) в X.500 описывает один объект (человека, конкретный ресурс сети, или организацию) и носит название Distinguished Name (неповторимый идентификатор). Это имя включает в себя следующие поля: фамилия, имя, организация, e-mail для людей. Информация в каталоге X.500 (Directory Information Base - DIB) организована иерархически и носит название информационное дерево каталога (Directory Information Tree - DIT). На верхнем уровне - корневая запись (the World), затем следует уровень страны, уровень организации и, наконец, человека (ресурса и т.д.).

X.500 доступна через локальный сервер, интерактивно через telnet или через электронную почту (или X.25). Возможен доступ и с помощью WWW или GOPHER.

Зависимость пропускной способности

Рисунок 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

2. Пусть строка L представляет собой последнюю колонку матрицы M с символами L[0],…,L[N-1] (соответствуют M[0,N-1],…,M[N-1,N-1]). Формируем строку последних символов вращений. Окончательный результат характеризуется (L,I). В данном примере L=’caraab’, I =1.

Процедура декомпрессии использует L и I. Целью этой процедуры является получение исходной последовательности из N символов (S).

1. Сначала вычисляем первую колонку матрицы M (F). Это делается путем сортировки символов строки L. Каждая колонка исходной матрицы M представляет собой перестановки исходной последовательности S. Таким образом, первая колонка F и L являются перестановками S. Так как строки в M упорядочены, размещение символов в F также упорядочено. F=’aaabcr’.

2. Рассматриваем ряды матрицы M, которые начинаются с заданного символа ch. Строки матрицы М упорядочены лексикографически, поэтому строки, начинающиеся с ch упорядочены аналогичным образом. Определим матрицу M’, которая получается из строк матрицы M путем циклического сдвига на один символ вправо. Для каждого i=0,…, N-1 и каждого j=0,…,N-1,

M’[i,j] = m[i,(j-1) mod N]

В рассмотренном примере M и M’ имеют вид:

Строка	M	M’
0	aabrac	caabra
1	abraca	aabraс
2	acaabr	racaab
3	bracaa	abraca
4	caabra	acaabr
5	racaab	bracaa

Подобно M каждая строка M’ является вращением S, и для каждой строки M существует соответствующая строка M’. M’ получена из M так, что строки M’ упорядочены лексикографически, начиная со второго символа. Таким образом, если мы рассмотрим только те строки M’, которые начинаются с заданного символа ch, они должны следовать упорядоченным образом с учетом второго символа. Следовательно, для любого заданного символа ch, строки M, которые начинаются с ch, появляются в том же порядке что и в M’, начинающиеся с ch. В нашем примере это видно на примере строк, начинающихся с ‘a’. Строки ‘aabrac’, ‘abraca’ и ‘acaabr’ имеют номера 0, 1 и 2 в M и 1, 3, 4 в M’.

Используя F и L, первые колонки M и M’ мы вычислим вектор Т, который указывает на соответствие между строками двух матриц, с учетом того, что для каждого j = 0,…,N-1 строки j M’ соответствуют строкам T[j] M.

Если L[j] является к-ым появлением ch в L, тогда T[j]=1, где F[i] является к-ым появлением ch в F. Заметьте, что Т представляет соответствие один в один между элементами F и элементами L, а F[T[j]] = L[j]. В нашем примере T равно: (4 0 5 1 2 3).

3. Теперь для каждого i = 0,…, N-1 символы L[i] и F[i] являются соответственно последними и первыми символами строки i матрицы M. Так как каждая строка является вращением S, символ L[i] является циклическим предшественником символа F[i] в S. Из Т мы имеем F[T[j]] = L[j]. Подставляя i =T[j], мы получаем символ L[T(j)], который циклически предшествует символу L[j] в S.

Индекс I указывает на строку М, где записана строка S. Таким образом, последний символ S равен L[I]. Мы используем вектор T для получения предшественников каждого символа: для каждого i = 0,…,N-1 S[N-1-i] = L[Ti[I]], где T0[x] =x, а Ti+1[x] = T[Ti[x]. Эта процедура позволяет восстановить первоначальную последовательность символов S (‘abraca’).

Последовательность Ti[I] для i =0,…,N-1 не обязательно является перестановкой чисел 0,…,N-1. Если исходная последовательность S является формой Zp для некоторой подстановки Z и для некоторого p>1, тогда последовательность Ti[I] для i = 0,…,N-1 будет также формой Z’p для некоторой субпоследовательности Z’. Таким образом, если S = ‘cancan’, Z = ‘can’ и p=2, последовательность Ti[I] для i = 0,…,N-1 будет [2,4,0,2,4,0].

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

Возьмем в качестве примера букву “t” в слове ‘the’ и предположим, что исходная последовательность содержит много таких слов. Когда список вращений упорядочен, все вращения, начинающиеся с ‘he’, будут взаимно упорядочены. Один отрезок строки L будет содержать непропорционально большое число ‘t’, перемешанных с другими символами, которые могут предшествовать ‘he’, такими как пробел, ‘s’, ‘T’ и ‘S’.

Аналогичные аргументы могут быть использованы для всех символов всех слов, таким образом, любая область строки L будет содержать большое число некоторых символов. В результате вероятность того, что символ ‘ch’ встретится в данной точке L, весьма велика, если ch встречается вблизи этой точки L, и мала в противоположном случае. Это свойство способствует эффективной работе локально адаптивных алгоритмов сжатия, где кодируется относительное положение идентичных символов. В случае применения к строке L, такой кодировщик будет выдавать малые числа, которые могут способствовать эффективной работе последующего кодирования, например, посредством алгоритма Хафмана.

Ссылки

J.Ziv and A.Lempel. A universal algorithm for sequential data compression. IEEE Transactions on Information Theory. Vol. IT-23, N.3, May 1977, pp. 337-343.

J.Ziv and A.Lempel. Compression of individual sequences via variable rate coding. IEEE Transactions on Information Theory. Vol. IT-24. N.5, September 1978, pp. 530-535.

M.Burrows and D.J.Wheeler. A block-sorting Lossless Data Compression Algorithm. Digital Systems Research Center. SRC report 124. May 10, 1994.

J.L.Bently, D.D.Sleator, R.E.Tarjan, and V.K.Wei. A locally adaptive data compression algorithm. Communications of the ACM, Vol. 29, No. 4, April 1986, pp. 320-330

http://www.ics.uci.edu/~dan/pubs/DataCompression.html (Saleem Bhatti)

http://www.speednet/~spenser/ted/DataCompression.html

http://www.iicm.edu/jucs_1_8/differencial_ziv_lempel_text/html/paper.html