Урок за симулатор на мрежа ns-3. Глава 4

глава 1,2
Глава 3

4 Преглед на концепцията
4.1 Ключови абстракции
4.1.1 Възел
4.1.2 Приложение
4.1.3 Канал
4.1.4 Мрежово устройство
4.1.5 Топологични помощници
4.2 Първи ns-3 скрипт
4.2.1 Шаблонен код
4.2.2 Добавки
4.2.3 ns3 пространство от имена
4.2.4 Регистриране
4.2.5 Основна функция
4.2.6 Използване на асистенти за топология
4.2.7 Използване на приложението
4.2.8 Симулатор
4.2.9 Изграждане на вашия скрипт
4.3 ns-3 Изходен код

Глава 4

Преглед на концепцията

Първото нещо, което трябва да направим, преди да започнем да учим или пишем ns-3 код, е да обясним няколко основни концепции и абстракции в системата. Голяма част от това може да изглежда очевидно за някои, но ние препоръчваме да отделите време да прочетете този раздел, за да сте сигурни, че започвате върху солидна основа.

4.1 Ключови абстракции

В този раздел ще разгледаме някои термини, които често се използват в мрежата, но имат конкретно значение в ns-3.

4.1.1 Възел

На интернет жаргон компютърно устройство, което се свързва към мрежа, се нарича хост или понякога крайна система. Тъй като ns-3 е мрежов симулатор, а не интернет симулатор, ние съзнателно не използваме термина хост, тъй като това е тясно свързано с интернет и неговите протоколи. Вместо това използваме по-общ термин, използван и от други симулатори, който произхожда от теорията на графите: възел (възел).

В ns-3 основната абстракция на изчислително устройство се нарича възел. Тази абстракция е представена в C++ от класа Node. Клас NodeNode (възел) предоставя методи за манипулиране на представяния на изчислителни устройства в симулации.

Трябва да разбереш Възел като компютър, към който добавяте функционалност. Ще добавите неща като приложения, стекове протоколи и периферни карти с драйвери, които позволяват на компютъра да върши полезна работа. Използваме същия основен модел в ns-3.

4.1.2 Приложение

Като цяло компютърният софтуер се разделя на два големи класа. Системният софтуер организира различни компютърни ресурси като памет, процесорни цикли, диск, мрежа и т.н. според някакъв изчислителен модел. Системният софтуер обикновено не използва тези ресурси за изпълнение на задачи, които са от пряка полза за потребителя. Потребителят обикновено изпълнява приложение за постигане на конкретна цел, което получава и използва ресурси, контролирани от системния софтуер.

Често линията на разделяне между системния и приложния софтуер се очертава при промени в нивото на привилегия, които се случват в прихващанията на операционната система. ns-3 няма истинска концепция за операционна система и следователно няма концепция за нива на привилегии или системни повиквания. Ние обаче имаме идея за приложение. Точно както в „реалния свят“ софтуерните приложения работят на компютри, за да изпълняват задачи, ns-3 приложенията работят на ns-3 възли, за да контролират симулации в симулирания свят.

В ns-3 основната абстракция за потребителска програма, която генерира някаква дейност за моделиране, е приложение. Тази абстракция е представена в C++ от класа Application. Класът Application предоставя методи за манипулиране на изгледи на нашата версия на приложения на потребителско ниво в симулации. Очаква се разработчиците да специализират класа Application в смисъл на обектно-ориентирано програмиране, за да създават нови приложения. В този урок ще използваме специализации на класа Application, наречен UdpEchoClientApplication и UdpEchoServerApplication. Както може да очаквате, тези приложения съставляват набор от приложения клиент/сървър, използвани за генериране и ехо на мрежови пакети.

4.1.3 Канал

В реалния свят можете да свържете компютър към мрежа. Често медиите, по които се предават данни в тези мрежи, се наричат ​​канали. Когато включите Ethernet кабел в стенен контакт, вие свързвате компютъра си към Ethernet връзка. В симулирания свят ns-3 възел е свързан с обект, представляващ комуникационен канал. Тук основната абстракция на комуникационната подмрежа се нарича канал и е представена в C++ от класа Channel.

Клас КаналКанал предоставя методи за управление на взаимодействието на подмрежови обекти и свързване на хостове към тях. Каналите също могат да бъдат специализирани от разработчиците в смисъл на обектно-ориентирано програмиране. Специализацията на канала може да моделира нещо толкова просто като проводник. Специален канал може също да моделира сложни неща като голям Ethernet комутатор или триизмерно пространство, пълно с препятствия в случай на безжични мрежи.

Ще използваме специализирани версии на канала в този урок, наречен CsmaChannelCsmaChannel, PointToPointChannelPointToPointChannel и WifiChannelWifiChannel. CsmaChannel, например, моделира версия на комуникационна подмрежа, която имплементира комуникационна среда с множествен достъп със сензор за оператор. Това ни дава функционалност, подобна на Ethernet.

4.1.4 Мрежово устройство

