Алгоритмы совершенствования процессов информационного обмена для протоколов транспортного уровня распределенных управляющих систем

Размещено на http://www.allbest.ru/

Алгоритмы совершенствования процессов информационного обмена для протоколов транспортного уровня распределенных управляющих систем

Костин С.В.

В статье рассматриваются алгоритмические методы повышения надежности распределенных управляющих систем на основе стека протоколов TCP/IP.

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

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

- установление и разъединение транспортных соединений;

- управление передачей сообщений и обеспечение их целостности;

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

- квитирование доставленных фрагментов сообщений;

- повторы недоставленных пакетов;

- разбивка сообщений на отдельные блоки данных либо, наоборот, их группировка;

- обеспечение передачи сообщений с разной категорией срочности;

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

Чтобы защитить внутренние механизмы сети от перегрузок и удержать характеристики передачи в желаемых пределах при доступе сообщений в транспортную сеть, организуется управление потоком. При этом в протоколе TCP используется механизм «скользящего окна», когда не все поступающие в транспортную сеть сообщения сразу отправляются на передачу; одна транспортная станция может одновременно вести передачу ограниченного числа сообщений (количество сообщений - размер «окна»), остальные поступившие сообщения ожидают передачи в очереди к «окну». При установлении соединения счетчики последовательностей сегментов у отправителя и получателя устанавливаются в одинаковые состояния. Получатель, приняв несколько подряд следующих сегментов, в ответном сообщении-квитанции передает отправителю номер следующего байта данных, который он намерен принять (номер последнего байта в последнем корректно принятом сегменте плюс единица).

Управление квитированием методом “скользящего окна” предоставляет возможность управления потоком в целях повышения качества приема пакетов в сети. Изменяя размер окна для множества источников информации, можно не только эффективно управлять перегрузками на отдельных участках сети, но и манипулировать числом сегментов в ней. Модуль TCP может использовать алгоритм "медленного старта", формируя при установлении соединения окно перегрузки, размер которого изначально равен размеру одного сегмента. Это окно показывает, сколько сегментов TCP-модуль, с его собственной точки зрения, может отправить без получения подтверждения. Скользящее же окно, рассмотренное выше, показывает, какой объем неподтвержденных данных модулю разрешено отправить с точки зрения удаленного модуля, получателя его данных. После прихода подтверждения от получателя окно перегрузки увеличивается на 1 сегмент, и отправитель может выслать уже два сегмента, не дожидаясь подтверждения. Такой подход позволяет постепенно увеличивать нагрузку на сеть. Если окно перегрузки становится больше скользящего окна, объявляемого получателем, ограничение на передачу неподтвержденных данных устанавливает уже скользящее окно получателя.

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

При всех преимуществах протокола ТСР он имеет следующие существенные недостатки:

1. Применяемый в TCP метод AIMD предписывает постоянное линейное увеличение нагрузки на сеть с целью определения момента начала перегрузки. Вследствие этого сеть постоянно находится либо в состоянии перегрузки, либо в состоянии выхода из нее. Это отрицательно сказывается на соединениях в виде увеличенного среднего RTT (Round trip time - время двойного прохода, т.е. промежуток времени от отправки пакета, до получения квитанции, подтверждающей прием), большой дисперсии измеряемых значений RTT, в постоянном наличии потерь, с помощью которых сеть сигнализирует о начале перегрузки.

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

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

Вторую проблему можно разрешить, преобразовав алгоритм следующим образом:

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

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

2. При превышении тайм-аута ожидания квитанции, процессу посылается сообщение «фиксация». После этого процесс сообщает о своем текущем состоянии (какие пакеты были правильно приняты).

3. Вводится объединенное состояние <>, включающее частные состояния процессов, не получивших пакеты.

4. Для каждого процесса из этого объединенного состояния посылается сообщение «восстановление», после которого идут блоки информации, которые не были получены данным процессом. В течение некоторого промежутка времени ожидается подтверждение правильного приема. Если в течении этого времени подтверждение не получено, то шаг 4 повторяется.

5. При достаточно большом увеличении размера объединенного состояния <> считается, что сеть перегружена, и всем процессам, чьи частные состояния входят в объединенное, посылается квитанция «сброс», сигнализирующая об очистке объединенного состояния. Процесс, получивший квитанцию сброс, считает что передача сообщения не была успешна, и начинает прием заново.

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

Центральной задачей моделирования является выбор критерия оценки функционирования системы.

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

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

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

Математическая задача формулируется следующим образом:

ДОЛЯ ПОТЕРЬ: вычисляется, как отношение числа пакетов, переданных заново к общему числу пакетов

КОЭФФИЦИЕНТ ИСПОЛЬЗОВАНИЯ КАНАЛА: вычисляется, как отношение числа удачно переданных сообщений к числу сообщений, которые могли бы быть переданы за рассматриваемый интервал времени T

За единицу времени моделирования принята 0,01 с. Из условий функционирования известно, что нагрузка в канале равна 1,25 сообщений/c. Отсюда средний интервал между поступлениями сообщений - 80 единиц времени. Предполагается, что интервалы между сообщениями имеют экспоненциальное распределение. Начальное значение времени отправки сообщения и времени получения подтверждения о получении равно 20 единицам времени. При времени моделирования 10 000 000 ед. времени, может быть передано максимум 56 829 сообщений.

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

Количество удачно отправленных сообщений для протокола TCP равно 49144, а для протокола MTCP - 53988. Процент заново переданных пакетов в протоколе TCP составил 12,1%, а в протоколе MTCP - 4,5%. Коэффициент использования каналов в моделируемой системе, использующей протокол TCP, равен 0.865, а MTCP - 0.95. По получившимся результатам можно говорить о том, что протокол MTCP эффективнее стандартного протокола TCP. В результате моделирования были получены графики изменения RTT со временем (рисунки 1, 2) и графики зависимости удачно поступивших сообщений от времени (рисунки 3, 4).

Рис. 2 - График изменения RTT со временем для протокола TCP

Рис. 2. График изменения RTT со временем для протокола MTCP

Рис. 3. Зависимость удачно поступивших сообщений от времени для протокола TCP

Рис. 4. Зависимость удачно поступивших сообщений от времени для протокола MTCP

Из графиков видно, что характер изменения параметров у протоколов TCP и MTCP сходный, однако наблюдается, что RTT в протоколе MTCP немного ниже, а количество удачно дошедших сообщений со временем возрастает быстрее.

В модели протокола MTCP учитывалась только неэффективность обработки ошибок протоколом TCP, однако небольшая доработка данного протокола позволит определять доступную пропускную способность сети. Такой механизм будет более эффективен, чем стандартный механизм протокола TCP.

Размещено на Allbest.ru