Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

2.5. Связь на основе потоков данных 151

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

приемником. Так, видеопоток, создаваемый камерой, может напрямую переда-

ваться на дисплей, как показано на рис. 2.29, б.

Другая ситуация имеет место в зависР1мости от того, имеется у нас всего один

источник или приемник или мы можем организовать многостороннюю связь.

Наиболее частая ситуация при многосторонней связи

—

присоединение к потоку

данных нескольких приемников. Другими словами, осуществляется групповая

рассылка потока данных нескольким получателям, как показано на рис. 2.30.

Поток данных .

Приемник

Источник

Промежуточный узел,

возможно

^с фильтрами

<ная

Меньшая пропускная

способность

Рис. 2.30. Пример групповой рассылки потока данных

нескольким получателям

Главной проблемой групповой рассылки потоков данных являются разные тре-

бования разных приемников к качеству потока. Рассмотрим, например, источ-

ник передачи высококачественного кино со стереозвуком. Он может потребовать

комплексного потока данных, содержащего вложенный поток для видео, по ко-

торому с частотой 50 Гц передается картинка, и два вложенных потока для аудио

с качеством на уровне компакт-дисков. Даже при использовании современных

технологий сжатия комплексный поток может потребовать скорости передачи

порядка 30x10^' бит/с

[434].

Не всякий приемник в состоянии обработать такой

объем данных. Поэтому поток должен быть настроен на фильтрацию

[500],

кото-

рая приводит в соответствие качество входящего потока и отличное от него каче-

ство исходящего потока, как показано на рис. 2.30. Мы вернемся к управлению

качеством потоков данных позже.

2.5.2.

Потоки данных и качество обслуживания

Временные зависимости и другие нефункциональные требования обычно выра-

жаются в вргде требований к

качеству обслуживания {Quality

of Sewice, QpS). Эти

требования описывают, что должны сделать базовая распределенная система

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

менных соотношений. Требования QoS для непрерывных потоков данных в ос-

новном характеризуются временными диаграммами, объемом и надежностью.

В этом пункте мы кратко рассмотрим требования QoS и их влияние на создание

потока данных.

152 Глава 2. Связь

Специфика QoS

Требования QoS могут быть выражены по-разному. Один из подходов

—

предо-

ставить точную спецификацию передачи {flow

specification),

содержащую требо-

вания по пропускной способности, скорости передачи, задержке и т. п. Пример

такой спецификации, взятый из

[343],

приведен в табл. 2.6.

Таблица 2.6. Спецификация передачи

Характеристики получаемых данных

Требуемое качество обслуживания

Максимальный размер элемента

данных (байт)

Скорость передачи корзины элементарных

пакетов(байт/с)

Размер корзины элементарных

пакетов(байт)

Максимальная скорость передачи (байт/с)

Чувствительность к потерям (байт)

Чувствительность к интервалам (ммс)

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

(элементов данных)

Минимальная фиксируемая

задержка (ммс)

Максимальное отклонение задержки (ммс)

Показатель соблюдения (единиц)

В этой модели характеристики потока формулируются в понятиях

алгоритма

корзипы

элемептарпых

пакетов

{token bucket

algorithm),

который описывает, ка-

ким образом поток формирует сетевой трафик. Принцип работы этого алгоритма

иллюстрирует рис. 2.31. Основная идея состоит в том, что элементарные пакеты

генерируются с постоянной скоростью. Элементарный пакет содержит фиксиро-

ванное число байтов, которые приложение намерено передать по сети. Элемен-

тарные пакеты собираются в корзину, емкость которой ограничена. После пере-

полнения корзины элементарные пакеты просто пропадают. Каждый раз, когда

приложение хочет передать в сеть элемент данных размером N, оно должно из-

влечь из корзины столько элементарных пакетов, чтобы их суммарный размер

был не менее N

байт.

То есть, например, если каждый элементарный пакет Ихмеет

длину k байт, приложение должно удалить из корзины как минимум N/k элемен-

тарных пакетов.

Приложение

Р^,-^^

Нерегулярный

поток элементов

данных

