ns-3 nettverkssimulator opplæring. Kapittel 3

kapittel 1,2

3 Komme i gang
3.1 Oversikt
3.2 Forutsetninger
3.2.1 Laste ned ns-3-utgivelsen som et kildearkiv
3.3 Laste ned ns-3 med Git
3.3.1 Laste ns-3 med Bake
3.4 Montering ns-3
3.4.1 Bygg med build.py
3.4.2 Bygging med bake
3.4.3 Bygg med Waf
3.5 Testing ns-3
3.6 Kjøre skriptet
3.6.1 Kommandolinjeargumenter
3.6.2 Feilsøking
3.6.3 Arbeidskatalog

Kapittel 3

Starter

Dette kapittelet er ment å forberede leseren til å begynne med en datamaskin som kanskje aldri har installert ns-3. Den dekker støttede plattformer, forutsetninger, hvordan du får tak i ns-3, hvordan du bygger ns-3, og hvordan du tester byggingen og kjører enkle programmer.

3.1 Oversikt

ns-3-simulatoren er bygget som et system av samarbeidende programvarebiblioteker. Under montering er koden til brukerprogrammer knyttet til disse bibliotekene. Programmeringsspråkene C++ eller Python brukes til å skrive tilpassede programmer.

Ns-3 distribueres som kildekode, noe som betyr at målsystemet må ha et programvareutviklingsmiljø for først å bygge bibliotekene og deretter bygge brukerprogrammet. I prinsippet vil ns-3 kunne distribueres som ferdige biblioteker for et bestemt system, og i fremtiden kan de distribueres på denne måten. Men i dag gjør mange brukere faktisk arbeidet sitt ved å redigere selve ns-3, så det er nyttig å ha kildekoden for å bygge bibliotekene. Hvis noen har lyst til å ta på seg arbeidet med å lage ferdige biblioteker og pakker for operativsystemer, ta kontakt med mailinglisten ns-utviklere.

Deretter skal vi se på tre måter å laste ned og bygge ns-3 på. Den første er å laste ned og bygge den offisielle utgivelsen fra hovedsiden. Den andre er valg og montering av kopier av utviklingsversjoner av den grunnleggende ns-3-installasjonen. Den tredje er å bruke ekstra byggeverktøy for å laste inn flere utvidelser for ns-3. Vi vil gå gjennom hver enkelt siden verktøyene er litt forskjellige.

Erfarne Linux-brukere lurer kanskje på hvorfor ns-3 ikke leveres som en pakke som de fleste andre biblioteker som bruker en pakkebehandling? Selv om det finnes binære pakker for ulike Linux-distribusjoner (f.eks. Debian), ender de fleste brukere opp med å redigere bibliotekene og må gjenoppbygge ns-3 selv, så det er praktisk å ha kildekoden tilgjengelig. Av denne grunn vil vi fokusere på å installere fra kilden.

For de fleste applikasjoner ns-3-rettigheter root ikke er nødvendig, anbefales det å bruke en uprivilegert brukerkonto.

3.2 Forutsetninger

Hele settet med tilgjengelige ns-3 biblioteker har en rekke avhengigheter av tredjeparts biblioteker, men for det meste kan ns-3 bygges og brukes med støtte for flere vanlige (ofte installert som standard) komponenter: en C++ kompilator, Python, en kildekoderedigerer (f.eks. vim, emacs eller Eclipse) og, hvis utviklingsrepositorier brukes, Git versjonskontrollsystemer. De fleste førstegangsbrukere trenger ikke å bekymre seg hvis konfigurasjonen deres rapporterer at noen ns-3 avanserte funksjoner mangler, men for de som ønsker en full installasjon, gir prosjektet en wiki som inneholder sider med mange nyttige tips og triks. En slik side er Installasjonssiden, med installasjonsinstruksjoner for ulike systemer, tilgjengelig på: https://www.nsnam.org/wiki/Installation.

Forutsetningsdelen av denne wikien forklarer hvilke pakker som kreves for å støtte vanlige ns-3-alternativer, og gir også kommandoene som brukes til å installere dem på vanlige varianter av Linux eller macOS.

Du kan benytte deg av denne muligheten til å utforske ns-3 wiki-siden eller hovednettstedet: https://www.nsnam.org, fordi det er mye informasjon der. Fra og med den nyeste versjonen av ns-3 (ns-3.29), kreves følgende verktøy for å kjøre ns-3:

Verktøypakke/versjon

• C++ kompilator
  clang++ eller g++ (g++ versjon 4.9 eller høyere)
• Python
  python2 versjon >= 2.7.10, eller python3 versjon >=3.4
• gå
  enhver nyeste versjon (for å få tilgang til ns-3 på GitLab.com)
• tjære
  enhver nyeste versjon (for utpakking av ns-3-utgivelsen)
• bunzip2
  enhver nyeste versjon (for utpakking av ns-3-versjonen)

For å sjekke standardversjonen av Python, skriv python -V. For å sjekke g++-versjonen, skriv g++ -v. Hvis noen verktøy mangler eller er for gamle, vennligst se installasjonsveiledningen på ns-3 wiki-siden.

Fra nå av antar vi at leseren kjører Linux, MacOS eller en Linux-emulator, og har minst verktøyene ovenfor.

