Упатство за мрежен симулатор 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 и Апликација UdpEchoServer. Како што може да очекувате, овие апликации сочинуваат збир на апликации за клиент/сервер што се користат за генерирање и ехо мрежни пакети.

4.1.3 Канал

Во реалниот свет, можете да поврзете компјутер на мрежа. Честопати медиумите преку кои се пренесуваат податоците во овие мрежи се нарекуваат канали. Кога приклучувате етернет кабел во ѕиден штекер, го поврзувате вашиот компјутер со етернет врска. Во симулираниот свет ns-3, јазол е поврзан со објект што претставува канал за комуникација. Овде, основната апстракција на комуникациската подмрежа се нарекува канал и е претставена во C++ со класата Channel.

Класа Канал Канал обезбедува методи за управување со интеракцијата на објектите на подмрежата и поврзување на хостовите со нив. Каналите, исто така, можат да бидат специјализирани од страна на развивачите во објектно-ориентирана програмска смисла. Специјализацијата на каналот може да моделира нешто едноставно како жица. Наменскиот канал може да моделира сложени работи како што е голем Ethernet прекинувач или тродимензионален простор полн со пречки во случај на безжични мрежи.

Ќе користиме специјализирани верзии на каналот во ова упатство наречено CsmaChannelCsmaChannel, PointToPointChannelPointToPointChannel и WifiChannelWifiChannel. CsmaChannel, на пример, моделира верзија на комуникациска подмрежа која имплементира комуникациско опкружување со повеќекратен пристап со носител. Ова ни дава функционалност слична на етернет.

4.1.4 Нето уред

Порано, ако сакате да поврзете компјутер на мрежа, требаше да купите специфичен мрежен кабел и хардверски уред наречен (во терминологија на компјутер) периферна картичка што треба да се инсталира на компјутерот. Ако периферната картичка имплементирала некои мрежни функции, тие се нарекувале картички за мрежен интерфејс или мрежни картички. Денес, повеќето компјутери доаѓаат со интегриран мрежен интерфејс хардвер и корисниците не ги гледаат како посебни уреди.

Мрежната картичка нема да работи без софтверски драјвер што го контролира нејзиниот хардвер. Во Unix (или Linux), дел од периферната опрема е класифициран како уред. Уредите се контролираат со помош на драјвери за уреди, а мрежните уреди (NIC) се контролираат со помош на драјвери за мрежни уреди (двигатели на мрежни уреди) и колективно се нарекуваат мрежни уреди (мрежни уреди). Во Unix и Linux Пристапувате до мрежни уреди со имиња како што се eth0.

Во ns-3, апстракцијата на мрежниот уред ги опфаќа и софтверот на двигателот и хардверот што се моделира. Во симулацијата, мрежен уред е „инсталиран“ во јазол за да му овозможи да комуницира со други јазли преку канали. Исто како вистински компјутер, јазолот може да се поврзе со повеќе канали преку повеќе уреди NetDevices.

Мрежната апстракција на уред е претставена во C++ со класата NetDevice. Класа NetDevice обезбедува методи за управување со врски со објекти на јазол и канал; а може да биде специјализиран од програмери во смисла на објектно-ориентирано програмирање. Во ова упатство ќе користиме неколку специјализирани верзии на NetDevice наречени CsmaNetDevice, PointToPointNetDevice и WifiNetDevice. Исто како што мрежен адаптер за етернет е дизајниран да работи со мрежа Етернет, CsmaNetDevice дизајниран да работи со CsmaChannel, PointToPointNetDevice дизајниран да работи со PointToPointChannelИ WifiNetDevice - дизајниран за работа Вифи-канал.

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 конфигурирајте —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 "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 во поддиректориум изгради/дебагира

Ако немате таков директориум, тоа значи дека не сте го навеле излезниот директориум при градењето на верзијата за издавање на ns-3, изградете вака:
$ ./waf конфигурирај --build-profile=debug --out=build/debug
$ ./waf изгради
или
$ ./waf конфигурирај --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 Documentation“, ќе бидете префрлени на страницата со документација ns-3 API.

На левата страна на страницата ќе најдете графички приказ на структурата на документацијата. Добро место за почеток е „книгата“ на Modules 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, кои ги нарекуваме јазли. Втората линија го повикува методот Креирај на објектот на јазли и бара од контејнерот да создаде два јазли. Како што е опишано во Кислород, контејнерот бара системот ns-3 да создаде два објекти Јазол и внатрешно складира покажувачи кон овие објекти.

Јазлите создадени во скриптата сè уште не прават ништо. Следниот чекор во градењето на топологијата е поврзување на нашите јазли со мрежата. Наједноставната форма на мрежа што ја поддржуваме е врската од точка до точка помеѓу два јазли. Сега ќе создадеме таква врска.

PointToPointHelper