Преди беше така, че ако искате да свържете компютър към мрежа, трябваше да закупите конкретен мрежов кабел и хардуерно устройство, наречено (в компютърната терминология) периферна карта, която трябваше да бъде инсталирана в компютъра. Ако периферна карта изпълнява някои мрежови функции, те се наричат ​​мрежови интерфейсни карти или мрежови карти. Днес повечето компютри идват с интегриран хардуер за мрежов интерфейс и не се разглеждат от потребителите като отделни устройства.

Мрежовата карта няма да работи без софтуерен драйвер, който управлява нейния хардуер. В Unix (или Linux) част от периферното оборудване се класифицира като устройство. Устройствата се управляват с помощта на драйвери на устройства, а мрежовите устройства (NIC) се управляват с помощта на драйвери на мрежови устройства (драйвери на мрежови устройства) и се наричат ​​заедно мрежови устройства (нетни устройства). В Unix и Linux наричате мрежовите устройства с имена като eth0.

В ns-3 абстракцията на мрежовото устройство обхваща както софтуерния драйвер, така и моделирания хардуер. В симулацията мрежово устройство е "инсталирано" във възел, за да му позволи да комуникира с други възли чрез канали. Точно като истински компютър, един възел може да бъде свързан към множество канали чрез множество устройства NetDevices.

Мрежовата абстракция на дадено устройство е представена в C++ от класа NetDevice. Клас NetDevice предоставя методи за управление на връзки към обекти Node и Channel; и може да се специализира от разработчиците в смисъла на обектно-ориентираното програмиране. В този урок ще използваме няколко специализирани версии на NetDevice, наречени CsmaNetDevice, PointToPointNetDevice и WifiNetDevice. Точно както Ethernet мрежовият адаптер е проектиран да работи с мрежа Ethernet, CsmaNetDevice предназначени за работа с CsmaChannel, PointToPointNetDevice предназначени за работа с PointToPointChannelИ WifiNetDevice - предназначени за работа с WifiChannel.

4.1.5 Топологични помощници

В реална мрежа ще намерите хост компютри с добавени (или вградени) мрежови карти. В ns-3 бихме казали, че ще видите възли с прикачени NetDevices. В голяма симулирана мрежа ще трябва да организирате връзки между много обекти Възел, NetDevice и Канал.

От свързването на NetDevices към възли, NetDevices към връзки, присвояване на IP адреси и т.н. в ns-3 са често срещана задача, за да направим това възможно най-лесно, ние предоставяме така наречените топологични помощници. Например, за да създадете NetDevice, трябва да извършите много ns-3 операции на ядрото, да добавите MAC адрес, да инсталирате мрежовото устройство в Node, да конфигурирате протоколния стек на възела и след това да свържете NetDevice към канала. Още повече работа ще е необходима за свързване на множество устройства към многоточкови връзки и след това свързване на отделните мрежи в мрежа на Internetworks. Ние предоставяме топологични помощни обекти, които комбинират тези много операции в лесен за използване модел за ваше удобство.

4.2 Първи ns-3 скрипт

Ако сте инсталирали системата, както е предложено по-горе, ще имате изданието ns-3 в директория, наречена repos във вашата начална директория. Отидете в директорията освободи

Ако нямате такава директория, това означава, че не сте указали изходната директория при изграждането на версията за освобождаване на ns-3, компилирайте така:
$ ./waf configure —build-profile=release —out=build/release,
$ ./waf компилация

там трябва да видите структура на директория, подобна на следната:

AUTHORS       examples      scratch       utils       waf.bat*
bindings      LICENSE       src           utils.py    waf-tools
build         ns3           test.py*      utils.pyc   wscript
CHANGES.html  README        testpy-output VERSION     wutils.py
doc           RELEASE_NOTES testpy.supp   waf*        wutils.pyc

Отидете в директорията примери/урок. Трябва да видите файл, който се намира там, наречен първо.cc. Това е скрипт, който ще създаде проста връзка от точка до точка между два възела и ще предаде един пакет между възлите. Нека да разгледаме този скрипт ред по ред; за да направите това, отворете first.cc в любимия си редактор.

4.2.1 Шаблонен код
Първият ред във файла е редът за режим на редактор Emacs. Той казва на emacs за конвенциите за форматиране (стил на кодиране), които използваме в нашия изходен код.

/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */

Това винаги е доста противоречив въпрос, така че трябва да изясним нещата, за да го премахнем веднага. Проектът ns-3, подобно на повечето големи проекти, е приел стил на кодиране, на който трябва да отговаря целият допринесъл код. Ако искате да допринесете с кода си за проекта, в крайна сметка ще трябва да се съобразите със стандарта за кодиране ns-3, както е описано във файла doc/codingstd.txt или показано на уеб страницата на проекта: https://www.nsnam.org/develop/contributing-code/coding-style/.

Препоръчваме ви да свикнете с външния вид на кода ns-3 и да прилагате този стандарт винаги, когато работите с нашия код. Целият екип за разработка и сътрудниците се съгласиха с това след известно мърморене. Редът за режим на emacs по-горе улеснява правилното форматиране, ако използвате редактора на emacs.