Через каждый

интервал ДТ

в корзину добавляется

один элементарный

пакет

Регулярный поток

Рис. 2.31. Принцип работы алгоритма корзины элементарных пакетов

2.5. Связь на основе потоков данных 153

Эффект алгоритма корзины элементарных пакетов состоит в том, что данные

передаются в сеть с относительно постоянной скоростью, определяемой скоро-

стью генерации элементарных пакетов. Однако он допускает некоторые вспле-

ски,

например, приложению разрешено передавать полную корзину элементарных

пакетов в сеть одной операцией. Чтобы предотвратить особо сильные выплески,

скорость потоков данных может быть ограничена некоторым максимумом. В спе-

цификации передачи приложение обещает, что будет поставлять элементы дан-

ных коммуникационной системе в соответствии с алгоритмом корзины элемен-

тарных пакетов.

Вдобавок к описанию временных отношений между элементами данных, спе-

цификация передачи также содержит требования к обслуживанию.

Чувствитель-

ность

к потерям в комбинации с интервалом потерь определяет максимально

допустимый темп потерь (например, один байт в минуту).

Чувствительность

групповым

потерям определяет, какое количество последовательных элементов

данных можно потерять.

Минимальная фиксируемая

задерэ/ска

определяет, на сколько сеть должна за-

держать доставку данных, чтобы приемник обнаружил задержку. Связанное с этой

величиной максимальное

отклонение задержки

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

дел дрожания. Величина вилки особенно важна для видео- и аудиопотоков.

И наконец,

показатель соблюдения —

число, показывающее, насколько точно

должны соблюдаться требования к качеству обслуживания. Обычно небольшое

число говорит, что если коммуникационная система не сможет обеспечить тре-

буемое качество обслуживания, реально ничего страшного не случится. И наобо-

рот, большое число указывает на то, что если невозможно получить надежные

гарантии качества обслуживанрш, система не сможет работать с потоком данных,

поскольку клиент не допускает отклонений от спецификации.

Описанная проблема со спецификацией передачи состоит в том, что прило-

жение может попросту не знать, что ему нужно на самом деле. Так, заставляя

пользователей описывать качество в понятиях параметров корзины элементар-

ных пакетов, чувствительности к потерям и т. п., поставщик услуг вполне может

вскоре растерять всех своих клиентов. Поэтому правильнее будет классифици-

ровать потоки данных и задать разумные значения по умолчанию для парамет-

ров,

включаемых в спецификации передачи. Так, например, максимум, что мож-

но требовать от пользователя,

—

это выбрать требуемый поток данных (аудио

или видео). При выборе аудиоданных можно предложить еще выбор между вы-

соким, средним и низким качеством. Схожая классификация может быть пред-

ложена и для видеоданных.

Как утверждается в

[344],

классификация не слишком отличается от специ-

фикаций передачи. Отличие состоит только в числе определяемых параметров

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

Создание потока

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

распределенная система должна захватить ресурсы для создания потока, удовле-

творяющего требованиям QoS. В контексте управления потоками ресурсами

154 Глава 2. Связь

обычно являются пропускная способность, буферы и вычислительная мощность.

Выделение пропускной способности производится для того, чтобы гарантиро-

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

приоритетов передачи. Выделение буферов в маршрутизаторах и операционных

системах позволяет сохранять элементы данных для дальнейшей обработки.

И наконец, необходимо, чтобы обработка элементов данных выполнялась за вре-

мя,

отводимое на это соответствующими задачам

—

планировщикам, кодерам

и декодерам, фильтрам и др. Для этого следует правильно распределить процес-

сорное время.

Одна из тех проблем, которые следует решить, состоит в том, что параметры,

характеризующие требованрш QoS к потоку данных, не соотносятся напрямую

с параметрами соответствующих ресурсов. Так, например, определив, что сеть

должна гарантировать возможность одновременной потери не более чем k после-

довательных элементов данных, мы должны преобразовать это определение в раз-

мер статически выделяемых буферов во всех маршрутизаторах от источника до

приемника. Этот размер может быть на самом деле подсчитан на основе других

