Формат описания типа канала

Рисунок 4.2.11.2. 9 Формат описания типа канала с LS=1



Если бит V=1 (virtual), маршрутизатор является оконечной точкой активного виртуального канала. Если бит E (external) равен 1, маршрутизатор является пограничным для автономной системы. Бит B=1 (border) указывает на то, что маршрутизатор является пограничным для данной области. Поле тип может принимать значения, приведенные в таблице 4.2.11.2.5.

Формат описания внешних маршрутов

Рисунок 4.2.11.2.13 Формат описания внешних маршрутов

Сетевая маска характеризует место назначения рекламируемого маршрута. Так для сети класса A маска может иметь вид 0xFF000000. Последующий набор полей повторяется для каждого вида TOS. Поля для TOS=0 заполняются всегда, и это описание является первым. Бит E характеризует внешнюю метрику. Если E=0, то она может непосредственно (без преобразования) сравниваться с метриками других каналов. При E=1 метрика считается больше любой метрики. Поле адрес пересылки указывает на место, куда будут пересылаться данные, адресованные рекламируемым маршрутом. Если адрес пересылки равен 0.0.0.0, данные посылаются пограничному маршрутизатору автономной системы - источнику данного сообщения. Метка внешнего маршрута - 32-битовое число, присваиваемое каждому внешнему маршруту. Эта метка самим протоколом OSPF не используется и предназначена для информирования других автономных систем при работе внешних протоколов маршрутизации. Маршрутная таблица OSPF содержит в себе:

IP-адрес места назначения и маску;

тип места назначения (сеть, граничный маршрутизатор и т.д.);

тип функции (возможен набор маршрутизаторов для каждой из функций TOS);

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

тип пути (характеризует путь как внутренний, межобластной или внешний, ведущий к AS);

цена маршрута до цели;

очередной маршрутизатор, куда следует послать дейтограмму;

объявляющий маршрутизатор (используется для межобластных обменов и для связей автономных систем друг с другом).

Преимущества OSPF:

Для каждого адреса может быть несколько маршрутных таблиц, по одной на каждый вид IP-операции (TOS).

Каждому интерфейсу присваивается безразмерная цена, учитывающая пропускную способность, время транспортировки сообщения. Для каждой IP-операции может быть присвоена своя цена (коэффициент качества).

При существовании эквивалентных маршрутов OSFP распределяет поток равномерно по этим маршрутам.

Поддерживается адресация субсетей (разные маски для разных маршрутов).

При связи точка-точка не требуется IP-адрес для каждого из концов. (Экономия адресов!)

Применение мультикастинга вместо широковещательных сообщений снижает загрузку не вовлеченных сегментов.

Недостатки:

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

OSPF является лишь внутренним протоколом.

Формат OSPF-сообщений о маршрутах

Рисунок 4.2.11.2.5 Формат OSPF-сообщений о маршрутах

Поля, начиная с тип канала, повторяются для каждого описания канала. Так как размер базы данных может быть велик, ее содержимое может пересылаться по частям. Для реализации этого используются биты I и М. Бит I устанавливается в 1 в стартовом сообщении, а бит M принимает единичное состояние для сообщения, которые являются продолжением. Бит S определяет то, кем послано сообщение (S=1 для сервера, S=0 для клиента, этот бит иногда имеет имя MS). Поле номер сообщения по порядку служит для контроля пропущенных блоков. Первое сообщение содержит в этом поле случайное целое число M, последующие M+1, M+2,...M+L. Поле тип канала может принимать следующие значения:

Формат ospf-сообщения, описывающего состояние канала

Рисунок 4.2.11.2.8 Формат ospf-сообщения, описывающего состояние канала

Поле возраст ls информации (Рисунок 4.2.11.2.8) определяет время в секундах с момента объявления состояния канала. Поле опции содержит значения типов сервиса (TOS), поддерживаемые маршрутизатором, рассылающим маршрутную информацию. Поле тип LS (тип состояния канала) может принимать значения, описанные выше в табл. 4.2.11.2.3. Следует обратить внимание, что код, содержащийся в этом поле, определяет формат сообщения. Поле длина задает размер сообщения в октетах, включая заголовок. В результате получается сообщение с форматом, показанным на Рисунок 4.2.11.2.9. Зарезервированный октет должен быть обнулен. Идентификатор связи определяет тип маршрутизатора, подключенного к каналу. Действительное значение этого поля зависит от поля тип. В свою очередь информация о канале также зависит от поля тип. Число tos определяет многообразие метрик, соответствующих видам сервиса, для данного канала. Последовательность описания метрик задается величиной кода TOS.

Формат ospf-запроса маршрутной информации

Рисунок 4.2.11.2.6 Формат ospf-запроса маршрутной информации

Три поля этого запроса повторяются согласно числу каналов, информация о которых запрашивается. Если список достаточно длинен, может потребоваться несколько запросов. Маршрутизаторы посылают широковещательные (или мультикастинговые) сообщения об изменении состояния своих непосредственных связей. Такое сообщение содержит список объявлений, имеющих формат (Рисунок 4.2.11.2.7):

Формат сообщений об адресатах в пределах автономной системы

Рисунок 4.2.11.2.12 Формат сообщений об адресатах в пределах автономной системы

Поля, следующие после заголовка, повторяются в соответствии с числом описываемых объектов. Рекламирование внешних маршрутов относится к пятому типу. Эта информация рассылается пограничными маршрутизаторами. Информация о каждом внешнем адресате, известном маршрутизатору, посылается независимо. Этот вид описания используется и для маршрутов по умолчанию, для которых идентификатор состояния канала устанавливается равным 0.0.0.0 (аналогичное значение принимает при этом и сетевая маска). Формат такого сообщения представлен на Рисунок 4.2.11.2.13.

Формат сообщения Hello в протоколе OSPF

Рисунок 4.2.11.2.4 Формат сообщения Hello в протоколе OSPF

Поле сетевая маска соответствует маске субсети данного интерфейса. Например, если интерфейс принадлежит сети класса B и третий байт служит для выделения нужной субсети, то сетевая маска будет иметь вид 0xFFFFFF00.

Поле время между Hello содержит значение времени в секундах, между сообщениями Hello. Поле опции характеризует возможности, которые предоставляет данный маршрутизатор. Поле приоритет характеризует уровень приоритета маршрутизатора (целое положительное число), используется при выборе резервного (backup) маршрутизатора. Если приоритет равен нулю, данный маршрутизатор никогда не будет использован в качестве резервного. Поле время отключения маршрутизатора определяет временной интервал в секундах, по истечении которого "молчащий" маршрутизатор считается вышедшим из строя. IP-адреса маршрутизаторов, записанные в последующих полях, указывают место, куда следует послать данное сообщение. Поля IP-адрес соседа k образуют список адресов соседних маршрутизаторов, откуда за последнее время были получены сообщения Hello.

Маршрутизаторы обмениваются сообщениями из баз данных OSPF, чтобы инициализировать, а в дальнейшем актуализовать свои базы данных, характеризующие топологию сети. Обмен происходит в режиме клиент-сервер. Клиент подтверждает получение каждого сообщения. Формат пересылки записей из базы данных представлен на Рисунок 4.2.11.2.5.

Формат сообщения о получении OSPF-пакета

Рисунок 4.2.11.2.10 Формат сообщения о получении OSPF-пакета

Рекламирование сетевых связей относится к типу 2. Сообщения посылаются для каждой транзитной сети в автономной системе. Транзитной считается сеть, которая имеет более одного маршрутизатора. Сообщение о сетевых связях должно содержать информацию обо всех маршрутизаторах, подключенных к сети, включая тот, который рассылает эту информацию. Расстояние от сети до любого подключенного маршрутизатора равно нулю для всех видов сервиса (TOS), поэтому поля TOS и метрики в этих сообщениях отсутствуют. Формат сообщения о транзитных сетевых связях показан на Рисунок 4.2.11.2.11.

Следует помнить, что приведенные ниже сообщения должны быть снабжены стандартными 24-октетными OSPF-заголовками (на Рисунок 4.2.11.2.11 отсутствует).