Симулаторът ns-3 е лицензиран с помощта на GNU General Public License. Ще видите подходящата легална заглавка на GNU във всеки файл за разпространение на ns-3. Често ще видите бележка за авторски права за една от участващите институции в проекта ns-3 над GPL текста и автора, показани по-долу.

/* 
* This program is free software; you can redistribute it and/or modify 
* it under the terms of the GNU General Public License version 2 as 
* published by the Free Software Foundation; 
*
* This program is distributed in the hope that it will be useful, 
* but WITHOUT ANY WARRANTY; without even the implied warranty of 
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 
* GNU General Public License for more details. 
* 
* You should have received a copy of the GNU General Public License 
* along with this program; if not, write to the Free Software 
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 
*/

4.2.2 Добавки

Самият код започва с поредица от инструкции за включване (include).

#include "ns3/core-module.h"
#include "ns3/network-module.h"
#include "ns3/internet-module.h"
#include "ns3/point-to-point-module.h"
#include "ns3/applications-module.h"

За да помогнем на нашите потребители на скриптове на високо ниво да се справят с големия брой заглавни файлове, налични в системата, ние ги групираме според употребата им в големи модули. Предоставяме един заглавен файл, който рекурсивно ще зареди всички заглавни файлове, използвани в даден модул. Вместо да се налага да търсите каква точно заглавка ви трябва и евентуално да получите правилния списък със зависимости, ние ви даваме възможността да изтеглите група от файлове с голяма детайлност. Това не е най-ефективният подход, но със сигурност прави писането на скриптове много по-лесно.

Всеки от ns-3 включващите файлове се поставя в директория, наречена ns3 (поддиректория за изграждане), за да избегнете конфликти на имената на файлове по време на процеса на изграждане. Файл ns3/core-module.h отговаря на модула ns-3, който ще намерите в указателя src/ядро във версията, която сте инсталирали. В списъка на тази директория ще намерите голям брой заглавни файлове. Когато направите сглобяването, Waf поставя публични заглавни файлове в директорията ns3 в поддиректория изграждане/отстраняване на грешки

Ако нямате такава директория, това означава, че не сте указали изходната директория при изграждането на версията за освобождаване на ns-3, компилирайте така:
$ ./waf configure --build-profile=debug --out=build/debug
$ ./waf компилация
или
$ ./waf configure --build-profile=optimized --out=build/optimized
$ ./waf компилация

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

$ ./waf -d debug --enable-examples --enable-tests configure

за да конфигурирате проекта да изпълнява компилации за отстраняване на грешки, които включват примери и тестове. Вие също го направихте

$ ./waf

за сглобяване на проекта. Така че сега, когато погледнете в директорията ../../build/debug/ns3, тогава там ще намерите, наред с други, заглавните файлове на четирите модула, показани по-горе. Можете да разгледате съдържанието на тези файлове и да откриете, че те включват всички публични файлове, използвани от съответните модули.

4.2.3 ns3 пространство от имена

Следващ ред в скрипта първо.cc е декларация на пространство от имена.

using namespace ns3;

Проектът ns-3 е реализиран в пространство от имена на C++, наречено ns3. Това групира всички свързани с ns-3 декларации в обхват извън глобалното пространство на имената, което се надяваме да помогне при интегрирането с друг код. Използването на оператора C++ въвежда пространството от имена ns-3 в текущия (глобален) декларативен регион. Това е изискан начин да се каже, че след тази декларация няма да е необходимо да въвеждате оператора за разрешение ns3::scope преди целия си ns-3 код, за да го използвате. Ако не сте запознати с пространствата от имена, вижте почти всеки учебник по C++ и сравнете пространството от имена ns3, като използвате пространството от имена и декларацията std using namespace std; в примери за работа с изходния оператор Cout и потоци.

4.2.4 Регистриране

Следващият ред на скрипта е:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Ще използваме това изявление като удобно място за обсъждане на нашата система за документация Кислород. Ако погледнете уебсайта на проекта ns-3, ще намерите връзка Документация в лентата за навигация. Ако щракнете върху тази връзка, ще бъдете отведени до нашата страница с документация. Има връзка „Най-нова версия“, която ще ви отведе до документацията за най-новата стабилна версия на ns-3. Ако изберете връзката „Документация на API“, ще бъдете отведени до страницата с документация на API ns-3.

В лявата част на страницата ще намерите графично представяне на структурата на документацията. Добро място за начало е "книгата" на модулите ns-3 в навигационното дърво на ns-3. Ако разкриете Модули, ще видите списък с документация за ns-3 модули. Както беше обсъдено по-горе, концепцията за модул тук е пряко свързана с файловете, включени в модула по-горе. Подсистемата за регистриране ns-3 се обсъжда в раздел Използване на модула за регистриране, така че ще се върнем към него по-късно в този урок, но можете да научите за горното твърдение, като разгледате модула Ядрои след това отваряне на книгата Инструменти за отстраняване на грешкии след това изберете страницата Влизане. Кликнете върху Влизане.

