Учебник по симулатор на мрежата 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 хранищата е да направите fork или да клоните окружението ns-3-allinone. Това е набор от скриптове, които управляват изтеглянето и изграждането на най-често използваните подсистеми на ns-3. Ако сте начинаещ в Git, термините "fork" и "клониране" може да не ви бъдат познати; ако е така, препоръчваме ви просто да клонирате (създадете собствена версия) репозитория, намиращ се на 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.

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

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

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

В последните версии на ns-3 Bake беше добавен в tar-изданието. В изданието е включен конфигурационен файл, позволяващ изтеглянето на актуалните версии на софтуера в момента на създаването на изданието. Тоест, например, версия Bake, която се разпространява с изданието 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. Нека кажем няколко предварителни думи за работата на Bake.

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

$ ./bake.py check

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

> Python - OK 
> GNU C++ компилатор - OK 
> Mercurial - OK 
> Git - OK 
> Tar инструмент - OK 
> Unzip инструмент - OK 
> Make - OK 
> cMake - OK 
> patch инструмент - 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'\n'build' finished successfully (6m25.032s) \n\nModules built:\nantenna                aodv                     applications\nbridge                 buildings                config-store\ncore                   csma                     csma-layout\ndsdv                   dsr                      energy \nfd-net-device          flow-monitor             internet\ninternet-apps          lr-wpan                  lte\nmesh                   mobility                 mpi\nnetanim (no Python)    network                  nix-vector-routing \nolsr                   point-to-point           point-to-point-layout \npropagation            sixlowpan                spectrum \nstats                  tap-bridge               test (no Python) \ntopology-read          traffic-control          uan \nvirtual-net-device     visualizer               wave \nwifi                   wimax \n\nModules not built (see ns-3 tutorial for explanation):\nbrite                  click                    openflow \nLeaving directory .\/ns-3.29

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

Modules not built (see ns-3 tutorial for explanation):\nbrite                     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
Това може да намали функционалността на крайната компилация.
Въпреки това, bake ще продължи, тъй като "castxml" не е основна зависимост.
За повече информация извикайте bake с -v или -vvv, за пълен подробен режим.

Но 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\/. Когато проектът бъде преустроен и системата за изграждане проверява различните зависимости, трябва да видите изход, подобен на следния:

Настройка на top до : /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 : ok 
Проверка за поддръжка на флаг за компилация -Wl,--soname=foo : ok 
Проверка за поддръжка на флаг за компилация -std=c++11 : ok 
Проверка за 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 : ok 
Проверка за поддръжка на флаг за компилация -Wno-array-bounds : ok 
Проверка за местоположение на 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' : ok 
Проверка за python модул 'cairo' : ok 
Проверка за python модул 'pygraphviz' : 1.4rc1 
Проверка за python модул 'gi.repository.Gtk' : ok 
Проверка за python модул 'gi.repository.Gdk' : ok 
Проверка за python модул 'gi.repository.Pango' : ok 
Проверка за python модул 'gi.repository.GooCanvas' : ok 
Проверка за програма 'sudo' : /usr/bin/sudo 
Проверка за програма 'valgrind' : не е намерен 
Проверка за 'gsl' : не е намерен python-config : не е намерен 
Проверка за поддръжка на флаг за компилация -fstrict-aliasing : ok 
Проверка за поддръжка на флаг за компилация -fstrict-aliasing : ok 
Проверка за поддръжка на флаг за компилация -Wstrict-aliasing : ok 
Проверка за поддръжка на флаг за компилация -Wstrict-aliasing : ok 
Проверка за програма '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 за компилации дебъг и 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           applications          bridge
click          config-store          core
csma           csma-layout           dsdv
emu            energy                flow-monitor
internet       lte                   mesh
mobility       mpi                   netanim
network        nix-vector-routing    ns3tcp
ns3wifi        olsr                  openflow
point-to-point point-to-point-layout propagation
spectrum       stats                 tap-bridge
template       test                  tools
topology-read  uan                   virtual-net-device
visualizer     wifi                  wimax

PASS: TestSuite ns3-wifi-interference
PASS: TestSuite histogram 

...

PASS: TestSuite object
PASS: TestSuite random-number-generators
92 от 92 теста са преминали (92 преминали, 0 неуспешни, 0 се сринаха, 0 грешки valgrind)

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

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

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

$ ./waf --run hello-simulator

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

Hello Simulator

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

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

Ако виждате съобщения Waf, които показват, че компилацията е завършила успешно, но не виждате изхода „Hello Simulator“, е възможно да сте в частта [Сборка-с-Waf] сменили режима на компилация на optimized, но да сте пропуснали да се върнете обратно в режим дебъг. Целият изход на консолата, използван в това ръководство, използва специален компонент 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