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

глави 1,2

3 Започваща работа
3.1 Преглед
3.2 Предварителни условия
3.2.1 Изтегляне на релиза на ns-3 като архив с изходен код
3.3 Изтегляне на ns-3 с помощта на Git
3.3.1 Изтегляне на ns-3 с помощта на Bake
3.4 Сглобяване на ns-3
3.4.1 Сглобяване с помощта на build.py
3.4.2 Сглобяване с Bake
3.4.3 Сглобяване с Waf
3.5 Тестване на ns-3
3.6 Стартиране на скрипт
3.6.1 Аргументи на командния ред
3.6.2 Дебъгване
3.6.3 Работна директория

Глава 3

Започваща работа

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

3.1 Преглед

Симулаторът ns-3 е построен като система от съвместно работещи софтуерни библиотеки. При сглобяване, кодът на потребителските програми се свързва с тези библиотеки. За написването на потребителски програми се използват езици за програмиране C++ или Python.

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

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

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

За повечето приложения ns-3 правата root не са необходими, препоръчва се да се използва непривилегирована потребителска сметка.

3.2 Предварителни условия

Целият набор от налични библиотеки ns-3 има редица зависимости от странични библиотеки, но в повечето случаи ns-3 може да бъде компилиран и използван с поддръжка на няколко разпространени (често инсталирани по подразбиране) компоненти: компилатор C++, Python, редактор на изходния код (например, vim, emacs или Eclipse) и, ако се използват разработки от репозитории, системи за управление на версии Git. На повечето начинаещи потребители не им трябва да се притесняват, ако тяхната конфигурация съобщава за някои липсващи допълнителни функции на ns-3, но за тези, които желаят пълна инсталация, проектът предлага уики, съдържаща страници с множество полезни съвети и подсказки. Една от тези страници е страницата „Инсталация“ с инструкции за инсталиране за различни системи, достъпни на адрес: https://www.nsnam.org/wiki/Installation.

Разделът „Предварителни условия“ на тази уики страница обяснява какви пакети са необходими за поддръжка на общите опции ns-3, както и предоставя команди, използвани за тяхната инсталация в разпространените версии на Linux или macOS.

Можете да се възползвате от възможността да проучите уики страницата ns-3 или основния уебсайт: https://www.nsnam.org, тъй като там има много информация. От последната версия ns-3 (ns-3.29) се изискват следните инструменти за стартиране на ns-3:

Инструмент Пакет/версия

• Компилатор C++
  clang++ или g++ (g++ версия 4.9 или по-нова)
• Python
  python2 версия >= 2.7.10, или python3 версия >=3.4
• Git
  всяка последна версия (за достъп до ns-3 на GitLab.com)
• tar
  всяка последна версия (за разархивиране на изданието ns-3)
• bunzip2
  всяка актуална версия (за разархивиране на изданието ns-3)

За да проверите версията на Python, инсталирана по подразбиране, въведете python -V. За да проверите версията на g++, въведете g++ -v. Ако някои инструменти липсват или са твърде стари, моля, обърнете се към ръководството за инсталация на уебстраницата на ns‑3.

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

3.2.1 Изтегляне на релиза на ns-3 като архив с изходен код

Това е начинът на действие на нов потребител, който желае да изтегли и експериментира с последните версии и пакетни издания на ns‑3. Изданията на ns‑3 се публикуват в компресирани архиви на изходен код, понякога наричани tarball. tarball — това е специален формат на софтуерен архив, в който няколко файла са обединени заедно. Архивът обикновено е компресиран. Процесът на изтегляне на ns‑3 през tarball е прост, просто трябва да изберете изданието, да го изтеглите и да го разархивирате.

Да предположим, че искате като потребител да компилирате ns‑3 в локална директория с име workspace. Можете да получите работна версия на изданието, като въведете в конзолата на Linux следното (разбира се, заменяйки съответните номера на версиите)

$ cd 
$ mkdir workspace 
$ cd workspace 
$ wget https://www.nsnam.org/release/ns-allinone-3.29.tar.bz2 
$ tar xjf ns-allinone-3.29.tar.bz2 

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

Следвайки тези стъпки, ще навигирате в директорията ns-allinone-3.29, където трябва да видите няколко файла и директории

$ cd ns-allinone-3.29
$ ls
bake constants.py ns-3.29 README
build.py netanim-3.108 pybindgen-0.17.0.post58+ngcf00cc0 util.py

Сега сте готови да компилирате основния дистрибутив на ns‑3 и можете да преминете към раздела, посветен на компилирането на ns‑3.

3.3 Изтегляне на ns-3 с помощта на Git

Кодът на ns‑3 е достъпен в репозиториите Git на GitLab.com на адрес https://gitlab.com/nsnam/. Групата nsnam обединява различни репозитории, използвани от проекта с отворен код.

Най-лесният начин да започнете да използвате репозиторите Git е да направите форк или да клонирате среда ns‑3-allinone. Това е набор от скриптове, които управляват изтеглянето и компилирането на най-често използваните подсистеми на ns‑3. Ако сте нови в Git, термините "форк" и "клониране" може да са ви непознати; ако е така, препоръчваме ви просто да клонирате (създайте собствена копия) репозитория на GitLab.com, както следва:

$ cd 
$ mkdir workspace 
$ cd workspace 
$ git clone https://gitlab.com/nsnam/ns-3-allinone.git 
$ cd ns-3-allinone 

На този етап прегледът на директорията ви ns‑3-allinone малко се различава от описаната по-горе директория с архив на версията. Тя трябва да изглежда приблизително така:

$ ls
build.py constants.py download.py README util.py

Обърнете внимание на наличието на скрипта download.py, който допълнително ще извлече ns‑3 и свързания изходен код. Тук имате избор: или да изтеглите най-новия моментен снимка на разработката ns‑3:

$ python download.py

или да предпочетете версията ns‑3, използвайки флага -n за указване на номера на версията:

$ python download.py -n ns-3.29

След тази стъпка в директорията ns‑3-allinone ще бъдат изтеглени допълнителни репозитории ns‑3, bake, pybindgen и netanim.

Забележка
На машина с чиста Ubuntu16.04 ми беше необходимо да променя командата на следния вид: $ sudo python3 download.py -n ns-3.29 (тук и нататък бележки на преводача).

3.3.1 Изтегляне на ns-3 с помощта на Bake

Двата споменати по-горе метода (архив на изходния код или репозитория ns‑3-allinone чрез Git) са полезни за получаване на най-простата инсталация на ns‑3 с няколко добавки (pybindgen за генериране на Python привързвания и netanim за анимиране на мрежата). Третият репозиторий, предоставен по подразбиране в ns‑3-allinone, се нарича bake.

Опаковка — това е инструмент за координирано изграждане на софтуер от няколко репозитория, разработен за проекта ns‑3. Опаковка може да се използва за получаване на разработчески версии на ns‑3, а също така за изтегляне и изграждане на разширения на основната версия на дистрибуцията ns‑3, като среда Direct Code Execution, CradleNetwork Simulation Cradle, възможността за създаване на нови Python привързвания и различни „приложения“ ns‑3.

Забележка
CradleNetwork Simulation Cradle — рамка, която позволява в рамките на мрежов симулатор да се използват реални мрежови стекове TCP / IP.

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

В последните версии на ns‑3 Опаковка беше добавен в tar-версия. В версията е включен файл конфигурация, позволяващ изтегляне на актуални към момента на създаване на версията версии на софтуера. Тоест, например, версия Опаковка, която се разпространява с версията ns‑3.29, може да се използва за получаване на компоненти за тази версия ns‑3 или по-ранни, но не може да се използва за извличане на компоненти за по-късни версии (ако файлът с описание на пакета bakeconf.xml не е актуализиран).

Можете също така да получите най-новата версия bake, като въведете следната команда във вашия Linux конзол (при условие, че имате инсталиран Git):

$ cd 
$ mkdir workspace 
$ cd workspace 
$ git clone https://gitlab.com/nsnam/bake.git

По време на изпълнението на командата git, трябва да видите нещо подобно на следното:

Клониране в 'bake'...
remote: Номериране на обекти: 2086, готово. 
remote: Броене на обекти: 100% (2086/2086), готово. 
remote: Компресиране на обекти: 100% (649/649), готово. 
remote: Общо 2086 (delta 1404), повторно използвани 2078 (delta 1399) 
Получаване на обекти: 100% (2086/2086), 2.68 MiB | 3.82 MiB/s, готово. 
Разрешаване на делти: 100% (1404/1404), готово.

След завършване на командата clone трябва да имате директория с име bake, съдържанието на която трябва да изглежда приблизително така:

$ cd bake
$ ls
bake bakeconf.xml bake.py doc examples generate-binary.py test TODO

Обърнете внимание, че сте изтеглили няколко Python скрипта, Python модул с име bake и XML конфигурационен файл. Следващата стъпка е да използвате тези скриптове за изтегляне и изграждане на разпределение на ns‑3 по ваш избор. Налични са няколко цели за настройка:

1. ns‑3.29: модул, отговарящ на версията; той ще изтегли компоненти, подобни на версията в tarball;

2. ns‑3-dev: подобен модул, но с използване на код от дървото за разработка;

3. ns-allinone-3.29: модул, който включва и други допълнителни функции, като Click маршрутиране и Network Simulation Cradle, Openflow за ns-3.

4. ns‑3-allinone: аналогично на версионния модул allinone, но за код за разработка.

Забележка
Click — модулна софтуерна архитектура за създаване на маршрутизатори.

Openflow — протокол за управление на процеса на обработка на данни, предавани в мрежата от маршрутизатори и комутатори, реализиращ технологията на софтуерно-настраивана мрежа.

Текущия Snapshot на разработката (нерелизен) ns‑3 можете да намерите на адрес:https://gitlab.com/nsnam/ns-3-dev.git.

Разработчиците се опитват да поддържат тези репозитории в последователно работно състояние, но те са в областта на разработката и съдържат нерелизен код, затова ако не планирате да използвате нови функции, изберете официалната версия.