3.2.1 Laste ned ns-3-utgivelsen som et kildearkiv

Dette er handlingsforløpet for en ny bruker som ønsker å laste ned og eksperimentere med den nyeste utgivelsen og pakkeversjonene av ns-3. ns-3-utgivelser publiseres som komprimerte kildearkiver, noen ganger kalt tarball. tarball er et spesielt programvarearkivformat der flere filer er kombinert sammen. Arkivet er vanligvis komprimert. ns-3 oppstartsprosess via tarball er enkelt, du trenger bare å velge en utgivelse, laste ned og pakke den ut.

La oss anta at du som bruker ønsker å bygge ns-3 i en lokal katalog kalt arbeidsområdet. Du kan få en arbeidskopi av utgivelsen ved å skrive inn følgende i Linux-konsollen (erstatte de riktige versjonsnumrene, selvfølgelig)

$ 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 

Vær oppmerksom på verktøyet som brukes ovenfor wget, som er et kommandolinjeverktøy for nedlasting av objekter fra Internett. Hvis du ikke har installert det, kan du bruke nettleseren til dette.

Ved å følge disse trinnene vil du ta deg til ns-allinone-3.29-katalogen, der skal du se flere filer og kataloger

$ 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

Du er nå klar til å bygge ns-3 basisdistribusjonen og kan gå videre til delen om bygning ns-3.

3.3 Laste ned ns-3 med Git

ns-3-koden er tilgjengelig i Git-repositoriene på GitLab.com på https://gitlab.com/nsnam/. Gruppe nsnam samler de ulike depotene som brukes av et åpen kildekode-prosjekt.

Den enkleste måten å begynne å bruke Git-depoter på er å dele eller klone miljøet ns-3-allinon. Dette er et sett med skript som styrer lasting og montering av de mest brukte ns-3-undersystemene. Hvis du er ny på Git, kan begrepene "gaffel" og "klone" være ukjente for deg; i så fall anbefaler vi at du ganske enkelt kloner (lag din egen kopi) depotet som ligger på GitLab.com slik:

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

På dette stadiet, visningen av katalogen din ns-3-allinon litt forskjellig fra utgivelsesarkivkatalogen beskrevet ovenfor. Det skal se omtrent slik ut:

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

Vær oppmerksom på at det er et skript download.py, som i tillegg vil trekke ut ns-3 og tilhørende kildekode. Her har du et valg: enten last ned det nyeste ns-3 utviklingsbildet:

$ python download.py

eller foretrekker ns-3-utgivelsen med flagget -n for å angi utgivelsesnummeret:

$ python download.py -n ns-3.29

Etter dette trinnet til katalogen ns-3-allinon ytterligere depoter vil bli lastet ned ns-3, bake, pybindgen и netanim.

Note
På en maskin med ren Ubuntu16.04 trengte jeg å endre kommandoen til dette: $ sudo python3 download.py -n ns-3.29 (heretter oversetterens notater).

3.3.1 Laste ns-3 med Bake

De to ovennevnte metodene (kildearkiv eller depot ns-3-allinon via Git) er nyttige for å få den enkleste ns-3-installasjonen med flere tillegg(pybindgen å generere Python-bindinger og netanim for nettverksanimasjon). Det tredje depotet som leveres som standard i ns-3-allinone kalles bake.

Varsel er et verktøy for koordinert bygging av programvare fra flere depoter, utviklet for ns-3-prosjektet. Varsel kan brukes til å skaffe utviklingsversjoner av ns-3, samt til å laste ned og bygge utvidelser av basisversjonen av ns-3-distribusjonen, for eksempel miljøet Direkte kodeutførelse, CradleNetwork Simulation Cradle, muligheten til å lage nye Python-bindinger og forskjellige ns-3 "apper".

Note
CradleNetwork Simulation Cradle er et rammeverk som lar deg bruke ekte TCP/IP-nettverksstabler inne i en nettverkssimulator.

Hvis du forventer at ns-3-installasjonen din har avanserte eller tilleggsfunksjoner, kan du følge denne installasjonsveien.

I de siste ns-3-utgivelsene Varsel ble lagt til tjærefrigjøringen. Utgivelsen inkluderer en konfigurasjonsfil som lar deg laste ned gjeldende programvareversjoner på utgivelsestidspunktet. Det er for eksempel versjonen Varsel, som er distribuert med utgivelse ns-3.29, kan brukes til å hente komponenter for den utgivelsen av ns-3 eller tidligere, men kan ikke brukes til å hente komponenter for senere utgivelser (hvis pakkebeskrivelsesfilen bakeconf.xml ikke oppdatert).

Du kan også få det siste eksemplaret bakeved å skrive inn følgende kommando i Linux-konsollen (forutsatt at du har Git installert):

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

Når du kjører git-kommandoen, bør du se noe sånt som følgende:

Cloning into 'bake'...
remote: Enumerating objects: 2086, done. 
remote: Counting objects: 100% (2086/2086), done. 
remote: Compressing objects: 100% (649/649), done. 
remote: Total 2086 (delta 1404), reused 2078 (delta 1399) 
Receiving objects: 100% (2086/2086), 2.68 MiB | 3.82 MiB/s, done. 
Resolving deltas: 100% (1404/1404), done.

