![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Фрагменты листингов библиотеки 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, пригодная для лёгких и удобных модификаций применительно к различным алгоритмам маршрутизации, включающая библиотеку моделей типовых компонентов моделируемых систем и специализированные библиотеки моделей систем и процессов, ориентированные на конкретные тематики применений. В комплекс входят также сервисные модули, создающие окружение базовой модели, и в сочетании с ней, обеспечивающие функционирование модельного комплекса. Основным критерием работы ТКС являются требования по качеству обслуживания. В качестве входных сигналов имитатор ТКС использует информационные потоки генератора трафика, которые обрабатываются мультиплексорами, аппаратно интегрированными в ПЭВМ, либо входящими в состав установленного в ней СПО.
|