Учебник по симулатор на мрежата 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 Основен код (Boilerplate)
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 Узел (Node)

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

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

Трябва да разберете Node като компютър, на който ще добавите функционалност. Ще добавите неща като приложения, стекове на протоколи и периферни карти с драйвери, които дават възможност на компютъра да извършва полезна работа. Използваме същата основна модел в 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. В голям моделируем мрежа ще трябва да организирате връзките между множество обекти. Node, 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 Основен код (Boilerplate)
Първият ред в файла е ред на режима на редактора 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 Логиране

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

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

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

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

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

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

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

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

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 има метод Инсталирайте. Изпълнението на този метод фактически води до създаването на основно приложение за ехо-сървър и привързването му към възел. Интересно е, че методът Инсталирайте приема NodeContainter приема параметър, както и другите Инсталирайте методи, които видяхме.

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

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

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

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

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

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));

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

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

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

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

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 беше зададен на единица), веригата от събития, инициирана от тази единствена клиентска ехо заявка, ще приключи и симулацията ще премине в режим на чакане. След като това се случи, оставащите планирани събития ще бъдат събития Спри за сървъра и клиента. Когато тези събития се изпълнят, за допълнителна обработка няма да останат събития и Simulator::Run ще върне контрола. Моделирането е завършено.

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

Simulator::Destroy ();
return 0;
}

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

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

Началните събития обикновено се инициират от обект, например IPv6 ще планира определяне на услуги в мрежата, запитвания на съседи и т.н. Приложението планира първото събитие за изпращане на пакет и т.н. Когато събитието бъде обработено, то може да генерира нула, едно или повече събития. С течение на симулацията, събитията просто завършват или породят нови. Симулацията автоматично ще спре, ако опашката от събития е празна или бъде открито специално събитие. Спри. Събитие Спри се генерира от функцията 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

Тук можете да видите как системата за компилация проверява, че файлът е компилиран, а след това го стартира. Виждате записа на компонента в клиент на ехо, който показва, че е изпратил един 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

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

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

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