Etter at kommandoen er fullført klone du bør ha en katalog som heter bake, hvis innhold skal se omtrent slik ut:

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

Merk at du har lastet inn flere Python-skript, en Python-modul kalt bake og en XML-konfigurasjonsfil. Det neste trinnet er å bruke disse skriptene til å laste ned og bygge ns-3-distribusjonen du ønsker. Flere tilpasningsmål er tilgjengelige:

1. ns-3.29: modul som tilsvarer utgivelsen; den vil laste ned komponenter som ligner på utgivelsen i tarballen;

2. ns-3-dev: en lignende modul, men bruker kode fra utviklingstreet;

3. ns-allinone-3.29: En modul som inkluderer andre tilleggsfunksjoner som klikkruting og Network Simulation Cradle, Openflow for ns-3.

4. ns-3-allinon: ligner på utgivelsesversjonen av modulen alt i et, men for utviklingskode.

Note
Klikk — modulær programvarearkitektur for å lage rutere.

Openflow er en protokoll for å administrere prosessen med å behandle data som overføres over et datanettverk av rutere og svitsjer, og implementere programvaredefinert nettverksteknologi.

Det nåværende øyeblikksbildet av utviklingen (ikke-utgitt) ns-3 kan finnes på:https://gitlab.com/nsnam/ns-3-dev.git.

Utviklerne prøver å holde disse depotene i en konsekvent fungerende stand, men de er i utviklingsområdet og inneholder uutgitt kode, så hvis du ikke planlegger å bruke nye funksjoner, velg den offisielle utgivelsen.

Du kan finne den nyeste versjonen av koden ved å bla gjennom listen over depoter, eller ved å gå til ns-3 Releases-nettsiden:https://www.nsnam.org/releases/ og klikke på den nyeste versjonslenken. I dette eksemplet fortsetter vi med ns-3.29.

Nå, for å få ns-3-komponentene vi trenger, bruker vi verktøyet Varsel. La oss si noen innledende ord om arbeidet Varsel.

Bake fungerer ved å laste inn pakkekilder i en katalog kilde og installere bibliotekene i byggekatalogen. Varsel kan kjøres ved å referere til binæren, men hvis du vil kjøre Varsel ikke fra katalogen der den ble lastet ned, er det tilrådelig å legge til banen til bake til banen din (PATH miljøvariabel), for eksempel som følger (eksempel for Linux bash shell). Gå til "bake"-katalogen og still inn følgende miljøvariabler:

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

Dette vil plassere programmet bake.py til skallbanen og vil tillate andre programmer å finne de kjørbare filene og bibliotekene den opprettet bake. I noen brukstilfeller bake, PATH og PYTHONPATH-innstillingen beskrevet ovenfor er ikke nødvendig, men en komplett oppbygging av ns-3-allinone (med tilleggspakker) krever det vanligvis.

Gå til arbeidskatalogen din og skriv inn følgende i konsollen:

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

Neste vil vi spørre Varsel sjekke om vi har nok verktøy til å laste de ulike komponentene. Slå:

$ ./bake.py check

Du bør se noe sånt som følgende:

> Python - OK 
> GNU C++ compiler - OK 
> Mercurial - OK 
> Git - OK 
> Tar tool - OK 
> Unzip tool - OK 
> Make - OK 
> cMake - OK 
> patch tool - OK 
> Path searched for tools: /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin ...

Spesielt er opplastingsverktøy som Mercurial, CVS, Git og Bazaar essensielle i dette trinnet da de lar oss få koden. På dette tidspunktet installerer du de manglende verktøyene på vanlig måte for systemet ditt (hvis du vet hvordan) eller kontakt systemadministratoren for å få hjelp.

Prøv deretter å laste ned programvaren:

$ ./bake.py download

resultatet bør være noe sånt som:

>> Searching for system dependency setuptools - OK 
>> Searching for system dependency libgoocanvas2 - OK 
>> Searching for system dependency gi-cairo - OK 
>> Searching for system dependency pygobject - OK 
>> Searching for system dependency pygraphviz - OK 
>> Searching for system dependency python-dev - OK 
>> Searching for system dependency qt - OK 
>> Searching for system dependency g++ - OK 
>> Downloading pybindgen-0.19.0.post4+ng823d8b2 (target directory:pybindgen) - OK 
>> Downloading netanim-3.108 - OK 
>> Downloading ns-3.29 - OK

Dette vil bety at tre kilder er lastet ned. Gå nå til kildekatalogen og skriv ls; Du bør se:

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

Nå er du klar til å bygge ns-3-distribusjonen.

3.4 Montering ns-3

Som med nedlasting av ns-3, er det flere måter å bygge ns-3 på. Det viktigste vi vil understreke er at ns-3 er bygget ved hjelp av et byggeverktøy kalt wafbeskrevet nedenfor. De fleste brukere vil jobbe med waf, men det er noen få nyttige skript som hjelper deg med å komme i gang eller organisere mer komplekse bygg. Så vær så snill, før du leser om waf, se på build.py og montering med bake.

3.4.1 Bygg med build.py

Advarsel! Dette byggetrinnet er kun tilgjengelig fra kildearkivversjonen hentet som beskrevet ovenfor; og ikke lastet ned via git eller bake.

