Имитационная модель процессов информационного обмена для распределенной управляющей системы

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

Имитационная модель процессов информационного обмена для распределенной управляющей системы

Костин С.В.

В статье рассматривается построение имитационной модели процессов информационного обмена в распределенной управляющей системе на основе модификации протокола TCP - MTCP.

The building of simulation model of processes information exchange in portioned controlling system on base of modification of protocol TCP - MTCP is considered in article.

Для исследования возможностей протокола и отработки его механизмов была разработана программная имитационная модель протокола передачи данных и сетевых компонентов, в среде которых должен функционировать протокол. Модель представляет собой набор компонентов, имитирующих реальные объекты в составе сети и объекты протоколов МTCP (модифицированного протокола TCP) и CBR (Constant Bit Rate). Изучаемая сеть может иметь топологическую схему достаточно большой сложности, которая строится из необходимого числа экземпляров имеющихся классов. Модификация протокола TCP заключается в использовании дополнительных полей в заголовке сегмента данных, для более эффективного вычисления оптимальной скорости передачи и в общем случае построенная модель легко может быть преобразована и для протокола TCP.

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

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

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

Сегменты протоколов - моделируются следующей структурой данных.

struct Мtcp_segment_s {

int src, dst, port; // адрес отправителя, получателя, порт назначения

long int seq, psn; //порядковый номер сегмента, смещение от предыдущего (поле PS)

double psk; // скорость потока, при получении этого сегмента (поле TI)

long int rcv_wnd; // окно, объявленное получателем

long int ack_trig, ack;// порядковый номер сегмента, вызвавшего подтверждение,

// номер подтверждения

long int syn_ack; // подтверждаемый порядковый номер SYN-сегмента

unsigned chМ flags; // управляющие флаги

int hdr_size, payload_size; // размер заголовка, размер поля данных

int link; // число ссылок на этот сегмент (для корректной работы с памятью)

long int id; // уникальный в модели номер сегмента

};

Новые сегменты создаются внутри объектов протоколов МTCP или CBR. Все объекты топологии передают друг другу указатель на область памяти, содержащую соответствующий сегмент, вместо копирования реальных данных. Кроме того, размеры заголовка сегмента и поля полезной нагрузки задаются в самой структуре данных, и все объекты определяют размер сегмента, интерпретируя значения этих полей. Поскольку ссылка на объект может одновременно содержаться во всех объектах, где реализована буферизация: МTCP, link, interface, то во избежание конфликтов счетчик ссылок хранит количество объектов, в буферах которых находится ссылка на данный сегмент. модификация транспортный протокол сетевой

Освобождение области памяти, содержащей сегмент, разрешено только в случае обнуления счетчика. За исключением полей "TI" и "PS" и служебных полей link, id, все остальные поля сегмента соответствуют полям стандартного TCP заголовка.

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

Для моделирования самого протокола МTCP и среды его исполнения используются организованные в топологическую модель сети экземпляры следующих основных классов: объект протокола МTCP,объект протокола CBR, конечная система (host), симплексный канал (link), маршрутизатор (router), интерфейс (interface).

Рис. 1. Иерархия объектов модели сети в ПМ. Буквами A, G, Р обозначены основные компоненты интерфейсов объектов. Штриховые пинии указывают отношение наследования. Сплошные линии - направления вызовов методов для передачи сегментов

Все классы, описывающие топологические элементы сети: конечная система (host), канал (link), маршрутизатор (router), интерфейс (interface), являются наследниками базового класса element. Интерфейс каждого из этих классов определяется тремя важнейшими компонентами: прием сегмента - accept_packet(), запрос сервиса - get_service(), обработка прерывания - proc_int(). Эти методы являются переопределением виртуальных функций базового класса. Кроме того, каждый производный класс расширен дополнительными специфическими для него методами. Посредством этих элементов интерфейса моделируется передача данных в системе (рис. 1). Каждый из наследников класса element ссылается на элемент, с которым он связан топологически, по указателю на базовый класс.

Экземпляр каждого из приведенных классов использует вызов accept_packet() топологически привязанного к нему объекта для передачи ему сегмента. В зависимости от наличия ресурсов метод вызываемого объекта может принять или не принять сегмент на обслуживание. Метод proc_int() каждого экземпляра вызывается из основной программы для обработки очереди и принятия решения об обслуживании очередного сегмента.

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

Класс, моделирующий канал, получает значения пропускной способности и задержки передачи при инициализации. Структура данных класса реализуется односвязной динамической очередью, в которую помещаются сегменты, принятые на обслуживание. После начала обслуживания сегмента канал блокирует последующие запросы в течение времени t=S/R, где S - размер сегмента, a R - скорость канала, т.е. времени приема сегмента размера S в канал. В очереди канала сегмент задерживается в течение установленного времени задержки передачи. По истечении этого времени объект канала вызывает метод accept_packet() следующего объекта в топологической схеме сети. Если следующий объект отказывает в обслуживании сегмента, то этот сегмент отбрасывается. Для моделирования дуплексной связи применяются 2 экземпляра канала. Параметры каналов могут быть различными для моделирования асимметричных систем.

