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

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

4 Преглед на концепцията
4.1 Ключови абстракции
4.1.1 Възел (Node)
4.1.2 Приложение (Application)
4.1.3 Канал (Channel)
4.1.4 Мрежово устройство (Net Device)
4.1.5 Топологични помощници
4.2 Първи скрипт ns-3
4.2.1 Основен код
4.2.2 Включваеми модули
4.2.3 Пространство от имена ns3
4.2.4 Логване (Logging)
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 Възел (Node)

В интернет жаргона компютърното устройство, което се свързва с мрежата, се нарича хост или понякога крайна система. Поради факта, че ns-3 е симулатор на мрежа, а не симулатор на Интернет, ние целенасочено не използваме термина хост, тъй като той е тясно свързан с Интернет и неговите протоколи. Вместо това използваме по-общ термин, също използван от други симулатори, който произхожда от теорията на графите – възел (Node).node).

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

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

4.1.2 Приложение (Application)

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

Често границата между системния и приложния софтуер се провежда при промяна на нивото на привилегии, която се реализира в ловушките на операционната система. В ns‑3 няма реална концепция за операционна система и съответно няма понятия за нива на привилегии или системни извиквания. Въпреки това, имаме концепцията за приложение. Както в "реалния свят", за да изпълнят задачи, софтуерните приложения работят на компютри, приложенията на ns‑3 работят на възли ns‑3 за управление на симулации в симулирания свят.

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

4.1.3 Канал (Channel)

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

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

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

4.1.4 Мрежово устройство (Net Device)

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

Мрежовата карта няма да работи без софтуерен драйвер, който управлява нейното оборудване. В Unix (или Linux), част от периферното оборудване се класифицира като устройство. Устройствата се управляват с помощта на драйвери на устройства, а мрежовите устройства (NIC) се управляват с драйвери за мрежови устройства (network device drivers) и имат обобщено наименование мрежови устройства (net devices). В 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 и Channel.

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

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

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

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

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

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

Преминете в директорията examples/tutorial. Трябва да видите файл с име first.cc. Това е скрипт, който ще създаде простo точка-точка свързване между два възела и ще прехвърли един пакет между тях. Нека разгледаме този скрипт ред по ред, за целта отворете 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/core в инсталираното от вас издание. В списъка на тази директория ще намерите голям брой заглавни файлове. Когато правите сборка, Waf поставя публичните заглавни файлове в директорията ns3 в поддиректорията build/debug

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

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

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

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

$ .\/waf

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

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

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

using namespace ns3;

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

4.2.4 Логване (Logging)

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

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Ще използваме това изявление като удобно място за обсъждане на нашата система за документация. DoxygenАко погледнете уебсайта на проекта ns‑3, ще намерите линк „Документация“ (Documentation) в навигационното меню. Ако изберете този линк, ще попаднете на нашата страница за документация. Съществува линк към „Последен релиз“, който ще ви отведе до документацията за последната стабилна версия на ns‑3. Ако изберете линка „API Documentation“, ще попаднете на страницата на документация за APIs на ns‑3.

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

Сега трябва да прегледате документацията Doxygen за модула Logging. В списъка с макроси в горната част на страницата ще видите запис за 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);

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

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

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

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

PointToPointHelper

Създаваме двуточково свързване, действайки по познатия ни шаблон, използваме топологичен помощен обект за извършване на ниско ниво работа, необходима за свързването. Нека припомним, че двата ни ключови абстракта NetDevice и Channel. В реалния свят тези термини съответстват на периферийни карти и мрежови кабели. Обикновено, тези две неща са тясно свързани помежду си и никой не може да разчита на обмен, например, между устройства 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 Mbps“ (пет мегабита в секунда) като „DataRate».

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

Подобно на „DataRate“ в 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 (nodes) имаме два възела, всеки с инсталирано мрежово устройство „точка-точка“ и един канал „точка-точка“ между тях. И двете устройства ще бъдат конфигурирани да предават данни със скорост от пет мегабита в секунда с закъснение по канала от две милисекунди.

InternetStackHelper

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

InternetStackHelper stack;
stack.Install (nodes);

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

Ipv4AddressHelper