Når du arbeider med et utgivelsesarkiv tarballI ns-3-allinon Det er et hendig skript som kan gjøre det enklere å sette sammen komponentene. Det heter build.py. Dette programmet vil sette opp prosjektet for deg på den mest nyttige måten. Vær imidlertid oppmerksom på at mer avansert oppsett og arbeid med ns-3 vanligvis innebærer bruk av ns-3s eget byggesystem, Waf, som vil bli introdusert senere i denne opplæringen.

Hvis du lastet ned ved hjelp av tarball, deretter i katalogen din ~/arbeidsområde en katalog med et navn noe sånt som ns-allinone-3.29. Skriv inn følgende:

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

Når du ringer build.py Vi brukte kommandolinjeargumenter for å bygge eksemplene og testene som ble brukt i denne opplæringen, som ikke er bygget som standard i ns-3. Som standard bygger programmet også alle tilgjengelige moduler. Deretter kan du, hvis du ønsker det, bygge ns-3 uten eksempler og tester, eller ekskludere moduler som ikke er nødvendige for arbeidet ditt.

Du vil se mange kompilatorutdatameldinger som vises av skriptet når det bygger de forskjellige delene du har lastet. Først vil manuset prøve å bygge animatøren netanim, deretter bindingsgeneratoren pybindgen og til slutt ns-3. Når prosessen er fullført, bør du se følgende:

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

I de tre siste linjene i listen ser vi en melding om moduler som ikke ble bygget:

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

Dette betyr ganske enkelt at noen ns-3-moduler som er avhengige av eksterne biblioteker kanskje ikke er bygget, eller at de ikke er pålagt å bygges for denne konfigurasjonen. Dette betyr ikke at simulatoren ikke er satt sammen eller at de sammensatte modulene ikke vil fungere riktig.

3.4.2 Bygging med bake

Hvis du brukte bake ovenfor for å hente kildekode fra prosjektlagrene, kan du fortsette å bruke den til å bygge ns-3. Slå:

$ ./bake.py build

og du bør se noe sånt som:

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

hjelpe: Du kan også gjøre både nedlastings- og byggetrinnene samtidig ved å ringe "bake.py deploy".

Montering av alle komponenter kan mislykkes, men monteringen vil fortsette hvis en komponent ikke er nødvendig. For eksempel var det et nylig portabilitetsproblem castxml kan settes sammen med verktøy bake ikke på alle plattformer. I dette tilfellet vil en melding som denne vises:

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

Men castxml bare nødvendig hvis du vil lage oppdaterte Python-bindinger. For de fleste brukere er det ikke behov for dette (i hvert fall før de endrer ns-3), så slike advarsler kan trygt ignoreres foreløpig.

Hvis det mislykkes, vil følgende kommando gi deg et hint om manglende avhengigheter:

$ ./bake.py show

De ulike avhengighetene til pakkene du prøver å bygge vil bli listet opp.

3.4.3 Bygg med Waf

Fram til dette punktet, for å begynne å bygge ns-3, brukte vi enten skriptet build.py, eller verktøy bake. Disse verktøyene er nyttige for å bygge ns-3 og vedlikeholde biblioteker. Faktisk kjører de byggeverktøyet for å bygge waf fra katalogen ns-3. waf installert med ns-3 kildekoden. De fleste brukere går raskt over til direkte bruk for å konfigurere og sette sammen ns-3 waf. Så for å fortsette, gå til ns-3-katalogen som du opprinnelig opprettet.

Dette er ikke strengt nødvendig for øyeblikket, men det vil være nyttig å gå tilbake litt og se hvordan du gjør endringer i prosjektkonfigurasjonen. Sannsynligvis den mest nyttige konfigurasjonsendringen du kan gjøre er å lage en optimalisert versjon av koden. Som standard har du konfigurert prosjektet til å bygge en feilsøkingsversjon. La oss ta en titt på et prosjekt for å lage en optimalisert konstruksjon. For å forklare til Waf at det bør lage optimaliserte bygg som inkluderer eksempler og tester, må du kjøre følgende kommandoer:

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

Dette vil starte waf utenfor den lokale katalogen (for enkelhets skyld). Den første kommandoen rydder opp fra forrige bygg, dette er vanligvis ikke strengt nødvendig, men det er god praksis (se også byggeprofiler nedenfor); dette vil slette tidligere opprettede biblioteker og objektfiler som ligger i katalogen bygge/. Når prosjektet er rekonfigurert og byggesystemet sjekker de ulike avhengighetene, bør du se utdata som ligner på følgende:

Setting top to      : /home/ns3user/workspace/bake/source/ns-3-dev
Setting out to      : /home/ns3user/workspace/bake/source/ns-3-dev/build
Checking for 'gcc' (C compiler)        : /usr/bin/gcc 
Checking for cc version                : 7.3.0 
Checking for 'g++' (C++ compiler)      : /usr/bin/g++ 
Checking for compilation flag -march=native support : ok 
Checking for compilation flag -Wl,--soname=foo support : ok 
Checking for compilation flag -std=c++11 support       : ok 
Checking boost includes   : headers not found, please ,!provide a --boost-includes argument (see help) 
Checking boost includes   : headers not found, please ,!provide a --boost-includes argument (see help) 
Checking for program 'python'            : /usr/bin/python 
Checking for python version >= 2.3       : 2.7.15 python-config                                                                     : /usr/bin/python-config
Asking python-config for pyembed '--cflags --libs --ldflags' flags : yes
Testing pyembed configuration                                      : yes
Asking python-config for pyext '--cflags --libs --ldflags' flags   : yes
Testing pyext configuration                                        : yes