Формат сообщения о сетевых связях (тип LS=

Рисунок 4.2.11.2.11 Формат сообщения о сетевых связях (тип LS=2)

Сетевая маска относится к описываемой сети, а поле подключенный маршрутизатор содержит идентификатор маршрутизатора, работающего в сети. Информация об адресатах в пределах автономной системы передается LS-сообщениями типа 3 и 4. Тип 3 работает для IP-сетей. В этом случае в качестве идентификатора состояния канала используется IP-адрес сети. Если же адресатом является пограничный маршрутизатор данной AS, то используется LS-сообщение типа 4, а в поле идентификатор состояния канала записывается OSPF-идентификатор этого маршрутизатора. Во всех остальных отношениях сообщения 3 и 4 имеют идентичные форматы (Рисунок 4.2.11.2.12):

Формат заголовка сообщений для протокола маршрутизации ospf

Рисунок 4.2.11.2.3 Формат заголовка сообщений для протокола маршрутизации ospf

Поле версия определяет версию протокола (= 2). Поле тип идентифицирует функцию сообщения согласно таблице 4.2.11.2.2:

Иллюстрация работы алгоритма Дикстры

Рисунок 4.2.11.2.1 Иллюстрация работы алгоритма Дикстры

Ниже дается формальное описание алгоритма. Сначала вводим некоторые определения.

Пусть D(v) равно сумме весов связей для данного пути.

Пусть c(i,j) равно весу связи между узлами с номерами i и j.

Далее следует последовательность шагов, реализующих алгоритм.

Устанавливаем множество узлов N = {1}. Для каждого узла v не из множества n устанавливаем D(v)= c(1,v).

Для каждого шага находим узел w не из множества N, для которого D(w) минимально, и добавляем узел w в множество N.

Актуализируем D(v) для всех узлов не из множества N

D(v)=min{D(v), D(v)+c(w,v)}.

Повторяем шаги 2-4, пока все узлы не окажутся в множестве N.

Топология маршрутов для узла a приведена на нижней части Рисунок 4.2.11.2.1. В скобках записаны числа, характеризующие метрику отобранного маршрута согласно критерию пункта 3.

Мультиплексирование с делением по длине волны в оптическом волокне

Рисунок 3.2.8. Мультиплексирование с делением по длине волны в оптическом волокне

Оптоволоконные каналы

3.2 Оптоволоконные каналы

А.Г.Белл в 1880 году запатентовал фотофон – прибор для передачи голоса посредством светового сигнала с селеновым фотодетектором. Первые коммерческие телефонные системы были созданы лишь в 1977 году и работали со скоростью 44,7 Мбит/с. Одномодовые волоконные кабели начали производиться в 1983 году. В 1990 году Линн Моллинер (Bellcore) продемонстрировал передачу данных со скоростью 2,5Гбит/c на расстояние 7500 км (без промежуточных усилителей сигнала) В 1990 году в США суммарная протяженность оптических волокон составляла около 9000000 км. В 2000 году обшая длина оптоволокон только в США превысила 30 миллионов километров. Оптоволоконные линии связи работают в частотном диапазоне 1013 – 1016Гц, что на 6 порядков больше, чем в случае

радиочастотных каналов (это обеспечивает пропускную способность 50000 Гбит/c). Но земная атмосфера является плохой средой для распространения света. По этой причине только разработка кремниевых волокон с низким коэффициентом поглощения в инфракрасном диапазоне (< 0,2 дБ/км) сделало возможным широкое распространение оптических каналов связи. Укладывается ~1000км оптоволоконного кабеля в день. В настоящее время каналы обычно имеют пропускную способность ~1Гбит/c и это связано с ограниченным быстродействием оборудования, преобразующего оптический сигнал в электрический и обратно. В ближайшие годы следует ожидать увеличения быстродействия таких устройств в 100-1000 раз. Учитывая, что

df = (cdl)/l2, где с - скорость света, f - частота, а l - длина волны.

Для наиболее популярного диапазона l = 1,3m и dl = 0,17m мы имеем df = ~30ТГц.

В 2002 году компанией Zonu разработан фототрансивер (GBIC) на 1,25Гбит/c для передачи и приема данных по одному и тому же волокну при длине волны 1310 нм. Для одномодового волокна расстояние передачи может составлять до 10 км. При длине волны 1550 нм достижимо расстояние передачи в 40 км. Разрабатывается вариант для скоростей передачи 2,5Гбит/c

Оптоволоконное соединение гарантирует минимум шумов и высокую безопасность (практически почти невозможно сделать отвод).
Пластиковые волокна применимы при длинах соединений не более 100 метров и при ограниченном быстродействии (-10, что во многих случаях делает ненужным контроль целостности сообщений.

При построении сетей используются многожильные кабели (Рисунок 3.2.1; существуют и другие разновидности кабеля: например, двух- или четырехжильные, а также плоские). В верхней части рисунка [a] изображено отдельное оптоволокно, а в нижней [Б] сечение восьмижильного оптического кабеля. Свет (длина волны l

~ 1350 или 1500 нм) вводится в оптоволокно (диаметром dm) с помощью светоизлучающего диода или полупроводникового лазера. Центральное волокно покрывается слоем (клэдинг, 1А), коэффициент преломления которого меньше чем у центрального ядра (стрелками условно показан ход лучей света в волокне). Для обеспечения механической прочности извне волокно покрывается полимерным слоем (2А). Кабель может содержать много волокон, например 8 (1Б). В центре кабеля помещается стальной трос (3Б), который используется при прокладке кабеля. С внешней стороны кабель защищается (от крыс!) стальной оплеткой (2Б) и герметизируется эластичным полимерным покрытием.

Пример выделения областей при ospf маршрутизации в автономной системе (М – маршрутизаторы; c – сети)

Рисунок 4.2.11.2.2 Пример выделения областей при ospf маршрутизации в автономной системе (М – маршрутизаторы; c – сети).

На рис 4.2.11.2.2 (см. также Рисунок 4.2.11.2.1) приведен пример выделения областей маршрутизации при ospf-маршрутизации в пределах автономной системы. На Рисунок 4.2.11.2.2 маршрутизаторы М4 и М2 выполняют функция опорной сети для других областей. В выделенных областях может быть любое число маршрутизаторов. Более толстыми линиями выделены связи с другими автономными системами.

При передаче OSPF-пакетов фрагментация не желательна, но не запрещается. Для передачи статусной информации OSPF использует широковещательные сообщения Hello. Для повышения безопасности предусмотрена авторизация процедур. OSPF-протокол требует резервирования двух мультикастинг-адресов:

224.0.0.5	предназначен для обращения ко всем маршрутизаторам, поддерживающим этот протокол.
224.0.0.6	служит для обращения к специально выделенному маршрутизатору.

Любое сообщение ospf начинается с 24-октетного заголовка:

Протокол OSPF (алгоритм Дикстры)

4.4.11.2 Протокол OSPF (алгоритм Дикстры)

Протокол OSPF (Open Shortest Pass First, RFC-1245-48, RFC-1583-1587, алгоритмы предложены Дикстрой) является альтернативой RIP в качестве внутреннего протокола маршрутизации. OSPF представляет собой протокол состояния маршрута (в качестве метрики используется - коэффициент качества обслуживания). Каждый маршрутизатор обладает полной информацией о состоянии всех интерфейсов всех маршрутизаторов (переключателей) автономной системы. Протокол OSPF реализован в демоне маршрутизации gated, который поддерживает также RIP и внешний протокол маршрутизации BGP.

Автономная система может быть разделена на несколько областей, куда могут входить как отдельные ЭВМ, так и целые сети. В этом случае внутренние маршрутизаторы области могут и не иметь информации о топологии остальной части AS. Сеть обычно имеет выделенный (designated) маршрутизатор, который является источником маршрутной информации для остальных маршрутизаторов AS. Каждый маршрутизатор самостоятельно решает задачу оптимизации маршрутов. Если к месту назначения ведут два или более эквивалентных маршрута, информационный поток будет поделен между ними поровну. Переходные процессы в OSPF завершаются быстрее, чем в RIP. В процессе выбора оптимального маршрута анализируется ориентированный граф сети. Ниже описан алгоритм Дикстры по выбору оптимального пути. На иллюстративном Рисунок 4.2.11.2.1 приведена схема узлов (A-J) со значениями метрики для каждого из отрезков пути. Анализ графа начинается с узла A (Старт). Пути с наименьшим суммарным значением метрики считаются наилучшими. Именно они оказываются выбранными в результате рассмотрения графа (“кратчайшие пути“).

Разновидности оптических волокон, отличающиеся зависимостью коэффициента преломления от радиуса

Рисунок 3.2.2. Разновидности оптических волокон, отличающиеся зависимостью коэффициента преломления от радиуса

Буквой В помечен одномодовый вид волокна (понятие мода связано с характером распространения электромагнитных волн). Мода представляет собой одно из возможных решений уравнения Максвелла. В упрощенном виде можно считать, что мода – это одна из возможных траекторий, по которой может распространяться свет в волокне. Чем больше мод, тем больше дисперсионное искажение сформы сигнала. Одномодовое волокно позволяет получить полосу пропускания в диапазоне 50-100 ГГц-км. Типовое значение модовой дисперсии лежит в пределах от 15 до 30 нсек/км. Эта разновидность волокна воспринимает меньшую долю света на входе, за то обеспечивает минимальное искажение сигнала и минимальные потери амплитуды. Следует также иметь в виду, что оборудование для работы с одномодовым волокном значительно дороже. Центральная часть одномодового волокна имеет диаметр 3-10 m, а диаметр клэдинга составляет 30-125 m. Число мод, допускаемых волокном, в известной мере определяет его информационную емкость. Модовая дисперсия приводит к расплыванию импульсов и их наезжанию друг на друга. Дисперсия зависит от диаметра центральной части волокна и длины волны света. Число мод n равно для волокна типа А:

Сечение оптоволоконного кабеля

Рисунок 3.2.1. Сечение оптоволоконного кабеля

Существует несколько типов оптических волокон, обладающих различными свойствами. Они отличаются друг от друга зависимостью коэффициента преломления от радиуса центрального волокна. На Рисунок 3.2.2 показаны три разновидности волокна (А, Б и В). Буквами А и Б помечен мультимодовый вид волокон. Тип Б имеет меньшую дисперсию времени распространения и по этой причине вносит меньшие искажения формы сигнала. Установлено, что, придавая световым импульсам определенную форму (обратный гиперболический косинус), дисперсионные эффекты можно полностью исключить. При этом появляется возможность передавать импульсы на расстояние в тысячи километров без искажения их формы. Такие импульсы называются солитонами. При современных же технологиях необходимо использовать повторители через каждые 30 км (против 5 км для медных проводов). По сравнению с медными проводами оптоволоконные кабели несравненно легче. Так одна тысяча скрученных пар при длине 1 км весит 8 тонн, а два волокна той же длины, обладающие большей пропускной способностью, имеют вес 100кг. Это обстоятельство открывает возможность укладки оптических кабелей вдоль высоковольтных линий связи, подвешивая или обвивая их вокруг проводников.

Схема оптического разъема

Рисунок 3.2.6. Схема оптического разъема

С использованием оптических волокон можно создавать не только кольцевые структуры. Возможно построение фрагмента сети, по характеру связей эквивалентного кабельному сегменту или хабу. Схема такого фрагмента сети представлена на Рисунок 3.2.7 (пассивный хаб-концентратор). Базовым элементом этой субсети является прозрачный цилиндр, на один из торцов которого подключаются выходные волокна всех передатчиков интерфейсов устройств, составляющих субсеть. Сигнал с другого торца через волокна поступает на вход фото приемников интерфейсов. Таким образом, сигнал, переданный одним из интерфейсов, поступает на вход всех остальных интерфейсов, подключенных к этой субсети. При этом потери света составляют 2С + S + 10*log(N), где С - потери в разъеме, S - потери в пассивном разветвителе, а N - число оптических каналов (N может достигать 64). Современные микросхемы приемо-передатчиков (корпус DIP) имеют встроенные разъемы для оптического кабеля (62,5/125мкм или 10/125 мкм). Некоторые из них (например, ODL 200 AT&T) способны осуществлять переключение на обходной оптический путь (bypass) при отключении питания.

Схема пассивного оптоволоконного хаба

Рисунок 3.2.7. Схема пассивного оптоволоконного хаба

В последнее время заметного удешевления оптических каналов удалось достичь за счет мультиплексирования с делением по длине волны. За счет этой техники удалось в 16-32 раза увеличить широколосность канала из расчета на одно волокно. Схема мультиплесирования показана на Рисунок 3.2.8. На входе канала сигналы с помощью призмы объединяются в одно общее волокно. На выходе с помощью аналогичной призмы эти сигналы разделяются. Число волокон на входе и выходе может достигать 32.

Сообщение об изменении маршрутов

Рисунок 4.2.11.2.7 Сообщение об изменении маршрутов

Сообщения об изменениях маршрутов могут быть вызваны следующими причинами:

1. Возраст маршрута достиг предельного значения (lsrefreshtime).

2. Изменилось состояние интерфейса.

3. Произошли изменения в маршрутизаторе сети.

4. Произошло изменение состояния одного из соседних маршрутизаторов.

5. Изменилось состояние одного из внутренних маршрутов (появление нового, исчезновение старого и т.д.)

6. Изменение состояния межзонного маршрута.

7. Появление нового маршрутизатора, подключенного к сети.

8. Вариация виртуального маршрута одним из маршрутизаторов.

9. Возникли изменения одного из внешних маршрутов.

10. Маршрутизатор перестал быть пограничным для данной as (например, перезагрузился).

Каждое сообщение о состоянии канала начинается с заголовка - "объявление состояния канала" (LS– link state). Формат этого типа заголовка приведен ниже (20 октетов):

Характеристики оптических приемников

Таблица 3.2.2. Характеристики оптических приемников

Параметры	pin	Лавинный фотодиод	Фототранзистор	Фотоприемник Дарлингтона
Чувствительность	0,5 мкa/мкВт	15 мкa/мкВт	35 мкa/мкВт	180 мкa/мкВт
Время нарастания	1 нс	2 нс	2 мкс	40 мкс
Напряжение смещения	10 В	100 В	10 В	10 В

Поглощение света в волокне происходит по нескольким причинам. Поглощение в собственно стекле волокна падает с частотой, в то время как потери из-за рассеяния на дефектах стекла (релеевское рассеяние) с увеличением частоты растет. При сгибании волокна поглощение увеличивается. По этой причине следует избегать малых радиусов изгиба (кроме всего прочего это может привести и к обрыву). В результате потери света в волокне обычно лежит в диапазоне (2-5) дБ/км для длин волн 0,8 – 1,8 m. Зависимость поглощения света в волокне от длины волны показана на Рисунок 3.2.3. Используемые диапазоны отмечены на рисунке зеленым цветом. Все эти диапазоны имеют ширину 25000-30000 ГГц.

Характеристики светодиодов и инжекционных лазерных диодов

Таблица 3.2.1. Характеристики светодиодов и инжекционных лазерных диодов

Параметры	Светодиод (led)	Инжекционные лазерные диоды
Выходная мощность	0,5 – 11,5 мВт	3 – 10 мВт
Время нарастания	1 – 20 нс	1 – 2 нс
Диапазон тока смещения	5- - 150 мА	100 – 500 мА

Время нарастания фотодиода ограничивает быстродействие системы. Не малую роль играет и уровень шумов на входе приемника. При этом световой импульс должен нести достаточно энергии (заметно больше уровня шума), чтобы обеспечить низкий уровень ошибок. В таблице 3.2.2 приведены характеристики оптических приемников.

кодов TOS, принятых в OSPF протоколе приведена ниже

Таблица кодов TOS, принятых в OSPF протоколе приведена ниже.

Коды идентификаторов канала

Таблица 4.2.11.2.6. Коды идентификаторов канала

Код идентификатора	Описание
1	Идентификатор соседнего маршрутизатора
2	IP-адрес основного маршрутизатора (по умолчанию)
3	IP-адрес сети/субсети
4	Идентификатор соседнего маршрутизатора

Маршрутизатор, получивший OSPF-пакет, посылает подтверждение его приема. Этот вид пакетов имеет тип=5 и структуру, отображенную на Рисунок 4.2.11.2.10. Получение нескольких объявлений о состоянии линий может быть подтверждено одним пакетом. Адресом места назначения этого пакета может быть индивидуальный маршрутизатор, группа маршрутизаторов или все маршрутизаторы автономной системы.

Коды поля тип

Таблица 4.2.11.2.2. Коды поля тип

Тип	Значение
1	Hello (используется для проверки доступности маршрутизатора).
2	Описание базы данных (топология).
3	Запрос состояния канала.
4	Изменение состояния канала.
5	Подтверждение получения сообщения о статусе канала.

Поле длина пакета определяет длину блока в октетах, включая заголовок. Идентификатор области - 32-битный код, идентифицирующий область, которой данный пакет принадлежит. Все ospf-пакеты ассоциируются с той или иной областью. Большинство из них не преодолевает более одного шага. Пакеты, путешествующие по виртуальным каналам, помечаются идентификатором опорной области (backbone) 0.0.0.0. Поле контрольная сумма содержит контрольную сумму IP-пакета, включая поле типа идентификации. Контрольное суммирование производится по модулю 1. Поле тип идентификации может принимать значения 0 при отсутствии контроля доступа, и 1 при наличии контроля. В дальнейшем функции поля будут расширены. Важную функцию в OSPF-сообщениях выполняет одно-октетное поле опции, оно присутствует в сообщениях типа Hello, объявление состояния канала и описание базы данных. Особую роль в этом поле играют младшие биты e и Т:

Коды типа сервиса (TOS)

Таблица 4.2.11.2.4. Коды типа сервиса (TOS)

OSPF-код	TOS-коды	TOS(RFC-1349)
0	0000	Обычный сервис
2	0001	Минимизация денежной стоимости
4	0010	Максимальная надежность
8	0100	Максимальная пропускная способность
16	1000	Минимальная задержка

Коды типов состояния каналов (LS)

Таблица 4.2.11.2.3. Коды типов состояния каналов (LS)

LS-тип	Описание объявления о маршруте
1	Описание каналов маршрутизатора, то есть состояния его интерфейсов.
2	Описание сетевых каналов. Это перечень маршрутизаторов, непосредственно связанных с сетью.
3 или 4	Сводное описание каналов, куда входят маршруты между отдельными областями сети. Эта информация поступает от пограничных маршрутизаторов этих зон. Тип 3 приписан маршрутам, ведущим к сетям, а тип 4 характеризует маршруты, ведущие к пограничным маршрутизаторам автономной системы.
5	Описания внешних связей автономной системы. Такие маршруты начинаются в пограничных маршрутизаторах AS.

Поле идентификатор канала определяет его характер, в зависимости от этого идентификатором может быть IP-адрес маршрутизатора или сети. Маршрутизатор, рекламирующий канал определяет адрес этого маршрутизатора. Поле порядковый номер канала позволяет маршрутизатору контролировать порядок прихода сообщений и их потерю. Поле возраст канала определяет время в секундах с момента установления связи. После обмена сообщениями с соседями маршрутизатор может выяснить, что часть данных в его базе устарела. Он может послать своим соседям запрос с целью получения свежей маршрутной информации о каком-то конкретном канале связи. Сосед, получивший запрос, высылает необходимую информацию. Запрос посылается в соответствии с форматом, показанном ниже (Рисунок 4.2.11.2.6):

Коды типов связей (см Рисунок

Таблица 4.2.11.2.5. Коды типов связей (см. Рисунок 4.2.11.2.9)

Код типа связи	Описание
1	Связь с другим маршрутизатором по схеме точка-точка
2	Связь с транзитной сетью
3	Связь с оконечной сетью
4	Виртуальная связь (например, опорная сеть или туннель)

Поле идентификатор канала характеризует объект, с которым связывается маршрутизатор. Примеры идентификаторов представлены в таблице:

может иметь совершенно

Таблица 4.2.11.2.1 может иметь совершенно иное содержимое для какого-то другого вида сервиса, выбранные пути при этом могут иметь другую топологию. Качество сервиса (QoS) может характеризоваться следующими параметрами:

пропускной способностью канала;

задержкой (время распространения пакета);

числом дейтограмм, стоящих в очереди для передачи;

загрузкой канала;

требованиями безопасности;

типом трафика;

числом шагов до цели;

возможностями промежуточных связей (например, многовариантность достижения адресата).

Определяющими являются три характеристики: задержка, пропускная способность и надежность. Для транспортных целей OSPF использует IP непосредственно, т.е. не привлекает протоколы UDP или TCP. OSPF имеет свой код (89) в протокольном поле IP-заголовка. Код TOS (type of service) в IP-пакетах, содержащих OSPF-сообщения, равен нулю, значение TOS здесь задается в самих пакетах OSPF. Маршрутизация в этом протоколе определяется IP-адресом и типом сервиса. Так как протокол не требует инкапсуляции пакетов, сильно облегчается управление сетями с большим количеством бриджей и сложной топологией (исключается циркуляция пакетов, сокращается транзитный трафик). Автономная система может быть поделена на отдельные области, каждая из которых становится объектом маршрутизации, а внутренняя структура снаружи не видна (узлы на Рисунок 4.2.11.2.1 могут представлять собой как отдельные ЭВМ или маршрутизаторы, так и целые сети). Этот прием позволяет значительно сократить необходимый объем маршрутной базы данных. В OSPF используется термин опорной сети (backbone) для коммуникаций между выделенными областями. Протокол работает лишь в пределах автономной системы. В пределах выделенной области может работать свой протокол маршрутизации.

Реализация алгоритма

Таблица 4.2.11.2.1. Реализация алгоритма

	Множество	Метрика связи узла a с узлами
Шаг	N	B	C	D	E	F	G	H	I	J
0	{A}	3	-	9	-	-	-	-	-	-
1	{A,B}	(3)	4	9	7	-	10	-	-	-
2	{A,B,C}	3	(4)	6	6	10	10	8	-	14
3	{A,BC,D}	3	4	(6)	6	10	10	8	9	14
4	{A,B,C,D,E}	3	4	6	(6)	10	10	8	9	14
5	{A,B,C,D,E,H}	3	4	6	6	10	10	(8)	9	14
6	{A,B,C,D,E,H,I}	3	4	6	6	10	10	8	(9)	14
7	{A,B,C,D,E,H,I,F}	3	4	6	6	(10)	10	8	9	14
8	{A,B,C,D,E,H,I,F,G}	3	4	6	6	10	(10)	8	9	14
9	{A,B,C,D,E,H,I,F,G,J}	3	4	6	6	10	10	8	9	(14)

Типовые характеристики оптических волокон

Таблица 3.2.3. Типовые характеристики оптических волокон

Тип волокна	Диаметр ядра [мкм]	Диаметр клэдинга [мкм]	А	Затухание [дБ/км]			Полоса пропускания [МГц/км]
Длина волны				850	1300	1550
Одномодовое	9,3 8,1	125 125	0,13 0,17		0,4 0,5	0,3 0,25	5000 для 850 нм
Со сглаженным индексом	50 62,5 85	125 125 125	0,2 0,275 0,26	2,4 3,0 2,8	0,6 0,7 0,7	0,5 0,3 0,4	600 для 850 нм; 1500 для 1300 нм
Ступенчатый индекс	200	380	0,27	6,0			6 при 850 нм

Одним из критических мест волоконных систем являются сростки волокон и разъемы. Учитывая диаметр центральной части волокна, нетрудно предположить, к каким последствиям приведет смещение осей стыкуемых волокон даже на несколько микрон (особенно в одномодовом варианте, где диаметр центрального ядра менее 10 микрон) или деформация формы сечения волокон.

Соединители для оптических волокон имеют обычно конструкцию, показанную на Рисунок 3.2.6, и изготовляются из керамики. Потеря света в соединителе составляет 10-20%. Для сравнения сварка волокон приводит к потерям не более 1-2%. Существует также техника механического сращивания волокон, которая характеризуется потерями около 10% (splice). Оптические аттенюаторы для оптимального согласования динамического диапазона оптического сигнала и интервала чувствительности входного устройства представляют собой тонкие металлические шайбы, которые увеличивают зазор между волокном кабеля и приемником.

Зависимость дисперсии от длины волны

Рисунок 3.2.4. Зависимость дисперсии от длины волны

Из рисунка видно, что в области ниже 1300 нм более длинные волны движутся быстрее коротких. Для длин волн >1300нм имеет место обратная ситуация – более длинные волны движутся медленнее коротких. Для одномодовых волокон определяющий вклад в искажения вносится дисперсией скоростей распространения, для многомодовых основной вклад вносит модовая дисперсия. Зависимость полосы пропускания волокна от его длины приведена на Рисунок 3.2.5.

Зависимость поглощения света в волокне от длины волны

Рисунок 3.2.3. Зависимость поглощения света в волокне от длины волны

Из рисунка видно, что минимумы поглощения приходятся на 1300 и ~1500 нм, что и используется для целей телекоммуникаций. При длине волны 1300 нм дисперсия скоростей распространения различных длин волн минимальна. Диапазон ~850 нм характеризуется высоким поглащением, но он привлекателен тем, что как лазеры, так и электроника могут быть изготовлены из одного материала (арсенида галлия). Используемые оптические диапазоны выделены зеленым цветом. Зависимость дисперсии от длины волны показана на Рисунок 3.2.4.

Зависимость полосы пропускания волокна от его длины

Рисунок 3.2.5. Зависимость полосы пропускания волокна от его длины

Типовые характеристики оптических волокон приведены в таблице 3.2.3. (См. также Дональд Дж. Стерлинг, Волоконная оптика. Техническое руководство. Изд. “ЛОРИ, Москва, 1998 а также Дж. Гауэр, Оптические системы связи. Москва, “Радио и связь”, 1989)

А Структура CSR-регистра интерфейса (CSR

Рисунок 7.2.1.А Структура CSR-регистра интерфейса (CSR0)

Init	инициализация (initialize);
Strt	старт;
Stop	стоп;
Tdnd	запрос передачи (transmit demand);
Txon	включение передачи;
Rxon	включение приема;
Inea	разрешение прерываний (interrupt enable);
Intr	прерывание;
Idon	инициализация выполнена (стирание записью 1);
Tint	прерывание при передаче (стирание записью 1);
Rint	прерывание при чтении (стирание записью 1);
Merr	ошибка при тайм-ауте на шине (стирание записью 1);
Miss	нет буфера для приема (стирание записью 1);
Cerr	ошибка из-за столкновения (стирание записью 1);
Labl	тайм-аут при передаче (стирание записью 1);
Err	ошибка типа Babl, Cerr, Miss, Merr (только для чтения).

CSR1 (доступ разрешен при CSR0[stop] = 1)

Алгоритм установления соединения PPP

Рисунок 3.5.2. Алгоритм установления соединения PPP

При обнаружении несущей или по инициативе клиента система может попытаться установить соединение. В случае успеха система переходит в фазу аутентификации. Если же и фаза аутентификации завершается благополучно, система выполняет подключение к сети (IP, IPX, Appletalk и т.д.), настройка сетевого уровня производится в рамках протокола NCP. Во всех остальных случаях производится возврат в исходное состояние. Процедура закрытия соединения осуществляется протоколом LCP.

В поле данных PPP-пакета может быть вложен один LCP-пакет, в этом случае в поле протокол должен быть записан код 0xC021 (Link Control Protocol). LCP-протокол служит для установления соединения путем обмена конфигурационными пакетами. По завершении этого обмена система переходит в фазу аутентификации (Рисунок 3.5.2). Формат LCP-пакета показан на Рисунок 3.5.3.

доступ разрешен при

Рисунок 7.2.1.Б. CSR1



CSR2 ( доступ разрешен при CSR0[stop] = 1)

Базовые протоколы Internet

10.15 Базовые протоколы Internet

Протокол	Описание	RFC
ARP	Address Resolution Protocol	826
BFTP	Background File Transfer Protocol	1068
BGP	Border Gateway Protocol (внешний протокол маршрутизации)	1105,1265-68, 1397, 1654-56
BOOTP	Bootstrap Protocol (протокол загрузки)	951,1048,1084
CIDR	Classless Inter-Domain Routing protocol	1519,1520
CLNP	ConnectionLess Network Protocol (ISO-8474)	1526,1561,1575
CLOCK	DCNET Time Server Protocol	778
CMOT	Common Management Information Service and Protocol over TCP/IP	1095
DNS	Domain Name Service (система распознавания имен доменов)	1713, 1712, 1612, 1611, 1383
DOMAIN	Domain Name System (DNS)	1034, 1035, 1032, 974
DVMRP	Distance Vector Multicast Routing Protocol	1075
ECHO	Эхо протокол	862
EGP	Exterior Gateway Protocol	904, 911, 1092, 1093
FINGER	Finger-протокол	1288,724
FTP	File Transfer Protocol (протокол пересылки файлов)	959
HEMP	High level Entity Management Protocol	1022
HEMS	High level Entity Management System	1021
HMP	Host Monitoring Protocol	869
GGP	Gateway to Gateway Protocol	823
ICMP	Internet Control Message Protocol	792,1256
IDRP	Inter-Domain Routing Protocol	1477,1479
IGMP	Internet Group Multicast Protocol	1112
IGP	Interior Gateway Protocol	1074,1371
IP	Internet протокол	791
IP субсети	950
IP широковещательные дейтограммы	919
то же для субсетей	922
IP-ARC	Internet протокол для Arcnet	1051
IP-E	Internet протокол для Ethernet	895
IP-FDDI	Передача IP через FDDI	1103
IP-SLIP	Передача IP по последовательным линиям	1055
IPM	Internet-протокол для сообщений	759
IRC	Internet Relay Chat	1459
IS-IS	OSI-междоменный протокол маршрутизации	1195,1142
MAIL	Формат сообщений электронной почты	822, 821, 1351, 1352
MIB-II	Management Information Base-II	1213
MIME	Multipurpose Internet Mail Extensions	1521,1522
NETBIOS	NetBIOS Service Protocols	1001,1002
NETRJE	Network Remote Job Entry Program	740,725
NETRJS	Network Remote Job Service	477,436
NFS	Network File System (файловая система)	1094
NNTP	Network News Transfer Protocol	977
NTP	Network Time Protocol	1119,1128-29
NUMBERS	Assigned Numbers	1700
OSPF	Open Shortest Pass First Protocol (маршрутный протокол "кратчайший путь лучше")	1131, 1245 -48, 1253, 1370, 1583-87
PCMAIL	PVmail Transport Protocol	1056
POP	Post Office Protocol	937, 1081, 1082, 1460
RAP	Router-Access Protocol	1476
PPP	Point-to-Point Protocol	1134
RARP	Reverse Address Resolution Protocol	903
RDP	Reliable Data Protocol	908
RIP	Routing Information Protocol (внутренний протокол маршрутизации)	1058, 1387, 1389, 1581, 1582,1388
RLP	Resource Location Protocol	887
RPC	Remote Procedure Call Protocol	1057,1050
SFTP	Simple File Transfer Protocol	913
SLIP	Serial Line IP (Интернет по послед. линии)	1055
SMI	Structure of Management Information	1155
SMTP	Simple Mail Transfer Protocol SMTP через X.25	821, 1090
SNMP	Simple Network Management Protocol SNMP в Ethernet	1157, 1089
TCP	Transmission Control Protocol	793
TELNET	Протокол удаленного доступа	854,856-861, 885, 927, 933, 946, 1041, 1043, 1053, 1073, 1079, 1093, 1096, 1097, 1143, 1184, 1205, 1372, 1411, 1412, 1416, 1571, 1572
TFTP	Trivial File Transfer Protocol	1350
UDP	User Datagram Protocol	768
USERS	Протокол активных пользователей	866
UUCP	Электронная почта под UNIX	976
VFIP	Voice File Interchange Protocol	978
VMTP	Versatile Message Transfer Protocol	1045
XDR	EXternal Data Representation	1014
X-Windows	Системный протокол X-Windows	1198,1013

<

Безопасная почта PGP

6.4.4 Безопасная почта PGP

В связи с массовым внедрением электронной почты и, в перспективе, полным вытеснением традиционной, проблема конфиденциальности доставки электронных сообщений становится крайне актуальной. В последние годы разработано несколько почтовых систем, предоставляющих эту конфиденциальность. Примером такой системы может служить PEM - почта с улучшенной защитой от несанкционированного доступа (PEM - Privacy Enhanced Mail, RFC-1421, 1422, 1423 и 1424). Первая разработка в области электронной криптографии относится к 1976 году, когда была создана система Диффи-Хелмана (Diffie-Hellman) с общедоступным шифровальным ключом. Позднее, в 1977 году Ривестом, Шамиром и Адлеманом была предложена двух ключевая система RSA (Rivest-Shamir-Adleman). Эта разработка была выполнена под патронажем Национального научного фонда США (NSF) и в 1983 году запатентована в США.

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

Предусмотрена интеграция MIME (Multipurpose Internet Mail Extensions) и PEM. Существует подписной лист (LISTSERV) для пользователей, интересующихся вопросами развития и использования PEM. Для подписки необходимо послать соответствующее сообщение по адресу pem-dev-request@tis.com.

Для пользователей PEM имеется еще один подписной лист: tispem-users@tis.com. Для подписки следует направлять заявки по адресу: tispem-users-request@tis.com. С вопросами по использованию TIS/PEM следует обращаться в tispem-support@tis.com.

Имеется версия программного обеспечения PEM в свободном доступе, например, TIS/PEM V7.0 (UNIX, только для США и Канады). Эта версия содержит в себе:

поддержку однопользовательского режима с возможностью совместного использования некоторых процедурных модулей;

легко читаемую базу данных для каждого пользователя;

поддержку для большего числа баз данных;

гибкую систему управления доступом;

гибкую систему поверки;

системы верификации, кодирования, декодирования и электронной подписи, совместимые с другими почтовыми серверами;

поддержку интеграции MIME-PEM.

Система TIS/PEM доступна через анонимное FTP в США и Канаде по адресу: ftp.tis.com pub/PEM/README; pub/PEM/LICENSE; pub/PEM/BUGS. Файл README содержит дополнительные инструкции по применению PEM.

Несравненно большей популярностью пользуется конфиденциальная почтовая система PGP (Pretty Good Privacy – замечательная конфиденциальность). История создания PGP довольно драматична (см. http://www.dcs.ex.ac.uk/~aba/timeline/. Создателем PGP является Фил Циммерман (США, 1991 год). PGP базируется на двух ключевой системе шифрования RSA и алгоритме IDEA (International Data Encryption Algorithm, предложен Ксейа Лайем и Джеймсом Массейем, Швейцария). Творение Циммермана было встречено без энтузиазма Агентством Национальной Безопасности США и против него было возбуждено уголовное дело. Хотя АНБ и могущественно, здравый смысл и закон в данном случае восторжествовали. Что же касается патента на RSA, он не является международным и вся ответственность за использование программ, базирующихся на данном алгоритме, лежит на пользователе (юридически ситуация весьма запутана). В России применение любой системы шифрования (формально даже архивирование!) требует лицензирования. Все правительства любят все держать в тайне, но не любят, когда кто-то пытается хранить в тайне что-то от правительства (даже если это любовные письма; если вы интересуетесь юридической стороной проблемы использования PGP, смотрите в http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm. Чему здесь удивляться, ведь история “черных кабинетов” (в том числе и в России) исчисляется столетиями.

PGP версия 2.5 (http://www.ifi.uio.no/~staalesc/PGP ) (и более поздние используют RSAREF 1.0 вместо MPILIB) представляет собой публично доступный (легальный!) пакет электронной почты со встроенной системой шифрования сообщений. Пакет обеспечивает конфиденциальность переписки и пересылки файлов. Конфиденциальность заключается в том, что только лица, кому адресовано послание или файл, смогут его прочесть. PGP поддерживает технологию электронной подписи, гарантирующей получателю, что сообщение пришло именно от вас. Предусмотрен контроль неизменности сообщения в процессе доставки (принцип сходен с идеей CRC). При этом не требуется каких-либо секретных каналов для пересылки ключей кодирования. Именно эта схема являлась до недавнего времени основной. Главный ее недостаток - необходимость транспортировки секретного ключа. PGP использует технику шифрования с общедоступными ключами, совмещая удобства системы кодирования RSA с быстродействием традиционных методов. Существуют коммерческие версии PGP, встроенные в известные текстовые редакторы WORD и другие. В PGP предусмотрена схема, резко ускоряющая дешифровку. Возможно применение большого набора пар общедоступных и секретных ключей. Имеется система авторизации, контролирующая доступ к ключам и препятствующая использованию краденных секретных ключей. Предусмотрены и другие методы повышения секретности пересылки любых сообщений.

Пакет работает под MS-DOS, UNIX, Windows. Данная версия позволяет посылать сообщение сразу нескольким адресатам. Пакет имеет встроенную справочную систему (Help на английском, французском и испанском языках. Описания, инструкции по постановке и использованию можно найти по адресу: FTP ftp.uu.net/pub/security/pgp.

Блок-схема кодирования и передачи изображения

Рисунок 2.5.5. Блок-схема кодирования и передачи изображения

Макроблоки не передаются, если данная часть изображения не изменилась. За MBA следует код переменной длины Mtype, характеризующий формат макроблока (применен ли метод подвижного вектора MVD и т.д.) и последующую информацию. CBP (Coded Block Pattern) представляет собой кодовое слово переменной длины, которое несет в себе информацию о том, какой из шести блоков преобразования (8*8) содержит коэффициенты (слой блоков). CBP нужно не для всех типов макроблоков. Каждый блок завершается флагом EOB (End of Block).

доступ разрешен при

Рисунок 7.2.1В. CSR2

Bcon	0 = <0:7> перестановка байтов адресов
Acon	0 = ale, 1 = /as
Bswp	0 = /bm1, bm0, /hold;

csr3 ( доступ разрешен при CSR0[stop] = 1)

Формат кадра в протоколе PPP

Рисунок 3.5.1 Формат кадра в протоколе PPP

Поле адрес всегда содержит байт 0xff (смотри также HDLC). Это указывает на то, что все станции должны принять этот кадр, и исключает необходимость выделения каких-то специальных адресов. Байт управления всегда равен 0x03, что указывает на ненумерованный тип кадра. По умолчанию кадры PPP передаются в режиме "без установления соединения". Если требуется надежная доставка, используется версия, описанная в RFC-1663. Двухоктетное поле протокол сходно по функции с полем тип в кадре Ethernet и определяет то, как следует интерпретировать информационное поле (см. табл. 3.5.1). Значение 0x0021 этого поля говорит о том, что последующее информационное поле содержит в себе IP-дейтограмму. Поле CRC (Cyclic Redundancy Check) представляет собой циклическую контрольную сумму, предназначенную для выявления ошибок при транспортировке PPP-кадра. Применение флагов-ограничителей кадра (0x7E) создает те же проблемы, о которых говорилось при описании SLIP-протокола, - эти байты не могут присутствовать в информационном поле. В синхронном режиме эта проблема решается на аппаратном уровне. При работе в асинхронном режиме для этого используется специальный ESC-символ, равный 0x7D. Когда этот esc-символ встречается в информационном поле, шестой бит в следующем за ним байте инвертируется. Так байт 0x7E будет преобразован в последовательность 0x7D, 0x5E, а байт 0x7D - в два байта 0x7D, 0x5D. Все символы с кодами меньше 0x20 также преобразуются в ESC-последовательности. Например, 0x07 будет преобразован в 0x7D, 0x27. Это необходимо делать, так как управляющие символы могут оказать непредсказуемые воздействия на режим работы драйверов или модемов, используемых в канале. Протокол ppp в отличие от SLIP допускает мультипротокольность и динамическое определение IP-адресов партнеров. Несмотря на определенные преимущества протокола PPP перед SLIP, последний распространен достаточно широко. Не трудно видеть, что все перечисленные физические среды используют последовательный формат передачи информации.

Формат кодированного адреса отправителя

Рисунок 4.4.9.5.5. Формат кодированного адреса отправителя

Поле бит s (бит рассеянности) содержит 1 для PIM-SM. Этот бит используется для обеспечения совместимости с PIM v.1.

Поле бит W (бит WC). Бит WC =1, если подключение (join) или удаление (prune) используются для маршрутной записи (*,g) или (*,*,rp). Если wc=0, join или prune используются для маршрутной записи (s,g), где s – адрес отправителя. Сообщения join и prune, посылаемые в RP, должны иметь этот бит равным 1.

Поле бит R (бит RPT). Бит RPT=1, если информация о (s,g) послана в RP. Если RPT=0, информация должна быть послана S, где S – адрес отправителя.

Поле длина маски имеет длину 8 бит. Значение этого поля охарактеризовано выше в комментарии к рисунку 4.4.9.5.4.

Поле адрес отправителя имеет длину, определяемую полем заголовка длина адреса. Для IPv4, она равна 4 октетам. Формат сообщения Hello показан на Рисунок 4.4.9.5.6.

Первые два байта представляют собой заголовок PIM-сообщения. Поле optiontype определяет тип опции, значение которой задано в поле optionvalue. Поле optionlength задает длину поля optionvalue в байтах. Поле optionvalue имеет переменную длину и содержит значение опции. Поле опция может содержать следующие значения:

Формат MР-пакета

Рисунок 3.5.5. Формат MР-пакета

Поля PID - идентификатор протокола. Субполе B (Beginning) - бит фрагмента =1 для первого фрагмента PPP и =0 для всех последующих фрагментов. Субполе E (Ending) - бит фрагмента =1 для последнего фрагмента PPP и =0 для всех прочих фрагментов. Поле номер по порядку имеет длину 24 бита. Существует модификация пакета с укороченным кодом (12 бит) номера по порядку. При этом к этому полю отходят 4 нулевые бита после BE00. Выбор длины этого поля осуществляется протоколом LCP. Значение полу увеличивается на 1 при посылке очередного фрагмента. Для вышерасположенных уровней совокупность совместно используемых каналов выглядит, как один виртуальный канал.

При передаче пакетов по каналу Multilink инкапсуляция производится согласно следующим правилам, которые задаются вручную:

Никакого асинхронного управления кодированием символов

Запрет использования магических чисел

Запрещено мониторирование качества канала

Сжатие полей адреса, протокола и управления

Никаких составных кадров

Запрет заполнения с самоописанием (Self-Describing-Padding)

Для предварительно фрагментированных пакетов запрещено дополнение нулями или использование каких-либо иных заполнителей. Рассмотрим пример Multilink-соединения, приведенный на Рисунок 3.5.6. Канал 1 между двумя системами согласуется сетевыми уровнями NL1, NL2 и MP. Затем эти две системы согласуют с MP канал 2. Кадры, полученные каналом 1, демультиплексируются на канальном уровне согласно сетевому протокольному идентификатору PPP и могут быть посланы NL1, NL2 или MP. Канал 2 примет кадры со всеми сетевыми протокольными идентификаторами, с которыми принимает их канал 1. Кадры, полученные MP, позднее демультиплексируются на сетевом уровне согласно протокольному идентификатору PPP и посылаются NL1 или NL2. Любые кадры, полученные MP для других протоколов сетевого уровня, отбрасываются с помощью стандартного протокольного механизма (Reject).

Формат пакета IPCP Младшие биты слева

Рисунок 3.5.4. Формат пакета IPCP. Младшие биты слева.

Поле тип содержит 2, в поле длина заносится число байт в пакете (?4). В поле протокол сжатия IP заносится код алгоритма сжатия (0х02D - в случае алгоритма Ван Джекобсона). Поле данные может содержать нуль или более октетов. Конфигурационный запрос может потребовать присылки (присвоения) IP-адреса. Для решения этой задачи предусмотрена опция IPCP-пакета, где поле тип=3, длина=6, а последующие 4 байта выделены для IP-адреса, куда отправитель должен его записать. Если туда записаны нули, это говорит о том, что отправитель запрашивает свой IP-адрес.

Протоколы PPP, LCP (Link Control Protocol), CCP (Compression Control Protocol; RFC-1962, -1967), и некоторые другие управляющие протоколы содержат 8-битовые поля код. Значения этих кодов приведены в таблице 3.5.2.

Формат сообщения assert

Рисунок 4.4.9.5.11. Формат сообщения assert

Поле закодированный групповой адрес характеризует групповой адрес места назначения пакетов, который явился причиной посылки сообщения assert. Поле уникастный адрес отправителя содержит IP-адрес отправителя из дейтограммы, вызвавшей посылку мультикастного пакета Assert. Длина поля в байтах определена полем длины адреса. Поле R

представляет собой RPT-бит. Если IP мультикастинг дейтограмма, вызвавшая посылку пакета assert направляется вниз по RP-дереву, тогда RPT-бит равен 1. Если маршрутизация осуществляется вдоль SPT, бит равен 0. Поле предпочтение несет в себе значения кода предпочтения, присвоенного уникастному протоколу маршрутизации, который организует проход до ЭВМ. Поле метрика содержит значение метрики для таблицы маршрутизации. Единицы измерения должны соответствовать требованиям маршрутного протокола.

Сообщения кандидата RP посылаются периодически C-RP способом и уникастно адресуются к BSR. Формат таких сообщений показан на Рисунок 4.4.9.5.12.

Формат сообщения bootstrap

Рисунок 4.4.9.5.10. Формат сообщения bootstrap

Сообщения bootstrap пересылаются мультикастным способом группе `all-pim-routers', через все интерфейсы, имеющие PIM-соседей (за исключением того, через который получено сообщение). Сообщения bootstrap генерируются в BSR и посылаются с TTL=1. Формат сообщения bootstrap показан на Рисунок 4.4.9.5.10.

Сообщение bootstrap делится на семантические фрагменты, если исходное сообщение превосходит предельный размер пакета. Формат этих фрагментов представлен ниже (см. также Рисунок 4.4.9.5.10):

Поле метка фрагмента является случайным числом и служит для идентификации фрагментов принадлежащих одному и тому же сообщению. Фрагменты одного и того же сообщения имеют идентичные метки фрагмента. Поле длина хэш>-маски – это длина маски хэш функции в битах. Для IPv4 рекомендуется значение 30, а для IPv6 - 126. Поле BSR-приоритет содержит значение BSR-приоритета для включенного BSR. Это поле рассматривается как старший байт при сравнении BSR-адресов. Поле уникастный BSR-адрес является IP-адресом маршрутизатора (bootstrap) домена. Размер этого поля в байтах специфицирован в поле длина адреса. Поля закодированный групповой адрес -1..n является групповым префиксом (адрес и маска), с которым ассоциируются кандидаты RP. Поля число RP -1..N равны числу адресов кандидатов RP, включенных в сообщение bootstrap для соответствующего группового префикса. Маршрутизатор не замещает старый RP-набор для данного группового префикса до тех пор, пока не получит новое число RP-адресов для этого префикса. Адреса могут содержаться в нескольких фрагментах. Если получена только часть RP-набора для данного префикса, маршрутизатор эту часть выбрасывает, не изменяя RP-набора. Поля FRAG RP-cnt-1..m представляет собой число адресов кандидатов RP, включенных в этот фрагмент сообщения bootstrap, для соответствующего группового префикса. Поле `FRAG RP-cnt' облегчает разбор RP-набора для данного группового префикса, когда он размещается в более чем одном фрагменте. Поля уникастные rp-адреса -1..m представляют собой адреса кандидатов RP, для соответствующего группового префикса. Длина поля в байтах специфицировано полем длина адреса. Поля rp1..m-holdtime характеризуют значения holdtime для соответствующих RP. Это поле копируется из поля `holdtime' RP, записанного в BSR.

Сообщение assert посылается когда мультикастный информационный пакет получен выходным интерфейсом, соответствующим (s,g) или (*,g), относящимся к отправителю. Формат такого сообщения представлен на Рисунок 4.4.9.5.11.

Формат сообщения Hello

Рисунок 4.4.9.5.6. Формат сообщения Hello

optiontype = 1; optionlength = 2; optionvalue = holdtime; где holdtime равно времени в секундах, в течение которого получатель должен сохранять доступность к соседу. Если holdtime установлено равным `0xFFFF', получатель этого сообщения никогда не прервет соединение с соседом по таймауту. Это может использоваться для каналов ISDN, для того чтобы избежать поддержания канала путем периодической посылки сообщений Hello. Более того, если holdtime= 0, информация объявляется устаревшей немедленно. Диапазон значений optiontype 2 – 16 зарезервирован на будущее. Сообщение register посылается DR или PMBR в RP, когда необходимо передать мультикаст-пакет по rp-дереву. IP-адрес отправителя при этом равен адресу DR, а адрес места назначения – адресу RP. Формат сообщения register показан на Рисунок 4.4.9.5.7. Постоянная часть заголовка здесь идентична, показанной на Рисунок 4.4.9.5.3.

Формат сообщения join/prune

Рисунок 4.4.9.5.9. Формат сообщения join/prune

Поле адрес вышестоящего соседа представляет собой IP-адрес RPF или вышестоящего соседа. Поле holdtime характеризует время в секундах, в течение которого получатель должен поддерживать активное состояние join/prune. Если holdtime сделано равным `0xffff', получатель сообщения отключает таймаут для данного выходного интерфейса. Если holdtime сделано равным `0', таймаут происходит немедленно. Поле число групп равно количеству мультикаст-групп, содержащихся в сообщении.

Поле закодированный мультикастный групповой адрес имеет формат, показанный на Рисунок 4.4.9.5.4. Произвольная группа (wildcard) (*,*,rp) характеризуется адресом 224.0.0.0 и `4' в поле длина маски. Подключение (*,*,rp) имеет биты WC и RPT равные 1.

Поле число подключенных отправителей равно количеству адресов подключенных отправителей для данной группы. Поля адрес подключенного отправителя -1 .. N представляют собой список отправителей, которым посылающий маршрутизатор переправляет мультикастные дейтограммы при получении их через интерфейс, на который пришло данное сообщение. Формат полей кодированного адреса отправителя следует описанию на Рисунок 4.4.9.5.5.

Формат сообщения кандидата RP (C-RP)

Рисунок 4.4.9.5.12. Формат сообщения кандидата RP (C-RP)

Поле # префиксов (Prefix-Cnt) содержит количество кодированных групповых адресов, включенных в сообщение, указывая групповые префиксы, для которых производится C-RP оповещение. Значение поля Prefix-Cnt = `0' предполагает использование префикса 224.0.0.0 с длиной маски 4, что означает - все мультикастные группы. Если C-RP не снабжена информацией о групповом префиксе, C-RP заносит в поле значение по умолчанию равное `0'. Поле A характеризует бит указания. Этот бит указывает, что BSR не должен переписывать информацию о групповых префиксах, приведенную в C-RP оповещении. В большинстве случаев C-RP устанавливает этот бит, равным 0. Поле Holdtime содержит значение времени, в течение которого оповещение корректно. Это поле позволяет определить время, когда оповещение устареет. Поле уникастный RP-адрес представляет собой адрес интерфейса, который объявляется кандидатом в RP. Длина этого поля в байтах определена полем длина адреса. Поле закодированный групповой адрес -1..n является групповым префиксом, для которого производится уведомление кандидатом в RP.

Литература

1	Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and A.Helmy. Protocol independent multicast (pim) : Motivation and architecture. Work in Progress.
2	Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, and L.Wei. The PIM architecture for wide-area multicast routing. ACM Transactions on Networks, April 1996.
3	Estrin, D., D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and A.Helmy. Protocol independent multicast-dense mode (pim-dm): Protocol specification. Work in Progress.
4	Deering, S. Host extensions for ip multicasting, Aug 1989. RFC1112.
5	Fenner, W. Internet group management protocol, version 2. Work in Progress.
6	Atkinson, R. Security architecture for the internet protocol, August 1995. RFC-1825.
7	Ballardie, A.J., P.F. Francis, and J.Crowcroft. Core based trees. In Proceedings of the ACM SIGCOMM, San Francisco, 1993.

<

Формат сообщения register

Рисунок 4.4.9.5.7. Формат сообщения register

Поле B – (бит border) пограничный бит. B=1, если маршрутизатор непосредственно соединен с отправителем. Поле N – бит нулевого регистра. n устанавливается DR равным 1 при тестировании RP до истечения времени регистрации (register-suppression timer). Поле информационный мультикаст-пакет представляет собой оригинальное сообщение, посланное отправителем.

Сообщение register-stop является уникастным, направляемым от RP к отправителю сообщения register. IP-адрес отправителя является адресом, к которому направлялось сообщение регистрации. IP-адрес места назначения равен адресу отправителя сообщения register. Формат сообщения register-stop показан на Рисунок 4.4.9.5.8.

Формат сообщения register-stop

Рисунок 4.4.9.5.8. Формат сообщения register-stop

Поле закодированный групповой адрес имеет тот же смысл, что и на Рисунок 4.4.9.5.4. Для сообщений register-stop поле длины маски содержит длину адреса * 8 (32 для IPv4), если сообщение послано для одной группы.

Поле уникастный адрес отправителя представляет собой IP-адрес ЭВМ отправителя из мультикастного информационного пакета. Длина этого поля в байтах задано полем длина адреса. Значение (0.0.0.0) может быть использовано для обозначения любого адреса.

Сообщение join/prune посылается маршрутизаторами в направлении вышестоящих отправителей и RP. Сообщения join служит для построения совместно используемых маршрутных деревьев (RP-деревьев) или деревьев отправителей (SPT). Сообщения prune посылаются для отключения деревьев отправителей, когда участники покидают группу, а также для отправителей, которые не используют общее дерево. Формат сообщения join/prune показан на Рисунок 4.4.9.5.9.

Формат заголовка LCP-пакета

Рисунок 3.5.3. Формат заголовка LCP-пакета

Вслед за заголовком следует поле данных. Поле код (1 октет) идентифицирует модификацию LCP-пакета. Если получен пакет с неизвестным полем код, посылается пакет-отклик “отклонение кода”. Поле идентификатор (1 октет) служит для нахождения соответствия между запросами и откликами. Если получен пакет с неправильным идентификатором, он просто уничтожается. Двухоктетное поле длина определяет размер LCP-пакета, включая размер заголовка. Октеты принятого пакета за пределами, заданными полем длина игнорируются.

В качестве примера можно рассмотреть процедуру подключения персональной ЭВМ к серверу через модем. После того как модем маршрутизатора ответит на вызов модема-клиента и установит физическое соединение, ЭВМ посылает последовательность LCP-пакетов, вложенных в поля данных одного или нескольких PPP-кадров. Это позволяет выбрать необходимые параметры PPP. По завершении этой процедуры посылается последовательность NCP-пакетов, которые конфигурируют сетевой уровень. Вероятно, ЭВМ захочет работать со стеком протоколов TCP/IP, и по этой причине нуждается в IP-адресе. Если провайдер имеет N IP-адресов в резерве, он может подключить одновременно N ЭВМ. Присвоение IP-адреса осуществляется также в рамках NCP-протокола. После этого ЭВИ становится узлом Интернет. Завершение сессии и освобождение IP-адреса выполняется также через NCP-протокол. Разрыв соединения осуществляет протокол LCP.

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

Значение кода поля типа	Назначение опции
0	Зарезервировано
1	Maximum-Receive-Unit (указывает максимальный размер блока данных, который может быть принят)
3	Authentication-Protocol (протокол аутотентификации)
4	Quality-Protocol (протокол качества)
5	Magic-Number (магическое число, опция служит для выявления каналов с петлями обратной связи)
6	Protocol-Field-Compression
7	Address-and-Control-Field-Compression

Существует три класса LCP-пакетов:

Пакеты конфигурации канала, которые используются при формировании виртуального канала (Configure-Request, Configure-Ack, Configure-Nak и Configure-Reject) . Пакеты закрытия канала (Terminate-Request и Terminate-Ack).

Пакеты поддержания, которые служат для управления и отладки(Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request).

Аналогом LCP является протокол IPCP (IP Control Protocol). В поле код протокола в этом случае записывается 8021 (RFC-1332). Формат пакета IPCP показан на Рисунок 3.5.4.

Формат заголовка сообщения PIM

Рисунок 4.4.9.5.3. Формат заголовка сообщения PIM

Поле OIM VER – версия протокола (в настоящее время = 2). Поле тип характеризует PIM-сообщение. Возможные значения поля тип представлены в таблице 4.4.9.5.1.

Формат закодированного группового адреса

Рисунок 4.4.9.5.4. Формат закодированного группового адреса

Поле длина маски имеет 8 бит. Значение поля определяет число последовательных бит, выровненных по левому краю, которые определяют адрес. Маска равна или меньше длины адреса * 8 (то есть 32 бита для IPv4 и 128 для IPv6). Поле групповой мультикаст адрес содержит адрес группы и имеет число байт, равное указанному в поле длина адреса. Формат кодированного адреса отправителя показан на Рисунок 4.4.9.5.5.

Графическое представление двухмерного преобразования по формуле [

Рисунок 2.5.2. Графическое представление двухмерного преобразования по формуле [2.5.1]

DCT обеспечивает сжатие на уровне 0.5-1.0 бит/пиксель при хорошем качестве изображения. Сжатие требует времени, а максимально приемлемым временем задержки при пересылке изображения является 5 секунд. На Рисунок 2.5.3 приведена качественная оценка четкости и соответствия оригиналу изображения в зависимости от величины сжатия (DCT). Если использовать скорость обмена 64 кбит/с, то степени сжатия 0,01 бита на пиксель будет соответствовать время передачи изображения 0,04 секунды, а сжатию 10 - время передачи 40сек.

Иллюстрация реализации протокола мультикастинг маршрутизации PIM

Рисунок 4.4.9.5.1. Иллюстрация реализации протокола мультикастинг маршрутизации PIM

Получатель посылает PIM-joint пакет в RP, устанавливая канал от RP до получателя. Из рисунка видно, что исходный маршрут d-c-b-a длиннее оптимального d-b-a. Последний может быть реализован после посылки PIM-joint команды от a к d.

При решении транспортных задач в мультимедиа чаще используется протокол UDP (малая избыточность и отсутствие подтверждений).

Использование протокола proxy ARP

Рисунок 4.4.7.1. Использование протокола proxy ARP

Не трудно видеть, что в смешанном протоколе ARP нескольким IP-адресам ставится в соответствие один и тот же физический адрес. Поэтому системы, где предусмотрен контроль за соответствием физических и IP-адресов, не могут работать со смешанным протоколом ARP. Главным преимуществом этого протокола является то, что он позволяет путем добавления одного маршрутизатора (Gateway) подключить к Интернет еще одну сеть, не изменяя таблиц маршрутизации в других узлах. Этот протокол удобен для сети, где есть ЭВМ, не способная работать с субсетями. Протокол используется при построении сетей Интранет.

известного французского

Рисунок известного французского художника Клода Серрэ из книги “Черный юмор и люди в белом” (см. начало раздела) может служить иллюстрацией того, к чему может привести использование протокола tcp при передаче изображения в реальном масштабе времени. Предположим, что в процессе передачи изображения носа пакеты были повреждены, тогда спустя некоторое время, определяемое размером окна (TCP), будет проведена повторная их передача. Тем временем переданные ранее пакеты будут использованы для построения изображения, а часть картинки, содержавшаяся в пакетах, посланных вместо поврежденных, будет отображена совсем не там, где это следует. Реально из-за повреждения пакетов возможны в этой версии и более тяжелые искажения изображения. Именно это является причиной использования UDP для передачи видео и аудио информации при видео и аудио конференциях (еще лучшего результата можно достичь, использую протокол RTP). Протокол UDP не требует подтверждения и повторной передачи при ошибке доставки. Поврежденные пакеты вызовут искажения изображения (или звука) лишь локально.

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

Стандарт MPEG

Стандарт MPEG-2 является усовершенствованием MPEG-1 и базируется на схеме шифрования с потерями и передачи без потерь. Кодирование в MPEG-2 идентично используемому в MPEG-1 (I- P- и B-кадры; В-кадры не используются). I-кадр (Intracoded) представляет собой изображение, закодированное согласно стандарту JPEG при полном разрешении по яркости и половинном разрешении по цвету. Такие кадры должны появляться периодически. Эти кадры обеспечивают совместимость с MPEG-1, и исключают влияние накопления ошибок в процессе передачи. P-кадры (Predictive) содержат отличие блоков в последнем кадре изображения (базируются на идее макроблоков).
B-кадры (Bidirectional) характеризуют отличие двух последовательных изображений. Здесь применено двойное косинусное преобразование с числом коэффициентов 10*10 (против 8*8 в MPEG-1). MPEG-2 предназначен для широковещательного телевидения (включая прямое спутниковое - DBS) и для записи на CD-ROM и поддерживает четыре разных стандартов разрешения: 352*240 (низкое), 720*480 (базовое), 1440*1152 (высокое-1440) и 1920*1080 (высокое). Низкое разрешение служит для обеспечения совместимости с MPEG-1. Базовое разрешение ориентировано на работу со стандартом NTSC. Последние два стандарта относятся к телевидению высокого разрешения (HDTV). Помимо этого MPEG-2 поддерживает 5 профайлов для различных прикладных областей. Основной профайл ориентирован на общие приложения с базовым разрешением. Простой профайл сходен с основным профайлом, но не работает с B-кадрами, чтобы облегчить процедуры кодирования/декодирования. Остальные профайлы служат для обеспечения масштабируемости и работы с HDTV, они отличаются цветовым разрешением и форматами информационных потоков. Скорость передачи данных для каждой комбинации разрешения и профайла различна и лежит в диапазоне от 3 до 100 Мбит/c. Для обычного ТВ характерна скорость 3-4 Мбит/c. В таблице 2.5.2 представлены размеры кадров в битах для MPEG-1 и MPEG-2.

Качество DCT-изображения для различных

Рисунок 2.5.3. Качество DCT-изображения для различных значений сжатия информации (картинка имеет разрешение 512*512 пикселей; заполненные квадратики соответствуют цветному изображению, а незаполненные - черно-белому)

Отображение графического образа может выполняться последовательно (примерно так, как мы читаем текст: слева-направо и сверху-вниз) или с использованием прогрессивного кодирования (сначала передается вся картинка с низким разрешением, затем последовательно четкость изображения доводится до максимальной). Последний метод весьма удобен для систем WWW, где просмотрев изображение низкого разрешения, можно отменить передачу данных улучшающих четкость и тем самым сэкономить время. Хорошо распознаваемое изображение получается при сжатии порядка 0,1 бита на пиксель.

Проблема сжатия и передачи движущегося изображения еще сложнее. Алгоритм кодирования такого изображения описан в рекомендациях CCITT H.261 и предполагает, что скорость передачи при этом лежит в интервале 40кбит/с - 2Мбит/с. Следует иметь в виду, что видео телефония и видеоконференции требуют синхронной передачи звука и изображения (стандарт H.221, например 46,4 Кбит/с для видео и 16 Кбит/с для звука). Нормальный формат телевидения имеет 625 и 525 строк развертки и частоту кадров 25-30 в секунду. Цветное телевидение использует сигналы R (red), G (green) и B (blue), причем яркость луча (y) определяется соотношением: Y = 0.30R + 0.59G + 0.11B (при отображении белого цвета). Информация о цветах определяется формулами: СB = B - Y и CR = R - Y. Зная величины y, CB и СR, можно восстановить значения R, G и B. При сжатии цветного изображения учитывается тот факт, что человеческий глаз извлекает большую часть информации из контуров предметов, а не из цветных деталей. Например в рекомендации CCIR 601 предлагается использовать полосу 13.5 Мгц для кодирования Y и только по 6.75 Мгц для СB и CR. Такая схема требует 216 Мбит/с, что в 3375 раза превышает возможности стандартного 64кбит/с B-канала ISDN. Приемлемыми решениями могут быть:

Если комбинация прямого и обратного DCT-преобразования не приводит к получению исходного объекта, то такого рода эффекты могут заметно усилиться. Для исключения этого время от времени производится передача непосредственно видеосигнала. Практически преобразователь изображения представляет чудо современной технологии, которое даст работу еще не одному поколению математиков и инженеров.

Нисколько не проще система передачи и мультиплексирования потока видео данных, который содержит помимо обычной информации описания формы движущихся объектов, векторы перемещения, коэффициенты дискретизации и многое другое. Схема передачи графической информации имеет 4-х уровневую, иерархическую структуру. Передача каждого кадра изображения начинается с 20-битного кода PSC (Picture Start Code, эта сигнатура позволяет выделить начало кадра изображения в общем потоке), далее следует 5-битовый код TR (Temporal Reference, временная метка, которая позволяет поместить соответствующую часть изображения в правильную точку экрана). Изображение пересылается частями, имеется 4 уровня: кадр, группа блоков GoB (Group of Blocks), макроблоки (MB) и просто блоки.

Ядро всей структуры составляет процедура передачи кадра (внутренний слой, существуют еще слои GoB, MB и блока, см. Рисунок 2.5.4, 2.5.5, 2.5.6)

Каскадный переключатель-мультиплексор

Рисунок 2.2.9. Каскадный переключатель-мультиплексор.

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

Рисунок 2.2.6. Кодирование сигнала с использованием манчестерского кода.

Манчестерский код достаточно неэффективно использует пропускную способность канала. Оба описанные выше кода требуют удвоения полосы для передачи данных. Этого можно избежать, используя схему цифровой фазировки DPLL - Digital Phase Locked Loop). Эта схема предполагает применение кодирования NRZI (non-return-zero-inverted). Здесь сигнал сначала кодируется с использованием кода NRZ и только затем последовательность преобразуется в NRZI. В процессе такого преобразования логический нуль из NRZ вызывает определенную модификацию исходного кода, в то время как логическая единица не приводит ни к каким вариациям. Здесь создаются условия, при которых количество переходов 0/1 и 1/0 в единицу времени достаточно велико, чтобы обеспечить надежную синхронизацию. Схема NRZI кодирования с использованием DPLL проиллюстрирована на Рисунок 2.2.7.

Методы преобразования и передачи изображения

2.5 Методы преобразования и передачи изображения

Передача изображения представляет собой наиболее тяжелую проблему, так как человеческий глаз с информационной точки зрения несравненно совершеннее уха.

В 1902 году Артур Корн (Германия) запатентовал систему фотоэлектрического сканирования изображения, а в 1910 году заработала первая международная факсимильная связь Берлин-Париж-Лондон. До 60-х годов этого века рынок факсимильной аппаратуры был ограничен.

В 1968 году CCITT разработала рекомендации по факсимильному оборудованию, которое было способно передавать страницу за 6 минут при разрешении 3.85 линий на мм. Позднее в 1976 году аналоговая факсимильная техника была улучшена. Это позволило сократить время передачи страницы до 3 минут. В 1980 году разработан стандарт для цифровых факс-машин (группа 3), здесь уже предусматривается сжатие информации, что позволяет сократить время передачи страницы до 1 мин при скорости передачи 4800 бит/с. Следует иметь в виду, что сжатие информации в сочетании с ошибками пересылки может приводить к неузнаваемости изображения локальному или полному. По этой причине число линий сканирования, которые используются при обработке изображения, с целью сжатия может варьироваться (1-4) и определяется в результате диалога между отправителем и получателем, а передача каждой скан-линии завершается довольно длинным кодом, предназначенным для надежного распознавания завершения строки сканирования, а также коррекции ошибок. Факсимильное оборудование группы 3 может и не обеспечивать сжатия передаваемых (принимаемых) данных. В 1984 году разработаны требования к факс-аппаратам группы 4. Система базируется на двухмерной системе кодирования изображения (MMR - Modified Modified Reed).

Факсимильное оборудование поделено на 4 группы. Первая группа практически совпадает с традиционным фототелеграфным оборудованием (6 минут на страницу при разрешении 3.85 линий на миллиметр). Динамической вариации кодовой таблицы не предусмотрено. При этом для кодирования очередной линии сканирования используются результаты, полученные для предшествующей линии.
Следует учитывать, что зона сканирования факс-машины больше размера изображения и всегда имеются пустые строки и поля, что предоставляет дополнительные возможности для сжатия передаваемой информации. Существует три режима кодирования: вертикальный, горизонтальный и проходной. Последний режим реализуется, когда позиция в эталонной строке a2 находится слева от b1 (см. Рисунок 2.5.1; вериткальному и горизонтальному режиму соответствует нижняя часть рисунка). При “вертикальном” режиме кодирования (a2 справа от b1 и |b1a1|) позиция b1 кодируется относительно позиции a1. Относительное положение b1a1 может принимать одно из семи значений V(0), VR(1), VR(2), VR(3), VL(1), vL(2) и VL(3) (см. табл. 2.5.1). Индексы r и l указывают на то, что b1 находится справа или слева по отношению к a1, а число в скобках обозначает расстояние b1a1. Если используется “горизонтальный” режим кодирования (a2 справа от b1 и |b1a1|>3), длины b0b1 и b1b2 отображаются с помощью кодовой комбинации H+M(b0b1)+M(b1b2). H представляет собой код 001, взятый из двумерной кодовой таблицы. M(b0b1) и M(b1b2) являются кодовыми словами, которые характеризуют длину и цвет субстрок b0b1 и b1b2 соответственно.

Мультиплексирование аудио и видео данных в MPEG-и MPEG-(внизу)

Рисунок 2.5.8. Мультиплексирование аудио и видео данных в MPEG-1 и MPEG-2 (внизу)

Преобразование аналогового сигнала в цифровую последовательность осуществляется в MPEG-2 с помощью кодеков, создавая первичный поток в 140 Мбит/с, который затем преобразуется для передачи через стандартные каналы 1,5 и 15 Мбит/с (например, для прямого широковещательного, спутникового телевидения). В соответствии со стандартом сжатия данных H.320 можно обеспечить передачу видео + аудио по каналу 56 кбит/с с низким разрешением и частотой 1 кадр/сек. Смотри раздел "Видеоконференции по каналам ISDN и Интернет".

Интерактивное телевидение

В последнее время благодаря широкому внедрению цифрового телевидения и новых стандартов передачи изображения (MPEG-2) открылись возможности для "телевидения по требованию" (интерактивного телевидения) - системы, где клиент может самостоятельно и индивидуально формировать ТВ-программу. Первые опыты такого рода относятся к 1995 году. Такие системы базируются на существующих сетях кабельного телевидения. Но развитие оптоволоконных технологий позволяют ожидать полной интеграции кабельного цифрового телевидения и информационных сетей Интернет. Следует, впрочем, заметить, что оптоволокно в каждом жилище является пока непозволительной роскошью. Общая схема такой системы показана на Рисунок 2.5.9.

NRZI-кодирование

Рисунок 2.2.7. NRZI-кодирование

Симметричная скрученная пара проводов с волновым сопротивлением 120 Ом обеспечивает пропускную способность 2048 Мбит/с (система кодирования HDB3, длина проводов ~100м), а 100 Ом - 1544 Мбит/с (амплитуда сигналов 3 в, система кодирования B8ZS). Номинальное значение перепада обычно составляет 750 мВ.

Наиболее простая схема передача данных путем представления и с помощью двух уровней напряжения не применяется из-за того, что линия обычно используется для подачи на оконечное (терминальное) оборудование. Проблема может быть решена, если характеризуется 0 вольт (приращение над постоянным уровнем), а попеременно сигналами положительной и отрицательной полярности (AMI - Alternate Mark Inversion). Такая схема создает проблему синхронизации, когда подряд следует большое число нулей. Необходимо, чтобы было достаточное число переходов 0->1 и 1->0 в единицу времени. Существует также схема ADI (Alternate Digit Inversion), где инверсия полярности производится для каждого из передаваемых двоичных разрядов. Но эта схема менее эффективна.

По этой причине система кодирования AMI была модифицирована в HDB3 (High Density Bipolar 3). Цифра 3 указывает на максимально возможное число последовательных нулей в кодовой последовательности. AMI требует, чтобы передавались попеременно сигналами противоположной полярности, так последовательность 11011 должна быть передана как +-0+-. HDB3 заменяет любую группу из 4 нулей последовательностью из 3 нулей, за которой следует нарушение последовательности отображения единиц. Таким образом, последовательность 11000001 будет отображена как +-000-0+ (возможен инверсный вариант, когда символы + заменяются на - и наоборот). Дальнейшего улучшения балансировки сигнала можно достичь, если заменить код, содержащий 4 нуля подряд, последовательностью b00v (b - обычный биполярный сигнал, v - нарушение последовательности). В США используют схему кодировки B8ZS (Bipolar with 8 Zeros Substitution), где 8 нулей кодируются как 00b0vb0v. В 1986 году ansi принял решение о введение схемы кодирования 2B1Q (2 Binary into 1 Quaternary). При этой схеме каждая пара бит преобразуется в четверичные элементы +3 +1 -1 -3. Код синхронизации (SW - Synchronization Word) при этом содержит 9 четверичных элементов, повторяющихся каждые 1.5 мс:

+3 +3 -3 -3 -3 +3 -3 +3 +3 (+3 соответствует +2.5 В)

В Германии используется схема кодировки 4B3T (4 двоичных разряда кодируются в 3 циклических кода).

Двоичная информация передается блоками, обычно зазываемыми кадрами (или пакетами). В рамках системы 2B1Q для передачи 144 кбит/с требуется частота модуляции не менее 72 кбод. На практике для передачи кадров и выполнения функций управления необходимо создать дополнительные виртуальные каналы. Это доводит требуемую частоту модуляции до 80 кбод. Сводные данные по наиболее популярным схемам кодирования приведены в табл. 2.2.1.

Передача цифровых кодов по передающей линии

Рисунок 2.2.1 Передача цифровых кодов по передающей линии

На практике число нулей или единиц следующих подряд не лимитировано. По этой причине на принимающей стороне при этом рано или поздно возникает проблема синхронизации временных шкал передатчика и приемника. Для решения этой проблемы существует два метода передачи данных: синхронный и асинхронный. Асинхронный метод используется для относительно низкоскоростных каналов передачи и автономного оборудования. Синхронный метод применяется в скоростных каналах и базируется на пересылке синхронизующего тактового сигнала по отдельному каналу или путем совмещения его с передаваемыми данными. При наличии синхронизации приемника и передатчика можно допустить более длинные последовательности нулей или единиц, что способствует повышению пропускной способности. На Рисунок 2.2.2 показана схема канала, использующая технику импульсно-кодовой модуляции. Импульсно-кодовая модуляция (ИКМ) была предложена в 30-ые годы 20-го века, но реализована лишь в 1962 году.

Ping и Traceroute

4.5.1 Ping и Traceroute

При работе в Интернет время от времени возникают ситуации, когда нужно определить, работоспособен ли тот или иной канал или узел, а в случае работы с динамическими протоколами маршрутизации выяснить, по какому из каналов вы в данный момент работаете. Используется эта процедура и для оценки вероятности потери пакетов в заданных сегментах сети или каналах. Для решения этих задач удобна программа Ping.

Ping - это процедура, которая базируется на ICMP- и UDP-протоколах пересылки дейтограмм и служит для трассировки маршрутов и проверки работоспособности каналов и узлов (в некоторых программных пакетах эта команда имеет имена trace, hopcheck, tracert или traceroute). Для решения поставленной задачи PING использует отклики протокола ICMP. Применяется PING и при отладке сетевых продуктов. Трассировка может выполняться, например, посредством команды ping -q (пакет PCTCP). При выполнении этой команды ЭВМ сообщит вам Internet адреса всех промежуточных узлов, их имена и время распространения отклика от указанного вами узла. Следует иметь в виду, что трассировка осуществляется непосредственно с помощью IP-протокола (опция записи адресов промежуточных узлов). Ниже приведен пример использования команды Ping. Если вы просто напечатаете команду ping (пакет PCTCP), то ЭВМ выдаст на экран справочную таблицу по использованию этой команды:

Usage:

ping [-options] host

options:

-d [bytes]	dump input packet	(пропечатка входных пакетов).
-d# [bytes]	dump output packet	(пропечатка выходных пакетов).
-e	cancel extended security	(отмена дополнительных мер безопасности)
-i seconds	IP time to live	(установка времени жизни пакетов IP)
-j dest 1...dest n	loose source routing	(свободная маршрутизация).
-k dest 1...dest n	strict source routing	(принудительная маршрутизация).
-l length	set length of icmp data	(установить длину данных для ICMP).
-n times	ping host times number of times	(провести зондирование ЭВМ заданное число раз).
-o	no-op option	(ни каких опций для операций).
-p precedence	set IP precedence	(установка IP-предпочтения).
-q	trace route	(трассировка маршрута).
-r	record route	(запись маршрута).
-s level [authority]	basic security	(базовый уровень безопасности).
-t	ping forever	(режим бесконечного ping).
-v type	set type of service	(установка типа операции).
-w seconds	time to wait for answer	(установка времени ожидания ответа).
-x [{1|3 dest1..destn}]	timestamp option	(опция временных меток).
-z	quiet mode	(набор статистики отключен).

<
/p> Команда трассировки маршрута ИТЭФ - сервер научно-исследовательской станции США Мак-Мурдо в Антарктиде (запись в файл route.txt):

ping -q mcmurdo-gw.mcmurdo.gov > route.txt

Содержимое файла route.txt будет иметь вид:

hop 1:	193.124.224.190	???	имя для GW ИТЭФ пока не придумано
hop 2:	193.124.137.13	MSU-Tower.Moscow.RU.Radio-MSU.net	Вперед, в космос
hop 3:	193.124.137.9	NPI-MSU.Moscow.RU.Radio-MSU.net	Через спутник "Радуга"
hop 4:	193.124.137.6	DESY.Hamburg.DE.Radio-MSU.net	пакеты совершили мягкую посадку в Гамбурге, ДЕЗИ
hop 5:	188.1.133.56	dante.WiN-IP.DFN.DE
hop 6:	193.172.4.12	duesseldorf2.empb.net
hop 7:	193.172.4.8	amsterdam6.empb.net
hop 8:	193.172.12.6	Amsterdam1.dante.net	Пересекаем Атлантический океан
hop 9:	194.41.0.42	New-York1.dante.net	вступили на землю США
hop 10:	192.103.63.5	en-0.cnss35.New-York.t3.ans.net
hop 11:	140.222.32.222	mf-0.cnss32.New-York.t3.ans.net
hop 12:	140.222.56.2	t3-1.cnss56.Washington-DC.t3.ans.net
hop 13:	140.222.145.1	t3-0.enss145.t3.ans.net
hop 14:	192.203.229.243	SURA2.NSN.NASA.GOV	Снова в космос
hop 15:	128.161.166.1	GSFC8.NSN.NASA.GOV	но теперь через американский
hop 16:	128.161.232.1	GSFC12.NSN.NASA.GOV	спутник
hop 17:	128.161.1.1	ARC1NEW.NSN.NASA.GOV
hop 18:	192.203.230.2	ARC1.NSN.NASA.GOV
hop 19:	192.100.12.2	ARC2.NSN.NASA.GOV
hop 20:	128.161.115.2	MCMURDO.NSN.NASA.GOV	Оденьте шапку, мы в Антарктиде!
Target	157.132.100.1	reached on hop 21	round-trip time 1370 ms

Фантастика, мы пересекли туда и обратно Европу, два океана и США с востока на запад, побывали в Антарктиде и все это менее чем за полторы секунды.

Ping позволяет не только проверить работоспособность канала, но измерить ряд его характеристик, включая надежность (например, версия ping для SUN):

PING -s cernvm.cern.ch 100 64 (пакеты по 100 байт посылаются 64 раза)

108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq=0.


time=606. Ms

.............. (результаты пересылки пакетов с номерами 1-61 опущены)

108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq=62. time=667. Ms

108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq=63. time=628. Ms

---- PING Statistics ----

64 packets transmitted, 63 packets received, 1% packet loss (процент потерянных пакетов)

round-trip (ms) min/avg/max = 600/626/702

Для получения большей точности следует послать большее число пакетов. В последней строке приведены результаты измерения RTT, где представлены минимальное/среднее/максимальное значения.

Наибольшее число модификаций имеет BSD-версия ping, если на вашей ЭВМ нет этой удобной программы, можно воспользоваться общедоступной версией по адресу:

ftp.uu.net /unix/bsd-sources/sbin/ping (см. также приложения).

Сходную информацию позволяет получить и программа traceroute (использует непосредственно IP-пакеты):

traceroute -n cernvm.cern.ch

traceroute to crnvma.cern.ch (128.141.2.4) 30 hops max, 40 byte packets

1 193.124.224.50 3 ms 2 ms 2 ms

2 194.85.112.130 3 ms 3 ms 3 ms

3 194.67.80.5 4 ms 3 ms 3 ms

4 193.124.137.6 534 ms 534 ms 534 ms

5 188.1.56.5 545 ms 545 ms 546 ms

6 193.172.4.12 558 ms (ttl=59!) 549 ms (ttl=59!) 548 ms (ttl=59!)

7 193.172.4.30 580 ms (ttl=58!) 581 ms (ttl=58!) 581 ms (ttl=58!)

8 193.172.24.10 586 ms 585 ms 597 ms

9 192.65.185.1 593 ms 587 ms 598 ms

10 128.141.2.4 628 ms 602 ms 619 ms

При написании программ, использующих протокол ICMP, полезно воспользоваться отладочной опцией PING, которая позволяет получить на экране шестнадцатеричный образ посылаемого и получаемого пакетов:

ping -d# 300 ns.itep.ru

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

Dump of outgoing packet

Version = 4 IP header length = 5 Precedence = Routine

Type of Service = Normal

Total length = 284 Protocol = 1 TTL = 64

45 00 01 1C 00 02 00 00 40 01 71 29 C0 94 A6 81 C1 7C E0 23 IP-заголовок

08 00 8D BD E9 03 00 01 ... ICMP-заголовок

host responding, time = 60 ms

Выдачи ради экономии места сильно сокращены. Тексты пакетов начинаются с кодов IP-версии (=4) и длины заголовка (=5), далее следует байт TOS=0, два байта длины пакета (01 1С) и т.д. в соответствии с требованиями IP-протокола.

ping -d 300 ns.itep.ru (команда получения текста пакета-отклика на запрос)

host responding, time = 25 ms

Dump of incoming packet

Version = 4 IP header length = 5 Precedence = Routine

Type of service = Normal

Total length = 284 Protocol = 1 TTL = 254

45 00 01 1C EE 29 00 00 FE 01 C5 00 C1 7C E0 23 C0 94 A6 81

00 00 93 BD EB 03 00 01 ..............

В принципе, процедуру Ping и Traceroute можно реализовать и с привлечением протоколов UDP и TCP. Рассмотрим следующую модель реализации Traceroute :

Посылаем последовательно по адресу IP(URL) IP-пакеты со значением TTL=1, 2,... и т.д. Если до больше одного шага, соответствующий маршрутизатор, размещенный по пути следования к адресату, уничтожит посланный пакет и вернет ICMP-сообщение: Time Exceeded (тип ICMP-сообщения=11), указав при этом IP-адрес узла, где это произошло. Послав запрос типа get_name_by_address для присланного IP, можно получить имя узла, откуда пришло данное уведомление. Отсутствие сообщения Time Exceeded (например, после трех попыток) будет говорить о достижении -адресата. В результате такой последовательности посылок будет получена исчерпывающая информация о пути до указанной цели.

Для данной методики реализации traceroute не существенно, какой протокол использовать, UDP, ICMP или TCP.

В некоторых небольших узлах Интернет

4.4.14.2 Почтовый протокол POP3

В некоторых небольших узлах Интернет бывает непрактично поддерживать систему передачи сообщений (MTS - Message Transport System). Рабочая станция может не иметь достаточных ресурсов для обеспечения непрерывной работы SMTP-сервера [RFC-821]. Для “домашних ЭВМ” слишком дорого поддерживать связь с Интернет круглые сутки.

Но доступ к электронной почте необходим как для таких малых узлов, так и индивидуальных ЭВМ. Для решения этой проблемы разработан протокол POP3 (Post Office Protocol - Version 3, STD: 53. M. Rose, RFC-1939). Этот протокол обеспечивает доступ узла к базовому почтовому серверу.

POP3 не ставит целью предоставление широкого списка манипуляций с почтой, он лишь получает и стирает почтовые сообщения. Более продвинутый и сложный протокол IMAP4 обсуждается в RFC-2060 (порт 143). Об аутентификации в POP3 можно прочесть в документе RFC-1734.

В дальнейшем ЭВМ-клиентом будет называться машина, пользующаяся услугами POP3, а ЭВМ-сервером – сторона, предлагающая услуги POP3.

Когда пользователь ЭВМ-клиента хочет послать сообщение, он устанавливает SMTP связь с почтовым сервером непосредственно и посылает все, что нужно через него. При этом ЭВМ POP3-сервер не обязательно является почтовым сервером.

В исходный момент ЭВМ POP3-сервер прослушивает TCP-порт 110. Если ЭВМ-клиент хочет воспользоваться услугами POP3-сервера, то устанавливает с ним TCP связь. По установлении связи POP3-сервер посылает клиенту уведомление (например, +OK POP3 server ready) и сессия переходит в фазу авторизации (см. также RFC-1734, -1957). После этого может производиться обмен командами и откликами.

Команды POP3 состоят из ключевых слов (3-4 символа), за которыми могут следовать аргументы. Каждая команда завершается парой символов CRLF. Как ключевые слова, так и аргументы могут содержать только печатаемые ASCII-символы. В качестве разделителя используются символы пробела. Каждый аргумент может содержать до 40 символов.

Сигнал отклика в POP3 содержит индикатор состояния и ключевое слово, за которым может следовать дополнительная информация. Отклик также завершается кодовой последовательностью CRLF. Длина отклика не превышает 512 символов, включая CRLF. Существует два индикатора состояния: положительный - "+OK" и отрицательный "-ERR" (все символы прописные).

Отклики на некоторые команды могут содержать несколько строк. В этом случае последняя строка содержит код завершения 046 ("."), за которым следует CRLF.

На практике многострочные отклики для исключения имитации завершаются последовательностью CRLF.CRLF.

В процессе авторизации клиент должен представить себя серверу, передав имя и пароль (возможен вариант посылки команды APOP). Если авторизация успешно завершена, сессия переходит в состояние транзакции (TRANSACTION). При получении от клиента команды QUIT сессия переходит в состояние UPDATE, при этом все ресурсы освобождаются и TCP связь разрывается.

На синтаксически неузнанные и неверные команды, сервер реагирует, посылая отрицательный индикатор состояния.

POP3 сервер может быть снабжен таймером пассивного состояния (10 мин.), который осуществляет автоматическое прерывание сессии. Приход любой команды со стороны клиента сбрасывает этот таймер в нуль.

Сервер нумерует все передаваемые сообщения из своего почтового ящика и определяет их длину. Положительный отклик начинается с +OK, за ним следует пробел, номер сообщения, еще один пробел и длина сообщения в октетах. Завершается отклик последовательностью CRLF. Переданные сообщения удаляются из почтового ящика сервера. Все сообщения, передаваемые во время сессии POP3 должны следовать рекомендациям формата Интернет сообщений [RFC822].

В состоянии транзакции клиент может посылать серверу последовательность POP3 команд, на каждую из которых сервер должен послать отклик. Далее следует краткое описание команд, используемых в состоянии транзакция.

LIST [сообщение]

Аргументы: номер сообщения (опционно), который не может относиться к сообщению, помеченному как удаленное. Команда может быть выдана только в режиме TRANSACTION. При наличии аргумента сервер выдает положительный отклик, содержащий информационную строку сообщения. Такая строка называется скэн-листингом сообщения (scan listing). scan listing состоит из номера сообщения, за которым следует пробел и число октетов в сообщении. Сообщения, помеченные как удаленные, не пересылаются. Примером отрицательного отклика может служить: -ERR no such message.

Примеры использования команды LIST:

Клиент выдает команду: LIST

Сервер откликается: +OK 2 messages (320 octets)

Сервер: 1 120

Сервер: 2 200

Сервер: .

...

Клиент: LIST 2

Сервер: +OK 2 200

...

К: LIST 3

С: -ERR no such message, only 2 messages in maildrop

Здесь и далее символом К обозначается клиент, а символом С - сервер.

STAT - аргументов не использует, возможный отклик +OK nn mm, где nn – номер сообщения, а mm – его длина в байтах. Пример использования:

К: STAT

С: +OK 2 320

QUIT - аргументов не использует, возможный отклик +OK.

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

К: QUIT

С: +OK dewey POP3 server signing off.

RETR msg (msg – номер сообщения)

Если POP3-сервер выдал положительный отклик, то за начальным +OK следует сообщение с номером, указанным в аргументе. Отрицательный отклик имеет вид -ERR no such message.

Пример использования команды:

К: RETR 1

С: +OK 120 octets

С:

С: .

DELE msg (msg – номер сообщения)

Сервер POP3 помечает сообщение как удаленное. Любая ссылка на это сообщение в будущем вызовет ошибку. При этом само сообщение не удаляется пока сессия не войдет в режим UPDATE.

Пример использования команды:

К: DELE 1

С: +OK message 1 deleted

...

К: DELE 2

С: -ERR message 2 already deleted

NOOP (не использует каких-либо аргументов). При реализации этой команды сервер не делает ничего, лишь посылает положительный отклик.

RSET (не использует каких-либо аргументов)

Если какие-либо сообщения помечены как удаленные, сервер POP3 удаляет эту пометку и возвращает положительный отклик. Например:

К: RSET

С: +OK maildrop has 2 messages (320 octets)

Если сессия завершается не по команде клиента, то перехода в состояние UPDATE не производится, а сообщения не удаляются из почтового ящика. Далее следует описание команд, используемых в состоянии UPDATE.

Ряд команд не входят в перечень обязательных (являются опционными).

TOP msg n, где msg – номер сообщения, а n – число строк (используется только в режиме TRANSACTION).

При положительном отклике на команду TOP сервер посылает заголовки сообщений и вслед за ними n строк их текста. Если n больше числа строк в сообщении, посылается все сообщение.

UIDL [msg], где msg – номер сообщения является опционным (Unique-ID Listing).

Если сервер выдаст положительный отклик, будет выдана строка, содержащая информацию о данном сообщении. Эта строка называется уникальным идентификатором сообщения ("unique-id listing"). При отсутствии аргумента аналогичная информация выдается для каждого из сообщений в почтовом ящике. Уникальный идентификатор сообщения состоит из 1-70 символов в диапазоне от 0x21 до 0x7E. Сообщения в почтовом ящике должны характеризоваться различными идентификаторами. Пример использования команды:

К: UIDL

С: +OK

С: 1 whqtswO00WBw418f9t5JxYwZ

С: 2 QhdPYR:00WBw1Ph7x7

USER name, где name – характеризует почтовый ящик сервера.

Команда используется на фазе авторизации или после неудачного завершения команд USER или PASS. При авторизации клиент должен сначала послать команду USER и лишь после получения положительного отклика команду PASS. Команда может вызвать следующие отклики:

+OK name is a valid mailbox

-ERR never heard of mailbox name

Примеры использования команды USER:

К: USER frated

С: -ERR sorry, no mailbox for frated here

...

К: USER mrose

С: +OK mrose is a real hoopy frood

PASS string (string – пароль для доступа к почтовому серверу)

Команда работает в режиме авторизации сразу после команды USER. Когда клиент выдает команду PASS, сервер использует аргументы команд USER и PASS для определения доступа клиента к почтовому ящику. На команду PASS возможны следующие отклики:

+OK maildrop locked and ready

-ERR invalid password

-ERR unable to lock maildrop

Пример диалога при использовании команды PASS:

К: USER mrose

С: +OK mrose is a real hoopy frood

К: PASS secret

С: -ERR maildrop already locked

...

К: USER mrose

С: +OK mrose is a real hoopy frood

К: PASS secret

С: +OK mrose's maildrop has 2 messages (320 octets)

APOP name digest, где name – идентификатор почтового ящика, а digest – дайджест сообщения – MD5 (RFC-1828). Команда используется только на стадии авторизации.

Обычно любая сессия начинается с обмена USER/PASS. Но так как в некоторых случаях подключения к серверу POP3 может осуществляться достаточно часто, возрастает риск перехвата пароля. Альтернативным методом авторизации является использование команды APOP. Сервер, который поддерживает применение команды APOP, добавляет временную метку в свое стартовое уведомление. Синтаксис временной метки соответствует формату идентификаторов сообщений, описанному в [RFC822] и должны быть уникальными для всех заголовков уведомлений. Так для UNIX-приложений синтаксис временной метки должен иметь вид:

где `process-ID' представляет собой десятичное значение PID процесса, clock – десятичное показание системных часов, а hostname – полное имя домена, где размещен сервер POP3.

Клиент POP3 фиксирует временную метку и выдает команду APOP. Параметр `name' семантически идентичен параметру `name' команды USER. Параметр `digest' вычисляется с использованием алгоритма MD5 [RFC1321] для строки, состоящей из временной метки (включая угловые скобки) за которой следует строка пароля, которая известна только клиенту и серверу. Параметр `digest' содержит 16 октетов, которые пересылаются в шестнадцатеричном формате с использованием строчных ASCII символов. Сервер, получив команду APOP, проверяет принятый дайджест и если он корректен, посылает положительный отклик клиенту. Сессия при этом переходит в состояние транзакции. В противном случае посылается отрицательный отклик и состояние сессии не изменяется. С целью обеспечения безопасности для каждого конкретного пользователя и сервера должен использоваться либо метод доступа USER/PASS, либо APOP, но не в коем случае оба метода попеременно.

Сервер перед закрытием канала по команде QUIT должен удалить из почтового ящика все сообщения, которые были перенесены с помощью команд RETR.

Предполагается, что все сообщения, передаваемые в ходе сессии POP3, имеют текстовый формат Интернет в соответствии с документом [RFC822].

Данный сервер частично создан на

Предисловие


Telecommunication technologies - телекоммуникационные технологии (v2.1)
Данный сервер частично создан на средства, выделенные по проектам РФФИ (99-07-90102 и 01-07-90069). В основу материалов легли тексты книг автора "Протоколы и ресурсы Интернет" (Радио и связь, М. 1996) и "Сети Интернет. Архитектура и протоколы" (Сиринъ, М. 1998), а также "Протоколы Интернет. Энциклопедия" ("Горячая линия - Телеком", М. 2001), которые базировались на двух курсах, читаемых студентам кафедры "Телекоммуникационные сети и системы" МФТИ (факультет ФПФЭ) - "Каналы и сети передачи данных", "Протоколы Интернет".



В сумме эти книги содержат около 1850 страниц, а на данном сервере размещается более 2600 стандартных книжных страниц (формат A4, times-12, следует заметить, что содержимое книг частично перекрывается). Причин здесь несколько.
Во-первых, ограниченность времени и жанр лекций не позволяют разместить полные описания протоколов (конспективность здесь неизбежна) и представить необходимые справочные материалы. Сервер, включая рисунки и формулы, содержит более 1000 файлов.
Во-вторых, данное направление науки и технологии развивается стремительно и отследить прогресс в этой отрасли с использованием техники книжных издательств практически невозможно (первая книга готовилась к печати с уровня машинных файлов около года, вторая - 4 месяца). Автор решил попытаться решить эту проблему методами современных сетевых технологий. Ускорение, которое достижимо в этом случае очевидно. Но у этого метода есть и несомненные недостатки - в книжном издательстве за ошибки отвечает редактор и корректор, а здесь автору это свалить не на кого. Практически невозможно избежать и некорректности сетевых ссылок, в Интернет все меняется слишком быстро. То что ещё вчера было доступно, сегодня может более не существовать. Зато вместо этого появляется несколько новых, чаще всего более емких ссылок. По этой причине я заранее прошу извинения за ошибки, содержащиеся в текстах, размещенных на сервере.
Эта работа заняла несколько лет, сейчас мне очень трудно обнаружить даже некоторые очевидные описки и ошибки, ведь я вижу не тот текст, что читаете вы, а тот, который я намеревался написать, а это не одно и то же. Буду весьма признателен читателям, обнаружившим любые ошибки и приславшим замечания. Это позволит мало-помалу привести материалы в должный порядок, сделать их более полными (общими силами это будет сделать легче). Надеюсь, что неизбежные ошибки не слишком испортят настроение читателей. Будут приниматься и пожелания по размещению новых материалов. Предполагается размещение новых материалов и других авторов. Окончательное решение по вопросу постановки таких статей будет приниматься мной. Авторские права в таких случаях будут неукоснительно соблюдаться.
Форма сервера позволяет непрерывно дополнять и корректировать материалы. В настоящее время содержимое сервера ориентировано на широкий круг читателей и в силу этого страдает недостаточной строгостью, например, здесь отсутствуют теоретические обоснования многих формул или выбора того или иного сетевого решения. Позднее это может быть устранено путем введения дополнительных глав, посвященных теории телекоммуникаций.
Помимо стандартных гиперссылок каждая из статей содержит в верхней части кнопки управления. <previous> - для перехода к предыдущей статье; <up> - к предыдущему разделу; <down> - к следующему разделу; <next> - для перехода к следующей статье; а также кнопка <index>, которая служит для обращения к оглавлению. Объем статей (в килобайтах) указан с учетом рисунков, хранящихся в виде отдельных файлов. Самая правая клавиша <ПОИСК> осуществляет переход на страницу, где размещена форма, позволяющая выполнить поиск в пределах данного сервера. При этом выдаются ссылки на все статьи (и позиции), где имеются представленные ключевые слова.
Надеюсь, что данный сервер окажется для вас полезным.
В дальнейшем предполагается предложить версию сервера на CD со встроенной поисковой системой.


Для студентов и всех желающих создан тренажер для проверки знаний по отдельным разделам (saturn.itep.ru и http://knowtest.itep.ru). Для просмотра сервера желательно использовать версии Netscape communicator v4+ и MS Explorer с версией 5+. Тренажер и многие программы из http:/saturn.itep.ru работают исключительно с MS Explorer.
Для некоммерческих целей читатели могут использовать данные тексты без ограничений. Размещение полных текстов или фрагментов на других серверах без согласия автора не допускается. ©
Данная версия сервера сформирована с использованием базы данных MySQL, куда были помещены все статьи. Дизайн страниц и формирование индексов определяется шаблонами, что облегчает любые изменения. Программы для этого были подготовлены сотрудником ИТЭФ Михаилом Крикуном (admin@ol.ru). Им же была поставлена поисковая система. Сервер размещен на ЭВМ saturn.itep.ru, администратор - Роман Нилов (Roman@itep.ru).
По вопросам приобретения книги "Протоколы Интернет. Энциклопедия" ("Горячая линия - Телеком", Москва, 2001 год) следует обращаться к Занину Евгению Александровичу по телефону 287-49-56 (radios_hl@mtu-net.ru)

Зам. зав. кафедры "Телекоммуникационные сети и системы" МФТИ Нач. лаб. Института Теоретической и Экспериментальной Физики (semenov@itep.ru)

Семенов Юрий Алексеевич

Представление электрических сигналов в цифровой форме

2.2 Представление электрических сигналов в цифровой форме

Прогресс последних лет в области повышения пропускной способности каналов в заметной мере связан с развитием технологии передачи цифровых данных. Здесь нужно решить проблемы синхронизации, эффективного кодирования и надежной передачи. Чем шире импульс, тем большую энергию он несет, тем лучше отношение сигнал/шум, но тем ниже и предельная скорость передачи. Раньше каждому двоичному разряду соответствовал импульс или перепад в кодовой последовательности. Сегодня перепад возникает лишь при смене последовательности нулей на последовательность единиц или наоборот. Цифровой метод имеет целый ряд преимуществ перед аналоговым:

Высокую надежность. Если шум ниже входного порога, его влияние не ощущается, возможна повторная посылка кода.

Отсутствие зависимости от источника информации (звук, изображение или цифровые данные).

Возможность шифрования, что повышает безопасность передачи.

Независимость от времени. Можно передавать не тогда, когда информация возникла, а когда готов канал.

На рисунке 2.2.1В представлена уже не последовательность импульсов, а последовательность переходов из одного состояния в другое. При этом уровень +V соответствует логической , а -V - логическому . Переключение из состояния в состояние и наоборот (бод) уже не соответствует передаче одного бита.

Пример биполярного кодирования сигнала (схема RZ – return-to-zero)

Рисунок 2.2.5. Пример биполярного кодирования сигнала (схема RZ – return-to-zero)

Другой разновидностью такого рода кодирования является использование манчестерского кода. В этой схеме логической единице и нулю соответствует не уровни напряжения, а перепады. Так логической единице поставлен в соответствие переход с низкого уровня на высокий, а логическому нулю – с высокого на низкий (схема NRZ – non-return-to-zero). Пример представления сигнала с использованием манчестерского кода показан на Рисунок 2.2.6.

Пример Multilink-конфигурации

Рисунок 3.5.6. Пример Multilink-конфигурации

Так как межсетевые связи часто используют последовательные каналы (выделенные линии, радиомодемы и пр.), протокол PPP распространен достаточно широко. Протокол PPP служит и для создания межсетевых туннелей (протокол PPTP - Point to Point Tunneling Protocol). Протокол PPTP использует MTU=1532, номер порта 5678 и номер версии 0x0100, пакеты данных здесь транспортируются с использованием протокола инкапсуляции GRE V2 (см. сноску в начале раздела).

Пример передачи кадра в асинхронном режиме

Рисунок 2.2.3. Пример передачи кадра в асинхронном режиме

Одним из способов обеспечения надежной синхронизации является применение в приемнике частоты, например, в 8 раз больше частоты следования данных. При этом стробирование данных может производиться примерно в середине сигнала бита (см. Рисунок 2.2.4).

Процедуры Интернет

4.5 Процедуры Интернет

Номер раздела	Название раздела	Объем в страницах	Объем в кбайт
4.5	Процедуры Интернет	1	9
4.5.1	Ping и Traceroute	4	27
4.5.2	Finger	3	46
4.5.3	Удаленный доступ (Telnet)	8	48
4.5.4	Протокол пересылки файлов FTP	10	79
4.5.5	Протокол X-Windows	2	33
4.5.6	WWW	12	82
4.5.7	Протокол новостей NNTP	10	45
4.5.8	Поиск узлов и людей	1	3
4.5.9	Серверы подписки (LISTSERV)	12	38
4.5.10	Электронная почта	12	200
4.5.11	Gopher	4	27
4.5.12	WAIS	7	49
4.5.13	Система поиска файлов Archie	7	34
4.5.14	Современные поисковые системы	16	186
4.5.15	Диалог в локальных сетях и в Интернет	5	46
4.5.16	Некоторые другие процедуры Интернет	3	46
4.5.17	Сетевое моделирование	8	66

Данный раздел наиболее динамично развивающаяся часть Интернет-технологий. Одни виды услуг устаревают и выходят из употребления (Gopher, WAIS, MOSAIC), другие появляются вновь (поисковые машины, например Alta Vista, NetScape, MSExplorer и др.). В последнее время несравненно большее внимание стали уделять сетевой безопасности, системам поиска и диагностическим аспектам работы с сетями. Безопасность вышла на первые позиции из-за внедрения Интернет в область финансов и бизнеса. Последнее время активно развивается технология мультимедиа (интеграция с кабельным телевидением), сфера развлечений (игровые серверы) и информационно-поисковые системы на основе техники WWW.

Прокси-ARP

4.4.7 Прокси-ARP

Еще одна разновидность протокола ARP служит для того, чтобы один и тот же сетевой префикс адреса можно было использовать для двух сетей. Этот протокол называется смешанным протоколом ARP (proxy). Предположим, мы имеем сеть из четырех ЭВМ (1-4; Рисунок 4.4.7.1), которую бы мы хотели соединить с другой сетью из четырех ЭВМ (5-8), причем так, чтобы машины взаимодействовали друг с другом так, будто они принадлежат одной сети. Решить эту проблему можно, соединив эти сети через маршрутизатор M, работающий в соответствии со смешанным протоколом ARP (функционально это IP-мост). Маршрутизатор знает, какая из машин принадлежит какой физической сети. Он перехватывает широковещательные ARP-запросы из сети 1, относящиеся к сети 2, и наоборот. Во всех случаях в качестве физического адреса маршрутизатор возвращает свой адрес. В дальнейшем, получая дейтограммы, он маршрутизирует их на физические адреса по их IP-адресам.

Протокол PIM

4.4.9.5 Протокол PIM

Протокол PIM (Protocol Independent Multicast) призван решить проблемы маршрутизации для произвольного числа и расположения членов группы и для произвольного числа отправителей информации. В настоящее время протокол не является стандартом.

Главным преимуществом данного протокола является эффективная поддержка работы "рассеянных" мультикастинг-групп. Такие группы могут включать не только членов из разных автономных систем, но и находящихся на разных континентах. Протоколы MOSPF и DVMRP хороши для сетей, где нет ограничений по пропускной способности каналов.

PIM базируется на традиционных маршрутных протоколах, конкретно не связан ни с каким из них, им используются сформированные этими протоколами маршрутные таблицы. Существует два режима работы протокола - DM (для компактных групп) и SM (Protocol Independent Multicast-Sparse Mode (PIM-SM)). Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, RFC-2117, June 1997) (для рассеянных групп). В режиме DM протокол PIM строит дерево маршрутов аналогично DVMRP.

В режиме SM маршрутизаторы, имеющие членов мультикастинг-группы, посылают сообщения о присоединении к дереву рассылки в узлы, которые называются точками встречи (RP). Отправители используют RP для объявления о своем существовании, а получатели, чтобы узнать о новых отправителях. В качестве RP может использоваться любой маршрутизатор, поддерживающий протокол PIM.

Когда какой-то клиент хочет подключиться к некоторой группе, ближайший к нему маршрутизатор посылает специальное сообщение о включении в группу (PIM-joint) узлу, объявленному для данной группы точкой встречи (RP). Число RP в сети может быть произвольным. Узел RP пересылает сообщение о включении узлу-отправителю (или отправителям). Если маршрутизатор не имеет информации о RP, включается схема, работающая для компактных групп. При обработке сообщения о включении в группу промежуточные маршрутизаторы формируют часть дерева мультикастинг-маршрутов между RP и получателем.
При отправке мультикастинг- пакета соответствующий маршрутизатор посылает узлу RP регистрационное сообщение (PIM-register), куда вкладывается информационный пакет. Если используется несколько RP, отправитель должен посылать пакеты всем RP. Получатель же должен быть подключен лишь к одному из RP. В случае, когда сообщение о включении достигнет отправителя раньше, чем RP, подключение осуществляется, минуя RP. Если необходимо оптимизировать дерево доставки пакетов, маршрутизаторы-получатели должны послать сообщение о включении самому отправителю. После этого дерево соединений видоизменяется, некоторыми узлами, если требуется, посылается сообщение об отключении. Ниже приведен пример взаимодействия узлов при формировании дерева маршрутов в режиме SM-PIM (Рисунок 4.4.9.5.1).

Следует заметить, что большинство протоколов для маршрутизации мультимедийной информации формируют маршрут не от отправителя к получателю, а в обратном направлении. Это имеет под собой веские причины. Дерево рассылки должно быть построено так, чтобы поток отправителя как можно дольше и меньше разветвлялся. Желательно, чтобы разветвления происходили как можно ближе к получателю. Это соображение проиллюстрировано на Рисунок 4.4.9.5.2. На рисунке условно, в виде сетки маршрутизаторов (желтые кружочки) показан фрагмент сети Интернет. Зеленым прямоугольником отмечен передатчик, а голубыми кружочками приемники – члены группы. Маршруты от передатчика к приемникам можно проложить индивидуально (выделены зеленым цветом), а можно и “коллективно” (синий цвет). От передатчика до маршрутизатора отмеченного красным цветом следует один поток для всех приемников. Такое решение приводит к минимизации сетевой загрузки, ведь всем приемникам посылаются одни и те же пакеты. Чем позже их пути разойдутся, тем лучше. Именно этот алгоритм и реализует протокол PIM. Точки разветвления потоков на Рисунок 4.4.9.5.2 отмечены крестами (RP).

Протокол PPP

3.5 Протокол PPP

Протокол PPP (Point-to-Point Protocol; RFC-2716, -2701, -2688, -2687, -2686, -2615, -2516, -2509, -2508, -2507, -2484, -2472, -2433, -2420, -2419, -2364, -2363, -2290, -2284, -2153, -2125, -2097, -2043, -1994, -1993, -1990, -1989, -1979, -1978, -1977, -1976, -1975, -1974, -1973, -1969, -1968, -1967, -1963, -1962, -1915, -1877, -1841, -1764, -1763, -1762, -1663, -1662, -1661, -1638, -1619, -1618, -1598, -1570, -1552, -1378, -1377, -1334, -1332, -1331, и STD-51, cмотри также www.spitbrook.destek.com:81/pptp.txt) предназначен для решения тех же задач, что и SLIP, но лишен многих его недостатков, он служит для передачи мультипротокольных дейтограмм от одного узла к другому. Сам по себе список RFC, приведенный выше, впечатляющ. Он говорит о том, что данный протокол относится к числу наиболее важных и широко используемых. Это и понятно, большинство региональных сетей строится с использованием соединений точка-точка. PPP поддерживает, как асинхронный режим с 8 битами данных без бита четности (согласуется со свойствами последовательного интерфейса, имеющегося практически на всех ЭВМ), так и побитовый синхронный режим. Протокол содержит в себе три составные части:

Метод инкапсуляции дейтограмм при передаче по последовательным коммуникационным каналам.

Протокол LCP для установления, конфигурирования и тестирования информационных каналов

Набор протоколов NCP для установки и конфигурирования различных протоколов сетевого уровня.

Протокол управления каналом (LCP - Link Control Protocol) является частью PPP. Идеология NCP реализована и в протоколе TCP. Каждый кадр PPP начинается и завершается флагом 0x7E. За стартовым флагом-октетом следует байт адреса, который всегда равен 0xFF. Формат кадра PPP представлен на рисунке 3.5.1. Кадр ppp может содержать только целое число байт. При инкапсуляции других пакетов в PPP используется бит-ориентированный протокол HDLC (High-level Data Link Control).

Размещение блоков в макроблоках

Рисунок 2.5.6. Размещение блоков в макроблоках

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

Так как при передаче изображения широко используются коды переменной длины, она крайне уязвима для любых искажений. В случае ошибки будет испорчена вся информация вплоть до следующего стартового кода GoB. Из-за рекурсивности алгоритма формирования картинки, искажения будут оставаться на экране довольно долго. Использование векторов перемещения может привести к дрейфу искажений по экрану и расширению их области. Для того чтобы уменьшить последствия искажений, в передаваемый информационный поток включаются коды коррекции ошибок BCH (511,493; Forward Error Correction Code), которые позволяют исправить любые две ошибки или кластер, содержащий до 6 ошибок в блоке из 511 бит (см. Рисунок 2.5.7). Алгоритм работает в широком диапазоне скоростей передачи информации. Для реализации коррекции ошибок в поток двоичных данных включается 8 пакетов, каждый из которых включает в себя 1 кадровый бит, 1 бит индикатор заполнения, 492 бита кодированных данных и 18 бит четности. Поле Fi (индикатор заполнения) может равняться нулю, тогда последующие 492 бита не являются графической информацией и могут игнорироваться. Алгоритм предназначен для работы в динамическом диапазоне частот 40:1.

Режимы кодирования: проходной; вертикальный; горизонтальный

Рисунок 2.5.1. Режимы кодирования: проходной; вертикальный; горизонтальный

Факс-оборудование группы 4 может поддерживать так называемый расширенный режим, когда часть рабочего поля кодируется без использования алгоритмов уплотнения информации (как правило, это участки, где попытка сжать либо ничего не дает, либо даже приводит к увеличению объема передаваемых данных). Оборудование этой группа использует на канальном уровне процедуры HDLC LAPB. Рекомендуемой полосой пропускания канала, к которому подключается такое оборудование, является 64 Кбит/с.

Сеть Петри с двумя позициями и

Рисунок 10.24.1. Сеть Петри с двумя позициями и двумя переходами. Цифрами 1 и 2 обозначены переходы, а буквами А и Б - позиции.

Состояние системы формируется в результате реализации локальных операций, называемых условиями реализации событий. Условие имеет емкость:

Условие не выполнено - емкость равна нулю

Условие выполнено - емкость равна 1.

Условие выполнено с n-кратным запасом - емкость равна n.

Определенная комбинация условий может стимулировать определенное событие, которое вызовет в свою очередь изменение изменение условий. В сетях Петри события и условия отображаются абстрактными символами, называемыми переходами(вертикальными или горизонатальными полосками - "барьерами") и позициями (кружками). Условия-позиции и события-переходы связаны отношениями зависимости, которые отображаются с помощью ориентированных дуг. Позиции, из которых исходят дуги данного перехода, называются входными позициями. Позиции же, к которым ведут дуги данного перехода, называются выходными позициями. Выполнение условий отображается помещением соотвествтующего числа меток в соответствующую позицию. Если число меток велико (более 2-3), емкость условия может быть отображена числом.

В исходный момент система находится в состоянии А, что отмечено на Рисунок 4.9. меткой в виде синего кружочка. Переходы обозначаются горизонтальными или вертикальными линиями. Каждый переход имеет нуль или более входных дуг, исходящих из позиций, и нуль или более исходящих дуг, направленных к выходным позициям. Переход разрешен, если имеется как минимум одна входая метка в каждой из его исходных позиций. Любой разрешенный переход может произойти (fire), удалив все входные метки и установив метки в выходных позициях, что отражает изменение условий (и емкостей). Если числа входных и выходных дуг отличаются, число меток не сохраняется. Если разрешено более одного перехода, может произойти любой из них. Причем один из осуществившихся переходов, может блокировать реализацию всех остальных переходов из данного набора. Формализм сетей Петри не предусматривает каких-либо механизмов преодоления подобных конфликтов. Переход осуществляется, если выполнены все условия реализации данного события. Если два или более переходов могут осуществиться (выполнены все условия) и они не имеют общих входных позиций, то из реализация некоррелирована и может происходить параллельно или в любой последовательности. Выбор перехода, вообще говоря, не определен. В отличии от модели машины конечных состояний здесь отсутствуют комбинированные состояния типа отправитель-канал-получатель, и переходы из состояния в состояние для каждого процесса или объекта рассматриваются независимо. Если условия ни для одного из переходов не реализованы, сеть переходит в заблокированное состояние.

Аналитическое определение. Сеть Петри - набор N = (P, T, F, W, M0), где (P, T, F) - конечная сеть (множество Х = ЗuT конечно), а W: F> N\ {O} (знак \ здесь означает разность множеств) и M0: P>N - две функции, называемые кратностью дуг и начальной пометкой. Первая ставит в соответствие каждой дуге число N>0 (кратность дуги). Если N>0, то при графическом представлении сети число N выписывается рядом с короткой чертой, пересекающей дугу. Дуги с кратностью 1 не помечаются. Каждой позиции p

ставится в соответствие некоторое число M0(p) N (пометка позиции).

Формально работа сети Петри описывается множеством последовательностей срабатываний и множеством реализуемых разметок позиций.

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

Сетевые драйверы

7.2 Сетевые драйверы

Читатели, знакомые с телекоммуникационными протоколами, могут заинтересоваться тем, как писать прикладные программы для работы с пакетами. Прикладная программа взаимодействует с драйвером сетевого интерфейса. Ethernet-интерфейс, как и всякий другой, содержит несколько статусных управляющих регистров (CSR) и один или несколько регистров данных. Запись (чтение) в эти регистры выполняется в IBM/PC с помощью команд IN (OUT). Каждому регистру ставится в соответствие определенный номер порта. Блок номеров портов задается с помощью переключателей на интерфейсе или в процессе постановки пакетного драйвера. В последнем случае в AUTOEXEC-файле должна присутствовать строка, например (для DOS):

NE2000 0x60 0x5 0x300, (если ваша ЭВМ снабжена интерфейсом типа NE2000).

Здесь предполагается, что интерфейс будет использовать номер прерывания 0x60, аппаратное прерывание 0x5 и блок портов, начиная с шестнадцатеричного адреса 0x300 (io_addr). Следует иметь в виду, что разные интерфейсы могут иметь разное число CSR-регистров и отличные от приведенных ниже функции (NE2100). Интерфейс характеризуется тремя целыми числами: класс (8 бит), тип (16 бит) и номер. Класс говорит о том, для какой из сетевых сред предназначен данный прибор (PPP, DIX Ethernet, IEEE 802.3, IEEE 802.5, Pronet-10, Appletalk и т.д.). Тип описывает конкретную реализацию интерфейса (NE2000, NI5210, 3C501 и т.д.). Тип 0xffff соответствует всем интерфейсам данного класса. В случае, когда ЭВМ оснащена более чем одним интерфейсом идентичного типа, для их идентификации используется номер. На Рисунок 7.2.1 показана структура управляющего (CSR) регистра сетевого интерфейса. В таблице 7.2.1 приведен перечень основных классов с примерами определенных типов интерфейсов.

Сети Петри

10.24 Сети Петри

Протоколы можно описывать не только с помощью модели машины конечных состояний. Альтернативой можно считать сети Петри (смотри, также книгу "Сети Петри", Котов В.Е., Москва, "Наука", ГРФМЛ, 1984 откуда взяты некоторые примеры и фрагменты данной статьи). Модель сети Петри является принципиально асинхронной и служит для отображения и анализа причинно-следственных связей в системе. Для привязки к определенным моментам времени тех или иных переходов в синхронных системах используются события. Переходы из состояния в состояния считаются "мгновенными". Если переход реально происходит через какие-то промежуточные состояния, а нам существенно учесть в модели эти обстоятельства, то вводятся соответствующие "подсобытия". Сеть Петри имеет четыре базовых элемента: позиции (places), переходы, дуги и метки (token).

Позиция (место) - это состояние, в котором находится система или определенная ее часть. Смотри Рисунок 10.24.1.

Схема передачи данных с коррекцией ошибок

Рисунок 2.5.7 Схема передачи данных с коррекцией ошибок

Во время переговоров или в ходе видеоконференции может возникнуть необходимость отобразить текст, выделить на экране какой-то объект, послать факс и т.д. Для решения таких задач можно использовать D-канал, но это не оптимально, так как он имеет свои специфические функции. Поэтому более привлекательным представляется создание специального протокола, работающего в рамках B-канала (H.221). Для этих целей используется младший бит каждого из октетов, что позволяет создать канал с пропускной способностью 8 Кбит/с. этот сервисный канал использует кадры по 80 бит. Первые 8 бит служат для целей синхронизации (FAS - Frame Alignment Signal) и выполняют следующие функции:

выделение начала кадра (исключение имитации этого в информационном потоке);

выделение начала блока кадров (опционно до 16 кадров);

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

нумерация соединений;

CRC-контроль (опционно);

”A-бит” для определения кадр/мультикадр/синхронизация при пересылке в противоположном направлении (A=0 - передача, см. также структуру кадров isdn );

При работе с каналами на 384, 1536 и 1920 Кбит/с сервисный канал использует тайм-слот 1. Следующие 8 бит имеют название BAS (Bit Allocation Signal) и выполняют следующие функции:

код, характеризующий возможности канала (узко/широко полосная передача звука, различные видео параметры, тип шифрования и т.д.);

коды команд, определяющие значения передаваемых кадров;

ESC-последовательности.

Очевидно, что BAS-коды (H.242) должны быть надежно защищены от ошибок. Для этой цели они пересылаются с использованием кодов, допускающих коррекцию ошибок. При работе оба приемника непрерывно ищут разделительный код кадров. Когда он обнаружен, бит А для выходного канала делается равным нулю. Только после получения А=0 терминал может быть уверен в том, что удаленный терминал правильно воспринял код BAS. Работа с кодами BAS описана в документе H.242.

При установлении режима обмена терминалы

При установлении режима обмена терминалы обмениваются командами BAS. Команда действительна для последующих двух кадров, следовательно, при частоте кадров 100 Гц, изменения режима могут производиться каждые 20 мс.

Многоточечный вызов может рассматриваться как несколько связей между терминалами и бриджом MCU (Multipoint Control Unit) по схеме точка-точка. Простой MTU передает на каждый из терминалов смешанный аудио-сигнал от остальных терминалов. Каждый терминал осуществляет широковещательную передачу для остальных терминалов, участвующих в обмене. При видео обмене на терминал выводится только одна картинка. Дополнительную информацию по данной тематике можно найти в рекомендациях H.231, H242 и H.243.

Для передачи нормального телевизионного изображения необходимо 364 Кбит/с (4х64 Кбит/c). Интеграция телевидения с сетями передачи данных, появление видеотелефона и широкое внедрение видеоконференций становится велением времени. Требования к каждому из этих видов услуг варьируется значительно в зависимости от приложения. Например, ставшие обычными телевизионные мосты требуют высокого качества передачи изображения и звука. А в некоторых дорогостоящих отраслях науки, где международное сотрудничество стало неизбежным, важным является передача статических изображений (чертежи, схемы, описания алгоритмов, и т.д.) с высоким (иногда более высоким, чем в телевидении) разрешением. Здесь важно передать звук с приемлемым качеством (но заметно хуже, чем на ТВ) и обеспечить синхронное перемещение маркера мыши по экрану в ходе обсуждения переданного документа. Экономия только на авиа билетах (не говоря о командировочных и времени экспертов) способна перекрыть издержки по оплате канала для видеоконференции. В этом режиме приемлемым может считаться один кадр в 1-4 секунды.

Схема передачи кадра изображения

Рисунок 2.5.4. Схема передачи кадра изображения

Поле Ptype содержит 6 бит, которые характеризуют формат изображения (используется ли формат CIF или QCIF). Однобитное поле PEI указывает на то, следует ли далее 8-битное поле PSpare (предназначено на будущее). Если PEI=0, начинается цикл передачи GoB. Группа блоков составляет одну двенадцатую картинки CIF или одну треть QCIF. GoB описывает Y (яркость), 176 пикселей для каждой из 48 строк и соответствующие 88*24 элементов для CB и CR.

GBSC - (Group of Blocks Start Code) представляет собой 16-разрядное слово, за которым следует 4 бита номера GoB (GN - GoB number). GN указывает, какой части изображения соответствует данный GoB. Поле gquant имеет 5 бит и указывает на номер преобразователя (одного из 31 дискретизаторов), который используется данным GoB. Смысл GEI идентичен PEI. GEI и GSpare позволяют сформировать структуру данных, идентичную той, что используется на уровне кадра.

Формат пересылки mb сложнее (см. [17]). Каждый GoB делится на 33 макроблока (MB), каждый из которых соответствует 16 строкам по 16 пикселей Y (четыре блока 8*8) и CB и CR. Каждый макроблок начинается с его адреса MBA (MacroBlock Address), имеющего переменную длину и определяющего положение макроблока в GoB.

Схема переключателя каналов с мультиплексированием по времени

Рисунок 2.2.8. Схема переключателя каналов с мультиплексированием по времени.

Кружочки на пересечениях линий представляют собой ключи, замыкая которые можно соединить i-й входной канал с j-м выходным. На каждой линии может быть только один замкнутый ключ. Такая схема коммутации называется TST (Time-Space-Time). Именно она преобладает сегодня при построении сетей ISDN. Магистральные каналы ISDN строятся в соответствии со стандартом T1.

Такая схема при числе входных и выходных каналов равном N=1000 требует миллиона элементарных переключателей. Можно рассмотреть вариант когда используются коммутаторы с n входами и k выходами. Схема коммутатора с N=16, n=4 и k=2 показана на Рисунок 2.2.9. Число элементаных переключателей в таком коммутаторе М равно:

M = 2kN + k(N/n)2

Первое слагаемое характеризует число элементарных переключателей во входной и выходной секциях системы, а второе - число элементарных переключателей в k внутренних модулях При N=1000, n=50 и k=10 требуется 24000 элементарных переключателей вместо миллиона (но и число одновременно формируемых каналов становится много меньше 1000).

Схема реализации интерактивного телевидения

Рисунок 2.5.9. Схема реализации интерактивного телевидения

Базовый мультимедийный сервер может обслуживать отдельный район города. В пределах квартала размещается промежуточный центр, где размещается локальный буферный сервер, где записываются фрагменты программ, заказанные локальными клиентами. Только новостийные и некоторые спортивные программы передаются в реальном масштабе времени, все фильмы берутся из локальной фильмотеки или предварительно записываются в накопитель из центрального мультимедиа-сервера. Транспортной средой здесь может стать ATM, SDH или Fibre Channel. Оптическое волокно доходит до квартального сервера или даже до дома клиента. Индивидуальная раздача сигнала на терминалы (телевизоры) может осуществляться через существующие телевизионные кабели. В этом случае по имеющимся каналам может передаваться не только программа телевидения и осуществляться телефонные переговоры, но выполняться полное информационное обслуживание. Сюда может включаться, помимо заказа ТВ-программ, подписка на газеты, заказ билетов на транспорт или в театр, получение прогноза погоды и данных о состоянии дорог, доступ к базам данных, включая библиотеки и фонотеки и многое другое. Особый интерес представляет возможность практически полного вытеснения традиционных газет. Клиент сможет получать только интересующие его статьи из любых газет (и только их и оплачивать). Если какая-то статья его заинтересует и он захочет почитать ее позднее в машине или на даче, он сможет ее распечатать на принтере, подключенном к его телевизору-терминалу. Цены на цветные принтеры в настоящее время спустились ниже 100 долларов, таким образом нужная копия уже сейчас дешевле стоимости газеты. Экономия на бумаге и средствах доставки очевидны, да и необходимость в типографиях отпадет, ведь даже книги можно будет получить непосредственно дома (хотя привлекательность данной услуги и не вполне очевидна - хорошо сброшированная и переплетенная книга будет привлекательным объектом еще долго (прогноз относительно будущих книг сотри в разделе "Заключение"). Массовое внедрение таких технологий будет стимулировать падение цен на соответствующие процессоры и принтеры. Интерактивная схема подключения телевизора-терминала сделает возможным многие новые виды развлечений, а также выполнение многих покупок, не выходя из дома. Традиционной почте подписала отсроченный приговор почта электронная, но появление интерактивных широкополосных средств завершит многовековую историю почты (да и телеграфа). Ей будет оставлена доставка товаров, билетов и документов. Побочным продуктом прогресса в данной области станет общедоступный видеотелефон.

В жилье клиента будет входить оптоволоконный кабель, завершающийся интерфейсной коробкой с разъемами для подключения телефона, телевизора и ЭВМ. Даже современные ограниченные скорости передачи позволяют решить стоящие проблемы. Во-первых люди не смотрят телевизор круглые сутки, это позволяет ночью или в рабочее время, когда клиент на службе, произвести передачу нужных фрагментов ТВ-программы на локальный сервер. Во-вторых популярность фильмов и программ не однородна, что также снижает требование на широкополосность. Известно, что наиболее популярный фильм запрашивается примерно в К раз чаще, чем фильм, занимающий к-ое место в списке популярности (эмпирический закон Ципфа (Zipf), выведенный из статистики контор по прокату видеокассет). Это означает, что из предлагаемого списка будут выбраны не все фильмы, а наиболее популярные фрагменты программ можно передавать по схеме MBONE, минимизируя загрузку каналов (смотри также описание протокола PIM). Способствовать решению данной проблемы будет и появление CD с емкостью 4 Гбайта. Но проблем здесь остается немало, так трудно себе представить, что все клиенты захотят смотреть один и тот же фильм в одно время. Решение подобной задачи потребует очень большого объема буферной памяти и ощутимо поднимет требования к широкополосности канала. "Синхронизовать" клиентов можно будет дифференциацией оплаты для разных временных интервалов, и группированием клиентов, заказавших близкие времена начала демонстрации фильмов, путем предварительного оповещения. Но несмотря на все эти ухищрения, локальные серверы должны будут иметь сложную иерархическую систему буферной памяти, базирующейся на разных принципах работы (CD, магнитная лента, дисковая память и даже RAM).

Практическая реализация фантастической схемы, предложенной в предыдущем абзаце, уже осуществляется в США и Канаде. Здесь есть немало проблем, например, нужен дешевый широкополосный кабельный модем (смотри раздел "Модемы", там же приведена схема подключения телевизора-терминала через кабельный модем). Предстоит написать огромное число различных сервисных программ, но все базовые технологии уже существуют.

Схема синхронизации и стробирования с кратной тактовой частотой приемника

Рисунок 2.2.4. Схема синхронизации и стробирования с 8-кратной тактовой частотой приемника

Начальный и стоп-биты на каждый байт данных снижают пропускную способность канала и по этой причине используются только для низких скоростей обмена. Увеличение же длины блока данных приводит к ужесточению требований к точности синхронизации. При использовании синхронного метода передачи необходимы специальные меры для выделения кадра в общем потоке данных. Для решения этой задачи используется специальная сигнатура. Если такая последовательность встретится внутри кадра, она видоизменяется путем ввода в нее двоичных нулей (bit stuffing). Синхронный приемник нуждается в синхронизирующем сигнале, передаваемом передатчиком. Обычно это реализуется путем введения определенного вида кодирования сигнала, например, биполярного кодирования. В этом случае используется три уровня сигнала: +v соответствует логической 1; -v – логическому нулю, а 0 вольт логическому нулю или единице. Пример такого типа кодирования показан на Рисунок 2.2.5.

Система коммуникаций с использованием кодово-импульсной модуляции (pcm)

Рисунок 2.2.2. Система коммуникаций с использованием кодово-импульсной модуляции (pcm)

Шаг квантования в АЦП должен быть много меньше диапазона вариации входного сигнала. Число уровней квантования n выбирается из соображений минимизации искажений сигнала и повышения уровня s/n. При разумных предположениях (биполярность сигнала (+V -V), однородность распределения уровня сигнала в рабочем диапазоне, ошибка квантования не более S/2, где S шаг квантования, и т.д.) [S/N]db = 10 log10(22n) = 6n (N - шум квантования при этом равен S2/12). Это означает, что при 2n уровнях квантования и при условии, что входной сигнал может варьироваться во всем рабочем диапазоне АЦП, отношение сигнал-шум (S/N), связанное с самим процессом квантования, будет равно 6n при n=8 это составит 48 дБ). Отсюда следует известное значение относительного расстояния между уровнями квантования, равное 6 дБ. Звуковой сигнал может иметь динамический диапазон 40 дБ, что создает определенные проблемы, которые преодолеваются путем прямого и обратного логарифмического преобразования (см. Рисунок 2.4.1).

Типичный кадр данных в асинхронном канале начинается со стартового бита, за которым следует 8 битов данных. Завершается такой кадр одним или двумя стоп-битами. Стартовый бит имеет полярность противоположную пассивному состоянию линии и переводит приемник в активное состояние. Пример передачи такого кадра показан на Рисунок 2.2.3.

Структура переменных init_mode

Рисунок 7.2.2. Структура переменных init_mode

Drx	запрет приема;
Dtx	запрет передачи;
Loop	цикл;
Dtcr	запрет передачи crc;
Coll	столкновение;
Drty	запрет повторов;
Intl	внутренний цикл;
Prom	режим приема всех пакетов (promiscuous mode).

Кольцевой входной буфер имеет следующую структуру:

rcv_msg_dscp	struc
rd_addr	dw ?	; Младшая часть адреса входного буфера
rd_stat	dw ?	; Статусная часть + старшая часть адреса
rd_bcnt	dw ?	; Размер буфера в байтах
rd_mcnt	dw ?	; Длина сообщения в байтах
rcv_msg_dscp	ends

Структура переменных rd_stat имеет вид

Структура переменных rd_stat

Рисунок 7.2.3. Структура переменных rd_stat

Enp	конец пакета;
Stp	начало пакета;
Buff	ошибка в буфере;
CRC	CRC-ошибка;
Oflo	переполнение буфера;
Fram	ошибка при записи в буфер;
Err	наличие ошибки;
Own	0 = полное заполнение.

Выходной буфер имеет сходную структуру.

Я не буду описывать здесь то, как следует писать системные драйверы (Исчерпывающую информацию по написанию таких драйверов читатель может найти в книге "Написание драйверов для MS-DOS" Р.Лея и "Уэйт Груп", Москва "Мир", 1995), тем более что существует достаточное их количество в депозитариях общего доступа (Например, анонимное FTP по адресам ftp.funet.fi, ftp.switch.ch или oak.oakland.edu, депозитарий SimTel ). Приведенное выше описание регистров интерфейса не является единственно возможным (см. также руководство по сетевому контроллеру 8390 и файл NE2.ASM из ссылки ftp.funet.fi. Структура драйверов варьируется для разных операционных систем. Для системных программистов полезно иметь возможность настраивать драйвер или непосредственно интерфейс на определенный режим, например, на прием всех пакетов, проходящих по кабельному сегменту. Последнее может представлять интерес в диагностических целях, так как вслед за пакетным драйвером загружается Etherdrv, Winsock или winpkt и т.д., блокирующие режим приема всех пакетов (mode=6). Ниже приведен пример описания основных параметров драйвера:

BLUEBOOK	equ	1
IEEE8023	equ	11
ADDR_LEN	equ	6	; размер Ethernet-адреса
MAX_M_CAST	equ	8	; максимальное число мультикаст-адресов.

Public	int_no,	io_addr
int_no	db	2,0,0,0	; должно иметь 4 байта для get_number.
io_addr	dw	0300h,0	; I/O адрес карты (переключатели)

public	driver_class	driver_type,	driver_name,	driver_function,	parameter_list
driver_class	db	BLUEBOOK, IEEE8023, 0	; из спецификации интерфейса
driver_type	dw	54	; из спецификации интерфейса
driver_name	db	'NE2000',0	; имя драйвера.
driver_function	db	2
parameter_list	label	byte
	db	1	;
	db	9	;
	db	14	; длина списка параметров в байтах
	db	ADDR_LEN	; длина адреса MAC-уровня в байтах
	dw	GIANT	; MTU, включая MAC-заголовок
	dw	MAX_M_CAST * ADDR_LEN

<
/p> ; размер буфера для мультикаст-адресов

	dw	0	;(# принимаемых подряд пакетов с; размером MTU) - 1
	dw	0	; (# посылаемых подряд пакетов) - 1
int_num	dw	0	; Номер прерывания

Работа с пакетным драйвером в MS-DOS

Существует множество пакетных драйверов. Можно обнаружить несколько модификаций для одного и того же типа интерфейса. Эти драйверы могут быть ориентированы на работу в разных программных средах (Novell, UNIX, MS-DOS и т.д.) и иметь разные возможности. Для MS-DOS сложился неофициальный стандарт, который позволяет использовать драйвер для самых разных приложений. Драйвер может использовать минимум возможностей интерфейса (базовый уровень), реализовать более широкий набор функций (мультикастинг, сбор статистики и т.д.) или поддерживать практически все, на что способен данный прибор. В последнем случае он занимает больше места в памяти. Описания операций с пакетными драйверами, приведенные ниже, выполнены в нотации ассемблера IBM/PC. При написании программы следует помнить, что порядок байтов в Ethernet противоположен тому, который используется в вашей IBM/PC.

Пакетные драйверы используют программные прерывания в интервале 0x60 - 0x80. Следует сразу заметить, что не все прерывания из этого списка свободны и при конфигурировании системы следует проявлять осмотрительность. Для того чтобы избежать конфликтов с другими внешними устройствами, предусматривается возможность реконфигурации прерываний. Предполагается, что программа обработки прерываний начинается с команды безусловной передачи управления (JMP), за которой следует текстовая строка "PKT DRVR". Именно эта строка служит указателем при поиске адреса пакетного прерывания. Практически все драйверы могут работать с различными протоколами (TCP/IP, OSI и др.). Решить задачу мультиплексирования на связном уровне помогает процедура access_type, которая обеспечивает доступ для пакетов определенного типа.

Все функции реализуются с помощью обращения к драйверу с набором определенных параметров.


При этом значение регистра AH определяет тип запроса. Каждому типу используемого сетевого протокола, с которым работает интерфейс, ставится в соответствие целочисленный указатель (handle), получаемый с помощью процедуры access_type. Выполнимость драйвером тех или иных операций может быть выяснена с помощью запроса driver_info.

При работе с драйвером следует проявлять осторожность и спасать нужные вам регистры. Следует также помнить, что порядок байтов в PC и в некоторых сетях, включая Ethernet, не совпадает. Описание основных запросов, посылаемых пакетному драйверу:



1. Получение информации о типе и функциональных возможностях драйвера

driver_info AH == 1,

AL == 255 (код запроса)

public	_driver_info
_driver_info	proc near
	mov AX, 1FFH	; ah=1, al=255
	call int_pkt	; обращение к драйверу
	jnc lv
	mov AX, seg _PARAM.ER_CODE
	mov DS, AX
	mov _PARAM.ER_CODE, 272	; Устанавливаем код "Нет инф. о драйвере"
lv:	ret
_driver_info	endp

int_pkt:		; Подпрограмма обращения к драйверу
	push ds
	push es
	pushf
	cli
	call _param.Handler	; адрес _param.Handler должен быть определен раньше
	pop es
	pop ds
	ret

Целочисленный указатель (handle) должен быть занесен в регистр BX (для старых драйверов). В случае ошибки устанавливается флаг carry, а код ошибки заносится в регистр DH. Сообщение BAD_HANDLE (неверный указатель) возможно только для старых драйверов. При благополучном исполнении флаг carry равен нулю, а в регистры будет занесены следующие параметры:

BX	версия;
CH	класс;
CL	номер;
DX	тип;
DS:SI	указывают на строку имени драйвера;
AL	функциональные возможности.
AL = 1	гарантируется выполнение базовых функций;
= 2	обеспечено выполнение базового и расширенного набора функций;
= 5	выполняется базовый и экстра-набор функций;
= 6	выполним полный набор функций;
= 255	драйвер не установлен.

<


/p> Ниже приведен пример программы, реализующей некоторые из описанных запросов.

.MODEL	small
PUBLIC	_INFACE
VERSION	EQU	1
EXTRN	_PARAM:BYTE
EXTRN	_Q:BYTE

.DATA

INCLUDE	DEF.ASM	; Определения некоторых констант
P_LIST	STRUC
LINTN	DB	32 dup(0)	; Список активных номеров прерываний
HANDLES	DW	?
HANDLEP	DW	?
ER_CODE	DW	?
ERNUM	DW	?	; Код ошибки
HANDLER	DD	?
MODE	DW	?	; Текущий режим приема пакетов
MLIST	DB	0,0,0,0,0,0	; Список допустимых режимов; 1 => имеется
PKT_IN	DW	?,?	; Диагностический массив
pkt_out	DW	?,?
byte_in	DW	?,?
byt_out	DW	?,?
err_in	DW	?,?
err_out	DW	?,?
pk_drop	DW	?,?
L1	DW	0	; Версия драйвера
L2	DW	0	; класс/номер
L3	DW	0	; Тип
L4	DW	0	; Функция
_NAME	DB	0,0,0,0,0,0,0,0,0,0	; Имя интерфейса
ETHER_ADR	DB	ADDR_LEN dup(-1)	; Ethernet-адрес
S_ADR	DB	EADDR_LEN+5 dup(-1)	; Ethernet-адрес получателя
D_ADR	DB	EADDR_LEN+5 dup(-1)	; Ethernet-адрес отправителя
P_LIST	ENDS

QUEUE	STRUC
Leng	DW	15000,?	; Длина очереди
Tail	DW	?	; Смещение последнего элемента очереди
Head	DW	?	; Смещение первого элемента очереди
_end	DW	?	; Указатель на конец очереди
p_len	DW	?	; Длина пакета
P_start	DW	?	; Указатель на текущий пакет = Q_head - Q_begin +2
NEW	DB	0	; Флаг нового пакета
Line	DB	?	; Строка экрана
Npacks	DD	0	; Счетчик принятых пакетов
B	DW	?	; смещение Q_beg
Point	DW	380 dup(?)
Beg	DB	31000 dup(?)	; Пакетный буфер
QUEUE	ENDS

ether_bdcst	DB	EADDR_LEN dup(-1)	; Широковещательный адрес Ethernet, заполненный -1.
ether_addr	DB	EADDR_LEN dup(-1)
bogus_type	DB	0,0;
signature	DB	'PKT DRVR',0	; Сигнатура пакетного драйвера
signature_len	equ	$-signature
SAFE	DW	?
DFLAG	DB	0

.CODE

	PUBLIC	_INFACE
_INFACE	PROC	NEAR

<


/p>

	CLD
	MOV DFLAG, 0	; Очистка флага драйвера
	MOV _PARAM.ER_CODE, 0	; Очистка флага ошибки
	PUSH BP	; Спасение регистров
	MOV BP, SP
	PUSH SI
	PUSH DI
	PUSH ES
	PUSH DS

	MOV CX, 32
	MOV AL, 60H	; Установка начального номера прерывания
	LEA SI, _PARAM.LINTN	; Формирование указателя на список номеров прерывания
CHECK:	PUSH AX
	PUSH CX
	PUSH SI
	CALL CHK_INT
	POP SI
	POP CX
	MOV byte ptr [SI], 0 ;
	JNE NO_SIGNATURE
	INC DFLAG	; Установка флага <Это драйвер>
	MOV BYTE PTR [SI], 1	; Установка флага наличия

NO_SIGNATURE:

	POP AX
	INC AL	; Следующий номер прерывания
	INC SI	; Актуализация указателя
	LOOP CHECK

	CMP DFLAG, 0	; Драйвер присутствует?
	JNE HAVE_SIGNATURE
	MOV _PARAM.ER_CODE, 271	; Установка флага <No signature>
	JMP OKAY

INT_PKT:

	PUSH ES
	pushf
	cli
	call _PARAM.HANDLER
	POP ES
	RET

CHK_INT:	PUSH ES	; AL = номер прерывания
	PUSH DI

	MOV AH, 35H	; Получение вектора прерывания
	INT 21H	; ES:BX=seg:offs драйвера

	MOV _PARAM.HANDLER.OFFS,BX	; Записываем адрес драйвера
	MOV _PARAM.HANDLER.SEGM, ES
	LEA DI, 3[BX]	; Устанавливаем смещение сигнатуры драйвера
	MOV SI, OFFSET SIGNATURE	; Проверка сигнатуры драйвера
	MOV CX, SIGNATURE_LEN	; Присутствует ли здесь драйвер?
	REPE CMPSB ; DS:[SI] - ES:[DI]

	POP DI
	POP ES
	RET

HAVE_SIGNATURE:

	MOV CX, 32	; Установка начального значения счетчика
	LEA SI, _PARAM.LINTN	; Устанавливаем указатель списка
	MOV AL, 60H	; Задаем начальный номер прерывания
CHOICE:	CMP BYTE PTR [SI], 0
	JNE SETDRV
	INC AL
	LOOP CHOICE

<


/p>

SETDRV:	MOV AH, 35H
	INT 21H
	MOV _PARAM.HANDLER.OFFS,BX	; Определяем адрес драйвера
	MOV _PARAM.HANDLER.SEGM, ES

	PUSH DS
	POP ES
	MOV CX, EADDR_LEN
	MOV SI, OFFSET ETHER_ADDR
	MOV DI, OFFSET ETHER_BDCST
	REPE CMPSB
	JE GET_MODE	; Адрес не определен

	MOV AH, 25	; Записываем ethernet-адрес
	MOV DI, offset ETHER_ADDR
	MOV CX, EADDR_LEN
	call int_pkt
	MOV _PARAM.ER_CODE, DX	; Устанавливаем код ошибки
	JMP OKAY

GET_MODE:

	MOV SAFE, DS	; Спасаем DS
	PUSH DS
	MOV AH, 2	; Открываем доступ пакетам
	MOV AL, 1	; Класс интерфейса
	MOV BX, -1	; Тип интерфейса
	MOV DL, 0	; Номер интерфейса
	MOV CX, 2	; Используем длину type = 2
	MOV SI, OFFSET BOGUS_TYPE
	PUSH CS	; ES:DI -> Receiver.
	POP ES
	MOV DI, OFFSET RECEIVER
	call INT_PKT
	JNC $_$
	MOV _PARAM.ER_CODE, DX	; Устанавливаем код ошибки
$_$:	MOV _PARAM.HANDLES, AX	; Записываем указатель-Handle

	MOV AH, 6	; Определяем ethernet-адрес интерфейса
	PUSH DS
	POP ES
	MOV DI, offset _PARAM.ETHER_ADR
	MOV CX, EADDR_LEN
	MOV BX, _PARAM.HANDLES
	call int_pkt
	JNC NOBAD
	MOV _PARAM.ER_CODE, 273	; Ошибка при определении Ethernet-адреса
	POP DS
	JMP OKAY

NOBAD:

	MOV AX, 1FFH	; Запрашиваем информацию о драйвере
	MOV BX, _PARAM.HANDLES	; Устанавливаем указатель
	call INT_PKT
	JNC N_BAD
	MOV _PARAM.ER_CODE, 272	; Ошибка при получении информации о драйвере
	POP DS
	JMP OKAY

<


/p>

N_BAD:	PUSH DS
	PUSH SS
&nsp;	POP DS
	MOV ES, SAFE

	MOV _PARAM.L1, BX	; Версия драйвера
	MOV _PARAM.L2, CX	; номер/класс
	MOV _PARAM.L3, DX	; Тип
	MOV _PARAM.L4, AX	; Функциональность
	LEA BX, _PARAM._NAME
	POP DS
	MOV CX, 8
ZFIND:	CMP byte ptr [SI], 0
	MOV AL, byte ptr [SI]
	MOV byte ptr ES:[BX], AL
	JE ZERO_
	INC SI
	INC BX
	LOOP ZFIND
ZERO_:	POP DS
	MOV AH, 21	; Запрашиваем код режима приема пакетов
	MOV BX, _PARAM.HANDLES
	call INT_PKT
	MOV _PARAM.MODE, AX	; Записываем код режима

.........................

OKAY:	POP DS
	POP ES
	POP DI
	POP SI
	MOV SP, BP
	POP BP
	RET

RECEIVER:	; Подпрограмма RECEIVER, вызываемая при получении пакета
	OR AX, AX	; Первый или второй вызов?
	JNE RECV
	MOV AX, seg _Q.beg	; Указатель буфера ES:DI
	MOV ES, AX
	MOV DI, offset _Q.beg

RECV:

RETF

2. Организация доступа для пакетов данного типа

access_type(if_class, if_type, if_number, type, typelen, receiver)

AH ==2 (код запроса)

Запрос access_type инициализирует доступ для пакетов определенного типа (type). Аргумент typelen – длина спецификации типа в байтах, для PC/TCP равна 5 (наименьшее значение - 2, для IP и ARP). Аргумент receiver является указателем на подпрограмму, которая вызывается при приеме пакета. Получая пакет, драйвер дважды обращается к этой программе. Первый раз (при AX==0) это делается с целью получения адреса буфера, куда должен быть положен пакет. Прикладная программа в этом случае должна выдать указатель буфера в регистры ES:DI. Если прикладной процесс не имеет свободного буфера,то возвращается значение 0:0. Пакет выбрасывается и повторное обращение к программе receiver отменяется.


Форма реализации запроса аналогична приведенному для driver_info:

Int	if_class; AL	; класс интерфейса
Int	if_type; BX	; тип интерфейса
Int	if_number; DL	; номер интерфейса
Char	far *type; DS:SI
Unsigned	typelen; CX
Int	(far *receiver); ES:DI

access:	mov ah, 2
	mov al, ch	; установка класса; здесь предполагается, что содержимое регистров соответствует тому, что получено в результате обращения к driver_info
	mov bx, dx	; устанавливаем параметр type
	mov dl, cl	; устанавливаем параметр number, при одном интерфейсе number=0
	xor cx, cx	; длина type равна нулю
	push cs	; устанавливаем сегментный регистр receiver
	pop es
	mov di, offset RECEIVER	; вызов подпрограммы receiver
	call int_pkt	; обращение к пакетному драйверу

В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

2	NO_CLASS не найдено интерфейса указанного класса;
3	NO_TYPE не найдено интерфейса указанного типа;
4	NO_NUMBER не найдено интерфейса с указанным номером;
5	BAD_TYPE специфицирован неправильный тип пакета;
9	NO_SPACE недостаточно места в памяти;
10	TYPE_INUSE было обращение к данному типу и он пока занят.

При успешном выполнении запроса флаг carry=0, а в регистр AX занесен указатель (handle).

Обращение к приемнику (receiver):

(*receiver)(handle, flag, len [, buffer])

int handle;	BX	; указатель
int flag;	AX	; флаг вызова(0/1)
unsigned len;	CX	; целое без знака - длина пакета

if AX == 1,

char far *buffer;

DS:SI

; адрес буфера

Если параметр typelen равен нулю, прикладной процесс готов получать все пакеты. Очень важно, чтобы при первом обращении к receiver (AX==0) CX (длина пакета) была указана правильно, что позволит выделить нужное место в памяти. CX должна включать в себя длину MAC-заголовка и размер самого сообщения без контрольной суммы (CRC). Повторный вызов (AX==1) программы receiver указывает на то,что пакет записан в буфер и прикладная программа может с ним работать.


Адрес буфера будет указан в регистрах DS:SI.



3. Завершение доступа пакетов данного типа release_type



int release_type(handle) AH == 3;

код запроса int handle;

BX ; указатель определяет тип пакетов

_release_type proc near

	push bp	; спасение регистров
	push ds
	push es
	mov ah, 3	; задаем код запроса
	mov bx, _param.handle	; заносим указатель
	pushf
	cli
	call _param.handler	; обращение к драйверу
	mov _param.er_CODE, dx	; занесение кода ошибки
	pop es	; восстановление регистров
	pop ds
	pop bp
	ret
	_release_type	endp

В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможная ошибка: BAD_HANDLE (не верный указатель). При успешном выполнении запроса флаг carry=0. Эта операция прерывает доступ пакетов, соответствующих указателю, полученному с помощью запроса access_type. Старый указатель после выполнения этого запроса не действителен.



4. Процедура посылки пакета send_packet(buffer, length)



AH == 4 (код запроса)

char far *buffer; DS:SI (адрес буфера)

unsigned length; CX (длина пакета в байтах)

В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки 12 CANT_SEND. send_packet отправляет пакет с числом байт, равным CX. Пакет должен в исходный момент лежать, начиная с адреса DS:SI. Прикладная программа должна сформировать все необходимые заголовки. Информация, нужная для осуществления демультиплексирования пакетов (MAC или LLC), также должна быть записана в пакет, так как при этом запросе не сообщается значение указателя (handle).



5. Завершение работы драйвера terminate(handle)



AH == 5 (код запроса)

int handle; BX (указатель)

В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

1 BAD_HANDLE;

7 CANT_TERMINATE.

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


Если возможно, драйвер будет выгружен и занимаемая им память освобождена.



6. Получение физического адреса интерфейса get_address(handle,buf,len)



AH == 6 (код запроса)

int handle; BX (указатель)

char far *buf; ES:DI (адрес буфера)

int len; CX (длина адреса в байтах)

В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

1 BAD_HANDLE;

9 NO_SPACE. При успешном выполнении запроса флаг carry=0, а в регистр CX занесена длина адреса.

Копирует текущее значение сетевого (физического) адреса интерфейса в буфер. Если получено сообщение NO_SPACE, это означает, что выделенного места (len=CX) для копирования адреса не хватило.



7. Возвращение интерфейса в исходное состояние reset_interface(handle)



AH == 7 (код запроса)

int handle; BX (указатель)

В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

1 BAD_HANDLE;

15 CANT_RESET.

Возвращает интерфейс в исходное состояние, прерывая все процессы. Местное значение физического сетевого адреса, если оно было изменено, восстанавливается из ROM, прием переключается в режим 3, а список мультикастинг-адресов обнуляется. При работе с несколькими указателями (handle) возможны серьезные неприятности, по этому выполнение запроса блокируется и присылается сообщение CANT_RESET.



8. Запрос установки режима приема пакетов set_rcv_mode(handle,mode)



AH == 20 (код запроса) int handle;

BX (входные параметры - указатель) int mode;

CX (код режима приема пакетов)

В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

1 BAD_HANDLE;

8 BAD_MODE.

Устанавливает режим приема пакетов. Режим 3 используется по умолчанию. Возможны (но не для всех интерфейсов) следующие режимы:

Режим	Значение
1	выключение приема пакетов;
2	прием пакетов, адресованных только данному интерфейсу;
3	режим 2 плюс бродкастинг-пакеты;
4	режим 3 плюс некоторые мультикастинг-пакеты;
5	режим 3 плюс все мультикастинг-пакеты;
6	все пакеты.

9. Считывание действующего режима приема пакетов get_rcv_mode(handle)



AH == 21 (код запроса)

int handle; BX (входной параметр - указатель)

В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки 1 BAD_HANDLE. При успешном выполнении запроса флаг carry=0, а в регистр AX заносится код режима приема пакетов.



10. Занесение списка мультикастинг-адресов в интерфейс set_multicast_list(addrlst,len)

AH == 22 (код запроса)

char far *addrlst; ES:DI (адрес буфера, где лежат адреса)

int len; CX (длина списка адресов)

В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

6 NO_MULTICAST;

9 NO_SPACE;

14 BAD_ADDRESS.

Список адресов представляет собой счетную последовательность, начинающуюся с байта числа адресов в списке. На список адресов указывает комбинация регистров ES:DI. Сообщение NO_SPACE присылается, если указатель адреса отсутствует, или число адресов превосходит аппаратные возможности интерфейса. Прежде чем заносить список, полезно сначала ознакомиться с имеющимся уже списком, выполнив запрос get_multicast_list. При получении сообщения NO_SPACE рекомендуется попытаться установить режим приема 3 с помощью запроса set_rcv_mode.



11. Получение рабочего списка мультикастинг-адресов



get_multicast_list

AH == 23 (код запроса)

В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

6 NO_MULTICAST;

9 NO_SPACE.

При успешном выпонении запроса флаг carry=0, в регистр CX заносится длина списка адресов, а регистры ES:DI указывают на начало счетной оследовательности, где запрошенный список лежит. Прикладная программа не должна модифицировать этот список.



12. Получение статистических данных об ошибках и трафике через данный интерфейсget_statistics(handle)

AH == 24 (код запроса)

int handle; BX (указатель)

char far *statistics; DS:SI (адрес буфера, куда записываются статистические данные)

В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки 1 BAD_HANDLE. При успешном выполнении запроса флаг carry=0, а в массиве, начиная с адреса DS:SI, лежит запрошенная информация.



struct statistics {

unsigned long packets_in;	( Число принятых пакетов для всех указателей)
unsigned long packets_out;	( Число посланных пакетов)
unsigned long bytes_in;	( Число принятых байтов, включая MAC заголовки)
unsigned long bytes_out;	( Число посланных байтов)
unsigned long errors_in;	( Полное число ошибок при приеме)
unsigned long errors_out;	( Число ошибок при посылке пакетов)
unsigned long packets_lost;	( Число потерянных пакетов из-за отсутствия свободного буфера или других ресурсов)

};

Статистические данные имеют вид целых 32-разрядных чисел в формате IBM/PC.

13. Смена физического адреса интерфейса

set_address(addr, len) AH == 25

char far *addr; ES:DI (адрес буфера, где лежит новое значение адреса)

int len; CX (длина адреса в байтах)

В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

13 CANT_SET;

14 BAD_ADDRESS.

При благоприятном выполнении запроса флаг carry=0, а значение регистра CX сохраняется.

Запрос используется в случае, когда необходим специфический физический адрес интерфейса (например, в случае DECNET). При наличии более одного указателя (handle) драйвер откажется исполнить данный запрос и пришлет сообщение CANT_SET.

Этим не исчерпывается перечень возможных запросов, существует некоторое количество операций, относящихся к экстра-набору функций (код функциональности 5 или 6, смотри описание запроса driver_info).

Таблица

Таблица 2.2.1.

Название метода	Расшифровка	Описание
1B2B		Один бит исходной последовательности кодируется комбинацией из 2 бит половинной длительности
B3ZS B6ZS B8ZS	bipolar with 3/6/8 zero substitution	Биполярный код с заменой 000/000000/00000000 на последовательности 00v/0vb0vb/000vb0vb (или b0v для B3ZS)
HDB2 (/3)	High density bipolar code of order 2 (/3)	Биполярный код высокой плотности второго (третьего) порядка. Эквивалентен коду с возвратом к нулю (RZ) и с инверсией для логических 1. Последовательность 000 (соответственно 0000) заменяется на 00v или b0v (соответственно 000v или b00v). Число b сигналов между v-сигналами всегда нечетно. В результате возникает трехуровневый код.
CMI	coded mark inversion	Двухуровневый двоичный код (класса 1B2B) без возвращения к нулю. Используется инверсия полярности для каждой логической 1 (единице ставится в соответствие 11 или 00), а для каждого логического нуля вводится смена полярности в середине интервала.

Кадр содержит 120 пар бит (quats), что соответствует 240 бит, 8 кадров образуют мультифрэйм. Первый кадр мультифрэйма выделяется путем посылки Inverted Synchronization Word (ISW). В конце каждого кадра всегда присутствуют специальные биты, которые служат для целей управления (бит активации, бит холодного старта, биты состояния питания, биты управления синхронизацией и т.д.). Структура кадра выглядит следующим образом:

Биты quats Канал 1-18 1-9 isw (кадр 1) sw (кадры 2-8) 19-26 10-13 b-канал 1 27-34 14-17 b-канал 2 34-36 18 d-канал 37-44 19-22 b 45-52 23-26 b 53-54 27 d 55-62 28-31 b 63-70 32-35 b 71-72 36 d 73-80 37-40 b 81-88 41-44 b 89-90 45 d 91-98 46-49 b 99-106 50-53 b 107-108 54 d 109-116 55-58 b 117-124 59-62 b 125-126 63 d

Биты quats Канал 127-134 64-67 b 135-142 68-71 b 143-144 72 d 145-152 73-76 b 153-160 77-80 b 161-162 81 d 163-170 82-85 b 171-178 86-89 b 179-180 90 d 181-188 91-94 b 189-196 95-98 b 197-198 99 d 199-206 100-103 b 204-214 104-107 b 215-216 108 d 217-224 109-112 b 225-232 113-116 b 233-234 117 d 235-240 118-120 Контроль и управление < Таблица Таблица 7.2.1. Сетевая среда Класс Фирма, интерфейс Тип интерфейса dec/intel/Xerox 1 3com 3C500/3C501 1 "Bluebook" ethernet 3com 3C505 2 Interlan NI5010 3 Micom-Interlan NP600 6 Ungermann-bass PC-nic 8 Univation NC-516 9 TRW PC-2000 10 Interlan NI5210 11 3com 3C503 12 3com 3C523 13 Western digital WD8003 14 Spider systems S4 15 Torus frame level 16 10net communications 17 Gateway PC-bus 18 Gateway at-bus 19 Gateway MCA-bus 20 IMC PCnic 21 1 IMC PCnic II 22 Micromatic research 25 Clarkson "multiplexor" 26 D-link 16-bit 28 D-link ps/2 29 Research machines 16 31 Research machines MCA 32 Interlan NI9210 34 Interlan NI6510 35 Novell NE2000 36 Allied telesis pc/xt/at 38 Allied telesis NEC PC-98 39 Ungermann-bass NIC/PS2 41 Tiara lancard/E AT 42 Tiara Lancard/E MC 43 Tiara Lancard/E TP 44 AT&T Starlan NAU 47 AT&T Starlan-10 NAU 48 AT&T Ethernet NAU 49 Pronet-10 2 Proteon P1300 1 Proteon P1800 2 IEEE 802.5/pronet-4 IBM Token Ring интерфейс 3 Proteon P1340 2 Proteon P1344 3 Gateway PC-bus 4 Gateway AT-bus 5 Gateway MCA-bus 6 Omninet 4   Appletalk 5     Последовательный интерфейс 6 Clarkson 8250-slip 1 Clarkson "multiplexor" 2 Starlan 7     Arcnet 8 Datapoint RIM 1 AX.25 9     KISS 10     IEEE 802.3 w/802.2 HDRS 11     FDDI W/802.2 HDRS 12     Internet X.25 13 Western Digital 1 N.T. Lanstar (encap. dix) 14 NT Lanstar/8 1 NT Lanstar/mc 2 SLFP 15     Netrom 16     Nclass 17     Любой пакетный драйвер имеет блок исходных данных (MS-DOS), напр.: EADDR_LEN equ 6   ; длина физического адреса init_block struc     init_mode dw 0   init_addr db eaddr_len dup(?) ; ethernet-адрес init_filter db 8 dup(0) ; Логический адресный фильтр (multicast filter). init_receive dw ?,? ; Указатель входного кольцевого буфера init_transmit dw ?,? ; Указатель выходного кольцевого буфера. init_block ends     Структура переменных init_mode (смещение = 0) имеет вид /td>

Кадры следуют каждые 1.5мс. Здесь нужно следить за тем, чтобы не было корреляции между сигналами, следующими в противоположных направлениях. Для этого используются скрэмблеры.
В традиционной телефонной сети для соединения с требуемым клиентом используются аппаратные коммутаторы. Если коммутатор имеет n входов и n выходов, то одновременно можно реализовать не более n связей. Реально это число всегда меньше и клиент слышит в трубке “короткие гудки” сигнала “занято”. В случае комбинирования традиционного коммутатора с m-канальными мультиплексорами пакетов по времени можно осуществить до m*n связей одновременно. При этом становится возможным объединить нескольких клиентов так, что они все одновременно могут говорить друг с другом. Схема такого переключателя каналов показана на Рисунок 2.2.8.

Кодирование элементов изображения

Таблица 2.5.1. Кодирование элементов изображения

Режим кодирования	Элементы, подлежащие кодированию	Обозначение	Код
Проход	a1a2	p	0001
Горизонтальный	b0b1,b1b2	h	001+m(b0b1)+m(b1b2)
Вертикальный	b1 под a1 b1a1=0 b1 справа от a1 b1a1=1 b1a1=2 b1a1=3 b1 слева от a1 b1a1=1 b1a1=2 b1a1=3	v(0) vr(1) vr(2) vr(3) vl(1) vl(2) vl(3).	1 011 000011 0000011 010 000010 0000010 0000001ххх

Перед началом передачи терминалы должны обменяться своими идентификаторами (TID - terminal identification). В последнее время появились факс-аппараты, которые печатают изображение на обычную бумагу с разрешением 300-400 точек на дюйм. Такая схема удобна, но имеет некоторые недостатки. Такие аппараты дороги, печать может начаться не ранее, чем будет передана вся страница; передающий аппарат может иметь более низкое разрешение, нужно уметь адаптироваться к любому разрешению, что приводит к тому, что скорость печати изображения при низком разрешении остается столь же низкой, как и при высокой.

В 1970 году в Бритиш Телеком были разработаны основные принципы еще одного вида передачи графической информации - телетекста, первые опыты по его внедрению относятся к 1979 году. Стандарт на мозаичное представление символов был принят CEPT в 1983 году. Каждому символу ставится в соответствие код длиной в 7-8 бит. На экране такой символ отображается с помощью специального знакового генератора, использующего таблицу.

Полному экрану видео текста, содержащему 24 строки по 40 символов, соответствует 960 байт, для передачи которых по коммутируемой телефонной сети требуется 6,4 секунды. D-канал ISDN может пропустить эту информацию за 1 сек, а B-канал быстрее за 0,1 сек. Телетекст позволяет более эффективно использовать каналы связи и не налагает чрезмерных требований на устройства отображения.

Известно, что для корректной передачи цвета требуется 16 миллионов оттенков (8 бит на каждую из трех цветовых компонент). Таким образом, для описания картинки на экране, содержащей 575 линий по 720 пикселей, требуется 1,240 Мбайта.

Для передачи такой информации по

Для передачи такой информации по B-каналу ISDN, если не используется сжатие, потребуется около 2,5 минут. Эта цифра помогает понять актуальность проблемы сжатия графической информации. При передаче чисто текстовой информации электронная почта имеет по этой причине абсолютное преимущество перед факсом. В перспективе можно ожидать внедрения сжатия информации при передаче почтовых сообщений с последующей дешифровкой данных принимающей стороной. Первым шагом на этом пути является внедрение системы MIME. Такое усовершенствование электронной почты сделает ее еще более грозным конкурентом факс-машин. Ведь передача графических образов уже не является монополией факсимильных систем, а возможность шифрования почтовых сообщений (например, в PGP) делает электронную почту более противостоящей перехвату. Таким образом, чтобы выдержать конкуренцию со стороны электронной почты разработчикам факс-систем нужно упорно работать.
Стандарты для представления и передачи изображения разрабатывает Joint Photographic Expert Group (JPEG). Для сжатия графической информации в настоящее время используется дискретное косинусное двухмерное преобразование (DCT - Discrete Cosine Transform), которое дает субъективно наилучший результат и описывается уравнением:

Коды типа сообщений

Таблица 4.4.9.5.1. Коды типа сообщений

Код поля тип	Тип сообщения pim
0	hello
1	register
2	register-stop
3	join/prune
4	bootstrap
5	assert
6	graft (используется только в pim-dm)
7	graft-ack (используется только в pim-dm)
8	candidate-rp-advertisement

Поле длина адреса характеризует длину кода адреса в байтах. Поле контрольная сумма вычисляется методом суммирования всего pim-сообщения по модулю 1, это поле имеет длину 16 бит. Формат закодированного группового адреса показан на Рисунок 4.4.9.5.4.

программируемого драйва

Таблица программируемого драйва

PDU

Protocol Data Unit

Протокольный блок данных

Plug Distribution Unit

Вставной блок распределения

PE

Program Element

Элемент программы

Processing Element

Обрабатывающий элемент

PhotoElement

Фотоэлемент

PEA

Pocket Ethernet Adapter

Карманный адаптер Ethernet

PEL

Picture Element [IBM]

Элемент изображения (пиксель)

PEM

Privacy Enhanced Mail

Почта с улучшенной защитой [Internet]

PEN SDK

Pen Computing Software Development Kit

PEP

Packetized Ensemble Protocol

Протокол сборки пакетов [Telebit]

Packet Encoding Protocol

Протокол кодирования пакетов

Pascal Execution Profiler

Конфигурационный файл исполнения Pascal

PER

Packet Error Rate

Частота ошибок при передаче пакетов

PERL

Practical Extraction and Report Language

Язык программирования [Unix]

PERT

Program Evaluation and Review Technique

Техника оценки и обзора программ (система планирования и руководства разработками)

PES

Personal Earth Station

Персональная наземная станция

Performance Enhancement Socket

Соединитель для улучшения характеристик

Positioning Error Signal

Сигнал ошибки позиционирования

Processor Enhancement Socket

Улучшенный соединитель процессора

Packetized Elementary Stream

Первичный пакетный поток (MPEG-2)

PET

Pascal Execution Timer

Таймер исполнения Pascal

Positron emission Thomograph

Позитронно-эмиссионный томограф

Print Enhancement Technology

Технология улучшения печати [Compaq]

PF

Presentation Function

Функция представления

Page Formatter

Средство форматирования страниц

P/F

Poll/Final bit

Бит запроса или завершения

PFB

PostScript Font-Binary

Файл с данными о шрифте в исходном двоичном формате

PFM

PostScript Font MetyricsBinary

Метрическая информация о шрифте PostScript

PFR

Power-Fail Restart

Перезапуск при сбое питания

PGA

Pin Grid Array

Массив ножек корпуса

Professional Graphics Adapter

Профессиональный графический адаптер [IBM]

PGDN

Page Down

На страницу вниз

PGL

Peer Group Leader

Член группы в ATM, который выполняет функции LGN

PGM

Portable GrayMap

Формат для полутоновых графических файлов

PGP

Pretty Good Privacy

Безопасная система электронной почты (Название программы шифрования)

PHIGS

Programmer's Hierarchical Interactive Graphics System

Иерархическая интерактивная графическая система для программистов

PHY

PHysical Layer Protocol

Протокол физического уровня

PI

Protocol Identifier

Идентификатор протокола

Program Interrupt

Программное прерывание

PIA

Programmable Interconnect Array

Программируемая матрица связи

Peripheral Interface Adapter

Адаптер периферийного интерфейса

PIB

Policy Information Base

База данных маршрутной политики (BGP)

PIC

Personal Intelligent Communicator

Персональный интеллигентный коммуникатор

Priority Interrupt Controller

Контроллер приоритета прерываний

Program Interrupt Controller

Контроллер программных прерываний

Programmable Interface Controller

Контроллер программируемого интерфейса

Position Independent Code

Программа, независящая от места загрузки

Primary Interchange Carrier

Первичная несущая

PICS

Platform for Internet Content Selection

Средство для отбора информации в Интернет (для WWW, например, отбор страниц непригодных для детей)

PID

Process Identifier

Идентификатор процесса

Process Identification Number

Идентификационный номер процесса

PIF

Picture Information File

Информационный файл картинки (DOS из Windows)

PILOT

Programmed Inquiry Learning Or Teaching

Программное дистанционное обучение или тестирование

PIM

Protocol of Independent Multicasting

Протокол независимого мультикастинга

Personal Information Manager

Персональный информационный менеджер

PIMB

PCTE Interface Management Board

Управляющий совет по интерфейсам PCTE

PIM-SM

Protocol of Independent Multicasting-Sparse Mode

Протокол независимого мультикастинга - распределенный режим

PIN

Personal Identification Number

Персональный идентификационный номер

Process Identification Number [Unix]

Идентификационный номер процесса

PINE

Pine Is Not Elm [Unix]

“Сосна не вяз” (почтовая система)

PING

Packet InterNet Groper

Пакетное зондирование в Интернет

PINX

Private Integrated Network Exchange

Местный сетевой коммутатор (ISDN)

PIO

Parallel Input/Output

Параллельный ввод/вывод

Processor Input/Output

Ввод/вывод процессора

Programmed Input/Output

Программируемый ввод/вывод

PIP

Picture In Picture

Картинка в картинке

Problem Isolation Procedure

Процедура вычленения проблемы

Programmable Interconnect Point

Программируемая точка подключения

PIPO

Parallel In, Parallel Out

Параллельный ввод, параллельный вывод

PIR

Packet Insertion Rate

Частота ввода пакетов

PIT

Programmable Interval Timer

Программируемый таймер интервала

PIU

Programmable Interface Unit

Программируемый интерфейс

PJE

Pointer Justification Event

Факт выравнивания указателя

PK

Public Key

Общедоступный ключ (в системах шифрования)

PKC

Public Key Center

Центр общедоступных ключей

PKCS

Public-Key Cryptography Standard

Криптографический стандарт для метода с открытым ключом

PKI

Public Key Infrastructure

Инфраструктура общедоступных ключей

PL

Physical Layer (in Net hierarchy)

Физический уровень (в иерархии сетей)

Private Line

Частная линия

PayLoad

Полезная нагрузка

PLA

Programmable Logical Array

Программируемая логическая матрица

PLAR

Private Line, Automatic Ring-down

Частная линия, автоматический дозвон

PLATO

Programmed Logic for Automatic Teaching Operations

Программируемая логика для автоматических операций обучения

PLC

Programmable Logic Controller

Программируемый логический контроллер

PLCC

Plastic Leadless Chip Carrier

Пластиковый безсвинцовый носитель кристаллов

PLCP

Physical Layer Convergence Protocol

Протокол конвергенции физического уровня

PLD

Programmable Logic Device

Программируемый логический прибор

PLDS

Pilot Land Data System [NASA]

PLIM

Physical Layer Interface Module

Интерфейсный модуль физического уровня

PLL

Phase Locked Loop

Система фазовой стабилизации (синхронизации)

PLMN

Public Land Mobile Network

Общедоступная сеть для мобильных клиентов

PLP

Packet Layer Procedure

Процедура пакетного уровня

Packet Layer Protocol

Протокол пакетного уровня (X.25)

PLR

Packet Loss Rate

Частота потери пакетов

PLS

Personal Library System

Система персональной библиотеки

Primary Link Station

Первичная станция канала

PLSP

PNNI Link State Packets

Пакеты состояния канала PNNI

PLU

Primary Logical Unit

Первичный логический блок

PLV

Production Level Video

Производственный уровень видео

PM

Presentation Manager

Менеджер презентаций [IBM]

Preventative Maintenance

Профилактическая работа

Performance Management

Управление рабочими характеристиками

Phase Modulation

Фазовая модуляция

Process Manager

Менеджер процесса

PMA

Physical Medium Attachment

Физическое подключение к среде

PMD

Physical layer Media Dependent

Физический уровень, зависящий от среды

Polarization Mode Dispersion

Поляризационный режим дисперсии

Post Mortem Dump

Распечатка после гибели процесса

PMMU

Paged Memory Management Unit

Блок управления страничной памятью

PMOS

Positive Channel Metal Oxide Semiconductor

Метал-оксидный транзистор с положительным каналом

PMS

Policy Management System

Система управления политикой

Physical Medium Sublayer

Субуровень, зависящий от физической среды

PNG

Portable Network Graphics

Формат графического файла

PNNI

Private Network-to-Network Interface

Частный сетевой интерфейс

Private Network Node Interface

Частный сетевой интерфейс узла

PNO

Public Network Operator

Общедоступный сетевой оператор

PNP

Plug And Play

Вставляй и работай

POC

Point Of Contact

Точка контакта

POET

Packet Over E3/T3

Передача паетов по каналам E3/T3

POH

Path Overhead

Маршрутный заголовок

POL

Problem Oriented Language

Язык, ориентированный на проблему

Procedure-Oriented Language

Процедурно-ориентированный язык

Provisioning Object Library

Объектная библиотека

POM

Provisioning Object Manager

Менеджер объектов

POP

Point Of Presence [MCI]

Точка присутствия

Pop from Stack

Извлечь из стека

Post Office Protocol

Почтовый протокол

POPA

Pop All Registers

Извлечь все регистры

POS

Point Of Sale

Точка торговли

Positive

Положительный

Programmable Object Select

Программируемый выбор объекта

POSIX

Portable Operating System Interface for Computer Environment

Переносимый интерфейс операционной среды для компьютерной среды (стандарт IEEE)

POST

Power On Self Test and initialization

Самотестирование питания и инициализация (PC)

POSTNET

Postal Numeric Encoding Technique

Техника кодирования почтовых номеров

POTS

Plain Old Telephone Service

Традиционные телефонные услуги

POWER

Performance Optimization with Enhanced RISC

Оптимизация рабочих характеристик для улучшенного RISC [IBM]

PPD

Postscript Printer Description

Описание постскриптовского принтера

PPDS

Personal Printer Data Stream

Поток данных персонального принтера [IBM]

PPI

PDH Physical Interface

Физический интерфейс сигнала PDH

PPM

Pages Per Minute

Число страниц в минуту

Part Per Million

Частей на миллион

Part Per Mile

Частей на тысячу

PPP

Point-to-Point Protocol

Протокол для связи точка-точка – традиционные телефонные услуги (RFC-1331-34; 77-78)

PPCS

Parallel Processing-Computer Server

Сервер параллельного процессора

PPL

Projection Pursuit Learning

PPS

Packets/pulses Per Second

Число пакетов/импульсов в секунду

Power Personal Systems

Персональные системы питания [IBM]

PPSN

Public Packet Switched Network

Общественная сеть с коммутацией пакетов

PPU

Pointer Processing Unit

Блок обработки указателей

PQ

Priority Queuing

Приоритетные очереди

PQFP

Plastic Quad Flatpack Package (chip housing)

Тип пластмассового корпуса микросхемы

PR

Pattern Recognition

Распознавание образов

PRACSA

Public Remote Access Computer Standards Association

Ассоциация по стандартам на удаленный общий доступ к ЭВМ

PRAM

Parallel Random-Access Machine

Машина с произвольным параллельным доступом

Parameter Random Access Memory

Параметрическая память с произвольным доступом

PRC

Primary Reference Clock

Первичный эталонный тактовый генератор

PREP

PowerPC Reference Platform

Эталонная платформа PowerPC

PRI

Primary Rate Interface

Интерфейс первичной скорости передачи (ISDN)

PRL

Process Resource List

Список ресурсов процесса

PRMD

PRivate Management Domain name

Частное имя управляющего домена [X.400]

PROFS

Professional Office System

Профессиональная офисная система (IBM)

PROLOG

Programming In Logic (Programming Language)

Название языка программирования

PROM

Programmable Read Only Memory

Программируемая память, рассчитанная только на чтение

PRR

Pulse Repetition Rate

Частота повторения импульсов

PRS

Primary Reference Source

Первичный эталонный источник

PS

Post Script

Формат текста

Permutation Symmetric

Симметричная перестановка

Planning and Scheduling

Планирование и составление графика

PSA

Program Structure Analyzer

Анализатор программной структуры (Borland Pascal)

Pascal Structure Analyzer

Анализатор структуры Паскаля

PSC

Print Server Command

Команда принт-сервера

Product Service Center

Сервисный центр

Protection Switch Count

Число защитных переключений

Picture Start Code

Стартовый код при передаче изображения

PSD

Protection Switch Duration

Длительность защитного переключения

PSDN

Packet-Switched Data Network

Сети с коммутацией информационных пакетов

PSD

Printer Sequence Description

Описание последовательности принтера

Power Spectral Density

Спектральная плотность

PSDN

Packet Switch Data Networks

Информационные сети с переключением пакетов

PSDS

Packet-Switched Data Service

Информационные услуги с коммутацией пакетов

PSE

Packet Switch Exchange

Коммутатор пакетов

PSF

Permanent Swap File

Постоянный файл подгрузки

PSH

Push flag

Флаг push (TCP-заголовок)

PSI

DEC's X.25 interface software

Программное обеспечение интерфейса X.25 DEC

Packet-Switch Interface

Интерфейс с переключением пакетов

PSID

PostScript Image Data

Графические данные PostScript

PSM

PDH-to-SDH Mediator

Устройство сопряжения PDH с SDH

PSN

Packet-Switch Network (Nodes)

Сеть с коммутацией пакетов

PSP

Program Segment Prefix

Префикс сегмента программы

Packet Switching Processor

Процессор переключения программы

Personal Software Products (group)

Персональный программный продукт [IBM]

PSPDN

Packet Switching Public Data Network

Общественная информационная сеть с пакетным переключением (X.25)

P-SRAM

Pseudo-Static Random Access Memory

Псевдо-статическая память с произвольным доступом

PSS

Packet Switch Stream

Поток с переключением пакетов

Physical Signaling Sublayer

Физический сигнальный субуровень

Private Signaling System

Частная сигнальная система (ISDN)

PSTN

Public Switched Telephone Network

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

PST

Pacific Standard Time

Тихоокеанское стандартное время

PSW

Program Status Word

Слово состояния программы

PT

Payload Type

Тип поля данных

PTD

Parallel Transfer Disk Drive

Диск-драйв с параллельной передачей

PTI

Payload Type Identifier

Идентификатор тип данных в пакете (ATM)

PTO

Public Telecommunication Operator (e.g. PTT)

Оператор общественных телекоммуникаций (например, PTT)

PTNX

Private Telecom Network Exchange

Местная цифровая АТС (ISDN)

PTSE

PNNI Topology State Element

Элемент состояния топологии PNNI

PTSЗ

PNNI Topology State Packet

Пакет состояния топологии PNNI

PTT

Post, Telephone, Telegraph service

Почта, телефон, телеграф (министерство связи)

PU

Physical Unit

Физический блок

PUP

PARC Universal Packet

Универсальный пакет PARC (Xerox)

PUS

Processor Upgrade Socket

Панель для замены процессора

Processor Upgrade Socket

Соединитель актуализации процессора

PVC

Permanent Virtual Circuit (Connection)

Постоянная виртуальная схема (соединение)

Polyvinyl Chloride

Поливинил хлорид

PVM

Parallel Virtual Machine

Параллельная виртуальная машина

Pass-through Virtual Machine (protocol)

Протокол виртуальной машины [IBM]

PVP

Packet Video Protocol

Пакетный видео-протокол

Permanent Virtual Path

Постоянный виртуальный маршрут

PW

Pass Word

Слово-пароль

Pulse Width

Ширина импульса

PWB

Printed Wiring Board

Карта с печатной разводкой проводов

Programmer's Workbench

Рабочая станция программиста [Microsoft]

PWD

Print Working Directory

Отобразить рабочий каталог [Unix]

PWSCS

Programmable Workstation Communication Services

Программируемая рабочая станция для коммуникационных услуг [IBM]

На выходе пакетизатора мы имеем

Таблица 2.5.2. Размеры кадров MPEG-1 и MPEG-2

	Тип кадра
i	p	b	Средний
mpeg-1 (1,15 Мбит/с)	150,000	50,000	20,000	38,000
mpeg-2 (4 Мбит/c)	400,000	200,000	80,000	130,000

Мультиплексирование аудио- и видеоданных в MPEG-2 показано на Рисунок 2.5.8. На выходе пакетизатора мы имеем элементарные потоки пакетов (PES- Packetized Elementary Stream), содержащих около 30 полей, включая длину, идентификаторы потоков, временные метки, контрольные суммы и т.д. В MPEG-2 формируется два комплексных потока, программный поток (PS) длинных пакетов переменной длины сходный с MPEG-1, содержащий видео и аудио данные и имеющий общую временную шкалу, и транспортный поток (TS) пакетов постоянной длины (188 байт) без общей временной шкалы. В последнем случае минимизируется влияние потерь пакетов в процессе транспортировки. Предусмотрено выделение в потоке составляющих разной степени важности (например, DCT-коэффициентов и обычных графических данных).

Стандартизованные DLL-номера протоколов для PPP (поле протокол)

Таблица 3.5.1. Стандартизованные DLL-номера протоколов для PPP (поле протокол)

DLL-код протокола (шестнадцатеричный)	Наименование протокола
0001	Протокол заполнения (padding)
0003-001F	Зарезервировано
0021	IP-протокол
0023	Сетевой уровень OSI
0025	Xerox NS IDP
0027	Decnet фаза IV
0029	Appletalk
002B	Novell IPX
002D	Компрессированный TCP/IP протокол Ван Джекобсона
002F	Не компрессированный TCP/IP протокол Ван Джекобсона
0031	PDU мостов
0033	Потоковый протокол (ST-II)
0035	Banyan Vines
0039	Appletalk EDDP
003B	Appletalk Smartbuffered
003D	Multi-link
003F	Кадры Netbios
0041	Cisco Systems
0043	Ascom Timeplex
0047	Удаленная локальная сеть DCA
0049	Транспортный протокол для последовательных данных (PPP-SDTP)
004B	SNA через 802.2
004D	SNA
004F	Сжатие заголовков IPv6
007D	Зарезервировано (Управл. ESC) [RFC1661]
00FD	1-ый вариант компрессии
0201	Пакеты отклика 802.1d
0203	IBM BPDU базовой маршрутизации
8021	Управляющий протокол Интернет (IPCP)
8023	Управляющий протокол сетевого уровня OSI
8025	Управляющий протокол Xerox NS IDP
8027	Управляющий протокол Decnet фаза VI
8029	Управляющий протокол Appletalk
802B	Управляющий протокол Novell IPX
8031	Бридж NCP
8033	Потоковый управляющий протокол
8035	Управляющий протокол Banyan Vines
803D	Многосвязный управляющий протокол
803F	Управляющий протокол кадров NetBIOS
8041	Управляющий протокол Cisco
8043	Ascom Timeplex
8045	Управляющий протокол Fujitsu LBLB
8047	Управляющий протокол удаленных локальных сетей DCA (RLNCP)
8049	Управляющий протокол передачи последовательных данных (PPP-SDCP)
804B	Управляющий протокол для передачи sna поверх 802.2
804D	Управляющий протокол SNA
804F	Управляющий протокол сжатия заголовков IPv6
80FD	Управляющий протокол сжатия
C021	Канальный управляющий протокол
C023	Протокол аутентификации паролей
C025	Сообщение о состоянии канала
C081	Управляющий протокол для работы с контейнерами

Значения кодов поля протокола от 0xxx до 3xxx идентифицируют протоколы сетевого уровня, а значения в интервале 8xxx - bxxx говорят о том, что протокол соответствует NCP (Network Control Protocol). Коды из диапазона 4xxx - 7xxx используются для протоколов с низким уровнем трафика, а коды от cxxx до exxx соответствуют управляющим протоколам (например, LCP).

Протокол PPP при установлении соединения предусматривает процедуру аутентификации, которая является опционной (смотри Рисунок 3.5.2.). После перехода на сетевой уровень вызывается NCP-протокол, который выполняет необходимую конфигурацию канала.

Значения поля код LCP-заголовка

Таблица 3.5.2 Значения поля код LCP-заголовка

Код	Тип пакета
1	Запрос конфигурации	Configure-Request
2	Подтверждение конфигурации	Configure-Ack
3	Не подтверждение конфигурации	Configure-Nak
4	Отклонение конфигурации	Configure-Reject
5	Запрос завершения	Terminate-Request
6	Подтверждение завершения	Terminate-Ack
7	Отклонение кода	Code-Reject
8*	Отклонение протокола	Protocol-Reject
9*	Запрос отклика	Echo-Request
10*	Эхо-отклик	Echo-Reply
11*	Запрос отмены	Discard-Request
12*	Идентификация
13*	Остающееся время
14**	Запрос сброса
15**	Отклик на запрос сброса
*) Только LCP;	**) Только CCP

Для случая запроса Discard-Request между полями длина и данные помещается 4-байтовое поле Magic-Number (магическое число).

Протокол PPP многолик, он способен поддерживать и многоканальные соединения (RFC-1990). Это бывает полезно при работе через ISDN, X.25, Frame Relay или при необходимости расширить пропускную способность за счет подключения нескольких параллельных каналов (MP - MultiLink Protocol). Так как я не сталкивался со случаями, когда пропускной способности было вполне достаточно, данную модификацию PPP-протокола следует считать крайне важной. При этом одной из проблем является распределение пакетов по каналам и последующее их упорядочение принимающей стороной. Особую осторожность в этом случае следует соблюдать при использовании заполнителей. В этом режиме по виртуальному каналу MultiLink запрещается посылать конфигурационные LCP-пакеты Configure-Request, -Reject, -Ack, -Nak, Terminate-Request или -Ack. Принимающая сторона в случае их обнаружения должна их игнорировать. Применение других LCP-пакетов допускается (например, Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request).

Формат MP-пакета представлен на Рисунок 3.5.5.

---

---