След това трябва да свържем нашите устройства с IP адреси. Предоставяме топологичен помощник за управление на разпределението на IP адреси. Единственият видим за потребителя API е задаването на основен IP адрес и маска на мрежата, които да се използват при извършването на действителното разпределение на адреси (това става на по-ниско ниво в помощника). Следващите два реда код в нашия примерен скрипт first.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 адреса с устройството, използвайки обекта Ipv4Interface. Както понякога ни е нужен списък на мрежовите устройства, създадени от помощника за по-нататъшна употреба, понякога ни е нужен и списък на обектите, Ipv4Interface. Ipv4InterfaceContainer предоставя тази функционалност.

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

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

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

UdpEchoServerHelper

Следващите редове код в примера ни скрипт first.cc се използват за настройка на приложението UDP Echo Server на един от възлите, които създадохме по-рано.

UdpEchoServerHelper echoServer (9);

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

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

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

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

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

Приложенията трябва да зададат момента за стартиране на генериране на трафик 'start' и може да се наложи допълнително да зададат времето, когато да спре 'stop'.Предоставяме и двете параметри. Тези времена се задават с помощта на методите ApplicationContainer Start и Stop. Тези методи приемат параметри от тип Време. В този случай използваме явна последователност от преобразувания C++, за да вземем C++ double 1.0 и да го преобразувате в обект tns‑3 Time, който използва обект Seconds за преобразуване в секунди. Помнете, че правилата за преобразуване може да се контролират от автора на модела, а C++ има свои собствени правила, така че не винаги можете да разчитате на това, че параметрите ще се преобразуват така, както очаквате. Две строки,

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

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

UdpEchoClientHelper

Клиентското приложение echo се настройва по начин, практически идентичен на сървъра. Има основен обект 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 байта.

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

4.2.8 Симулатор

На този етап трябва да стартираме симулацията. Това се прави с помощта на глобалната функция Simulator::Run.

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 секунди. След извикването на Simulator::Run, системата ще започне да преглежда списъка с планирани събития и ще ги изпълнява. Първо той ще стартира събитието след 1.0 секунди, което активира приложението на ехо-сървъра (това събитие може, от своя страна, да планира много други събития). След това ще стартира събитието, планирано за t = 2.0 секунди, което ще активира приложението на ехо-клиента. Отново, това събитие може да планира още много събития. Реализацията на събитието за стартиране в ехо-клиента ще започне етапа на предаване на данните за симулацията, изпращайки пакет до сървъра.

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

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

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

Simulator::Destroy ();
return 0;
}

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

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

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

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

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

• RIPng — периодична транслация на актуализации на таблиците за маршрутизиране;

• и т.н.

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

Много от симулационните програми в учебника не извикват Simulator::Stop очевидно, тъй като те приключват автоматично при изчерпване на събитията в опашката. Въпреки това, тези програми също ще приемат извикването на 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 в каталога scratch

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

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

$ .\/waf

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

Waf: Влизане в директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n[614\/708] cxx: scratch\/myfirst.cc -> build\/debug\/scratch\/myfirst_3.o\n[706\/708] cxx_link: build\/debug\/scratch\/myfirst_3.o -> build\/debug\/scratch\/myfirst\nWaf: Напускане на директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'build' завършен успешно (2.357s)

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

$ ./waf --run scratch/myfirst

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

Waf: Влизане в директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf: Напускане на директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'build' завършен успешно (0.418s) Изпратени 1024 байта до 10.1.1.2\nПолучени 1024 байта от 10.1.1.1\nПолучени 1024 байта от 10.1.1.2

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

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

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

Сорс кодът се намира основно в директорията src. Можете да прегледате изходния код, като кликнете върху името на директорията или върху линка "файлове" вдясно от името на директорията. Ако кликнете върху директорията src, ще получите списък с поддиректории на src. Ако след това кликнете върху поддиректорията core, ще намерите списък с файлове. Първият файл, който ще видите (към момента на написване на това ръководство) — abort.h. Ако кликнете на линка abort.h, ще бъдете насочени към изходния файл за abort.h, който съдържа полезни макроси за излизане от скриптове, ако се открият ненормални условия. Изходният код за помощниците, които използвахме в тази глава, можете да намерите в директорията src/Applications/helper. Не се колебайте да разгледате дървото на директорийте, за да разберете какво къде е и да се запознаете със стила на програмиране на ns-3.

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