Checking for compilation flag -fvisibility=hidden support          : ok 
Checking for compilation flag -Wno-array-bounds support            : ok 
Checking for pybindgen location          : ../pybindgen ,!(guessed) 
Checking for python module 'pybindgen'   : 0.19.0. ,!post4+g823d8b2 
Checking for pybindgen version           : 0.19.0. ,!post4+g823d8b2 
Checking for code snippet                : yes 
Checking for types uint64_t and unsigned long equivalence : no 
Checking for code snippet                                 : no 
Checking for types uint64_t and unsigned long long equivalence     : yes 
Checking for the apidefs that can be used for Python bindings                       : gcc-LP64 
Checking for internal GCC cxxabi         : complete 
Checking for python module 'pygccxml'    : not found 
Checking for click location              : not found 
Checking for program 'pkg-config'        : /usr/bin/pkg- ,!config 
Checking for 'gtk+-3.0'                  : not found 
Checking for 'libxml-2.0'                : yes 
checking for uint128_t                   : not found 
checking for __uint128_t                 : yes 
Checking high precision implementation   : 128-bit integer ,!(default) 
Checking for header stdint.h             : yes 
Checking for header inttypes.h           : yes 
Checking for header sys/inttypes.h       : not found 
Checking for header sys/types.h          : yes 
Checking for header sys/stat.h           : yes 
Checking for header dirent.h             : yes 
Checking for header stdlib.h             : yes 
Checking for header signal.h             : yes 
Checking for header pthread.h            : yes 
Checking for header stdint.h             : yes 
Checking for header inttypes.h           : yes 
Checking for header sys/inttypes.h       : not found
Checking for library rt                  : yes 
Checking for header sys/ioctl.h          : yes 
Checking for header net/if.h             : yes 
Checking for header net/ethernet.h       : yes 
Checking for header linux/if_tun.h       : yes 
Checking for header netpacket/packet.h   : yes 
Checking for NSC location                : not found 
Checking for 'sqlite3'                   : not found 
Checking for header linux/if_tun.h       : yes 
Checking for python module 'gi'          : 3.26.1 
Checking for python module 'gi.repository.GObject'      : ok 
Checking for python module 'cairo'                      : ok 
Checking for python module 'pygraphviz'                 : 1.4rc1 
Checking for python module 'gi.repository.Gtk'          : ok 
Checking for python module 'gi.repository.Gdk'          : ok 
Checking for python module 'gi.repository.Pango'        : ok 
Checking for python module 'gi.repository.GooCanvas'    : ok 
Checking for program 'sudo'                             : /usr/bin/sudo 
Checking for program 'valgrind'                         : not found 
Checking for 'gsl' : not found python-config            : not found 
Checking for compilation flag -fstrict-aliasing support : ok 
Checking for compilation flag -fstrict-aliasing support : ok 
Checking for compilation flag -Wstrict-aliasing support : ok 
Checking for compilation flag -Wstrict-aliasing support : ok 
Checking for program 'doxygen'                          : /usr/bin/doxygen
---- Summary of optional ns-3 features:
Build profile : optimized
Build directory : 
BRITE Integration : not enabled (BRITE not enabled (see option --with- ,!brite)) 
DES Metrics event collection : not enabled (defaults to disabled) 
Emulation FdNetDevice        : enabled 
Examples                     : enabled 
File descriptor NetDevice    : enabled 
GNU Scientific Library (GSL) : not enabled (GSL not found) 
Gcrypt library               : not enabled
(libgcrypt not found: you can use ,!libgcrypt-config to find its location.) GtkConfigStore               : not enabled (library 'gtk+-3.0 >= 3.0' not fou   nd)
MPI Support                  : not enabled (option --enable-mpi not selected)
ns-3 Click Integration       : not enabled (nsclick not enabled (see option --with- ,!nsclick))
ns-3 OpenFlow Integration   : not enabled (Required boost libraries not found) 
Network Simulation Cradle    : not enabled (NSC not found (see option --with-nsc))
PlanetLab FdNetDevice         : not enabled (PlanetLab operating system not detected ,!(see option --force-planetlab)) PyViz visualizer : enabled 
Python API Scanning Support   : not enabled (Missing 'pygccxml' Python module)
Python Bindings : enabled 
Real Time Simulator           : enabled 
SQlite stats data output      : not enabled (library 'sqlite3' not found)
Tap Bridge                    : enabled 
Tap FdNetDevice               : enabled
Tests                         : enabled 
Threading Primitives          : enabled 
Use sudo to set suid bit   : not enabled (option --enable-sudo not selected)
XmlIo                         : enabled
'configure' finished successfully (6.387s)

