Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Фрагменты листингов библиотеки TCNSym






Исходный код элемента модели узла ТКС, отвечающего за моделирование протокола Reverse Path Multicasting, представлен на листинге 9.1.

 

 

Листинг 9.1

 

typedef size_t address_t;

 

namespace TCNsym

{

template < class Config, class Node, class GroupPacket>

struct ReversePathMulticasting

{

struct Retransmit

{

template < class LinkTableEntry>

void operator() (LinkTableEntry & le)

{

if (le.link()-> sink()! = original_-> previous())

{

if (! le.is_prune(original_-> sender(), original_-> groupId()))

{

le.link()-> send(new GroupPacket(world_,

original_-> size(), original_-> groupId(),

original_-> sender(), id_,

original_-> log(), original_-> name()));

}

}

}

 

Retransmit (Config & w, GroupPacket * original, address_t id)

: world_(w), id_(id), original_(original) {}

 

private:

Config & world_;

GroupPacket * original_;

address_t id_;

};

 

bool sendPacketIfItCameFromParent(GroupPacket * pct)

{

// Только если пакет пришел по оптимальному к отправителю пути,

//перепосылаем его дальше

if (

self().getLinkByNode(pct-> previous())

==

self().getLinkPacketSendBy(pct-> sender())

)

{

self().links().for_each(Retransmit(self().world(), pct, self().id()));

return true;

}

 

return false;

}

 

struct PrunePacket: Config:: Packet

{

PrunePacket(Config & w, group_id_t group_id, address_t source,

address_t pruned)

: Config:: Packet(w, size(), -1)

, group_id_ (group_id)

, source_ (source)

, pruned_ (pruned)

{}

 

void onNode(Node * node)

{

node-> process(this);

}

 

group_id_t groupId() const { return group_id_; }

address_t source() const { return source_; }

address_t pruned() const { return pruned_; }

 

private:

// пакеты, адресованные группе group_id

group_id_t group_id_;

 

// отправленные с адреса source_

address_t source_;

 

// не надо направлять в узел pruned_

address_t pruned_;

};

 

typedef typename Config:: Link Link;

 

// По идее у линков должен быть в дополнение к foreach метод find

struct SetPruned

{

SetPruned (address_t makeprune, group_id_t group,

address_t src, bool * pruned, Link * parentLink)

: group_ (group)

, source_ (src)

, makeprune_ (makeprune)

, pruned_ (pruned)

, parent_ (parentLink)

{

*pruned_ = true;

}

 

template < class LinkTableEntry>

void operator () (LinkTableEntry & le)

{

if (le.link()-> sink() == makeprune_)

le.prune(source_, group_);

 

if (le.link()! = parent_)

if (! le.is_prune(source_, group_))

*pruned_ = false;

}

 

 

private:

group_id_t const group_;

address_t const source_;

address_t const makeprune_;

Link * const parent_;

bool * pruned_;

};

 

void process(PrunePacket * pct)

{

typename Config:: Link * parent =

self().getLinkPacketSendBy(pct-> source());

 

if (parent)

{

bool pruned;

 

// пробегаем по всем порожденным интерфейсам и определяем, не отсечены ли они

self().links().for_each(

SetPruned(

pct-> pruned(), pct-> groupId(), pct-> source(), & pruned, parent));

 

if (self().belongsTo(pct-> groupId()))

pruned = false;

 

// И если отсечены, то посылаем отсекающее сообщение родителю

if (pruned)

{

PrunePacket * prunepacket =

new PrunePacket(

self().world(), pct-> groupId(), pct-> source(), self().id());

 

parent-> send(prunepacket);

}

}

 

delete pct;

}

 

void process(GroupPacket * pct)

{

 

if (! sendPacketIfItCameFromParent(pct))

{

// пакет пришел по " порожденному интерфейсу"

// посылаем в ответ отсекающее сообщение

// nb! делаем только в случае, если мы не принадлежим группе

// это влечет за собой, то что будет построено не дерево

// Почему так все плохо? Потому что таблицы маршрутизации могут быть //не согласованы

if (! self().belongsTo(pct-> groupId()))

self().getLinkByNode(pct-> previous())

-> send(new PrunePacket(self().world(),

pct-> groupId(), pct-> sender(), self().id()));

}

 

delete pct;

}

 

private:

Node const & self() const { return static_cast< Node const & > (*this); }

Node & self() { return static_cast< Node & > (*this); }

};

}

 

Исходный код элемента модели канала связи ТКС, отвечающего за моделирование пропускной способности сети, представлен на листинге 9.2.

Листинг 9.2.

 

#pragma once

 

namespace TCNsym

{

// Queue:

// void push(Entity)

// void pop()

// Entity front() const;

//

// ProcessingTime

// double operator () (Entity)

//

// Next

// operator () (Entity)

template

<

class World,

class Entity, // скорей всего, указатель на сущность

class Queue, // ссылка или если очередь внутренняя, std:: queue

class ProcessingTime, // функционал, по сущности возвращающий, сколько //времени займет ее обработка

class Next // обработчик освобожденных сущностей

>

struct Resource

{

template < class Q, class PT, class N>

Resource (World & w, Q const & q, PT const & pt, N const & n)

: queue_ (q)

, world_ (w)

, processingTime_ (pt)

, next_ (n)

, busy_ (false)

, bytes_ (0)

{}

 

void operator () (Entity e)

{

queue_.push(e);

tryToProcessFrontEntity();

 

bytes_ += e-> size();

}

 

size_t bytesToSend() const { return bytes_; }

double timeToFree () const { return processingTime_(bytes_); }

 

private:

 

void tryToProcessFrontEntity()

{

if (! busy_)

{

if (! queue_.empty())

{

world_.schedule(processingTime_(queue_.front()),

boost:: bind(& Resource:: releaseFrontEntity, this));

 

busy_ = true;

}

}

}

 

void releaseFrontEntity()

{

bytes_ -= queue_.front()-> size();

next_(queue_.front());

queue_.pop(); busy_ = false;

tryToProcessFrontEntity();

}

 

private:

Queue queue_;

ProcessingTime processingTime_;

Next next_;

bool busy_;

World & world_;

 

size_t bytes_;

};

}

 