Метод proc_int() всех экземпляров класса link вызывается из главного цикла. Обработка прерывания переводит внутренний счетчик времени и вызывает передачу готового сегмента из канала следующему объекту топологии.

Для моделирования ошибок среды передачи экземпляр класса link может быть инициализирован перегружаемым инициализатором, который, помимо параметров скорости и задержки канала, получает также параметр, соответствующий резидентному значению ошибки передачи BER. С вероятностью 1 - (1 - BER)S сегмент отбрасывается вместо передачи следующему элементу топологии. Таким образом, можно моделировать спутниковые, радио, сотовые каналы.

В состав класса router входят несколько экземпляров класса interface. При инициализации класса router ему передаются два параметра: количество интерфейсов и объем буферного пространства (максимальная длина очереди), одинаковый для всех интерфейсов. Объект маршрутизатора создает заданное количество экземпляров класса interface. Указатели на каждый интерфейс располагаются в специальном массиве, проиндексированном по порядку создания интерфейсов. После этого на конкретный интерфейс можно ссылаться как router.interface(X), где X - номер нужного интерфейса. Каждый интерфейс при инициализации получает указатель на создавший его объект класса router, по которому он может ссылаться на методы класса router для передачи сегментов в матрицу коммутации (обозначена в схемах как "поле коммутации").

При приеме сегмента интерфейс незамедлительно передает его объекту маршрутизатора. Блокировки при этом произойти не может, т.е. моделируется не блокирующая коммутационная матрица. Объект маршрутизатора вносит запись, состоящую из двух полей: {номер интерфейса, адрес отправителя} в таблицу маршрутизации. После этого сопоставление адреса назначения сегмента со вторым полем таблицы маршрутизации дает номер выходного интерфейса для данного сегмента. При отсутствии совпадения с записями таблицы маршрутизации, сегмент передается для рассылки всем интерфейсам маршрутизатора, кроме того, с которого он был получен. Очередь обслуживается со скоростью канала, к которому подключен интерфейс.

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

Таким образом, объект маршрутизатора моделирует современное межсетевое устройство с не блокирующей коммутационной матрицей и буферизацией на выходе. Возможно также расширение класса маршрутизатора алгоритмами RED и WFQ или CBQ.

Класс host имеет в своем составе экземпляр класса МTCP, моделирующего сам протокол и экземпляр класса CBR, моделирующий протокол передачи данных без подтверждений и управления потоком с постоянной битовой скоростью. В каждый момент времени только один из протоколов может быть в активном состоянии.

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

В случае приема сегмента от объекта канала, метод accept_packet() передает указатель протоколу, определяемому по значению поля port заголовка сегмента. Сегменты, чей адрес назначения не совпадает с адресом данного экземпляра узла, отбрасываются.

Метод proc_int() класса host используется для передачи запроса на обработку прерывания объекту активного протокола.

Протокол постоянной скорости передачи CBR напрямую соответствует реальному режиму передачи данных с постоянной битовой скоростью, например, CBR в ATM или CES (Circuit emulation services) в IP сетях. Корректное взаимодействие с таким режимом передачи данных является актуальной задачей любого адаптивного транспортного протокола в современных сетях с интеграцией сервисов. Именно поэтому протокол CBR включен в модель среды исполнения МTCP. Протокол CBR генерирует сегменты и отправляет их в сеть с предустановленной скоростью RCBR, .т.е. временные промежутки между моментами начала последовательных трансляций составляют фCBR = S / RCBR. Подтверждения и, следовательно, ретрансляция сегментов и контроль скорости не реализуется протоколом CBR.

Модель МTCP реализует управление скоростью отправки сегментов посредством механизма скользящего окна и собственно алгоритма МTCP, коррекцию ошибок передачи, не связанную с управлением передачи, быструю ретрансляцию сегментов и стандартную ретрансляцию по срабатыванию ТПП. Основные методы класса МTCP таковы: Establish() - применяется для начальной синхронизации соединения, getМea() - вычисляет значение области компенсации, accept_packet(), proc_int(), status() - запрашивает результат отправки сегмента узлом. Из них три последние являются открытыми и составляют интерфейс класса. В состав класса МTCP входят два экземпляра класса Queue, которые реализуют приемный и передающий буфер и методы для манипуляции с ними.

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

Рис. 2. Концептуальная схема взаимодействия очередей приема и передачи с алгоритмом управления потоком в объекте протокола МTCP

Сегмент, принятый узлом, передается объекту МTCP. Метод accept_packet() принимает сегмент и обрабатывает его как подтверждение, если сегмент содержит поле подтверждения. Параметры МTCP вычисляются, если установлено поле "TI" сегмента. Если номер подтверждаемого сегмента образует непрерывную последовательность с порядковыми номерами сегментов, находящихся в очереди передачи, то вся последовательность, кроме подтверждаемого сегмента, удаляется из очереди. Например, сегменты в очереди передачи: {k, k+1, k+2, k+3, k+4, ...} и узел получает подтверждение {k+З}, из очереди удаляются сегменты k, k+1, k+2.