Vær oppmerksom på den siste delen av oppføringen ovenfor. Noen ns-3-alternativer er ikke aktivert som standard eller krever systemstøtte for å fungere skikkelig. For eksempel, for å aktivere XmlTo, må biblioteket være tilstede på systemet libxml-2.0. Hvis dette biblioteket ikke ble funnet og den tilsvarende ns-3-funksjonen ikke var aktivert, vil en melding vises. Merk også at det er mulig å bruke kommandoen sudo for å sette suid-biten "sett gruppe-ID ved kjøretid" for visse programmer. Den er ikke aktivert som standard, og derfor vises denne funksjonen som "ikke aktivert". Til slutt, for å få en liste over aktiverte alternativer, bruk waf med parameter --check-config.

La oss nå gå tilbake og bytte tilbake til feilsøkingsbygget som inneholder eksempler og tester.

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

Byggesystemet er nå satt opp, og du kan bygge feilsøkingsversjoner av ns-3-programmer ved ganske enkelt å skrive:

$ ./waf

Trinnene ovenfor kan ha tvunget deg til å bygge en del av ns-3-systemet to ganger, men nå vet du hvordan du endrer konfigurasjonen og bygger optimalisert kode.

For å sjekke hvilken profil som er aktiv for en gitt prosjektkonfigurasjon, er det en kommando:

$ ./waf --check-profile 
Waf: Entering directory `/path/to/ns-3-allinone/ns-3.29/build' 
Build profile: debug

Scenarioet ovenfor build.py støtter også argumenter --enable-examples и --enable-tests, men andre alternativer waf den støtter ikke direkte. Dette vil for eksempel ikke fungere:

$ ./build.py --disable-python

reaksjonen vil være slik:

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

Den spesielle operatøren - - kan imidlertid brukes til å sende ytterligere parametere via WAFså i stedet for ovennevnte vil følgende kommando fungere:

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

fordi den genererer hovedkommandoen ./waf configure --disable-python. Her er noen flere innledende tips om waf.

Håndtering av byggefeil

ns-3-utgivelser er testet på de nyeste C++-kompilatorene som er tilgjengelige på utgivelsestidspunktet på vanlige Linux- og MacOS-distribusjoner. Over tid blir imidlertid nye distribusjoner utgitt med nye kompilatorer, og disse nyere kompilatorene har en tendens til å være mer pedantiske når det gjelder advarsler. ns-3 konfigurerer bygget til å behandle alle advarsler som feil, så noen ganger hvis du kjører en eldre versjon på et nyere system, kan en kompilatoradvarsel stoppe byggingen.

For eksempel var det tidligere en utgivelse av ns-3.28 for Fedora 28, som inkluderte en ny hovedversjon gcc (gcc-8). Ved å bygge utgivelsen ns-3.28 eller tidligere versjoner under Fedora 28, med Gtk2+ installert, vil følgende feil oppstå:

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

I utgivelser som starter fra ns-3.28.1, i waf et alternativ er tilgjengelig for å løse disse problemene. Den deaktiverer innstilling av "-Werror"-flagget i g++ og clang++. Dette er alternativet "--disable-werror" og må brukes under konfigurasjonen:

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

Konfigurer eller sett sammen

Noen kommandoer waf har mening kun i konfigurasjonsfasen, og noen er kun gyldige i byggefasen. Hvis du for eksempel vil bruke ns-3-emuleringsfunksjonene, kan du aktivere bitinnstillingen suid ved hjelp av sudo, som beskrevet ovenfor. Dette vil overstyre kommandoene for konfigurasjonstrinn, og dermed kan du endre konfigurasjonen ved å bruke følgende kommando, som også inkluderer eksempler og tester.

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

Hvis du gjør dette waf vil starte sudofor å endre programmer for opprettelse av emuleringskodesocket til å kjøre med tillatelser root. I waf Det er mange andre alternativer tilgjengelig for konfigurasjons- og byggetrinnene. For å utforske alternativene dine, skriv inn:

$ ./waf --help

I neste avsnitt vil vi bruke noen testrelaterte alternativer.

Monteringsprofiler

Vi har allerede sett hvordan du kan konfigurere waf for forsamlinger feilsøke и optimalisert:

$ ./waf --build-profile=debug

Det er også en mellomliggende monteringsprofil, slipp. Alternativ -d er synonymt med --build-profile. Byggprofilen kontrollerer bruken av brytere for logging, påstander og kompilatoroptimalisering:

Som du kan se, er logging og påstander bare tilgjengelig i feilsøkingsbygg. Den anbefalte praksisen er å utvikle skriptet i feilsøkingsmodus, og deretter utføre gjentatte kjøringer (for statistikk eller parameterendringer) i en optimalisert byggeprofil.

Hvis du har kode som bare skal kjøres i visse byggeprofiler, bruk kodebrytermakroen:

NS_BUILD_DEBUG (std::cout << "Part of an output line..." << std::flush; timer.Start ,!()); DoLongInvolvedComputation ();
NS_BUILD_DEBUG (timer.Stop (); std::cout << "Done: " << timer << std::endl;)

Misligholde, waf plasserer byggeartefakter i byggekatalogen. Du kan spesifisere en annen utdatakatalog ved å bruke alternativet - -out, for eksempel:

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

Ved å kombinere dette med byggeprofiler kan du enkelt bytte mellom ulike kompileringsalternativer:

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

Som lar deg jobbe med flere sammenstillinger uten å måtte skrive om den siste sammenstillingen hver gang. Når du bytter til en annen profil, waf vil kompilere bare det, uten å fullstendig rekompilere alt.

Når du bytter byggeprofiler på denne måten, må du være forsiktig med å gi de samme konfigurasjonsalternativene hver gang. Å definere flere miljøvariabler vil hjelpe deg å unngå feil:

$ 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

Kompilatorer og flagg

I eksemplene ovenfor waf å bygge ns-3 bruker C++ kompilatoren fra GCC ( g ++). Du kan imidlertid endre den du bruker waf C++ kompilator, ved å definere CXX miljøvariabelen. For eksempel, for å bruke C++-kompilatoren Clang, clang++,

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

På samme måte kan du konfigurere waf å bruke distribuert kompilering ved hjelp av distcc:

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

Mer informasjon om distcc og distribuert kompilering finner du på prosjektsiden i dokumentasjonsdelen. For å legge til kompilatorflagg når du konfigurerer ns-3, bruk miljøvariabelen CXXFLAGS_EXTRA.

Installasjon

waf kan brukes til å installere biblioteker på forskjellige steder på systemet. Som standard er de kompilerte bibliotekene og kjørbare filene plassert i katalogen bygge, og siden Waf kjenner plasseringen til disse bibliotekene og kjørbare filene, er det ikke nødvendig å installere bibliotekene noe annet sted.

Hvis brukere foretrekker å installere utenfor byggekatalogen, kan de kjøre kommandoen ./waf installasjon. Standard prefiks for installasjon er / Usr / localSå ./waf installasjon vil installere programmer i / Usr / local / bin, biblioteker i / Usr / local / lib og header-filer i /usr/local/include. Superbrukerrettigheter må vanligvis settes med et standard prefiks, så en typisk kommando vil være det sudo ./waf installer. Ved lansering vil Waf først velge å bruke de delte bibliotekene i byggekatalogen, og deretter se etter biblioteker langs stien til bibliotekene som er konfigurert i det lokale miljøet. Så når du installerer biblioteker på et system, er det en god praksis å sjekke at de riktige bibliotekene blir brukt. Brukere kan velge å installere med et annet prefiks ved å overføre alternativet under konfigurasjonen --prefix, for eksempel:

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

Hvis brukeren senere, etter byggingen, skriver inn installasjonskommandoen ./waf, vil prefikset bli brukt / opt / lokal.

Lag ./waf clean må brukes før du rekonfigurerer prosjektet hvis installasjonen vil bruke waf under et annet prefiks.

For å bruke ns-3 er det derfor ikke nødvendig å ringe ./waf install. De fleste brukere trenger ikke denne kommandoen fordi waf henter de gjeldende bibliotekene fra build-katalogen, men noen brukere kan finne dette nyttig hvis aktivitetene deres involverer arbeid med programmer utenfor ns-3-katalogen.

Waf singel

På toppnivået i ns-3 kildetreet er det bare ett Waf-skript. Når du begynner å jobbe, vil du bruke mye tid i katalogen scratch/ eller dypere innsrc/... og samtidig må løpe waf. Du kan bare huske hvor du er og løpe waf som følger:

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

men dette vil være kjedelig og feilutsatt, så det finnes bedre løsninger. En vanlig måte er å bruke et tekstredigeringsprogram som f.eks emacs eller vim, der to terminalsesjoner åpnes, den ene brukes til å bygge ns-3, og den andre brukes til å redigere kildekoden. Hvis du bare har tarball, så kan en miljøvariabel hjelpe:

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

$ cd scratch 
$ waff build

I modulkatalogen kan det være fristende å legge til et trivielt waf-skript som exec ../../waf. Ikke gjør det er du snill. Dette er forvirrende for nybegynnere, og når det gjøres dårlig, fører det til byggefeil som er vanskelig å oppdage. Løsningene vist ovenfor er banen som bør brukes.

3.5 Testing ns-3

Du kan kjøre ns-3-distribusjonens enhetstester ved å kjøre skriptet ./test.py:

$ ./test.py

Disse testene kjøres parallelt med waf. Til slutt bør du se en melding som sier:

92 of 92 tests passed (92 passed, 0 failed, 0 crashed, 0 valgrind errors)

Dette er en viktig melding for å identifisere valgrind-krasj, krasj eller feil, som indikerer problemer med koden eller inkompatibilitet mellom verktøy og kode.

Du vil også se den endelige utgangen fra waf og en tester som kjører hver test, som vil se omtrent slik ut:

Waf: Entering directory `/path/to/workspace/ns-3-allinone/ns-3-dev/build' 
Waf: Leaving directory `/path/to/workspace/ns-3-allinone/ns-3-dev/build' 
'build' finished successfully (1.799s) 

Modules built:
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 of 92 tests passed (92 passed, 0 failed, 0 crashed, 0 valgrind errors)

Denne kommandoen kjøres vanligvis av brukere for raskt å bekrefte at ns-3-distribusjonen er riktig bygget. (Merk at rekkefølgen på "PASS: ..."-linjene kan være forskjellig, dette er normalt. Det som er viktig er at sammendragslinjen på slutten av rapporten viser at alle tester bestått; ingen tester mislyktes eller krasjet.) Og wafOg test.py vil parallellisere arbeidet på tvers av de tilgjengelige prosessorkjernene på maskinen.

3.6 Kjøre skriptet

Vi kjører vanligvis skript under kontroll waf. Dette gjør det mulig for byggesystemet å sikre at delte bibliotekstier er riktig angitt og at bibliotekene er tilgjengelige under kjøring. For å kjøre programmet, bruk ganske enkelt waf med parameter - -run. La oss kjøre ns-3-ekvivalenten til det allestedsnærværende programmet hallo verdenved å skrive følgende:

$ ./waf --run hello-simulator

Waf vil først sjekke at programmet er riktig bygget og bygge om nødvendig. Deretter waf vil kjøre et program som produserer følgende utdata.

Hello Simulator

Gratulerer! Du er nå en ns-3 bruker!

Hva bør jeg gjøre hvis jeg ikke ser resultater?

Hvis du ser meldinger wafsom indikerer at byggingen ble fullført, men at du ikke ser utdataene "Hei Simulator", så er det en mulighet for at du byttet byggemodus til delen [Bygg-med-Waf] optimalisert, men savnet å bytte tilbake til modusen feilsøke. All konsollutdata som brukes i denne opplæringen bruker en spesiell ns-3-komponent som utfører logging og brukes til å skrive ut egendefinerte meldinger til konsollen. Utdata fra denne komponenten blir automatisk deaktivert når optimalisert kode kompileres - den er "optimalisert". Hvis du ikke ser "Hello Simulator"-utgangen, skriv inn følgende:

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

å tilpasse waf å bygge feilsøkingsversjoner av ns-3-programmer, som inkluderer eksempler og tester. Du bør deretter gjenoppbygge den gjeldende feilsøkingsversjonen av koden ved å skrive

$ ./waf

Nå hvis du kjører programmet hei-simulator, bør du se det forventede resultatet.

3.6.1 Kommandolinjeargumenter

For å sende kommandolinjeargumenter til ns-3-programmet, bruk følgende mønster:

$ ./waf --run <ns3-program> --command-template="%s <args>"

Erstatte til navnet på programmet og til argumentene. Argument - -command-template for waf er egentlig en oppskrift for å bygge selve kommandolinjen waf brukes til å kjøre programmet. Waf sjekker at byggingen er fullført, setter de delte bibliotekbanene, bruker deretter den medfølgende kommandolinjemalen og erstatter programnavnet med %s plassholderen for å kalle den kjørbare. Hvis du synes denne syntaksen er komplisert, er det en enklere versjon som involverer ns-3-programmet og dets argumenter omsluttet av enkle anførselstegn:

$ ./waf --run '<ns3-program> --arg1=value1 --arg2=value2 ...'

Et annet spesielt nyttig eksempel er å kjøre testsuiter selektivt. La oss anta at det er en testpakke kalt mytest (det er det faktisk ikke). Ovenfor brukte vi ./test.py-skriptet til å kjøre en rekke tester parallelt, som gjentatte ganger kaller testprogrammet testløper. Anrop testløper direkte for å kjøre én test:

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

Argumenter vil bli sendt til programmet testløper. Siden mytest ikke eksisterer, vil en feilmelding bli generert. For å skrive ut de tilgjengelige testløper-alternativene, skriv inn:

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

3.6.2 Feilsøking

For å kjøre ns-3-programmer under et annet verktøy, for eksempel en debugger (f.eks. gdb) eller et minnetestverktøy (f.eks. valgrind), bruk en lignende form - -command-template = "…". For eksempel å kjøre i debuggeren gdb ditt hello-simulator ns-3-program med argumenter:

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

Merk at ns-3-programnavnet kommer med argumentet - -run, og administrasjonsverktøyet (her gdb) er det første symbolet i argumentet - -command-template. Alternativ - -args rapporter gdbat resten av kommandolinjen tilhører det "nedre" programmet. (Noen versjoner gdb forstår ikke alternativet - -args. I dette tilfellet fjerner du programargumentene fra - -command-template og bruk kommandosettet gdb args.) Vi kan kombinere denne oppskriften og den forrige for å kjøre testen under feilsøkeren:

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

3.6.3 Arbeidskatalog

Waf må skytes ut fra sin plassering på toppen av ns-3-treet. Denne mappen blir arbeidskatalogen der utdatafilene skal skrives. Men hva om du vil beholde disse filene utenfor ns-3-kildetreet? Bruk argument - -cwd:

$ ./waf --cwd=...

Du kan finne det mer praktisk å få utdatafilene i arbeidskatalogen din. I dette tilfellet kan følgende indirekte handling hjelpe:

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

Denne dekorasjonen av den forrige versjonen av kommandoen bevarer gjeldende arbeidskatalog, går til katalogen wafog instruerer deretter waf for å endre arbeidskatalogen tilbake til gjeldende arbeidskatalog som er lagret før du starter programmet. Vi nevner laget - -cwd For fullstendighetens skyld kjører de fleste brukere ganske enkelt Waf fra toppnivåkatalogen og genererer utdatafiler der.

Fortsettelse: Kapittel 4

Kilde: www.habr.com