Сега трябва да прегледате документацията Кислород за модул Влизане. В списъка с макроси в горната част на страницата ще видите запис за NS_LOG_COMPONENT_DEFINE. Преди да щракнете върху връзката, не забравяйте да погледнете „Подробното описание“ на регистрационния модул, за да разберете как работи като цяло. За да направите това, можете да превъртите надолу или да изберете „Още...“ под диаграмата.

След като имате обща представа какво се случва, продължете напред и погледнете документацията за конкретния NS_LOG_COMPONENT_DEFINE. Няма да дублирам документацията тук, но за да обобщя, този ред декларира компонент за регистрация, наречен FirstScriptExample, което ви позволява да активирате или деактивирате конзолното регистриране на съобщения чрез препратка към име.

4.2.5 Основна функция

В следващите редове на скрипта ще видите,

int 
main (int argc, char *argv[])
{ 

Това е просто декларация на основната функция на вашата програма (скрипт). Както при всяка програма на C++, трябва да дефинирате основна функция, тя се изпълнява първо. Тук няма нищо особено. Вашият ns-3 скрипт е просто C++ програма. Следният ред задава разделителната способност на времето на 1 наносекунда, което е по подразбиране:

Time::SetResolution (Time::NS);

Времевата разделителна способност или просто разделителната способност е най-малката времева стойност, която може да се използва (най-малката представима разлика между две времена). Можете да промените разделителната способност точно веднъж. Механизмът, който осигурява тази гъвкавост, консумира памет, така че след като разделителната способност е изрично зададена, ние освобождаваме паметта, предотвратявайки по-нататъшни актуализации. (Ако не зададете изрично разделителната способност, тя по подразбиране ще бъде една наносекунда и паметта ще бъде освободена, когато симулацията започне.)

Следните два реда от скрипт се използват за активиране на два компонента за регистриране, които са вградени в приложения EchoClient и EchoServer:

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO); LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO);

Ако прочетете документацията за компонента Logging, ще видите, че има няколко нива на регистриране/подробност, които можете да активирате за всеки компонент. Тези два реда код позволяват регистриране на грешки до ниво INFO за ехо клиенти и сървъри. На това ниво приложението ще отпечатва съобщения, докато изпраща и получава пакети по време на симулация.

Сега ще се заемем със създаването на топологията и изпълнението на симулацията. Използваме помощни обекти за топология, за да направим тази работа възможно най-лесна.

4.2.6 Използване на асистенти за топология

Следващите два реда код в нашия скрипт всъщност ще създадат обектите Node ns-3, които ще представляват компютрите в симулацията.

NodeContainer nodes;
nodes.Create (2);

Преди да продължим, нека намерим документацията за класа NodeContainer. Друг начин да стигнете до документацията за даден клас е чрез раздела Класове на страници Кислород. Ако вече сте отворили Doxygen, просто превъртете нагоре до горната част на страницата и изберете раздела Класове. Трябва да видите нов набор от раздели, един от които е списък с класове. Под този раздел ще видите списък с всички класове ns-3. Превъртете надолу до ns3::NodeContainer. Когато намерите клас, изберете го, за да отидете до документацията за класа.

Както си спомняме, една от нашите ключови абстракции е възелът. Той представлява компютъра, към който ще добавим неща като протоколни стекове, приложения и периферни карти. Асистент по топология NodeContainer предоставя удобен начин за създаване, управление и достъп до всякакви обекти Възел, който създаваме, за да стартираме симулацията. Първият ред по-горе просто декларира NodeContainer, които наричаме възли. Вторият ред извиква метода Create на обекта nodes и моли контейнера да създаде два възела. Както е описано в Кислород, контейнерът изисква системата ns-3 да създаде два обекта Възел и съхранява указатели към тези обекти вътрешно.

Възлите, създадени в скрипта, все още не правят нищо. Следващата стъпка в изграждането на топологията е свързването на нашите възли към мрежата. Най-простата форма на мрежа, която поддържаме, е връзка от точка до точка между два възела. Сега ще създадем такава връзка.

PointToPointHelper

Създаваме връзка от точка до точка, като използваме познат модел, използвайки помощен обект на топология, за да извършим работата на ниско ниво, необходима за връзката. Спомнете си, че нашите две ключови абстракции NetDevice и Канал. В реалния свят тези термини приблизително съответстват на периферни карти и мрежови кабели. Обикновено тези две неща са тясно свързани едно с друго и никой не може да разчита на споделяне на устройства, например Ethernet по безжичен канал. Нашите помощници в топологията следват тази тясна връзка и затова вие ще използвате един обект в този сценарий PointToPointHelper за настройка и свързване на обекти ns-3 PointToPointNetDevice и PointToPointChannel. Следващите три реда в скрипта:

PointToPointHelper pointToPoint;
pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps")); 
pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));

Първа линия,

PointToPointHelper pointToPoint;

създава екземпляр на обект в стека PointToPointHelper. От гледна точка на най-високо ниво следният ред,

pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));

казва на обекта PointToPointHelper използвайте стойността "5 Mbit/s" (пет мегабита в секунда) като "Скорост на данните".

От по-конкретна гледна точка, низът "DataRate" съответства на това, което наричаме атрибут PointToPointNetDevice. Ако погледнете Кислород за клас ns3::PointToPointNetDevice и в документацията към метода GetTypeId ще намерите списък с атрибути, дефинирани за устройството. Сред тях ще бъде атрибутът „Скорост на данните" Повечето видими от потребителя ns-3 обекти имат подобни списъци с атрибути. Използваме този механизъм за лесно настройване на симулацията без повторно компилиране, както ще видите в следващия раздел.

Подобен на "Скорост на данните" в PointToPointNetDevice ще намерите атрибута "Delay", свързан с PointToPointChannel. Последната линия

pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));

Той говори PointToPointHelper използвайте стойността "2 ms" (две милисекунди) като стойност на забавяне на разпространението за връзката от точка до точка, която впоследствие създава.

NetDeviceContainer

В момента имаме в сценария NodeContainer, който съдържа два възела. Ние имаме PointToPointHelper, който е подготвен за създаване на обекти PointToPointNetDevices и свързването им с помощта на обект PointToPointChannel. Точно както използвахме помощния обект на топологията NodeContainer за създаване на възли, ще попитаме PointToPointHelper извършват работа за нас, свързана със създаването, конфигурирането и инсталирането на нашите устройства. Имаме нужда от списък на всички създадени обекти NetDevice, затова използваме NetDeviceContainer да ги съхраняваме по същия начин, както използвахме NodeContainer за съхраняване на възлите, които създадохме. Следващите два реда код,

NetDeviceContainer devices;
devices = pointToPoint.Install (nodes);

пълна настройка на устройството и канала. Първият ред декларира контейнера на устройството, споменат по-горе, а вторият върши основната работа. Метод инсталирам обект PointToPointHelper приема NodeContainer като параметър. Вътре NetDeviceContainer за всеки възел, разположен в NodeContainer се създава (за комуникация от точка до точка трябва да има точно две) PointToPointNetDevice се създава и записва в контейнера на устройството. PointToPointChannel е създаден и към него са прикрепени две PointToPointNetDevices. След създаване на обекти, атрибутите, съхранени в PointToPointHelper, се използват за инициализиране на съответните атрибути в създадените обекти.

След обаждане pointToPoint.Install (възли) ще имаме два възела, всеки с инсталирано мрежово устройство от точка до точка и една връзка от точка до точка между тях. И двете устройства ще бъдат конфигурирани да предават данни със скорост от пет мегабита в секунда със забавяне на предаването от две милисекунди по канала.

InternetStackHelper

Вече имаме конфигурирани възли и устройства, но нашите възли нямат инсталирани протоколни стекове. Следващите два реда код ще се погрижат за това.

InternetStackHelper stack;
stack.Install (nodes);

InternetStackHelper - е помощник за топология за интернет стекове, подобен на PointToPointHelper за мрежови устройства от точка до точка. Метод инсталирам приема NodeContainer като параметър. Когато се изпълни, той ще инсталира интернет стека (TCP, UDP, IP и т.н.) на всеки контейнерен възел.

IPv4AddressHelper

След това трябва да свържем нашите устройства с IP адреси. Ние предоставяме асистент за топология за управление на разпределението на IP адреси. Единственият API, видим за потребителя, е настройката на основния IP адрес и мрежовата маска, които да се използват при извършване на действителното разпределение на адресите (това се прави на по-ниско ниво в рамките на помощника). Следващите два реда код в нашия примерен скрипт първо.cc,

Ipv4AddressHelper address;
address.SetBase ("10.1.1.0", "255.255.255.0");

декларирайте помощния обект на адреса и му кажете, че трябва да започне да разпределя IP адреси от мрежа 10.1.1.0, като използва битовата маска 255.255.255.0 за определяне. По подразбиране разпределените адреси ще започват от един и ще нарастват монотонно, така че първият разпределен адрес от тази база ще бъде 10.1.1.1, след това 10.1.1.2 и т.н. В действителност, на ниско ниво, системата ns-3 запомня всички разпределени IP адреси и генерира фатална грешка, ако случайно създадете ситуация, при която един и същ адрес се генерира два пъти (между другото, тази грешка е трудна за отстраняване на грешки).

Следният ред код,

Ipv4InterfaceContainer interfaces = address.Assign (devices);

извършва действителното присвояване на адреса. В ns-3 установяваме връзка между IP адрес и устройство, използващо обекта IPv4 интерфейс. Точно както понякога се нуждаем от списък с мрежови устройства, създаден от асистента за по-късна употреба, понякога се нуждаем от списък с обекти IPv4 интерфейс. IPv4InterfaceContainer предоставя тази функционалност.

Изградихме мрежа от точка до точка с инсталирани стекове и присвоени IP адреси. Сега имаме нужда от приложения във всеки възел, за да генерираме трафик.