характеристик потока и привести к абсолютной или статистической гарантии

обслуживания в сети.

К сожалению, в настоящее время не существует единственно лучшей модели

для, во-первых, выбора параметров QoS, во-вторых, обобщенного описания ре-

сурсов в любой коммуникационной системе и, в-третьих, преобразования пара-

метров QoS в значения используемых ресурсов. Отсутствие подобной модели

является причиной того, что описание и организация качественного обслужива-

ния часто нелегка и что разные системы используют разные и несовместимые

методы.

Чтобы дополнительно прояснить вопрос и описать, как QoS в распределен-

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

специальный протокол резервирования ресурсов для QoS в непрерывных пото-

ках данных. Протокол резервирования ресурсов {Resource reSerVation Protocol,

RSVP)

—

это управляющий протокол транспортного уровня для резервирования

ресурсов сетевых маршрутизаторов [72, 503].

Передатчики в RSVP предоставляют спецификацию передачи, характеризую-

щую потоки данных в понятиях пропускной способности, задержек, дрожания

т.

п., очень напоминающую спецификацию передачи, представленную в табл. 2.6.

Это описание передается процессу RSVP, который работает на той же машине,

что и отправитель, как показано на рис. 2.32. Процесс RSVP не занимается

интерпретацией спецификацией передачи. Фактически единственное, что он де-

лает, — это принимает спецификацию передачи от отправителя и локально

сохраняет ее. RSVP

—

это инициируемый получателем протокол QoS. Другими

словами, получатель должен запросить у отправителя запрос на резервирование.

Сохраняя спецификацию передачи, RSVP предотвращает резервирование боль-

шего,

чем это необходимо, объема ресурсов.

Отправитель в RSVP определяет путь к потенциальным получателям и пре-

доставляет спецификацию передачи для потока данных всем промежуточным уз-

лам. Когда получатель готов принимать входящие элементы данных, он сначала

2.5. Связь на основе потоков данных 155

посылает запрос на резервирование по обратному маршруту своему отправите-

лю.

Формат этого запроса в сущности такой же, как у исходной спецификации

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

требования QoS, которые должен определить отправитель, чтобы полностью

удовлетворить запросы получателя.

Процесс

отправителя хост, поддерживающий протокол RSVP

Поток

данных -

приложения

Приложение

Контроль

|соблюдения|

правил

Программа

RSVP

Локальная ОС

- Процесс RSVP

Запрос на резервирование

к другим хостам RSVP

Поток данных

канального уровня

Информация для настройки

других хостов RSVP

Рис. 2.32. Основы организации процесса RSVP для резервирования ресурсов

в распределенных системах

Когда процесс RSVP обрабатывает запрос на резервирование, он передает за-

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

запрашиваемые ресурсы. Запрос передается также и модулю проверки правил,

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

обеих проверок

—

«да», ресурсы могут быть зарезервированы.

Резервирование ресурсов сильно зависит от канального уровня. Фактически,

чтобы протокол RSVP работал, процесс RSVP должен преобразовать параметры

QoS из спецификации передачи в нечто, понятное канальному уровню. Простой

пример: запрос на высокую пропускную способность транслируется в установку

максимального приоритета каждого кадра, несущего данные потока. Основыва-

ясь на первоначальной спецификации передачи (которая указывает на макси-

мальную скорость передачи данных, генерируемых отправителем) и доступной

пропускной способности канального уровня, такое преобразование вполне мо-

жет удовлетворить требования QoS получателя.

Другой подход применяется, если канальный уровень имеет собственный на-

бор параметров QoS, как, например, в сетях ATM. В сетях ATM данные переда-

ются элементами (которые называются ячейками), состоящими из 48-байтного

информационного поля и заголовка длиной 5 байт. ATM позволяет процессу

156 Глава 2. Связь

RSVP задать максимальную скорость ячеек, среднюю скорость ячеек, минимально

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

ками. Существуют и другие параметры QoS. В этом случае задачей процесса

RSVP будет трансляция спецификаций передачи, ориентированных на потоки