Можете да намерите последната версия на кода, преглеждайки списъка на репозиторите или като посетите уеб страницата „ns‑3 Releases“:https://www.nsnam.org/releases/ и щракнете върху връзката на последната версия. В този пример ще продължим с ns‑3.29.

Сега, за да получим необходимите ни съставки на ns‑3, ще приложим инструмента Опаковка. Нека кажем няколко въведени думи за работата Опаковка.

Bake функционира, изтегляйки изходните пакети в директорията source и инсталира библиотеки в директорията за изграждане. Опаковка може да се стартира, позовавайки се на бинарния файл, но ако искате да стартирате Опаковка не от директорията, в която беше качен, е желателно да се добави пътят към bake вашия път (променливата среда PATH), например, по следния начин (пример за Linux bash). Преминете в директорията „bake“ и след това задайте следните променливи на средата:

$ export BAKE_HOME=`pwd` 
$ export PATH=$PATH:$BAKE_HOME:$BAKE_HOME/build/bin 
$ export PYTHONPATH=$PYTHONPATH:$BAKE_HOME:$BAKE_HOME/build/lib

Това ще постави програмата bake.py в пътя на обвивката и ще позволи на другите програми да намират изпълними файлове и библиотеки, създадени от bake. В някои случаи на използване bake, описаната по-горе настройка на PATH и PYTHONPATH не е необходима, но за пълното сглобяване на ns‑3-allinone (с допълнителни пакети) обикновено е необходима.

Отидете в работната директория и напишете в конзолата следното:

$ ./bake.py configure -e ns-3.29

След това ще ви помолим Опаковка да проверите дали имаме достатъчно инструменти за изтегляне на различни компоненти. Напишете:

$ ./bake.py check

Трябва да видите нещо такова:

> Python - OK 
> GNU C++ компилатор - OK 
> Mercurial - OK 
> Git - OK 
> Tar tool - OK 
> Unzip tool - OK 
> Make - OK 
> cMake - OK 
> patch tool - OK 
> Път, търсен за инструменти: /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin ...

По-специално, инструменти за изтегляне като Mercurial, CVS, Git и Bazaar са основни на тази стъпка, тъй като те ни позволяват да получим кода. На този етап инсталирайте липсващите инструменти по обичайния начин за вашата система (ако знаете как) или се обърнете за помощ към вашия системен администратор.

След това опитайте да изтеглите софтуера:

$ ./bake.py download

Резултатът трябва да бъде нещо такова:

>> Търсене на системната зависимост setuptools - OK 
>> Търсене на системната зависимост libgoocanvas2 - OK 
>> Търсене на системната зависимост gi-cairo - OK 
>> Търсене на системната зависимост pygobject - OK 
>> Търсене на системната зависимост pygraphviz - OK 
>> Търсене на системната зависимост python-dev - OK 
>> Търсене на системната зависимост qt - OK 
>> Търсене на системната зависимост g++ - OK 
>> Изтегляне на pybindgen-0.19.0.post4+ng823d8b2 (целевата директория:pybindgen) - OK 
>> Изтегляне на netanim-3.108 - OK 
>> Изтегляне на ns-3.29 - OK

Това ще означава, че са изтеглени три изходника. Сега отидете в директорията source и напишете ls; трябва да видите:

$ cd source 
$ ls
netanim-3.108 ns-3.29 pybindgen

Сега сте готови да сглобите дистрибуцията ns‑3.

3.4 Сглобяване на ns-3

Както при изтеглянето на ns‑3, има няколко начина да сглобите ns‑3. Най-важното, което искаме да подчертаем, е, че ns‑3 се сглобява с инструмента за сглобяване, наречен Waf, описан по-долу. Повечето потребители ще работят с Waf, но има няколко удобни сценария, които могат да ви помогнат да започнете или да организирате по-сложни конструкции. Затова, моля, преди да прочетете за Waf, погледнете на build.py и изграждане с bake.

3.4.1 Сглобяване с помощта на build.py

Внимание! Тази стъпка на изграждане е налична само от версията на изходния архив, получена както е описано по-горе; а не изтеглена през git или bake.

При работа с архив на изданието tarball, в ns‑3‑allinone има удобен сценарий, който може да опрости изграждането на компонентите. Той се нарича build.py. Тази програма ще настрои проекта за вас по най-полезния начин. Въпреки това, имайте предвид, че по-сложните настройки и работа с ns‑3 обикновено включват използването на собствената система за изграждане на ns‑3, Waf, която ще бъде представена по-късно в това ръководство.

Ако сте изтеглили с помощта на tarball, то във вашата директория ~ /workspace трябва да се появи директория с име нещо като ns-allinone-3.29. Въведете следното:

$ ./build.py --enable-examples --enable-tests

При повикване на build.py приложихме аргументи на командния ред, за да изградим примерите и тестовете, използвани в това ръководство, които в ns‑3 по подразбиране не се изграждат. По подразбиране, програмата също така строи всички налични модули. След това, ако желаете, можете да изградите ns‑3 без примери и тестове или да изключите модулите, които не са необходими за вашата работа.

Ще видите много изходни съобщения от компилатора, показвани от скрипта при изграждането на различните части, които сте изтеглили. Първо, скриптът ще се опита да събере аниматора netanim, след това генератора на свързвания pybindgen и накрая, ns‑3. В края на процеса, трябва да видите следното:

