CC BY
98
УДК004.7:004.272.44
МОДИФИЦИРОВАННЫЙ МЕТОД АДАПТАЦИИ СКОРОСТИ ПЕРЕДАЧИ ПОТОКОВ ДАННЫХ В КОМПЬЮТЕРНОЙ СЕТИ НА ОСНОВЕ ПРОТОКОЛА RAP
САЕНКО В.И., СНУРНИКОВ О.М._______________
Рассматриваются вопросы обеспечения качества функционирования потоковых мультимедиа-приложений в компьютерных сетях. Предлагается модифицированный метод адаптации скорости передачи мультимедиа-потоков с использованием протокола RAP для сетей с участками типа «узкое горло». Приводятся результаты имитационных исследований.
1. Описание проблемы и анализ известных результатов исследований
Недостаточная поддержка средств обеспечения качества обслуживания в современных компьютерных сетях не останавливает быстрый рост потребности в использовании потоковых мультимедиа-приложений, таких как аудио- и видеоприложения. На протяжении последних лет, наряду с р азвитием и стандартизацией высокоскоростных средств передачи данных, наблюдается также и развитие средств повышения качества обслуживания потоков.
Потоки данных аудио- и видео-приложений в компьютерных сетях относятся к так называемым потокам данных реального времени, предъявляющим жесткие требования как к предоставляемой полосе пропускания, так и к задержкам и потерям пакетов. В то же время современные технологии компьютерных сетей ориентированы преимущественно на обслуживание потоков по мере возможности и не могут гарантировать обеспечения выполнения такого рода требований.
Протоколы обеспечения передачи потоков аудио- и видеоданных должны обеспечивать как возможность максимальной утилизации доступных ресурсов компьютерной сети (при этом не допуская перегрузок сети), так и справедливость распределения этих ресурсов между потоками. Справедливость распределения ресурсов должна обеспечиваться также по отношению к потокам данных, не являющимся потоками данных реального времени, как преобладающих в компьютерных сетях на сегодняшний день. Также должна обеспечиваться своевременная реакция на изменения в утилизации ресурсов сети.
Существует целый ряд работ, предлагающих специальные протоколы передачи мультимедиа-потоков в компьютерных сетях [1-3]. Общей проблемой современных протоколов адаптации скорости передачи мультимедиа-потоков является недостаточный уровень контроля перегрузок в сети либо чрезмерная
агрессивность в отношении распределения полосы пропускания.
Актуальной является проблема разработки адаптивных по отношению к состоянию сети передачи данных методов управления процессом передачи мультимедиа-потоков.
Весьма удачным решением проблем передачи потоков аудио- и видеоданных является протокол RAP [4] (Rate Adaptation Protocol, протокол адаптации скорости передачи). Это специализированный протокол контроля перегрузок сети при трансляции аудио- и видеоданных, обеспечивающий справедливое распределение ресурсов сети между потоками RAP и при наличии потоков TCP. Особенностями данного протокола являются ориентированность на адаптацию одноадресных (unicast) потоков и использование уровня потерь пакетов в канале передачи данных для оценки состояния сети.
2. Постановка задачи и описание объекта исследования
Целью работы является выявление путей обеспечения стабильности использования ресурсов компьютерной сети при передаче потоков аудио- и видеоданных
Опишем процесс передачи данных на основе адаптивных методов. Пусть задана компьютерная сеть с множеством сегментов и неоднородными с точки зрения полосы пропускания и задержек участками передачи данных. В этой сети осуществляется одноадресная передача одного или более потоков мультимедиаданных. Каждый из передаваемых потоков проходит через множество сегментов от узла-источника до узла-получателя, на которых функционируют, соответственно, приложение-источник и приложение-получатель. На пути потока может содержаться канал связи с минимальной доступной пропускной способностью, который считается «узким горлом» для данного потока. Пусть процесс передачи осуществляется с использованием протокола RAP [4].
Считается, что сеть не содержит избыточных путей либо же путь прохождения потока остается неизменным на время его существования. Предполагается отсутствие специальных средств обеспечения качества обслуживания (QoS).
Согласно [4], архитектура протокола RAP может быть представлена следующим образом (рис. 1).
Приложением-источником является, например, web-сервер либо специализированный сервер видео по запросу. Приложением-получателем является клиент, запрашивающий аудио- или видеоинформацию у приложения-источника.
Скорость передачи потока сервером управляется при помощи модуля RAP, контролирующего перегрузки в сети путем обнаружения потерь пакетов при передаче потока и определяющего на основании состояния сети необходимую скорость передачи потока серве-
ВЕ, 2005, 1 4
103
ром. Значение скорости передачи, определяемое модулем RAP, поступает на вход менеджера слоев, целью которого является определение максимально возможного количества слоев, суммарная скорость передачи которых соответствовала бы значению, задаваемому модулем RAP. Выходная информация о передаваемых слоях поступает на вход менеджера буфера сервера, извлекающего информацию соответствующих слоев из файлового архива или получающего ее непосредственно от источника «живого» сигнала и отправляющего полученную информацию в буфер передачи. Буфер передачи потока представляет собой FIFO-очередь, на вход которой поступает информация слоев для передачи по сети, а на выходе формируются пакеты для передачи по сети; размер пакетов фиксирован, а временной промежуток между ними задается модулем RAP.
Буфер приема предназначен для сглаживания влияния кратковременных перегрузок сети на качество воспроизведения потока. Менеджер буфера приема предназначен для обеспечения селективной ретрансмиссии потерянных пакетов; он определяет потерянные пакеты, передачу которых целесообразно повторить до декодирования и воспроизведения соответствующей мультимедийной информации. Агент RAP сообщает серверному блоку RAP об уровне потерь и номера пакетов, подлежащих ретрансмиссии. Для управления ретрансмиссией со стороны сервера используется менеджер ретрансмиссии. Необходимо отметить тот факт, что суммарная скорость передачи всех слоев и ретрансмиссируемых пакетов не должна превышать значение скорости передачи, задаваемое модулем RAP.
Общая задача всех компонент состоит в обеспечении передачи мультимедиа-данных от источника к получателю. При этом не учитывается число однородных потоков и существование в сети других потоков. Очевидно, что нестабильность характеристик передачи отдельного потока может существенно влиять на
104
состояние сети в целом, приводя к перегрузкам научастках, являющихся «узким горлом», и препятствуя тем самым передаче других потоков.
Описание метода адаптации RAP. Кратко метод адаптации, используемый в RAP, можно охарактеризовать следующим образом:
- если перегрузки сети не обнаружены, происходит периодическая инкрементация значения скорости передачи потока данных;
- в случае обнаружения перегрузок сети происходит немедленная дек-рементация значения скорости передачи потока данных.
Сигналом о возникновении перегрузок сети для RAP является факт наличия потерь пакетов при передаче потока.
Аналогично протоколу TCP, в RAP используется сглаженная оценка среднего времени прохождения пакетов в оба конца канала связи (RTT, round-trip time), обозначаемая как SRTT (sample round-trip time). Определение SRTT производится по алгоритму Дже-кобсона/Карела [7] для обеспечения совместимости с наиболее широко распространенной модификацией TCP Reno.
В отличие от протокола TCP, использующего управление размером скользящего окна для адаптации к состоянию сети, в RAP применяется управление значением скорости передачи данных. Передача производится пакетами фиксированного размера с регулируемой задержкой между их отправлениями.
Постановка задачи. Пусть существует некоторая информационная система, предоставляющая сервис видеопотоков в компьютерной сети, функционирующий на основе протокола RAP. Формулируются задачи:
- провести исследование поведения процесса передачи данных на основе протокола RAP;
- найти новые решения по улучшению характеристик протокола RAP;
- доказать, что новое решение действительно улучшает характеристики процесса передачи потоков данных.
3. Описание структуры имитационной модели и результатов исследований
Исследование поведения алгоритмов управления потоками проводилось с использованием метода имитационного моделирования. В качестве инструментального средства была выбрана система имитационного моделирования пакетных сетей ns-2 [8], использовавшаяся в рамках специально разработанной методики.
Объектом исследований является метод передачи потоков данных на основе протокола RAP.
BE, 2005, 1 4
Методика исследований основана на построении модели в семантике ns-2, выборе топологии моделируемой среды (компьютерной сети), выборе установочных параметров моделируемого процесса передачи данных. Для проведения моделирования использо -валась топология, показанная на рис. 2.
Рис. 2. Схема топологической структуры моделируемого участка сети
Пусть есть компьютерная сеть, заданная узлами (S1, S2, R1, R2, D1, D2) и каналами передачи данных. Пусть в сети имеется участок с «узким горлом» (R1, R2). В сети имеются серверы вещания - источники (S1, S2) и станции-получатели (D1, D2). Пусть существуют два потока (поток 1, поток 2). Каналы связи имеют следующую пропускную способность C(S1, R1) = C(S2, R1) = C(D1, R2) = C(D2, R2) = 1,5 Мб/с. Полоса пропускания узкого места сети составляет 0,5 Мб/с, C(R1, R2) = 0,5 Мб/с. Для каналов связи, не являющихся узкими местами сети, выбрана полоса пропускания, превышающая полосу пропускания «узкого места» в несколько раз, а именно 1,5 Мб/с. Задержки в каналах равны d(S1,R1) = d(S2, R1) = d(R1, R2) = d(R2, D1) = d(R2, D2) = 50 ms. Длина очереди на промежуточных (маршрутизирующих) узлах R1 и R2 составляет 32 пакета.
В рамках исследований осуществлялся сбор следующих параметров: длительность переходного процесса
*
T ; минимальное пиковое значение скорости передачи потока Smm ; максимальное пиковое значение скорости передачи потока Smax ; суммарный уровень потерь пакетов при передаче ^ s . Период снятия измеряемых значений составлял S с.
Описание результатов исследований. Динамика изменения скорости передачи потоков графически показана на рис. 3, а основные значения количественных параметров приведены в табл. 1.
Как видно из табл.1, в моделируемых условиях каждый из потоков RAP изменяет скорость передачи данных. Изменение скорости каждого из потоков на начальном этапе имеет колебательный характер, с длительностью переходного процесса T* порядка 57 с. В течение этого времени амплитуда колебаний (см. значения S™1 и Smax ) является значительной относительно установившегося режима, что, в совокупности с потерями пакетов |Е, приводит к снижению качества работы приложения, использующего протокол RAP. Иными словами, в течение времени порядка одной минуты оба пользователя, для которых были созданы эти потоки, будут получать неудовлетворительное качество воспроизведения мультимедиа- данных (звука или видео), при этом ресурсы сети являются достаточными для предоставления более высокого качества. Очевидно, что наличие столь длительных перегрузок в сети, способной предоставить достаточные ресурсы для качественной работы моделируемых мультимедиа-приложений, является явным показателем недостатков RAP.
Таблица 1
Производилось моделирование передачи двух потоков RAP в течение 100 с, передача обоих потоков начиналась одновременно на 4-й с от момента начала моделирования и завершалась в его конце.
Выбор в имитационной модели топологии с «узким местом» обусловлен тем, что в реальных условиях такая ситуация наблюдается практически в любой компьютерной сети. Как пример может рассматриваться сеть с неоднородными участками, соединенными через маршрутизаторы
ИЛИ КОММутаТОрЫ, Т.е. ТИПИЧ- S,K5/c 600
ная учрежденческая или корпоративная компьютерная сеть.
Допустимые скорости передачи потоков удовлетворяют требованиям, когда при одновременной передаче потоков полоса пропускания «узкого горла» являлась достаточной для передачи обоих потоков в установившемся режиме управления скоростью.
краж
gmx*
500
450
400
350
300
250
200
150
100
50
0
550
Результаты моделирования поведения протокола RAP
Поток Значения параметров
T*, с Smin Кб/с S max Кб/с Iе , пакетов
Л 58 120 520 97
f2 56 100 540 80
0
10 20 30 40 50 60 70
80
90 t, с
Рис. 3. Динамика изменения скорости передачи потоков RAP
BE, 2005, 1 4
105
Таким образом, можно сделать вывод, что методы передачи данных на основе протокола RAP в условиях работы в сетях со структурой «узкое горло» обладают нестабильностью характеристик скорости передачи данных.
Результаты анализа показали, что на основании информации о динамике изменения скорости обоих потоков RAP, показанной на рис. 3, можно отметить, что колебания скорости потоков осуществляются синхронно, т.е. до определенного момента времени периоды наращивания и сброса скорости адаптации совпадают для каждого из потоков.
Выявленная проблема нестабильности скорости передачи объясняется тем, что при одновременной р аботе нескольких потоков (f1, f2) с аналогичными параметрами в условиях дефицита пропускной способности сети происходит одновременное возрастание скорости передачи потоковS(f) и S(f2). Это приводит к более быстрому возникновению перегрузки, нежели в том случае, если производится трансляция единственного потока RAP в аналогичных условиях. При возникновении перегрузки каждый из потоков RAP сбрасывает скорость передачи, и процесс начинается снова. Возникает корреляция колебаний, вызванная
тем, что для потоков, находящихся в одинаковых условиях, время принятия решения об изменении скорости передачи будет практически совпадать. В свою очередь, это вызвано тем, что время принятия решения об изменении скорости передачи и задаваемое значение скорости детерминировано зависят от значения оценки RTT (т.е. SRTT), которое для транслируемых в равных условиях потоков не будет существенно различаться.
4. Модифицированный метод адаптации RRAP
Для того чтобы решить описанную проблему, было решено найти пути улучшения характеристик RAP на основе полученных результатов исследований (п. 3). Решение предлагается в виде усовершенствованного метода, который далее по тексту будет именоваться RRAP (Randomized RAP).
Суть метода. Выделяется несколько процессов выполнения: передача данных, обновление скорости передачи, получение ACK, коррекция SRTT. Схема алгоритма для каждого из указанных процессов приведена на рис. 4. Доступ к данным, используемым процессами совместно, показан пунктирной линией.
Передача данных Начало ►
Обновление скорости Начало
Получение АСК
Коррекция SRTT
Ожидание,
длительность
=IPGH
Отправка пакета
IPG
Нет
еанс окончен ?
Да
Конец
Ожидание, длительность=SRTT
^ Обновление скорости передачи
Рис. 4. Схема алгоритма процессов выполнения RRAP
Передача
данных
Получение
ACK
Обновление
скорости
передачи
Внесение
аддитивной
стохастической[1
составляющей
SRTT
1
Г Обнаружена потеря j
п п п п п
t, c
Рис. 5. Временная диаграмма выполнения процессов RRAP
106
BE, 2005, 1 4
Последовательность выполнения процессов схематично показана на рис. 5.
Осо бенностиреализации метода. Переменные IPG и SRTT, как показано на рис. 4, используются параллельно выполняющимся процессам, поэтому для синхронизации доступа к значениям переменных применяется известный алгоритм критических секций. Суть его можно вкратце представить следующим образом (на примере изменения значения SRTT при получении ACK-квитанции):
1. При чтении или изменении SRTT процесс, обрабатывающий получение ACK, проверяет значение флага блокировки, которое может быть установлено процессом обновления скорости передачи или же процессом внесения стохастической составляющей:
Fsrtt
0, если переменная занята ,
1, если переменная не занята .
2. Если Fsrtt = 0, то выполнение процесса приостанавливается до тех пор, пока флаг не будет снят установившим его процессом, в противном случае происходит немедленный переход на следующий шаг.
3. Когда флагFsrtt принимает значение 1, обращающийся процесс устанавливает его в 0, препятствуя доступу других процессов (обновления скорости передачи и внесения стохастической составляющей) к значению SRTT.
4. Производится обновление значения SRTT.
5. Устанавливается значение флага блокировки Fsrtt = 1, позволяя доступ к SRTT из других процессов.
чена квитанция; a - параметр, определяющий степень сглаживания оценки RTT для устранения влияния скачкообразных кратковременных перегрузок сети.
Процесс обновления скорости передачи выполняется с периодичностью, равной текущему значению SRTTt. Скорость передачи на i-м шаге определяется как
S, = S:
i PacketSize
н SRTT , где S, и Si_1 - значения скоро-
сти передачи на текущем и на предыдущем шаге; PacketSize - размер пакета (фиксирован для сеанса). Так как размер пакета на время сеанса фиксирован, то для изменения скорости изменяется значение
IPG, * SRTT, IPG, + SRTT, .
При обнаружении потерь производится немедленный сброс скорости передачи: S,+1 = PS,, где 0 < Р < 1 -коэффициент сброса скорости при перегрузке, для совместимости с TCP принято значение р = 0,5 . Регулировка скорости производится путем увеличения значения IPG: IPG,+1 = IPG, / р .
Как видно из рис. 3, процесс передачи данных в рассматриваемых условиях сопряжен с проявлением синхронизации скорости передачи потоков, приводящей к значительному увеличению длительности переходного процесса Т *. Значение SRTT является входным параметром для управления скоростью, и корреляция между вычисляемыми значениями SRTT для каждого из потоков является причиной синхронизации колебаний.
Доступ к SRTT из других процессов, а также доступ к переменной IPG производится аналогично описанию, приведенному выше.
Так как основу метода составляют процессы, приведенные на рис. 4, опишем каждый из них.
Процесс передачи данных представляет собой поочередную передачу пакетов фиксированного размера с периодом, значение которого обозначено как IPGi (Inter-Packet Gap, межпакетный интервал). Скорость передачи на любом i-м шаге определяется как
S _ PacketSize S,
1 IPG, .
Процесс получения ACK. По получению положительных квитанций (ACK) о получении пакета от приложе -ния-получателя происходит обновление SRTT, осуществляемое по методу Джекобсона/Карела [7]:
SRTTj = a * SRTTj_! + (1 - a)* RTTj, где RTTj - значение RTT на текущем шаге, определяемое как Riij = tj - tj; tj - время получения квитанции;
tj - время отправки пакета, для которого была полу-
Процесс коррекции SRTT. Для устранения корреляции колебаний скорости передачи предлагается вносить аддитивную стохастическую составляющую:
SRTT* = SRTTj *(1 + а(0.5-у)), где Y - случайное значение, равномерно распределенное в интервале [0..1]; а - коэффициент, определяющий разброс значений оценки SRTT . Внесение составляющей выполняется с фиксированным интервалом времени Ф,
таким, что ф << min(min(IPG), min (RTT)). Значение
VIPG VRTT
Ф не зависит от текущего состояния потока и определяется параметрами сети, такими как максимальная пропускная способность «узкого горла» и величина задержек на пути потока.
5. Исследование характеристик стабильности RRAP (методика)
Условия проведения исследований. Для сравнительного исследования стабильности RRAP и RAP использовалась топология с участком типа «узкое горло», аналогичная той, что была применена для моделирования RAP (см. выше). Схема моделируемого участка сети приведена на рис. 6
BE, 2005, 1 4
107
Рис. 6. Схема топологической структуры моделируемого участка сети
Пусть есть компьютерная сеть, заданная узлами (S1,S2,..., R1, R2, D1, D2, ...) и каналами передачи данных.. В рассматриваемой сети имеется 50 узлов-источников потоков RAP (S1..S50), передающих данные соответствующим узлам-получателям (D1. .D50). Каждый из источников S1..S50 связан с узлом R1 отдельным полнодуплексным каналом связи с пропускной способностью 100 Мбит/с и задержкой 5 мс. Получатели D1..D50 связаны с узлом R2 аналогичным образом.
Канал связи между узлами R1 и R2 является «узким горлом» в сети, так как он лежит на пути каждого из передаваемых потоков. Полоса пропускания каждого участка сети составляет 100 Мбит/с, C(S1, R1) = .= C(S50, R1) = C(D1, R2) =.= C(D50, R2) = C(R1, R2) = 100 мб/с. Задержки в каналах до узлов R равны d(S1,R1) = . = d(S50, R1) = d(R2, D1)= d(R2, D50) = =5 мс, «узкое место» имеет задержку в канале 10 мс, d(R1, R2)=10 мс. Длина очереди на промежуточных (маршрутизирующих или коммутирующих) узлах R1 и R2 составляет 32 пакета.
Описание методики исследований. Проводилось моделирование 120 с функционирования сети при одновременном запуске всех моделируемых потоков на 4-й с от начала моделирования. Результаты, приведенные ниже, получены на основании раздельного моделирования RAP и RRAP в эквивалентных условиях, описанных выше. Для RRAP были эксперимен-
тальным путем выбраны значения параметров Ф =10Е-4 с, а = 0.4 .
Основные результаты. Динамика изменения скорости для произвольно выбранного потока, моделируемого с использованием RAP и RRAP, показана на рис. 7. В RRAP сравнительно с RAP наблюдается значительное уменьшение длительности переходного процесса; также необходимо отметить, что скорость передачи в установившемся режиме для обоих методов не различается.
В табл. 2 приведены усредненные по потокам результаты моделирования, такие как: среднее время выхода
на установившийся режим MT = ^ T*
N
где Tj -
время выхода на установившийся режим для j-го потока; N - количество потоков; средний размах колебаний скорости передачи в неустановившемся
N 1
режиме MД8 =£ (Sfax - Sfm)^, где Sf
J
N
Smin J-
соответственно, максимальное и минимальное значения скорости передачи -го потока в неустановившемся режиме; среднее значение скорости передачи в
установившемся режиме Ms SJj>t —, где S^> -
JN
значение скорости передачи J-го потока в установившемся режиме; среднее количество потерянных пакетов M—, где ^ - количество пакетов,
JN
потерянных при передаче J-го потока; среднее значение SRTT в установившемся режиме
N
msrt =Е SRTTj‘>T^, где SRTT
1
t >T
N
- значение
SRTT в установившемся режиме для J-го потока.
Как показывают результаты моделирования, применение RRAP вместо RAP в заданных условиях приводит к значительному (более чем в 8 раз) снижению длительности переходных процессов при незначительном (порядка 3%) росте размаха колебаний ско-
108
BE, 2005, 1 4
Таблица 2
Результаты моделирования поведения протокола RAP
Значения измеряемых параметров
Метод мт,с M AS, Мб/с Ms, Мб/с м^, пакетов. MSrt, с
RAP 76.49 4.68 2 590.38 0.04
RRAP 9.5 4.83 2 103.52 0.04
рости передачи в неустановившемся режиме. В установившемся режиме потоки, управляемые RAP и RRAP, выходят на одно и то же значение скорости передачи, что свидетельствует о сохранении ключевых свойств RAP в модификации RRAP. Необходимо отметить значительное уменьшение количества потерь в RRAP сравнительно с RAP. Также важным является то, что смещение значения SRTT в установившемся режиме, вызванное внесением аддитивной стохастической составляющей в RRAP, весьма незначительно (на 0,5%) отличается от RAP. Отсутствие значительного смещения SRTT является показателем совместимости RAP и RRAP, а также сохранения в RRAP такого важного свойства RAP как «дружественность» по отношению к TCP.
Полученные результаты показывают, что введение аддитивной стохастической составляющей в RRAP позволило резко снизить корреляцию колебаний скорости потоков без появления каких-либо отрицательных эффектов. Влияние аддитивной стохастической составляющей на длительность колебаний объясняется внесением незначительного разброса в такие ключевые управляющие параметры как время принятия решения об изменении скорости и задаваемое значение скорости. Незначительные отличия в указанных параметрах для одновременно транслируемых через общее «узкое горло» потоков приводят к тому, что периоды наращивания и сброса скорости каждого из потоков происходят не строго одновременно и с различной амплитудой. Благодаря этому, каждый из потоков имеет возможность выйти на установившийся режим управления скорости, подвергаясь меньшему влиянию со стороны остальных потоков, а следовательно, быстрее, нежели при использовании метода RAP, не использующего внесение аддитивной стохастической составляющей.
Область применения полученныхрезулътатов. Предлагаемый метод может применяться для реализации протоколов управления скоростью передачи потоков мультимедиа-данных в компьютерных сетях.
6. Выводы
Предложены результаты исследований метода адаптивного управления передачей мультимедиа- данных в компьютерной сети. Из результатов имитационных исследований следует, что метод адаптации скорости передачи потоков данных на основе RAP для топологических структур компьютерных сетей с «узким горлом» (см.рис. 2) приводит к ухудшению показателей качества передачи потоков и использования ре-
сурсов сети. Выявлена причина такого поведения метода, состоящая в особенностях оценивания времени прохождения пакетов из конца в конец канала связи.
К основным результатам можно отнести выводы о нестабильности характеристик метода RAP (п. 3), усовершенствованный метод (п.4), результаты исследований (п.5) и методику их проведения (п.3, п.5). Все результаты получены впервые.
Основные научные результат ы можно представить в вербальном виде:
- впервые получены зависимости характеристик стабильности работы протокола передачи данных на основе RAP от способа оценивания задержек в канале связи (п.3). Результаты получены на основании имитационных исследований. Использование этих результатов позволяет выявить область эффективного применения метода RAP и исключить возможные потери ресурсов в сети;
- усовершенствован метод адаптивной передачи данных на основе RAP благодаря изменению процедур оценивания текущей скорости передачи данных. Изменение оценивания достигается добавлением специальной компоненты, позволяющей уменьшить самосинхронизацию процесса передачи. Расчет компоненты осуществляется на основании изменения способа оценивания времени прохождения пакетов из конца в конец канала связи. В свою очередь это к улучшает характеристики стабильности потока и коэффициенты загрузки каналов передачи (равномерность нагрузки);
- получены доказательства того, что усовершенствованный метод действительно обладает лучшими характеристиками стабильности передачи данных. Результаты получены на основе имитационных исследований и могут быть использованы для дополнительных исследований и построения их методик. Это в свою очередь повысит эффективность проводимых аналогичных исследований.
Практическая ценность предложенного метода состоит в том, что в компьютерных сетях использование RRAP приводит к сокращению длительности переходного процесса. Это в свою очередь приводит к повышению качества обслуживания пользователя (позволяет привлечь к услуге новых пользователей), снижает общую нагрузку на сеть, создаваемую потоками, уменьшает нестабильность характеристик загрузки сети. Эти результаты позволяют повысить коэффициент утилизации каналов сети, что непосредственно связано с прибылью от использования систем в целом.
Сравнение с лучшими аналогами. Методы адаптивной передачи потоков данных достаточно распространены [1-3]. В ряде работ отмечались их достоинства и недостатки, обусловленные нестабильностью основных характеристик и неравномерностью скорости адаптации к изменениям загрузки сети [9-12]. Анализ
BE, 2005, 1 4
109
эффективности применения протоколов на основе RAP показан в работах [5, 6], где подчеркивалось, что открытым остается вопрос о скорости реакции протокола на изменения в утилизации сети и вопрос обеспечения стабильной регулировки скорости передачи при скачкообразных изменениях загрузки сети. Кроме того, нигде не исследовались возможности использования этих протоколов в компьютерных сетях с топологией «узкое горло». В то же время такая топология является наиболее типичной для большинства сетей.
В настоящей работе вскрыты недостатки метода RAP, предложен модифицированный по сравнению с [5] метод (RRAP), позволяющий улучшить характеристики качества реализации известного метода RAP [4]. Как показывают результаты имитационного моделирования, применение метода RRAP для протокола RAP позволило значительно снизить длительность переходного процесса T*, не ухудшая основных свойств исходного протокола.
Направление дальнейших исследований. Результаты, полученные в данной работе, касались лишь одного из аспектов улучшения работы протокола управления качеством передачи потока данных. В дальнейшем предполагается также исследовать вопросы совместимости протокола RRAP с различными технологиями управления очередями пакетов на узлах сети.
Литература: 1. Jehan-Francois Paris et al. A hybrid broadcasting protocol for video on demand // Multimedia Computing and Networking Conference. Р. 317-26, San Jose, CA, USA, January, 1999. 2. Shulzrinne H. et al. RTP: a transport protocol for real-time applications // RFC 1889, Internet Engineering Task Force, Jan, 1996. 3. Sally Floyd et al. Equation-Based Congestion Control for Unicast Applications // ACM SIGCOMM 2000, Stockholm, Aug,
2000. 4. Rejaie R. et al. RAP: An End-to-end Rate-based Congestion Control Mechanism for Realtime Streams in the Internet // IEEE Infocom’99, New York, March, 1999. 5. Rejaie
R. et al. Quality Adaptation for Congestion Controlled Video Playback over the Internet // IEEE Journal on Selected Areas of Communications (JSAC), Special issue on Internet QoS, Winter, 2000. 6.MohitTalwar. A Simulation Based Evaluation of RAP // T echnical Report, University of Southern California, Dec., 1998. http://netweb.usc.edu/reza/RAP/NewRAP/ report.ps. 7. Jacobson V. et al. Congestion Avoidance and Control // Computer Communication Review, Aug. 1988. Vol. 18, № 4. Р. 314-329. 8. Bajaj S. et al. Improving Simulation for Network Research. // Technical Report 99-702, University of Southern California, March, 1999. 9. Wang Z., Paganini F. Global Stability with Time Delay in Network Congestion Control // Proc. IEEE CDC. 2002. 10. Wang J, Wei D., Low
S. Modelling and Stability of FAST TCP // Proc. IEEE Infocom March, 2005. 11. Paganini F. et al. Congestion control for high performance, stability and fairness in general networks // IEEE/ACM Transactions on Networking, 13(1), February, 2005. 12. Треногин Н.Г., Соколов Д.Е. Фрактальные свойства сетевого трафика в клиент-серверной информационной системе // Вестник НИИ СУВПТ. Сборник научных трудов. Вып. 14. Красноярск. 2003. С. 163-172.
Поступила в редколлегию 20.10.2005 Рецензент: д-р техн. наук, проф. Кучеренко Е. И.
Саенко Владимир Иванович, канд. техн. наук, доц., проф. каф. информационных управляющих систем ХНУРЭ. Научные интересы: менеджмент компьютерных сетей. Увлечения и хобби: садоводство. Адрес: Украина, 61166, Харьков, пр. Ленина, 14.
Снурников Олег Михайлович, аспирант каф. информационных управляющих систем ХНУРЭ. Научные интересы: методы и технологии управления потоками в компьютерных сетях. Увлечения и хобби: домашний ремонт. Адрес: Украина, 61166, Харьков, пр. Ленина, 14.
УДК004.891
РЕАЛИЗАЦИЯ РЕШАТЕЛЯ И БАЗЫ ЗНАНИЙ ЭКСПЕРТНОЙ СИСТЕМЫ ДЛЯ ПЛАНИРОВАНИЯ ДЕЙСТВИЙ ПОЛЬЗОВАТЕЛЯ ПРИ РАЗРАБОТКЕ ПРОГРАММ
ПРИГОЖЕВ А.С.__________________________
Рассматриваются вопросы, связанные с реализацией подсистемы помощи для планирования действий пользователя при работе с вычислительной системой. Рассматриваются возможные режимы работы подсистемы, структура для различных режимов и особенности реализации. Такой подход позволяет снизить требование к уровню подготовки пользователей и ускорить процесс освоения способов работы с вычислительной системой.
1. Введение
Важной составной частью современных программных систем является подсистема помощи пользователю, позволяющая существенно упростить освоение сис-
1 1 0
темы. Подсистема помощи, как правило, включает набор справочников по возможностям программной системы в виде гипертекста, контекстно-зависимую помощь, поиск по ключевым словам.
Реализация системы помощи на базе набора справочников позволяет пользователю изучить основные концепции и команды в системе. Примерами такой реализации являются файлы помощи операционной системы Windows, man-файлы операционной системы Linux и т.д.
Контекстно-зависимая помощь даёт возможность получать контекстную информацию о функциях программной системы, основываясь на текущем отображаемом окне и/или введённых командах и данных.
Главным недостатком указанных выше подсистем помощи является слабое развитие или отсутствие средств, позволяющих помочь пользователю в решении определённой задачи. Чаще всего метод решения той или иной задачи описан в справочной системе. Однако это не даёт возможности проконтролировать действия пользователя при решении задач. Кроме того, справочная система, которая опи-
ВЕ, 2005, 1 4