данных, в значения параметров, приемлемые для сетей ATM. Соблюдение этих

требований QoS будет проверяться на уровне ATM.

2.5.3. Синхронизация потоков данных

В мультимедийных системах важное значение имеет взаимная синхронизация

разных потоков данных, возможно, собранных в комплексный поток. Синхрони-

зация потоков данных подразумевает поддержание временных соотношений ме-

жду ними. Существует два типа синхронизации.

Простейшая форма синхронизации имеет место между дискретными и непре-

рывными потоками данных. Рассмотрим, например, показ слайдов через Web,

дополненный звуковым рядом. Каждый слайд передается с сервера на клиент

в виде дискретного потока данных. В то же самое время клиент воспроизводит не-

кий аудиопоток (или его часть), который соответствует текущему слайду и так-

же поступает с сервера. В данном случае аудиопоток синхронизируется с пока-

зом слайдов.

Более сложный тип синхронизации наблюдается между непрерывными пото-

ками данных. Дежурный пример воспроизведения фильма, при котором видео-

поток должен быть синхронизирован со звуком, известен как синхронизация ар-

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

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

ное воспроизведение требует взаимной синхронизации двух вложенных пото-

ков,

несовпадение более чем на 20 мс может исказить стереоэффект.

Синхронизация происходит на уровне элементов данных, из которых состоит

поток. Другими словами, мы можем синхронизировать два потока только отно-

сительно элементов данных. Выбор элементов данных очень сильно зависит от

уровня абстракции представления потока данных. Для разъяснения этого мо-

мента рассмотрим аудиопоток (одноканальный) с качеством компакт-диска. При

максимальной степени детализации поток данных представляется в виде после-

довательности 16-битных выборок. При частоте выборки 44 100 Гц синхрониза-

ция с другим аудиопотоком может теоретически производиться каждые 23 мс.

Для получения высококачественного стереоэффекта оказывается, что синхрони-

зация на этом уровне абсолютно необходима.

Однако если мы рассмотрим синхронизацию между аудио- и видеопотоками

для синхронизации артикуляции, обнаружится, что в этом случае можно исполь-

зовать значительно более грубую детализацию. Как мы говорили, видеокадры

показываются с частотой 25 Гц и выше. Используя широко распространенный

стандарт NTSC с его частотой 30 Гц, мы можем сгруппировать аудиовыборки

в логические блоки с временем воспроизведения, равным времени показа видео-

кадра (33 мс. При частоте выборки звука 44 100 Гц блок аудиоданных будет

содержать 1470 отдельных выборок, или И 760 байт, из расчета 16-битных выбо-

2.5. Связь на основе потоков данных

157

рок).

На практике вполне удовлетворительное качество обеспечивается

боль-

шими блоками, по 40 или даже 80 мс

[435].

Механизмы синхронизации

Ну вот, мы и подошли к вопросу о том, как на самом деле обеспечивается синхро-

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

хронизации двух потоков данных и, во-вторых, распределение этих механизмов

в сетевой среде.

Механизмы синхронизации могут рассматриваться с позиций разных уров-

ней абстракции. С точки зрения самого нижнего, синхронизация полностью оп-

ределяется работой с элементами данных простых потоков. Этот принцип иллю-

стрирует рис. 2.33. В сущности, здесь показан процесс, который осуществляет

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

этом обеспечение ограничений синхронизации.

Машина получателя

Процедура, считывающая

два элемента аудиоданных

на каждый элемент

^^^

видеоданных >

Входящий поток

Приложение

ОС

•^

Сеть

Рис. 2.33. Принцип явной синхронизации на уровне элементов данных

Рассмотрим, например, фильм, представленный двумя входными потоками дан-

ных. Видеопоток содержит несжатые изображения низкого качества с разреше-

нием 320x240 пикселов. Каждый из пикселов при кодировании требует одного

байта, что в сумме приводит к элементам видеоданных размером в 76 800 байт.

Предположим, что изображения демонстрируются с частотой 30 Гц, или по 33 мс

на изображение. Считаем, что аудиопоток содержит аудиовыборки, сгруппиро-