Waf: Leaving directory '/path/to/workspace/ns-allinone-3.29/ns-3.29/build'
'build' finished successfully (6m25.032s) 

Modules built:
antenna                aodv                     applications
bridge                 buildings                config-store
core                   csma                     csma-layout
dsdv                   dsr                      energy 
fd-net-device          flow-monitor             internet
internet-apps          lr-wpan                  lte
mesh                   mobility                 mpi
netanim (no Python)    network                  nix-vector-routing 
olsr                   point-to-point           point-to-point-layout 
propagation            sixlowpan                spectrum 
stats                  tap-bridge               test (no Python) 
topology-read          traffic-control          uan 
virtual-net-device     visualizer               wave 
wifi                   wimax 

Modules not built (see ns-3 tutorial for explanation):
brite                  click                    openflow 
Leaving directory ./ns-3.29

В последните три реда на листинга виждаме съобщение за модулите, които не са били събрани:

Modules not built (see ns-3 tutorial for explanation):
brite                     click

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

3.4.2 Сглобяване с Bake

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

$ ./bake.py build

и трябва да видите нещо такова:

>> Building pybindgen-0.19.0.post4+ng823d8b2 - OK 
>> Building netanim-3.108 - OK 
>> Building ns-3.29 - OK

Подсказка: можете също да изпълните и двете стъпки наведнъж, изтегляне и компилиране, като извикате 'bake.py deploy'.

При компилиране на всички компоненти могат да се появят грешки, но компилацията ще продължи, ако компонентът не е задължителен. Например, наскоро имаше проблем с преносимостта, свързан с факта, че castxml може да бъде компилиран от инструмент bake не на всички платформи. В този случай ще се появи съобщение от вида:

>> Building castxml - Problem 
> Problem: Optional dependency, module "castxml" failed
This may reduce the functionality of the final build.
However, bake will continue since "castxml" is not an essential dependency.
For more information call bake with -v or -vvv, for full verbose mode.

Обаче castxml нужен е само ако искате да създадете актуализирани Python обвивки. За повечето потребители това не е необходимо (по-скоро докато не започнат да променят ns-3), така че такива предупреждения могат безопасно да се игнорират за момента.

Ако възникне грешка, следната команда ще ви даде подсказка за липсващите зависимости:

$ ./bake.py show

Ще бъдат изброени различни пакети с зависимости, които опитвате да компилирате.

3.4.3 Сглобяване с Waf

Досега, за да започнем компилирането на ns-3, използвахме или скрипт build.py, или инструмент bake. Тези инструменти са полезни за компилиране на ns-3 и поддържане на библиотеките. Всъщност, те стартират инструмента за компилиране Waf от директорията на ns-3. Waf инсталира се заедно с изходния код на ns-3. Повечето потребители бързо преминават към пряко използване на Waf. И така, за да продължите, моля, преместете се в директорията ns-3, която първоначално създадохте.

В момента това не е строго задължително, но ще бъде полезно да направим малко отклонение и да видим как да внесем промени в конфигурацията на проекта. Най-вероятно най-полезната промяна в конфигурацията, която можете да направите, е създаването на оптимизирана версия на кода. По подразбиране, проектът ви е настроен да компилира отладъчната версия. Нека погледнем проекта за създаване на оптимизирана версия. За да обясните на Waf как да направи оптимизирани компилации, включващи примери и тестове, ще трябва да изпълните следните команди:

$ .\/waf clean 
$ .\/waf configure --build-profile=optimized --enable-examples --enable-tests

Това ще стартира Waf извън локалната директория (за ваше удобство). Първата команда извършва почистване от предишната компилация, което обикновено не е строго необходимо, но е добра практика (вж. също профилите за компилация по-долу); това ще премахне преди съществуващите библиотеки и обектни файлове, намиращи се в директорията build\/. Когато проектът е пренастроен и системата за компилация проверява различните зависимости, трябва да видите изход, подобен на следния:

Настройване на папката за      : /home/ns3user/workspace/bake/source/ns-3-dev
Настройване на изхода за      : /home/ns3user/workspace/bake/source/ns-3-dev/build
Проверка за 'gcc' (C компилатор)        : /usr/bin/gcc 
Проверка за версия на cc                : 7.3.0 
Проверка за 'g++' (C++ компилатор)      : /usr/bin/g++ 
Проверка на компилационния флаг -march=native : одобрено 
Проверка на компилационния флаг -Wl,--soname=foo : одобрено 
Проверка на компилационния флаг -std=c++11 : одобрено 
Проверка на Boost включвания   : заглавия не намерени, моля, предоставете аргумент --boost-includes (вижте помощта) 
Проверка на Boost включвания   : заглавия не намерени, моля, предоставете аргумент --boost-includes (вижте помощта) 
Проверка за програма 'python'            : /usr/bin/python 
Проверка за версия на python >= 2.3       : 2.7.15 python-config                                                                     : /usr/bin/python-config
Запитване до python-config за флаговете pyembed '--cflags --libs --ldflags' : да
Тест на конфигурацията на pyembed                                      : да
Запитване до python-config за флаговете pyext '--cflags --libs --ldflags'   : да
Тест на конфигурацията на pyext                                        : да