4.2.7 Използване на приложението

Друга от основните абстракции на системата ns-3 е Приложение (приложение). В този сценарий използваме две специализации от базов клас Приложение ns-3 се обади UdpEchoServerApplication и UdpEchoClientApplication. Както и в предишните случаи, ние използваме спомагателни обекти за конфигуриране и управление на базовите обекти. Тук използваме UdpEchoServerHelper и UdpEchoClientHelper предмети, които да улеснят живота ни.

UdpEchoServerHelper

Следните редове код в нашия примерен скрипт first.cc се използват за конфигуриране на UDP ехо сървърно приложение на един от възлите, които създадохме по-рано.

UdpEchoServerHelper echoServer (9);

ApplicationContainer serverApps = echoServer.Install (nodes.Get (1));
serverApps.Start (Seconds (1.0));
serverApps.Stop (Seconds (10.0));

Първият ред код в горния фрагмент създава UdpEchoServerHelper. Както обикновено, това не е самото приложение, а обект, който ни помага да създаваме реални приложения. Една от нашите конвенции е да предадем необходимите атрибути на конструктора на помощния обект. В този случай помощникът не може да направи нищо полезно, освен ако не му бъде даден номерът на порта, на който сървърът ще слуша за пакети, този номер също трябва да бъде известен на клиента. В този случай предаваме номера на порта на помощния конструктор. Конструкторът от своя страна просто го прави SetAttribute с предадената стойност. По-късно, ако желаете, можете да използвате SetAttribute, за да зададете различна стойност за атрибута Port.

Подобно на много други спомагателни обекти, обектът UdpEchoServerHelper има метод инсталирам. Изпълнението на този метод ефективно създава основно приложение за ехо сървър и го свързва с хоста. Интересното е, че методът инсталирам приема NodeContainer като параметър също като другите инсталирам методи, които сме виждали.

Неявното преобразуване на C++, работещо тук, взема резултата от метода node.Get(1) (който връща интелигентен указател към обекта на възела - Ptr ) и го използва в конструктора за анонимния обект NodeContainerкойто след това се предава на метода инсталирам. Ако не можете да определите в кода на C++ кой подпис на метода се компилира и изпълнява, тогава потърсете сред неявните преобразувания.

Сега виждаме това echoServer.Install на път да инсталирате приложението UdpEchoServerApplication на намерени в NodeContainerкойто използваме за управление на нашите възли, възел с индекс 1. Метод инсталирам ще върне контейнер, който съдържа указатели към всички приложения (в този случай едно, тъй като предадохме анонимен NodeContainer, съдържащ един възел), създаден от помощника.

Приложенията трябва да посочат кога да започнат да генерират трафик започнете и може да се наложи допълнително да посочите време, когато да го спрете "Спри се". Предлагаме и двата варианта. Тези времена се задават с помощта на методите ApplicationContainer Начало и Спиране. Тези методи приемат параметри от тип Време. В този случай използваме изрична последователност от преобразувания на C++, за да вземем C++ удвои 1.0 и го преобразувайте в обект tns-3 Time, който използва обекта Seconds за преобразуване в секунди. Не забравяйте, че правилата за преобразуване могат да се контролират от автора на модела, а C++ има свои собствени правила, така че не винаги можете да разчитате, че параметрите ще бъдат преобразувани по начина, по който сте очаквали. Два реда

serverApps.Start (Seconds (1.0));
serverApps.Stop (Seconds (10.0));

ще накара приложението на ехо сървъра да стартира (включи автоматично) една секунда след началото на симулацията и да спре (изключи) след десет секунди от симулацията. Поради факта, че декларирахме симулационно събитие (събитие за спиране на приложението), което ще се изпълни след десет секунди, ще бъдат симулирани поне десет секунди работа на мрежата.

UdpEchoClientHelper

Клиентско приложение ехо конфигуриран по начин, почти подобен на сървъра. Има основен обект UdpEchoClientApplication, която се контролира
UdpEchoClientHelper.

UdpEchoClientHelper echoClient (interfaces.GetAddress (1), 9);
echoClient.SetAttribute ("MaxPackets", UintegerValue (1));
echoClient.SetAttribute ("Interval", TimeValue (Seconds (1.0)));
echoClient.SetAttribute ("PacketSize", UintegerValue (1024));

ApplicationContainer clientApps = echoClient.Install (nodes.Get (0));
clientApps.Start (Seconds (2.0));
clientApps.Stop (Seconds (10.0));;

За ехо клиента обаче трябва да зададем пет различни атрибута. Първите два атрибута се задават по време на създаване UdpEchoClientHelper. Предаваме параметри, които се използват (вътре в помощника) за задаване на атрибутите "RemoteAddress" и "RemotePort" в съответствие с нашето споразумение за предаване на необходимите параметри на помощния конструктор.