ванные в элементы длиной 11 760 байт, каждый из которых, как говорилось

ранее, соответствует звуку длительностью 33 мс. Если процесс ввода может

обеспечить скорость 2,5 Мбайт/с, мы можем обеспечить синхронизацию, просто

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

Оборотная сторона подобного подхода состоит в том, что приложение может

полностью отвечать за синхронизацию только в том случае,

еслР1

оно имеет дос-

туп к механизмам низкого уровня. Лучше будет предоставить приложенрпо ин-

терфейс, который упростил бы ему управление потоками и устройствами. От-

носительно нашего примера это будет означать, что видеодрюплей получит

интерфейс управления, с помощью которого сможет управлять частотой воспро-

изведения изображений. Кроме того, интерфейс предоставит механизм регистра-

158

Глава 2. Связь

ции пользовательского обработчика, который будет вызываться каждый раз после

приема очередных k изображений. Аналогичный интерфейс будет предоставлен

и устройству воспроизведения звука. Используя эти управляющие интерфейсы,

разработчик приложения сможет написать простую программу мониторинга,

сравнивающую два заголовка соответствующих потоков данных. Эта программа

будет проверять, достаточна ли синхронизация видео- и аудиопотоков и в случае

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

Этот последний пример (рис. 2.34) типичен для многих систем мультимедиа

промежуточного уровня. В действительности системы мультимедиа промежуточ-

ного уровня содержат набор интерфейсов для управления аудио- и видеопотоками,

включая интерфейсы управляющих устройств

—

мониторов, камер, микрофоков

и т. п. Каждое устройство и поток данных имеют свои собственные интерфейсы

верхнего уровня, в том числе и интерфейсы для уведомления приложенир! о на-

ступлении некоторого события Последние часто используются при написании

обработчР1Ков, предназначенных для синхронизацирг потоков. Примеры подоб-

ных интерфейсов можно найти в [65].

Система контроля

мультимедиа — это часть

промежуточного уровня

Промежуточный уровень

программного обеспечения"

Приложение сообщает

Машина получателя промежуточному

уровню, что делать

с входящим потоком

Входящий поток

Сеть

Рис. 2.34. Принцип синхронизации, поддерживаемой

высокоуровневыми интерфейсами

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

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

ных, состоящего из требующих синхронизации вложенных потоков, должен точ-

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

локальную

спецификацию

синхронизации.

Обычно эта информация предоставля-

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

в один, содержащий все элементы данных, в том числе и предназначенные для

синхронизации.

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

ты MPEG {Motion

Picture

Experts Group) содержат набор алгоритмов сжатия ви-

део-

и аудиоданных. Существует несколько стандартов MPEG. MPEG-2, напри-

мер,

был изначально предназначен для сжатия видеоизображения с качеством

типичного телесигнала на скоростях от 4 до 6 Мбайт/с. Согласно этому стандар-

ту в единый поток данных может быть собрано неограниченное количество

2.6. Итоги 159

непрерывных и дискретных потоков. Каждый входящий поток сначала преобра-

зуется в поток пакетов, содержащих отметку времени, базирующуюся на 90-кило-

герцевых системных часах. Затем эти потоки мультиплексируются в программ-

ный поток данных

{program

stream), состоящий из пакетов переменной длины,

объединенных одинаковым базовым временем. Принимающая сторона демуль-

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

основы механизма межпотоковой синхронизации.

Еще один важный вопрос: где проводить синхронизацию, на передающем

конце или на принимающем? Если синхронизацией занимается передатчик, он

может объединить потоки данных в один, содержащий различные типы элемен-

тов данных. Рассмотрим вновь поток стереозвука, содержащий два вложенных

потока, по одному на канал. Мы рассматривали единственную возможность

—

передачу потоков независимо друг от друга с последующей синхронизацией на

приемнике путем попарного объединения выборок. Ясно, что если задержки

в каждом из вложенных потоков данных будут разными, синхронизация окажется

крайне затруднительной. Значительно лучше объединить вложенные потоки на

отправителе. Получившийся в результате поток будет содержать элементы дан-