Проверка на компилационния флаг -fvisibility=hidden : одобрено 
Проверка на компилационния флаг -Wno-array-bounds : одобрено 
Проверка за местоположение на pybindgen          : ../pybindgen ,!(предположено) 
Проверка за python модул 'pybindgen'   : 0.19.0. ,!post4+g823d8b2 
Проверка за версия на pybindgen           : 0.19.0. ,!post4+g823d8b2 
Проверка за кодов фрагмент                : да 
Проверка за равенство на типове uint64_t и unsigned long : не 
Проверка за кодов фрагмент                                 : не 
Проверка за равенство на типове uint64_t и unsigned long long : да 
Проверка за apidefs, които могат да се използват за Python биндинги                       : gcc-LP64 
Проверка за вътрешен GCC cxxabi         : завършено 
Проверка за python модул 'pygccxml'    : не е намерен 
Проверка за местоположение на click              : не е намерено 
Проверка за програма 'pkg-config'        : /usr/bin/pkg- ,!config 
Проверка за 'gtk+-3.0'                  : не е намерено 
Проверка за 'libxml-2.0'                : да 
Проверка за uint128_t                   : не е намерен 
Проверка за __uint128_t                 : да 
Проверка за високопрецизна реализация   : 128-битов цяло число ,!(по подразбиране) 
Проверка за заглавен файл stdint.h             : да 
Проверка за заглавен файл inttypes.h           : да 
Проверка за заглавен файл sys/inttypes.h       : не е намерен 
Проверка за заглавен файл sys/types.h          : да 
Проверка за заглавен файл sys/stat.h           : да 
Проверка за заглавен файл dirent.h             : да 
Проверка за заглавен файл stdlib.h             : да 
Проверка за заглавен файл signal.h             : да 
Проверка за заглавен файл pthread.h            : да 
Проверка за заглавен файл stdint.h             : да 
Проверка за заглавен файл inttypes.h           : да 
Проверка за заглавен файл sys/inttypes.h       : не е намерен
Проверка за библиотека rt                  : да 
Проверка за заглавен файл sys/ioctl.h          : да 
Проверка за заглавен файл net/if.h             : да 
Проверка за заглавен файл net/ethernet.h       : да 
Проверка за заглавен файл linux/if_tun.h       : да 
Проверка за заглавен файл netpacket/packet.h   : да 
Проверка за местоположение на NSC                : не е намерено 
Проверка за 'sqlite3'                   : не е намерен 
Проверка за заглавен файл linux/if_tun.h       : да 
Проверка за python модул 'gi'          : 3.26.1 
Проверка за python модул 'gi.repository.GObject'      : одобрено 
Проверка за python модул 'cairo'                      : одобрено 
Проверка за python модул 'pygraphviz'                 : 1.4rc1 
Проверка за python модул 'gi.repository.Gtk'          : одобрено 
Проверка за python модул 'gi.repository.Gdk'          : одобрено 
Проверка за python модул 'gi.repository.Pango'        : одобрено 
Проверка за python модул 'gi.repository.GooCanvas'    : одобрено 
Проверка за програма 'sudo'                             : /usr/bin/sudo 
Проверка за програма 'valgrind'                         : не е намерена 
Проверка за 'gsl' : не е намерен python-config            : не е намерен 
Проверка за компилационен флаг -fstrict-aliasing : одобрено 
Проверка за компилационен флаг -fstrict-aliasing : одобрено 
Проверка за компилационен флаг -Wstrict-aliasing : одобрено 
Проверка за компилационен флаг -Wstrict-aliasing : одобрено 
Проверка за програма 'doxygen'                          : /usr/bin/doxygen
---- Резюме на опционалните функции на ns-3:
Профил на компилация : оптимизиран
Директория на компилация : 
BRITE Интеграция : не е активирана (BRITE не е активиран (вижте опцията --with-,!brite)) 
Събиране на метрики за събития DES : не е активирано (по подразбиране е деактивирано) 
Емуляция FdNetDevice        : активирана 
Примери                     : активирани 
Файл дескриптор NetDevice    : активиран 
GNU Научна Библиотека (GSL) : не е активирана (GSL не е намерен) 
Библиотека Gcrypt               : не е активирана
(библиотеката libgcrypt не е намерена: можете да използвате ,!libgcrypt-config за да намерите нейното местоположение.) GtkConfigStore               : не е активиран (библиотека 'gtk+-3.0 >= 3.0' не е намерена)
MPI Поддръжка                  : не е активирана (опция --enable-mpi не е избрана)
ns-3 Click Интеграция       : не е активирана (nsclick не е активиран (вижте опцията --with-,!nsclick))
ns-3 OpenFlow Интеграция   : не е активирана (Необходимите библиотеки на boost не са намерени) 
Cradle на мрежовата симулация    : не е активиран (NSC не е намерен (вижте опцията --with-nsc))
PlanetLab FdNetDevice         : не е активирано (Операционната система PlanetLab не е разпозната ,!(вижте опцията --force-planetlab)) PyViz визуализатор : активиран 
Поддръжка за Python API сканиране   : не е активирана (Липсва 'pygccxml' Python модул)
Python Биндинги : активирани 
Симулатор в Реално Време           : активиран 
Изход на данни за SQLite статистики      : не е активиран (библиотеката 'sqlite3' не е намерена)
Tap Bridge                    : активиран 
Tap FdNetDevice               : активиран
Тестове                         : активирани 
Примитиви за многопоточност          : активирани 
Използвайте sudo за задаване на suid бит   : не е активирано (опция --enable-sudo не е избрана)
XmlIo                         : активиран
'configure' завърши успешно (6.387s)