Создаваме врска од точка до точка користејќи позната шема, користејќи помошен објект за топологија за да ја извршиме работата на ниско ниво потребна за поврзувањето. Потсетиме дека нашите две клучни апстракции NetDevice и канал. Во реалниот свет, овие термини приближно одговараат на периферните картички и мрежните кабли. Вообичаено, овие две работи се тесно поврзани една со друга и никој не може да смета на споделување, на пример, уреди Етернет преку безжичен канал. Нашите помошници за топологија ја следат оваа блиска врска и затоа ќе користите единствен објект во ова сценарио 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, итн.) на секој контејнерски јазол.

IPv4Address Helper

Потоа треба да ги поврземе нашите уреди со 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 Апликација UdpEchoServer и 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++ што работи овде го зема резултатот од методот јазол. Земете (1) (што враќа паметен покажувач на објектот на јазол - Ptr ) и го користи во конструкторот за анонимниот објект NodeContainerкој потоа се предава на методот Инсталирајте. Ако не можете да одредите во кодот C++ кој метод потпис е компајлиран и извршен, тогаш погледнете меѓу имплицитните конверзии.

Сега го гледаме тоа echoServer.Инсталирај за да ја инсталирате апликацијата Апликација UdpEchoServer на пронајдени во NodeContainerкој го користиме за управување со нашите јазли, јазол со индекс 1. Метод Инсталирајте ќе врати контејнер што содржи покажувачи до сите апликации (во овој случај една, бидејќи поминавме анонимна NodeContainer, кој содржи еден јазол) создаден од помошникот.

Апликациите треба да специфицираат кога да почнат да генерираат сообраќај "почеток" и можеби ќе треба дополнително да одредите време кога да го прекинете "стоп". Ние ги нудиме двете опции. Овие времиња се поставени со помош на методите Контејнер за апликација почеток и Стоп. Овие методи прифаќаат параметри од типот време. Во овој случај користиме експлицитна низа од конверзии на 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. Подаваме параметри кои се користат (внатре во помошникот) за поставување на атрибутите „Далечинска адреса“ и "RemotePort" во согласност со нашиот договор да ги пренесеме потребните параметри на помошниот конструктор.

Да потсетиме дека користевме IPv4InterfaceContainer за следење на IP адресите што сме ги доделиле на нашите уреди. Нултиот интерфејс во контејнерот за интерфејси ќе одговара на IP адресата на нуланиот јазол во контејнерот за јазли. Првиот интерфејс во контејнерот за интерфејси одговара на IP адресата на првиот јазол во контејнерот за јазли. Значи, во првата линија на код (погоре), создаваме помошник и му кажуваме дека далечинската адреса на клиентот ќе биде IP адресата доделена на јазолот каде што се наоѓа серверот. Ние, исто така, велиме дека треба да организираме испраќање на пакети до портата девет.

Атрибутот „MaxPackets“ му кажува на клиентот максималниот број на пакети што можеме да ги испратиме за време на симулацијата. Атрибутот „Интервал“ му кажува на клиентот колку долго да чека помеѓу пакетите, а атрибутот „Големина на пакетот“ му кажува на клиентот колку треба да биде големо оптоварувањето на пакетот. Со оваа комбинација на атрибути му кажуваме на клиентот да испрати еден пакет од 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 се користи за синхронизирање на часовникот за симулација со машинскиот часовник, и Симулатор::Стоп неопходни за запирање на процесот.

Многу од програмите за симулација во учебникот не повикуваат Симулатор::Стоп експлицитно, бидејќи тие автоматски завршуваат кога настаните во редица се исцрпени. Меѓутоа, овие програми ќе го прифатат и повикот Симулатор::Стоп. На пример, следната дополнителна изјава во првата програма за пример ќе закаже експлицитно запирање на 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. Да пробаме. Вратете се во директориумот на највисоко ниво и копирајте примери/упатство/прв.cc до каталогот изгребат

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

Сега изградете го вашиот прв примерок на скрипта користејќи мафта:

$ ./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. 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

Нашите примери на скрипти се во директориумот примери. Ако кликнете на примерите, ќе видите листа на поддиректориуми. Една од датотеките во поддиректориумот упатство - прво.cc. Ако кликнете на прво.cc ќе го видите кодот што штотуку го научивте.

Изворниот код главно се наоѓа во директориумот src. Можете да го видите изворниот код со кликнување на името на директориумот или кликнување на врската со датотеките десно од името на директориумот. Ако кликнете на директориумот src, ќе добиете листа на поддиректориуми src. Ако потоа кликнете на основниот поддиректориум, ќе најдете листа на датотеки. Првата датотека што ќе ја видите (во моментот на пишување на овој водич) е прекине.ж. Ако кликнете на врската прекине.ж, ќе бидете испратени до изворната датотека за прекине.ж, кој содржи корисни макроа за излез од скрипти доколку се откријат абнормални услови. Изворниот код за помошниците што ги користевме во ова поглавје може да се најде во директориумот src/Апликации/помошник. Слободно ѕиркајте околу дрвото на директориуми за да дознаете што е каде и да го разберете стилот на програмите ns-3.

Извор: www.habr.com