Нека си спомним, че използвахме IPv4InterfaceContainer за проследяване на IP адресите, които сме присвоили на нашите устройства. Нулевият интерфейс в контейнера за интерфейси ще съответства на IP адреса на нулевия възел в контейнера за възли. Първият интерфейс в контейнера за интерфейси съответства на IP адреса на първия възел в контейнера за възли. И така, в първия ред от кода (по-горе) създаваме помощник и му казваме, че отдалеченият адрес на клиента ще бъде IP адресът, присвоен на хоста, където се намира сървърът. Също така казваме, че трябва да уредим пакетите да бъдат изпращани до порт девет.

Атрибутът "MaxPackets" казва на клиента максималния брой пакети, които можем да изпратим по време на симулацията. Атрибутът "Interval" казва на клиента колко време да чака между пакетите, а атрибутът "PacketSize" казва на клиента колко голям трябва да бъде полезният товар на пакета. С тази комбинация от атрибути казваме на клиента да изпрати един 1024-байтов пакет.

Както при ехо сървъра, задаваме атрибутите на ехо клиента Начало и Спиране, но тук стартираме клиента секунда след включването на сървъра (две секунди след началото на симулацията).

4.2.8 Симулатор

В този момент трябва да стартираме симулацията. Това се прави с помощта на глобалната функция Симулатор::Бягай.

Simulator::Run ();

Когато преди извикахме методи,

serverApps.Start (Seconds (1.0));
serverApps.Stop (Seconds (10.0));
... 
clientApps.Start (Seconds (2.0));
clientApps.Stop (Seconds (10.0));

всъщност планирахме събития в симулатора на 1,0 секунди, 2,0 секунди и две събития на 10,0 секунди. След обаждането Симулатор::Бягай, системата ще започне да преглежда списъка с планирани събития и да ги изпълнява. Първо ще задейства събитие след 1,0 секунди, което ще задейства приложението на ехо сървъра (това събитие от своя страна може да планира много други събития). След това ще задейства събитие, планирано на t=2,0 секунди, което ще стартира клиентското приложение за ехо. Отново, това събитие може да има много други планирани събития. Реализацията на стартовото събитие в ехо клиента ще започне фазата на пренос на данни на симулацията чрез изпращане на пакет към сървъра.

Актът на изпращане на пакет до сървъра ще задейства верига от събития, които автоматично ще бъдат планирани зад кулисите и които ще реализират механиката на изпращане на ехо пакет според параметрите за време, които сме задали в скрипта.

В резултат на това, тъй като изпращаме само един пакет (не забравяйте, атрибутът MaxPackets беше зададено на едно), веригата от събития, инициирани от този единичен пинг на клиента, ще приключи и симулацията ще премине в режим на готовност. След като това се случи, останалите планирани събития ще бъдат събитията Спиране за сървър и клиент. Когато тези събития се изпълнят, няма да останат събития за по-нататъшна обработка и Симулатор::Бягай ще върне контрола. Симулацията е завършена.

Остава само да почистите след себе си. Това става чрез извикване на глобалната функция Симулатор::Унищожи. Тъй като бяха извикани помощните функции (или ns-3 код на ниско ниво), които са организирани така, че кукичките бяха вмъкнати в симулатора, за да унищожат всички създадени обекти. Не е необходимо да проследявате нито един от тези обекти сами - всичко, което трябваше да направите, беше да се обадите Симулатор::Унищожи и излезте. Системата ns-3 ще свърши тази тежка работа вместо вас. Останалите редове от нашия първи ns-3 скрипт, first.cc, правят точно това:

Simulator::Destroy ();
return 0;
}

Кога ще спре симулатора?

ns-3 е симулатор на дискретно събитие (DE). В такъв симулатор всяко събитие е свързано с неговото време за изпълнение и симулацията продължава чрез обработка на събития в реда, в който се появяват, докато симулацията напредва. Събитията могат да накарат бъдещи събития да бъдат планирани (например таймерът може да се пренасрочи, за да завърши отброяването в следващия интервал).

Първоначалните събития обикновено се инициират от обекта, например IPv6 ще планира откриването на услуги в мрежата, съседни заявки и т.н. Приложението планира първото събитие за изпращане на пакет и т.н. Когато едно събитие се обработва, то може да генерира нула, едно или повече събития. С напредването на симулацията възникват събития, които завършват или създават нови. Симулацията ще спре автоматично, ако опашката за събития е празна или бъде открито специално събитие Спиране. Събитие Спиране генерирани от функцията Симулатор::Стоп (спиране на времето).

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

• FlowMonitor - периодична проверка за изгубени пакети;

• RIPng – периодично излъчване на актуализации на таблици за маршрутизиране;

• и др.

В такива случаи Симулатор::Стоп необходими за правилно спиране на симулацията. Освен това, когато ns-3 е в режим на емулация, RealtimeSimulator се използва за синхронизиране на часовника за симулация с часовника на машината и Симулатор::Стоп необходимо за спиране на процеса.

Много от симулационните програми в учебника не се обаждат Симулатор::Стоп изрично, тъй като те прекратяват автоматично, когато събитията в опашката са изчерпани. Тези програми обаче ще приемат и повикването Simulator::Stop. Например следният допълнителен оператор в първата примерна програма ще насрочи изрично спиране на 11 секунди:

+ Simulator::Stop (Seconds (11.0));
  Simulator::Run ();
  Simulator::Destroy ();
  return 0;
}

Горното всъщност няма да промени поведението на тази програма, тъй като тази конкретна симулация естествено приключва след 10 секунди. Но ако промените времето за спиране в горния израз от 11 секунди на 1 секунда, ще забележите, че симулацията спира преди какъвто и да е изход да се появи на екрана (тъй като изходът се появява след около 2 секунди време за симулация).

Важно е да извикате Simulator::Stop, преди да извикате Simulator::Run; в противен случай Simulator::Run може никога да не върне контрола на основната програма, за да изпълни спирането!

4.2.9 Изграждане на вашия скрипт

Направихме създаването на вашите прости скриптове тривиално. Всичко, което трябва да направите, е да поставите скрипта си в scratch директорията и той ще бъде изграден автоматично, ако стартирате Waf. Да опитаме. Върнете се в директорията от най-високо ниво и копирайте examples/tutorial/first.cc към каталога надраскат

$ cd ../.. 
$ cp examples/tutorial/first.cc scratch/myfirst.cc

Сега изградете първия си примерен скрипт, като използвате WAF:

$ ./waf

Трябва да видите съобщения, показващи, че вашият първи пример е създаден успешно.

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
[614/708] cxx: scratch/myfirst.cc -> build/debug/scratch/myfirst_3.o
[706/708] cxx_link: build/debug/scratch/myfirst_3.o -> build/debug/scratch/myfirst
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (2.357s)

Сега можете да стартирате примера (имайте предвид, че ако изградите вашата програма в scratch директорията, тогава трябва да я стартирате от надраскат):

$ ./waf --run scratch/myfirst

Трябва да видите подобен резултат:

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.418s) Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2

Тук можете да видите, че системата за изграждане проверява дали файлът е създаден и след това го изпълнява. Виждате, че записът на компонента на ехо клиента показва, че е изпратил единичен 1024-байтов пакет до ехо сървър 10.1.1.2. Вие също виждате компонента за регистриране на ехо сървъра, който казва, че е получил 1024 байта от 10.1.1.1. Ехо сървърът тихо възпроизвежда пакета и можете да видите в дневника на ехо клиента, че той е получил своя пакет обратно от сървъра.

4.3 ns-3 Изходен код

Сега, след като сте използвали някои от ns-3 помощниците, можете да разгледате някои от изходния код, който прилага тази функционалност. Последният код може да бъде видян на нашия уеб сървър на следната връзка: https://gitlab.com/nsnam/ns-3-dev.git. Там ще видите страницата с резюме на Mercurial за нашето дърво за разработка на ns-3. В горната част на страницата ще видите няколко връзки,

summary | shortlog | changelog | graph | tags | files

Продължете и изберете връзката към файловете. Ето как ще изглежда най-горното ниво на повечето от нашите хранилища:

drwxr-xr-x                               [up]
drwxr-xr-x                               bindings python  files
drwxr-xr-x                               doc              files
drwxr-xr-x                               examples         files
drwxr-xr-x                               ns3              files
drwxr-xr-x                               scratch          files
drwxr-xr-x                               src              files
drwxr-xr-x                               utils            files
-rw-r--r-- 2009-07-01 12:47 +0200 560    .hgignore        file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 1886   .hgtags          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 1276   AUTHORS          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 30961  CHANGES.html     file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 17987  LICENSE          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 3742   README           file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 16171  RELEASE_NOTES    file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 6      VERSION          file | revisions | annotate
-rwxr-xr-x 2009-07-01 12:47 +0200 88110  waf              file | revisions | annotate
-rwxr-xr-x 2009-07-01 12:47 +0200 28     waf.bat          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 35395  wscript          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 7673   wutils.py        file | revisions | annotate

Нашите примерни скриптове са в директорията примери. Ако щракнете върху примерите, ще видите списък с поддиректории. Един от файловете в поддиректорията урок - първо.cc. Ако щракнете върху първо.cc ще видите кода, който току-що научихте.

Изходният код се намира главно в директорията SRC. Можете да видите изходния код, като щракнете върху името на директорията или щракнете върху връзката към файловете вдясно от името на директорията. Ако щракнете върху директорията src, ще получите списък с поддиректории src. Ако след това щракнете върху основната поддиректория, ще намерите списък с файлове. Първият файл, който ще видите (по време на писане на това ръководство), е аборт.ч. Ако щракнете върху връзката аборт.ч, ще бъдете изпратени до изходния файл за аборт.ч, който съдържа полезни макроси за излизане от скриптове, ако бъдат открити необичайни условия. Изходният код за помощниците, които използвахме в тази глава, може да бъде намерен в директорията src/Приложения/помощник. Чувствайте се свободни да бръкнете из дървото на директориите, за да разберете какво къде има и да разберете стила на програмите ns-3.

Източник: www.habr.com