Обърнете внимание на последната част от списъка по-горе. Някои опции на ns‑3 не са включени по подразбиране или изискват подкрепа от системата, за да работят правилно. Например, за да активирате XmlTo, системата трябва да има библиотеката libxml-2.0. Ако тази библиотека не е намерена и съответната функция на ns‑3 не е активирана, ще се покаже съобщение. Също така, имайте предвид, че можете да използвате командата sudo за задаване на бит suid "идентификация на групата по време на изпълнение" за определени програми. Той не е включен по подразбиране и затова тази функция се показва като "не е включена" ("not enabled"). Накрая, за да получите списък с включените опции, използвайте Waf с параметъра --check-config.

Сега да се върнем и да преминем обратно на отладъчната версия, съдържаща примери и тестове.

$ .\/waf clean 
$ .\/waf configure --build-profile=debug --enable-examples --enable-tests

Системата за компилиране сега е настроена и можете да компилирате отладъчни версии на програмите ns‑3, като просто напишете:

$ .\/waf

Нека описаните по-горе стъпки ви накарат да компилирате част от системата ns‑3 два пъти, но сега знаете как да промените конфигурацията и да изградите оптимизиран код.

За да проверите кой профил е активен за дадената конфигурация на проекта, съществува команда:

$ .\/waf --check-profile 
Waf: Влизане в директория `\/path\/to\/ns-3-allinone\/ns-3.29\/build' 
Профил на компилация: debug

Обсъденият по-горе сценарий build.py също поддържа аргументи --enable-examples и --enable-tests, но не поддържа други опции Waf той не поддържа директно. Например, това няма да работи:

$ .\/build.py --disable-python

реакцията ще бъде:

build.py: error: no such option: --disable-python

Все пак, специален оператор - - може да се използва за предаване на допълнителни параметри чрез waf, така че вместо гореспоменатото, следната команда ще работи:

$ .\/build.py -- --disable-python

тъй като генерира основната команда .\/waf configure —disable-python. Ето още няколко съвета за Waf.

Обработка на грешки при компилация

Версиите на ns-3 са тествани с най-новите C++ компилатори, налични по време на пускането им в разпространените дистрибуции на Linux и MacOS. Въпреки това, с времето, нови дистрибуции с нови компилатори се пускат, и тези нови компилатори обикновено са по-прецизни по отношение на предупрежденията. ns-3 настройва своята компилация да третира всички предупреждения като грешки, затова понякога, ако използвате по-стара версия в по-нова система, предупреждение от компилатора може да спре компилацията.

Например, преди имаше версия ns-3.28 за Fedora 28, която включваше нова основна версия gcc (gcc-8). Компилацията на версия ns-3.28 или по-стари версии под Fedora 28, при инсталиран Gtk2+, ще предизвика следната грешка:

/usr/include/gtk-2.0/gtk/gtkfilechooserbutton.h:59:8: error: unnecessary parentheses ,!in declaration of ‘__gtk_reserved1’ [-Werror=parentheses] void (*__gtk_reserved1);

В версиите, започващи от ns-3.28.1, Waf е налична опция за решаване на тези проблеми. Тя деактивира задаването на флага "-Werror" в g++ и clang++. Тази опция "--disable-werror" трябва да бъде приложена по време на конфигуриране:

$ ./waf configure --disable-werror --enable-examples --enable-tests

Конфигуриране или компилиране

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

$ ./waf configure --enable-sudo --enable-examples --enable-tests

Ако направите това, Waf запуска sudo, за да промени програмите за създаване на сокет кода на емулатора, за да се стартира с права. root. В Waf Налични са много други опции за етапите на конфигуриране и компилиране. За да проучите опциите, напишете:

$ ./waf --help

В следващия раздел ще използваме някои опции, свързани с тестването.

Профили на компилация

Вече видяхме как можем да конфигурираме Waf за компилации debug и optimized:

$ ./waf --build-profile=debug

Има и междинен профил на компилация, release. Опцията -d е синоним на --build-profile. Профилът на компилация управлява използването на логиране, утверждения (assertions) и ключове за оптимизация на компилятора:

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

Ако имате код, който трябва да се изпълнява само в определени профили на сборка, използвайте макроса Code Wrapper Macro:

NS_BUILD_DEBUG (std::cout << "Част от изходния ред..." << std::flush; timer.Start ,!()); DoLongInvolvedComputation ();
NS_BUILD_DEBUG (timer.Stop (); std::cout << "Готово: " << timer << std::endl;)

По подразбиране, Waf поставя артефактите на сборката в директорията на сборката. Можете да посочите друга директория за изход с опцията - -out, например:

$ ./waf configure --out=my-build-dir

Комбинирайки това с профилите на сборка, можете лесно да превключвате между различни компилационни параметри:

$ ./waf configure --build-profile=debug --out=build/debug
$ ./waf build
...
$ ./waf configure --build-profile=optimized --out=build/optimized
$ ./waf build
...

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

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

$ export NS3CONFIG="--enable-examples --enable-tests" 
$ export NS3DEBUG="--build-profile=debug --out=build/debug"
$ export NS3OPT="--build-profile=optimized --out=build/optimized" 

$ ./waf configure $NS3CONFIG $NS3DEBUG
$ ./waf build 
...
$ ./waf configure $NS3CONFIG $NS3OPT
$ ./waf build

Компилатори и флагове

В горепосочените примери Waf за сборка на ns-3 се използва C++ компилатор от GCC ( g++). Въпреки това, можете да промените използвания Waf C++ компилатор, като определите променливата на средата CXX. Например, за да използвате C++ компилатора Clang, clang++,

$ CXX="clang++" ./waf configure 
$ ./waf build 

По подобен начин можете да конфигурирате Waf за използване на разпределена компилация с помощта на distcc:

$ CXX="distcc g++" ./waf configure 
$ ./waf build

По-подробна информация за distcc и разпределената компилация можете да намерите на страницата на проекта в раздела "Документация". За да добавите флагове на компилатора при конфигурирането на ns-3, използвайте променливата на средата CXXFLAGS_EXTRA.

Инсталиране

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

Ако потребителите предпочитат инсталация извън директорията за изграждане, могат да изпълнят командата .\/waf install. По подразбиране префиксът за инсталация е /usr/local, следователно .\/waf install ще инсталира програмите в /usr/local/bin, библиотеките в /usr/local/lib и заглавните файлове в /usr/local/include. Права на суперпотребителя обикновено са необходими за инсталиране с подразбиращия се префикс, така че типичната команда ще бъде sudo .\/waf install. При стартиране, Waf първо ще предпочете да използва общите библиотеки в директорията за изграждане и след това ще търси библиотеки по пътя към библиотеките, настроени в локалната среда. Така че при инсталиране на библиотеки в системата е добра практика да се проверява, че се използват необходимите библиотеки. Потребителите могат да изберат инсталация с различен префикс, предавайки по време на конфигурирането опцията --prefix, например:

.\/waf configure --prefix=\/opt\/local

Ако по-късно, след изграждането, потребителят въведе командата за инсталация .\/waf, ще бъде използван префикс /opt/local.

Екип .\/waf clean трябва да се използва преди повторна настройка на проекта, ако за инсталацията ще се използва Waf под друг префикс.

Така че, за да се използва ns‑3, не е необходимо да се извиква .\/waf install. На повечето потребители тази команда няма да им бъде нужна, тъй като Waf ще подхване текущите библиотеки от директорията за изграждане, но някои потребители могат да намерят това полезно, ако тяхната дейност включва работа с програми извън директорията ns‑3.

Waf е единен

На най-горно ниво на дървото с изходен код на ns‑3 има само един Waf скрипт. Като започнете работа, ще прекарате много време в директорията scratch\/ или по-дълбоко вsrc\/... и по време на това ще имате нужда да стартирате Waf. Можете просто да запомните къде се намирате и да стартирате Waf по следния начин:

$ ..\/..\/..\/waf ...

но това ще бъде досадно и подложено на грешки, затова има по-добри решения. Един от разпространените начини е да се използва текстов редактор, като emacs или vim, в който се отварят две терминални сесии, едната се използва за изграждане на ns‑3, а втората за редактиране на изходния код. Ако имате само tarball, това може да помогне променливата среда:

$ export NS3DIR="$PWD" 
$ function waff { cd $NS3DIR && ./$WAF $*; } 

$ cd scratch 
$ waff build

В директорията на модула може да изглежда примамливо да добавите тривиален сценарий waf по пример exec ../../waf. Моля, не го правете. Това обърква начинаещите и при лошо изпълнение води до трудно откриваеми грешки в компилацията. Решенията, показани по-горе, са пътят, който трябва да се използва.

3.5 Тестване на ns-3

Можете да изпълните модулни тестове на дистрибуцията ns-3, като стартирате скрипта ./test.py:

$ ./test.py

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

92 от 92 теста са преминали (92 преминали, 0 неуспешни, 0 сринати, 0 грешки valgrind)

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

Също така ще видите окончателния изход от Waf и тестера, изпълняващ всеки тест, който ще изглежда по следния начин:

Waf: Влизане в директория `\/path\/to\/workspace\/ns-3-allinone\/ns-3-dev\/build' 
Waf: Излизане от директория `\/path\/to\/workspace\/ns-3-allinone\/ns-3-dev\/build' 
'build' завърши успешно (1.799s) 

Сглобени модули:
aodv           приложения          мост
click          конфигурационен магазин          основен
csma           csma-структура           dsdv
ему            енергия                монитор на поток
интернет       lte                   мрежа
мобилност       mpi                   netanim
мрежа        nix-векторно маршрутизиране    ns3tcp
ns3wifi        olsr                  openflow
точка-точка точка-точка-структура разпространение
спектър       статистики                 tap-мост
template       тест                  инструменти
tопология-четене  uan                   виртуално мрежово устройство
визуализатор     wifi                  wimax

PASS: Тестов пакет ns3-wifi-interference
PASS: Тестов пакет хистограма 

...

PASS: Тестов пакет обект
PASS: Тестов пакет генератори на случайни числа
92 от 92 теста са преминали (92 преминали, 0 неуспешни, 0 сринати, 0 грешки valgrind)

Тази команда обикновено се стартира от потребители за бърза проверка на правилността на изграждането на дистрибуцията ns-3. (Обърнете внимание, че редът на линиите «PASS: ...» може да е различен, това е нормално. Важно е, че в окончателния ред в края на отчета всички тестове са преминали; нито един тест не е завършил неуспешно или е сринат.) И Waf, и test.py ще разпределят работата между наличните ядра на процесора на машината.

3.6 Стартиране на скрипт

Обикновено стартираме скриптовете под контрола на Waf. Това позволява на системата за изграждане да гарантира, че пътищата към общата библиотека са настроени правилно и че библиотеките са достъпни по време на изпълнение. За да стартирате програмата, просто използвайте Waf с параметъра -  -run. Нека стартираме за ns-3 еквивалент на всемогъща програма здравей свят, като напишем следното:

$ ./waf --run hello-simulator

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

Hello Simulator

Поздравления! Сега сте потребител на ns‑3!

Какво да правя, ако не виждам резултата?

Ако виждате съобщения Waf, които показват, че компилацията е завършила успешно, но не виждате изхода «Hello Simulator», то е възможно да сте в секцията [Сборка-с-Waf] променили режима си на компилация на optimized, но пропуснали да се върнете обратно в режим debug. Целият изход на конзолата, използван в това ръководство, използва специален компонент ns‑3, който изпълнява запис на лог и се използва за печат на потребителски съобщения в конзолата. Изходът от този компонент е автоматично деактивиран при компилация на оптимизиран код — той е "оптимизиран". Ако не виждате изхода "Hello Simulator", въведете следното:

$ .\/waf configure --build-profile=debug --enable-examples --enable-tests

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

$ .\/waf

Сега, ако стартирате програмата hello-simulator, трябва да видите очаквания резултат.

3.6.1 Аргументи на командния ред

За да предавате аргументи от командния ред на програмата ns‑3, използвайте следния шаблон:

$ .\/waf --run  --command-template="%s "

Заменете с името на вашата програма и с аргументите. Аргументът - -command-template за Waf е по същество рецепта за изграждане на фактическата командна линия Waf използвана за изпълнение на програмата. Waf проверява дали компилацията е завършила, задава пътища към общата библиотека, след това използва предоставения шаблон за командна линия и замества името на програмата вместо запълнителя %s, за да извика изпълнимия файл. Ако този синтаксис ви се струва сложен, има по-прост вариант, който включва програмата ns‑3 и нейните аргументи, поставени в единични кавички:

$ .\/waf --run ' --arg1=value1 --arg2=value2 ...'

Друг особено полезен пример е селективното стартиране на набори от тестове. Нека предположим, че има тестов набор (suite) mytest (всъщност такъв не съществува). По-горе използвахме скрипта .\/test.py за паралелно стартиране на редица тестове, който многократно извиква програмата за тестване test-runner. Извикване test-runner директно за изпълнение на един тест:

$ . /waf --run test-runner --command-template="%s --suite=mytest --verbose"

Аргументите ще бъдат предадени на програмата test-runner. Тъй като mytest не съществува, ще бъде генерирано съобщение за грешка. За да отпечатате наличните параметри на test-runner, въведете:

$ . /waf --run test-runner --command-template="%s --help"

3.6.2 Дебъгване

За да стартирате програми ns-3 под управление на друга утилита, като например отладчик (например, gdb) или инструмент за проверка на паметта (например, valgrind), използвайте подобна форма - -command-template = "…". Например, за да стартирате във отладчика gdb вашата програма hello-simulator ns-3 с аргументи:

$ . /waf --run=hello-simulator --command-template="gdb %s --args "

Обърнете внимание, че името на програмата ns-3 идва с аргумента -  -run, а управленската утилита (тук gdb) е първият токен в аргумента - -command-template. Опцията - -args се съобщава gdb, като останалата част от командния ред принадлежи на "ниската" програма. (Някои версии gdb не разбират опцията - -args. В този случай премахнете аргументите на програмата от - -command-template и използвайте набор от команди. gdb args) Можем да комбинираме тази рецепта и предишната за стартиране на теста под отладчика:

$ . /waf --run test-runner --command-template="gdb %s --args --suite=mytest --verbose"

3.6.3 Работна директория

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

$ . /waf --cwd=...

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

$ function waff {
CWD="$PWD" 
cd $NS3DIR > /dev/null 
. /waf --cwd="$CWD" $*
cd - > /dev/null 
}

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

Продължение: глава 4

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