Отрывок из определения класса модели узла ТКС, поддерживающего маршрутизацию с учетом состояния линий дан на листинге 9.3. Он иллюстрирует, как этот класс «собирается» при помощи множественного наследования из элементов модели.

Листинг 9.3.

namespace TCNsym {

namespace linkstate {

template < class Config>

struct Node: HasId, HasName

, LinkTable < Config, Node>

, PacketDispatcher < Node, typename Config:: Packet>

, rip_2:: EchoNeighbours < Config, Node>

, LinkStateCasting < Config, Node>

, LinkStateCollector < Config, Node>

, LinkStatePacketFactory < Config, Node,

, PacketForwarder < Node, typename Config:: Packet>

, MemberOfGroups

, ReversePathBroadcasting < Config, Node, typename Config:: GroupPacket< Config> >

9.12. Структура стенда имитационного моделирования ТКС

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

Предоставление пакетов современных телекоммуникационных услуг с качеством, необходимым клиентам, требует отработки алгоритмов выбора оптимальных маршрутов и пропускной способности в ТКС с пакетной коммутацией, алгоритмов динамической маршрутизации в ATM сетях и т.п.

Для эффективной отладки и продуктивного тестирования методов и конкретных инструментов имитационного моделирования ТКС был спроектирован и реализован специализированный моделирующий стенд, структура которого приведена на Рис. 9.25 [52, 65, 66].

Этот стенд позволяет отрабатывать протоколы динамического и адаптивного управления с учётом гетерогенного информационного трафика и требований по качеству обслуживания (Quality of Service – QoS) для ТКС нового поколения глобального характера.

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

Для анализа передачи информации по различным структурам ТКС могут быть синтезированы различные виды тестовых информационных потоков, в том числе:

- низкоскоростной поток, содержащий текстовую и графическую информацию;

- высокоскоростной поток, который содержит аудио/видеоинформацию в формате сжатия MPEG-2;

- смешанный тестовый поток, с чередованием низкоскоростной графики, аудио / видеоинформации с форматом сжатия MPEG-2, аудио / видеоинформацию с форматом сжатия MPEG-4.

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

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

Имитационный программный комплекс, реализованный на этом стенде и предназначенный для моделирования глобальных ТКС, базируется на языках SIMQUENT и PROTOSINT [52, 65, 66]. В свою очередь реализации этих языков, заложенные в стенде, базируются на имитационной системе ARENA. Такое двухслойное построение облегчило реализацию всего комплекса.

Структурно стенд ТКС является фрагментом ЛВС и включает 4 ПЭВМ, различаемыe по составу оборудования, специальному программному обеспечению (СПО) и функциональному назначению. В него входят:

1) генератор трафика;

2) имитатор работы ТКС;

3) станция сбора и обработки статистики;

4) система управления топологией сети

5) некоторые другие вспомогательные средства, не показанные на Рис. 9.25.

9.13. Описание основных подсистем стенда

9.13.1. Генератор трафика

Эта подсистема является синтезатором необходимых информационных потоков в форматах выбранных способов доставки контента, используемых в анализируемой ТКС. Реализована на базе ПЭВМ Intel Pentium 4, CPU 2, 80 GHz, 512 МБ ОЗУ.

Установлено СПО синтезатора информационных транспортных потоков. Наполнение потоков данных конкретной аудио/видео информацией, при необходимости, производится со встроенного CD-ROM. Запись информации может производиться с внешних источников на встроенный RW-DVD диск.

В перспективе для интеграции стенда имитационного моделирования в реально используемые ТКС для проверки и отладки полученных результатов аппаратно через PCI шину возможно будет поддерживать внешние интерфейсы:

- DVB-C цифровой телерадиовещательной кабельной сети;

- DVB-C цифровой интерактивной кабельной сети с обратным каналом;

- DVB-S спутниковых цифровых телерадиовещательных и информационных каналов;

- асинхронный последовательный интерфейс ASI;

- 100Base-T, определяемый стандартом для стыка с сетью Internet;

- ITU-T G.703 и оптический интерфейс с длинами волн 1, 33 и 1, 55 мкм для сопряжения с сетями плезиохронной цифровой иерархии интегрального обслуживания.

Предусмотрена принципиальная возможность поддержки внешнего интерфейса для сопряжения стенда с сетью АТМ.

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

9.13.2. Имитатор работы ТКС

Эта подсистема представляет собой аппаратно-программный комплекс, реализованный на базе ПЭВМ Intel Pentium 4, CPU 2, 80 GHz, 512 МБ ОЗУ, CD-ROM, RW-DVD. Моделирует функционирование набора алгоритмов, описывающих выбранную архитектуру ТКС. Установленное СПО позволяет вести поиск необходимых алгоритмов оптимизации архитектуры ТКС в целом для удовлетворения запросов потребителей телекоммуникационных услуг с учетом прогнозируемых внешних воздействий.

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

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

 






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.