ных, состоящие из пар выборок, по одной на канал. В этом случае приемнику

достаточно просто считать элемент данных и разделить его на выборки левого

и правого каналов. Задержка для обоих каналов будет абсолютно одинаковой.

2.6. Итоги

Наличие мощных и гибких механизмов взаимодействия между процессами явля-

ется важным для всякой распределенной системы. В традиционных сетевых при-

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

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

промежуточного уровня является предоставляемая ими высокая степень абстрак-

ции, благодаря которой описание взаимодействия между процессами на проме-

жуточном уровне значительно проще, чем если бы мы ограничились только ин-

терфейсами транспортного уровня.

Одной из наиболее широко используемых абстракций является удаленный

вызов процедур (Remote Procedure Call, RPC). Сущность RPC в том, что любая

служба реализуется посредством вызова процедуры, тело которой выполняется

на сервере. Клиент предоставляет только сигнатуру процедуры, то есть имя про-

цедуры и ее параметры. Когда клиент вызывает процедуру, клиентская реализа-

ция, называемая заглушкой, упаковывает значения параметров в сообщение и пе-

ресылает его на сервер. Последний вызывает собственно процедуру и возвращает

результат, снова в виде сообщения. Клиентская заглушка извлекает из этого со-

общения значение результата и передает его приложению клиента, иницииро-

вавшему вызов.

Механизм RPC ориентирован на обеспечение прозрачности доступа. Однако

он относительно слабо поддерживает передачу ссылок. В этом смысле удаленные

160 Глава 2. Связь

объекты более прозрачны. Обращение к удаленным методам (Remote Method

Invocation, RMI) напоминает RPC, но отражает специфику удаленных объектов.

Основная разница между ними состоит в том, что RMI позволяет использовать

в качестве параметров ссылки на объекты системы.

RPC и RMI предоставляют механизмы синхронной связи, при которой кли-

ент блокируется до получения ответа от сервера. Несмотря на вариации сущест-

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

более удобными оказываются универсальные высокоуровневые модели, ориен-

тированные на передачу сообщений.

В моделях передачи сообщений неважно, является ли связь сохранной, так

же как неважно и то, является ли она синхронной. Смысл сохранной связи со-

стоит в том, что посылаемое сообщение хранится в коммуникационной системе

до тех пор, пока не будет доставлено по назначению. Другими словами, ни отправи-

тель,

ни получатель при передаче сообщения не обязаны быть активными. В слу-

чае нерезидентной связи механизмы хранения не предусмотрены, а значит, полу-

чатель должен быть готов принять сообщение, когда бы оно ни было послано.

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

установки сообщения в очередь на отправку, возможно, еще до того, как оно бу-

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

до момента получения сообщения. В других вариантах отправитель может бло-

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

него ответа, как это сделано в RPC.

Модели обмена сообщениями промежуточного уровня обычно предоставля-

ют сохранную асинхронную связь и используются там, где применение механиз-

мов RFC и RMI не оправдано. В первую очередь это интеграция наборов баз

данных (сильно распределенных) в крупных информационных системах. Другие

области их применения включают в себя электронную почту и рабочие потоки.

Абсолютно иную связь предлагают потоки данных, проблема которых состо-

ит в том, что любые два последовательных сообщения взаимосвязаны по време-

ни.

В непрерывных потоках данных максимальная задержка доставки своя для

каждого сообщения. Кроме того, необходимо, чтобы сообщения обладали некоей

минимальной задержкой доставки. Типичными примерами непрерывных пото-

ков данных являются аудио- и видеопотоки. Часто бывает сложно описать, каки-

ми должны быть временные взаимосвязи или чего мы ожидаем от базовой под-

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

сталкиваемся с затруднениями. Усложняющим фактором является роль дрожа-

ния (максимальное PI минимальное значения параметров). Даже если средняя

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

привести к неприемлемой производительности.

Вопросы и задания

Во многих протоколах модели OSI каждый уровень добавляет к сообщению

свой заголовок. Несомненно, создавать в начале каждого сообщения единый