Если сегмент содержит данные, то он помещается в приемную очередь, после чего приемная очередь сканируется, из нее убираются (передаются пользователю) сегменты, полученные в непрерывной последовательности порядковых номеров. Затем генерируется подтверждение следующего ожидаемого получателем сегмента, в поля которого заносятся следующие значения: ack - кумулятивное подтверждение, ack-trig - номер последнего полученного сегмента, adv_wnd - свободное пространство в очереди приема. Например, в очереди приема находятся сегменты {i+1, i+2, i+3}, после получения i-ro сегмента и его записи в очередь, из нее удаляются сегменты i, i+1, i+2, i+З и значение кумулятивного подтверждения становится равным i+4. Прототип контрольного сегмента с подтверждением ставится на очередь к передаче.

Метод proc_int() активного протокола вызывается из метода proc_int() содержащего его экземпляра класса узла. Данный метод обновляет значение внутреннего счетчика времени экземпляра объекта протокола, вычисляет текущую скорость передачи потока по формулам в состоянии SS; в состоянии НЕС; в состоянии FT.

Вычислив значение межсегментного интервала, метод proc_int() класса протокола МTCP определяет, прошло ли это время с момента отправки предыдущего сегмента. Если да, то запрашивается экземпляр очереди передачи на предмет наличия в ней готового к отправке сегмента. Сегмент для отправки берется из очереди или создается новый (в случае отсутствия готового сегмента в очереди), после чего в поля ack, ack_trig, adv_wnd заносятся значения из прототипа контрольного сегмента и сегмент передается объекту узла для передачи. Если передача успешна, то узел, вызывая метод status(), уведомляет об этом объект протокола, который отмечает соответствующий сегмент как отправленный и запускает ТПП для него.

Поддержка ускоренной ретрансляции сегментов также включена в ПМ. Для этого объект протокола МTCP отслеживает поступление дублирующих подтверждений. Если последовательно приходят два подтверждения одного и того же 1-го сегмента, то МTCP осуществляет ретрансляцию данного сегмента вне зависимости от значения его ТПП. После осуществления ретрансляции алгоритм переходит в состояние, в котором ускоренная ретрансляция не разрешена, и остается в этом состоянии, пока не придет хотя бы одно подтверждение следующего: (i+l)-ro сегмента.

Для осуществления вычисления начального значения RTT, при открытии нового соединения объект протокола МTCP реализует обмен сегментом специального типа с противоположной стороной. При активации объект МTCP попадает в "не синхронизированное" состояние. Сегмент, обозначенный как SYN (по наличию соответствующего флага), отправляется от инициирующей стороны обмена к получателю. Сегмент SYN несет порядковый номер, не влияющий на порядковые номера при обмене данными. Получатель сегмента SYN реагирует отправкой сегмента с установленными флагами SYN, ACK, где поле ack несет значение порядкового номера SYN сегмента. Получение SYN, ACK сегмента дает возможность отправителю измерить время RTT и переводит соединение в состояние "синхронизации", после чего начинается обмен данными. Наличие идентифицирующего SYN сегмент порядкового номера дает возможность различить их возможные копии и правильно измерить время RTT.

Главный цикл программы вызывает метод обработки прерывания proc_int() всех элементов топологии модели (host, link, router). В результате эмулируется ход внутренних часов каждого из объектов, и моделируются процессы передачи данных. Также из главного цикла с конфигурируемой периодичностью вызываются процедуры, генерирующие отчеты.

Протокол МTCP, как и TCP, способен осуществлять симметричный обмен информацией по одному соединению. В таком режиме контрольная информация получателя транслируется не отдельными сегментами, а записывается в соответствующие поля сегментов с данными, следующими в противоположном направлении. Программная модель предусматривает наличие буфера под прототип заголовка контрольного сегмента. Этот заголовок, содержащий номер подтверждения, размер окна и другую управляющую информацию, формируется после получения очередного сегмента с данными. Однако вместо немедленной отправки пустого сегмента с подтверждением, созданным из прототипа, модель проверяет наличие сегмента с данными ожидающего передачи, и если такой сегмент имеется, то подтверждение передается вместе с ним. Иначе из прототипа контрольного сегмента создается отдельный сегмент, не несущий данных, а лишь передающий подтверждение.

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

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

Для визуализации полученных при моделировании данных применялась программа gnuplot версии 3.7 для OS UNIX. Результаты моделирования наиболее наглядно представляются следующими способами: зависимость скорости потока, порядкового номера передаваемого сегмента, времени RTT, средней длины очереди от времени.

Кроме того, по построенной таким образом модели возможно рассмотреть следующие сценарии:

Сценарий 1. Сравнение функционирования реализации протокола МTCP в модели с ожидаемым поведением его алгоритма и наглядная иллюстрация работы соединения протокола МTCP.

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

Сценарий 3. Сравнение протоколов МTCP и TCP при различных значениях битовых ошибок передачи на канале.

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