🥇Tutorial om ns-3 netværkssimulator. Kapitel 3

kapitler 1,2

3 Arbejde med ns-3
3.1 Oversigt
3.2 Forudsætninger
3.2.1 Download af ns-3 som kildekodearkiv
3.3 Hentning af ns-3 med Git
3.3.1 Download af ns-3 med Bake
3.4 Bygning af ns-3
3.4.1 Bygning med build.py
3.4.2 Bygning med Bake
3.4.3 Bygning med Waf
3.5 Test af ns-3
3.6 Kørsel af script
3.6.1 Kommandolinjeargumenter
3.6.2 Fejlretning
3.6.3 Arbejdsmappe

Kapitel 3

Arbejdet med ns-3

Dette kapitel har til formål at forberede læseren på at arbejde med en computer, som måske aldrig har haft ns-3 installeret. Det dækker understøttede platforme, forudsætninger, metoder til at hente ns-3, metoder til at bygge ns-3, og hvordan man kan teste sin bygning og køre enkle programmer.

3.1 Oversigt

Ns-3-simulatoren er bygget som et system af samarbejdende softwarebiblioteker. Når man bygger, links koden fra brugerprogrammerne med disse biblioteker. Programmeringsspråkene C++ eller Python anvendes til at skrive brugerprogrammer.

Ns-3 distribueres som kildekode, hvilket betyder, at målsystemet skal have et softwareudviklingsmiljø for at kunne bygge bibliotekerne først og derefter bygge brugerprogrammet. I princippet kan ns-3 distribueres som færdige biblioteker til specifikke systemer, og i fremtiden kan de blive distribueret på denne måde. Men i øjeblikket udfører mange brugere deres arbejde ved at redigere selve ns-3, så det er nyttigt at have kildekoden til at bygge bibliotekerne. Hvis nogen gerne vil påtage sig ansvaret for at skabe færdige biblioteker og pakker til operativsystemer, bedes de kontakte mailinglisten. ns-developers.

Her vil vi gennemgå tre metoder til at hente og bygge ns-3. Den første er at hente og bygge den officielle version fra hovedsitet. Den anden er at vælge og bygge udviklerversioner af den grundlæggende ns-3 installation. Den tredje er at bruge yderligere byggredskaber til at hente flere udvidelser til ns-3. Vi vil se på hver metode, da værktøjerne varierer lidt.

Erfarne Linux-brugere måtte spørge sig selv, hvorfor ns-3 ikke leveres som en pakke, ligesom de fleste andre biblioteker, der bruger en pakkehåndterer? Selvom der findes binære pakker til forskellige Linux-distributioner (f.eks. Debian), ender de fleste brugere med at redigere bibliotekerne og er derfor tvunget til selv at rekonstruere ns-3, hvilket gør tilgængeligheden af kildekoden praktisk. Af denne grund vil vi fokusere på installation fra kildekode.

For de fleste anvendelser af ns-3 er rettigheder root ikke nødvendige, det anbefales at bruge en ikke-privilegeret brugerkonto.

3.2 Forudsætninger

Hele sættet af tilgængelige ns-3 biblioteker har en række afhængigheder til tredjepartsbiblioteker, men for det meste kan ns-3 bygges og bruges med støtte for flere almindelige (ofte installeret som standard) komponenter: C++ compiler, Python, kildekodeeditor (f.eks. vim, emacs eller Eclipse) og, hvis der bruges udviklingsrepositorier, versionskontrolsystemer såsom Git. De fleste begyndere behøver ikke at bekymre sig, hvis deres konfiguration rapporterer om nogle manglende ekstra funktioner til ns-3, men for dem, der ønsker en fuld installation, tilbyder projektet en wiki, som inkluderer sider med mange nyttige tips og vejledninger. En sådan side er 'Installations' siden med installationsinstruktioner for forskellige systemer, tilgængelige på: https://www.nsnam.org/wiki/Installation.

Afsnittet 'Forudsætninger' på denne wiki-side forklarer, hvilke pakker der er nødvendige for at understøtte de generelle muligheder for ns-3, samt giver kommandoerne, der bruges til at installere dem i almindelige versioner af Linux eller macOS.

Du kan drage fordel af muligheden for at udforske ns-3 wiki-siden eller den officielle hjemmeside: https://www.nsnam.org, da der er mange oplysninger. Fra den seneste version af ns-3 (ns-3.29) er følgende værktøjer nødvendige for at køre ns-3:

Værktøj Pakke/version

C++ Compiler
clang++ eller g++ (g++ version 4.9 eller nyere)
Python
python2 version >= 2.7.10, eller python3 version >= 3.4
Git
enhver seneste version (for adgang til ns-3 på GitLab.com)
tar
enhver seneste version (for at pakke ns-3 frigivelse ud)
bunzip2
enhver nyeste version (for at pakke ns-3 frigivelse ud)

For at kontrollere standard Python-versionen, skriv python -V. For at kontrollere versionen af g++, skal du indtaste g++ -v. Hvis nogle værktøjer mangler eller er for gamle, henviser vi til installatørens vejledning på ns-3's wiki-side.

Fra nu af antager vi, at læseren arbejder på Linux, MacOS, eller i en Linux-emulator, og har mindst de værktøjer, der er nævnt ovenfor.

3.2.1 Download af ns-3 som kildekodearkiv

Dette er fremgangsmåden for en ny bruger, der ønsker at downloade og eksperimentere med de nyeste udgivelses- og pakkesversioner af ns-3. Udgivelser af ns-3 offentliggøres i form af komprimerede arkiver af kildetekst, som nogle gange kaldes tarball. tarball — det er et særligt format for softwarearkiv, hvor flere filer er samlet sammen. Arkivet er normalt komprimeret. Processen for at downloade ns-3 er tarball simpel; du skal blot vælge en udgivelse, downloade og pakke den ud.

Lad os antage, at du som bruger ønsker at kompilere ns-3 i en lokal mappe ved navn workspace. Du kan få en arbejds kopi af udgivelsen ved at indtaste følgende i Linux-konsollen (selvfølgelig ved at erstatte de relevante versionsnumre)

$ 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

Bemærk den anvendte ovenstående værktøj wget, som er et kommandolinjeværktøj til at downloade objekter fra internettet. Hvis du ikke har installeret det, kan du bruge din browser til dette.

Ved at følge disse trin vil du komme ind i mappen ns-allinone-3.29, hvor du skal kunne se flere filer og mapper

$ 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

Nu er du klar til at kompilere den grundlæggende distribution af ns-3 og kan gå videre til afsnittet om at kompilere ns-3.

3.3 Hentning af ns-3 med Git

Koden til ns-3 er tilgængelig i Git-repositorier på GitLab.com på adressen https://gitlab.com/nsnam/. Gruppen nsnam samler forskellige repositorier, der anvendes af projektet med åbent kildekode.

Den nemmeste måde at begynde at bruge Git-repositorierne på er at lave et fork eller klone miljøet ns-3-allinone. Dette er et sæt scripts, der styrer download og kompilering af de mest ofte anvendte underværktøjer i ns-3. Hvis du er ny til Git, er termerne 'fork' og 'kloning' muligvis ikke velkendte; hvis dette er tilfældet, anbefaler vi, at du blot kloner (laver din egen kopi) af lagret på GitLab.com på følgende måde:

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

På dette tidspunkt skal du se indholdet af din mappe ns-3-allinone adskiller sig lidt fra den ovenfor beskrevne mappe med releasede arkiver. Den bør se omtrent sådan ud:

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

Bemærk nærværet af scriptet download.py, som yderligere vil udtrække ns-3 og tilhørende kildekode. Her har du mulighed for at vælge: enten at downloade den nyeste udviklingssnapshot af ns-3:

$ python download.py

eller foretrække ns-3-releasen ved hjælp af flaget -n til at angive release-nummeret:

$ python download.py -n ns-3.29

Efter dette trin vil yderligere repositoryer blive downloaded til mappen ns-3-allinone ns-3 bake, pybindgen, netanim og På en ren Ubuntu16.04-maskine måtte jeg ændre kommandoen til følgende:.

Bemærk
$ sudo python3 download.py -n ns-3.29 (her og fremover er oversætternotater). De to ovennævnte metoder (kildearkiv eller repository

3.3.1 Download af ns-3 med Bake

gennem Git) er nyttige til at få den mest enkle installation af ns-3 med flere add-ons ( ns-3-allinone til generering af Python-bindinger ognetanim til netværksanimation). Det tredje repository, der tilbydes som standard i ns-3-allinone, kaldes På en ren Ubuntu16.04-maskine måtte jeg ændre kommandoen til følgende: — et værktøj til koordineret softwarebygning fra flere repositories, udviklet til ns-3-projektet. pybindgen.

Bake kan bruges til at få udviklingsversioner af ns-3 samt til at downloade og kompilere udvidelser af den grundlæggende version af ns-3-distributionen, såsom miljøet Bake Direct Code Execution CradleNetwork Simulation Cradle, , muligheden for at oprette nye Python-bindinger og forskellige "applikationer" for ns-3.CradleNetwork Simulation Cradle er et rammeværk, der tillader brug af rigtige netværksstakke TCP / IP inden for netværksimulatoren.

Bemærk
Hvis du antager, at din ns-3-installation skal have udvidede eller ekstra funktioner, kan du følge denne installationsmetode.

I de seneste ns-3-udgivelser

blev tilføjet i tar-udgivelsen. Udgivelsen inkluderer en konfigurationsfil, der muliggør download af de softwareversioner, der er aktuelle på tidspunktet for frigivelsen. Det vil sige, for eksempel, versionen Bake , der distribueres med ns-3.29 udgivelsen, kan bruges til at hente komponenter til denne ns-3-release eller tidligere, men kan ikke bruges til at udtrække komponenter til senere udgivelser (hvis package-beskrivelsesfilen Bakebakeconf.xml ikke er opdateret). Du kan også få den nyeste kopi

, ved at indtaste følgende kommando i din Linux-konsol (forudsat at du har installeret Git): pybindgen, indtast følgende kommando i din Linux-konsol (forudsat at du har installeret Git):

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

Når du kører git-kommandoen, skal du se noget som følgende:

Kloning til 'bake'...
remote: Tæller objekter: 2086, færdig. 
remote: Tæller objekter: 100% (2086/2086), færdig. 
remote: Komprimering af objekter: 100% (649/649), færdig. 
remote: Total 2086 (delta 1404), genbrugt 2078 (delta 1399) 
Modtager objekter: 100% (2086/2086), 2.68 MiB | 3.82 MiB/s, færdig. 
Løser deltas: 100% (1404/1404), færdig.

Når kommandoen er færdig clone skal du have en mappe med navnet pybindgen, hvis indhold skal se cirka sådan ud:

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

Bemærk, at du har downloaded flere Python-scripts, et Python-modul ved navn pybindgen og en XML-konfigurationsfil. Næste skridt er at bruge disse scripts til at downloade og bygge distributionen af ns-3 efter dit valg. Flere konfigurationsmål er tilgængelige:

ns-3.29: et modul, der svarer til udgivelsen; det vil downloade komponenter svarende til udgivelsen i tarball;
ns-3-dev: et tilsvarende modul, men med brug af kode fra udviklingstræet;
ns-allinone-3.29: et modul, der inkluderer andre ekstra funktioner såsom Click-routing og Network Simulation Cradle, Openflow til ns-3.
ns-3-allinone: svarer til den udgivne version af modulet allinone, men for udviklingskoden.

Bemærk
Click — en modulær softwarearkitektur til opbygning af routere.

Openflow er en protokol til styring af processen for datahåndtering, der sendes over netværk af routere og switches, og som implementerer teknologi til programmerbart netværk.

Den nuværende udviklingssnapshot (ikke-udgivet) ns-3 kan findes på:https://gitlab.com/nsnam/ns-3-dev.git.

Udviklerne forsøger at holde disse repositories i en konsistent arbejdsstand, men de befinder sig i udviklingsområdet og indeholder ikke-udgivne koder, så hvis du ikke planlægger at bruge nye funktioner, så vælg den officielle udgivelse.

Du kan finde den nyeste version af koden ved at gennemse listen over repositories eller ved at gå til hjemmesiden 'ns-3 Releases':https://www.nsnam.org/releases/ og klikke på linket til den seneste version. I dette eksempel fortsætter vi med ns-3.29.

Nu for at få de nødvendige komponenter af ns-3, vil vi anvende værktøjet Bake. Lad os sige et par introducerende ord om arbejdet med Bake.

Bake fungerer ved at downloade kildekoderne til pakkerne til mappen source og installere bibliotekerne i build-mappen. Bake kan køre ved at henvise til den binære fil, men hvis du vil køre Bake ikke fra den mappe, den blev uploadet til, det er ønskeligt at tilføje stien til pybindgen din sti (miljøvariablen PATH), for eksempel som følger (eksempel for Linux bash-shell). Gå til mappen «bake» og indstil derefter 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 placere programmet bake.py i shellens sti og tillade andre programmer at finde de eksekverbare filer og biblioteker, som er oprettet af pybindgen. I nogle brugsscenarier pybindgen, kræves den ovenfor beskrevne opsætning af PATH og PYTHONPATH ikke, men for en fuld installation af ns‑3-allinone (med ytterligere pakker) er det normalt nødvendigt.

Gå til arbejdsbiblioteket og skriv følgende i konsollen:

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

Derefter vil vi bede Bake om at kontrollere, om vi har de nødvendige værktøjer til at hente forskellige komponenter. Skriv:

$ ./bake.py check

Du skal se noget, der ligner dette:

> Python - OK 
> GNU C++ compiler - OK 
> Mercurial - OK 
> Git - OK 
> Tar værktøj - OK 
> Unzip værktøj - OK 
> Make - OK 
> cMake - OK 
> patch værktøj - OK 
> Sti søgt for værktøjer: /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin ...

Især downloadværktøjer som Mercurial, CVS, Git og Bazaar er essentielle på dette trin, da de giver os mulighed for at hente koden. På dette punkt skal du installere de manglende værktøjer på den sædvanlige måde for dit system (hvis du kan) eller søge hjælp fra din systemadministrator.

Prøv derefter at downloade softwaren:

$ ./bake.py download

resultatet skal være noget 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 betyder, at tre kilder er blevet downloadet. Gå nu til mappen source og skriv ls; du skal se:

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

Nu er du klar til at bygge ns‑3-distributionen.

3.4 Bygning af ns-3

Som med download af ns‑3, er der flere måder at bygge ns‑3 på. Det vigtigste, vi ønsker at understrege, er, at ns‑3 bygges med et byggesystem kaldet Waf, beskrevet nedenfor. De fleste brugere vil arbejde med Waf, men der er flere nyttige scripts, der kan hjælpe dig med at komme i gang eller organisere mere komplekse opbygninger. Så, før du læser om Waf, så kig på build.py og opbygningen med pybindgen.

3.4.1 Bygning med build.py

Opmærksomhed! Dette bygge trin er kun tilgængeligt fra den version af kildearkivet, der er opnået som beskrevet ovenfor; ikke downloadet via git eller bake.

Når du arbejder med udgivelsesarkivet tarball, i ns‑3‑allinone er der et nyttigt script, der kan forenkle opbygningen af komponenter. Det hedder build.py. Dette program vil konfigurere projektet for dig på den mest nyttige måde. Vær dog opmærksom på, at mere komplekse konfigurationer og arbejde med ns‑3 normalt involverer brug af eget opbygningssystem ns‑3, Waf, som vil blive præsenteret senere i denne vejledning.

Hvis du har hentet det med tarball, skal der være en mappe i din directory ~/workspace , der hedder noget som ns-allinone-3.29. Indtast følgende:

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

Ved kald af build.py vi har anvendt kommandolinjeargumenter for at samle de eksempler og tests, der bruges i denne vejledning, som ikke er samlet som standard i ns‑3. Som standard bygger programmet også alle tilgængelige moduler. Derefter, hvis du ønsker det, kan du samle ns‑3 uden eksempler og tests eller udelukke moduler, som ikke er nødvendige for dit arbejde.

Du vil se mange compilerens udgange, der vises af scriptet, mens det samler de forskellige dele, du har hentet. Først forsøger scriptet at samle animatoren På en ren Ubuntu16.04-maskine måtte jeg ændre kommandoen til følgende:, derefter bindingsgeneratoren netanim og til sidst ns‑3. Ved afslutningen af processen skal 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 sidste tre linjer af output ser vi meddelelsen om de moduler, der ikke blev bygget:

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

Det betyder blot, at nogle ns‑3-moduler, der afhænger af eksterne biblioteker, muligvis ikke er blevet bygget, eller at deres opbygning ikke er nødvendig for denne konfiguration. Det betyder ikke, at simulatoren ikke er blevet bygget, eller at de byggede moduler vil fungere forkert.

3.4.2 Bygning med Bake

Hvis du ovenfor brugte bake til at hente kildekoden fra projektets repositories, kan du fortsætte med at bruge det til at bygge ns‑3. Indtast:

$ ./bake.py build

og du skal se noget som:

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

Ledetråd: du kan også udføre begge trin, download og byg, ved at kalde «bake.py deploy».

Når du bygger alle komponenter, kan der opstå fejl, men opbygningen vil fortsætte, hvis komponenten ikke er obligatorisk. For eksempel, et nyligt problem med bærbarhed involverede det, at castxml kan sættes op med værktøjet pybindgen ikke på alle platforme. I så fald vil der komme en meddelelse som:

>> Bygger castxml - Problem 
> Problem: Valgfri afhængighed, modulet "castxml" fejlede
Dette kan reducere funktionaliteten i den endelige opbygning.
Men bake vil fortsætte, da "castxml" ikke er en essentiel afhængighed.
For mere information, kald bake med -v eller -vvv for fuld verbose-tilstand.

analysen castxml er kun nødvendig, hvis du ønsker at oprette opdaterede Python-bindings. For de fleste brugere er der ikke behov for dette (i det mindste indtil de begynder at ændre ns‑3), så sådanne advarsler kan sikkert ignoreres for nu.

Hvis der opstår fejl, vil den næste kommando give dig en ledetråd om manglende afhængigheder:

$ ./bake.py show

Der vil blive opført forskellige pakkeafhængigheder, som du prøver at bygge.

3.4.3 Bygning med Waf

Indtil nu har vi brugt enten scriptet build.py, eller værktøjet pybindgen. Disse værktøjer er nyttige til at bygge ns‑3 og understøtte biblioteker. Faktisk kører de build-værktøjet Waf fra ns‑3-mappen. Waf installeringen følger med ns‑3 kildekoden. De fleste brugere går hurtigt videre til at bruge Wafdirekte til konfiguration og opbygning af ns‑3. Så for at fortsætte, bedes du gå til ns‑3-mappen, som du oprindeligt oprettede.

I øjeblikket er det ikke strengt nødvendigt, men det kan være nyttigt at lave en lille afstikker og se, hvordan man foretager ændringer i projektets konfiguration. Sandsynligvis vil det mest nyttige ændring af konfigurationen, som du kan lave, være at oprette en optimeret version af koden. Som standard har du indstillet dit projekt til at bygge en fejlsøgningsversion. Lad os overveje projektet for at skabe en optimeret bygning. For at forklare Waf, at det skal lave optimerede bygninger, der inkluderer eksempler og tests, skal du køre følgende kommandoer:

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

Dette vil starte Waf uden for den lokale mappe (for din bekvemmelighed). Den første kommando rydder op fra den tidligere bygning, det er normalt ikke strengt nødvendigt, men det er en god praksis (se også byggeprofiler nedenfor); dette vil fjerne tidligere oprettede biblioteker og objektfiler, der findes i mappen build\/. Når projektet er omkonfigureret, og bygget systemet tjekker forskellige afhængigheder, bør du se en output, der ligner følgende:

Indstiller top til      : /home/ns3user/workspace/bake/source/ns-3-dev
Indstiller ud til      : /home/ns3user/workspace/bake/source/ns-3-dev/build
Tjekker for 'gcc' (C compiler)        : /usr/bin/gcc 
Tjekker for cc version                : 7.3.0 
Tjekker for 'g++' (C++ compiler)      : /usr/bin/g++ 
Tjekker for kompilationsflag -march=native support : ok 
Tjekker for kompilationsflag -Wl,--soname=foo support : ok 
Tjekker for kompilationsflag -std=c++11 support       : ok 
Tjekker boost inkluderinger   : headere ikke fundet, please ,!provide a --boost-includes argument (se hjælp) 
Tjekker boost inkluderinger   : headere ikke fundet, please ,!provide a --boost-includes argument (se hjælp) 
Tjekker for program 'python'            : /usr/bin/python 
Tjekker for python version >= 2.3       : 2.7.15 python-config                                                                     : /usr/bin/python-config
Anmoder python-config om pyembed '--cflags --libs --ldflags' flags : ja
Tester pyembed konfiguration                                      : ja
Anmoder python-config om pyext '--cflags --libs --ldflags' flags   : ja
Tester pyext konfiguration                                        : ja

Tjekker for kompilationsflag -fvisibility=hidden support          : ok 
Tjekker for kompilationsflag -Wno-array-bounds support            : ok 
Tjekker for pybindgen placering          : ../pybindgen ,!(gættet) 
Tjekker for python modul 'pybindgen'   : 0.19.0. ,!post4+g823d8b2 
Tjekker for pybindgen version           : 0.19.0. ,!post4+g823d8b2 
Tjekker for kode snippet                : ja 
Tjekker for typer uint64_t og unsigned long ækvivalens : nej 
Tjekker for kode snippet                                 : nej 
Tjekker for typer uint64_t og unsigned long long ækvivalens     : ja 
Tjekker for apidefs der kan bruges til Python bindings                       : gcc-LP64 
Tjekker for intern GCC cxxabi         : komplet 
Tjekker for python modul 'pygccxml'    : ikke fundet 
Tjekker for click placering              : ikke fundet 
Tjekker for program 'pkg-config'        : /usr/bin/pkg-,!config 
Tjekker for 'gtk+-3.0'                  : ikke fundet 
Tjekker for 'libxml-2.0'                : ja 
Tjekker for uint128_t                   : ikke fundet 
Tjekker for __uint128_t                 : ja 
Tjekker høj præcision implementering   : 128-bit heltal ,!(standard) 
Tjekker for header stdint.h             : ja 
Tjekker for header inttypes.h           : ja 
Tjekker for header sys/inttypes.h       : ikke fundet 
Tjekker for header sys/types.h          : ja 
Tjekker for header sys/stat.h           : ja 
Tjekker for header dirent.h             : ja 
Tjekker for header stdlib.h             : ja 
Tjekker for header signal.h             : ja 
Tjekker for header pthread.h            : ja 
Tjekker for header stdint.h             : ja 
Tjekker for header inttypes.h           : ja 
Tjekker for header sys/inttypes.h       : ikke fundet
Tjekker for bibliotek rt                  : ja 
Tjekker for header sys/ioctl.h          : ja 
Tjekker for header net/if.h             : ja 
Tjekker for header net/ethernet.h       : ja 
Tjekker for header linux/if_tun.h       : ja 
Tjekker for header netpacket/packet.h   : ja 
Tjekker for NSC placering                : ikke fundet 
Tjekker for 'sqlite3'                   : ikke fundet 
Tjekker for header linux/if_tun.h       : ja 
Tjekker for python modul 'gi'          : 3.26.1 
Tjekker for python modul 'gi.repository.GObject'      : ok 
Tjekker for python modul 'cairo'                      : ok 
Tjekker for python modul 'pygraphviz'                 : 1.4rc1 
Tjekker for python modul 'gi.repository.Gtk'          : ok 
Tjekker for python modul 'gi.repository.Gdk'          : ok 
Tjekker for python modul 'gi.repository.Pango'        : ok 
Tjekker for python modul 'gi.repository.GooCanvas'    : ok 
Tjekker for program 'sudo'                             : /usr/bin/sudo 
Tjekker for program 'valgrind'                         : ikke fundet 
Tjekker for 'gsl' : ikke fundet python-config            : ikke fundet 
Tjekker for kompilationsflag -fstrict-aliasing support : ok 
Tjekker for kompilationsflag -fstrict-aliasing support : ok 
Tjekker for kompilationsflag -Wstrict-aliasing support : ok 
Tjekker for kompilationsflag -Wstrict-aliasing support : ok 
Tjekker for program 'doxygen'                          : /usr/bin/doxygen
---- Resumé af valgfrie ns-3 funktioner:
Bygprofil : optimeret
Bygmappe : 
BRITE integration : ikke aktiveret (BRITE ikke aktiveret (se mulighed --with-,!brite)) 
DES metrics hændelsesindsamling : ikke aktiveret (standard er deaktiveret) 
Emulation FdNetDevice        : aktiveret 
Eksempler                     : aktiveret 
Fil descriptor NetDevice    : aktiveret 
GNU Scientific Library (GSL) : ikke aktiveret (GSL ikke fundet) 
Gcrypt bibliotek               : ikke aktiveret
(libgcrypt ikke fundet: du kan bruge ,!libgcrypt-config for at finde dens placering.) GtkConfigStore               : ikke aktiveret (bibliotek 'gtk+-3.0 >= 3.0' ikke fou   nd)
MPI support                  : ikke aktiveret (mulighed --enable-mpi ikke valgt)
ns-3 Click integration       : ikke aktiveret (nsclick ikke aktiveret (se mulighed --with-,!nsclick))
ns-3 OpenFlow integration   : ikke aktiveret (Nødvendige boost biblioteker ikke fundet) 
Network Simulation Cradle    : ikke aktiveret (NSC ikke fundet (se mulighed --with-nsc))
PlanetLab FdNetDevice         : ikke aktiveret (PlanetLab operativsystem ikke opdaget ,!(se mulighed --force-planetlab)) PyViz visualizer : aktiveret 
Python API scanning support   : ikke aktiveret (Manglende 'pygccxml' Python modul)
Python bindings : aktiveret 
Real Time Simulator           : aktiveret 
SQlite stats data output      : ikke aktiveret (bibliotek 'sqlite3' ikke fundet)
Tap Bridge                    : aktiveret 
Tap FdNetDevice               : aktiveret
Tests                         : aktiveret 
Threading primitives          : aktiveret 
Brug sudo til at sætte suid bit   : ikke aktiveret (mulighed --enable-sudo ikke valgt)
XmlIo                         : aktiveret
'configure' er afsluttet med succes (6.387s)

Vær opmærksom på den sidste del af den ovenstående liste. Nogle ns-3 indstillinger er ikke inkluderet som standard eller kræver systemunderstøttelse for korrekt funktion. For eksempel, for at aktivere XmlTo, skal systemet have biblioteket libxml-2.0. Hvis dette bibliotek ikke blev fundet, og den relevante ns-3 funktion ikke ville være aktiveret, vil en fejlmeddelelse blive vist. Vær også opmærksom på, at der er mulighed for at bruge kommandoen sudo til at sætte suid-bit 'set group ID on execution' på visse programmer. Den er ikke aktiveret som standard, og derfor vises denne funktion som 'ikke aktiveret' ('not enabled'). Endelig, for at få vist en liste over aktiverede indstillinger, brug Waf with the parameter --check-config.

Lad os nu vende tilbage og skifte tilbage til debug-builden, som indeholder eksempler og tests.

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

Bygningssystemet er nu konfigureret, og du kan bygge debug-versioner af ns-3 programmerne ved blot at skrive:

$ ./waf

Selvom de ovenfor beskrevne trin fik dig til at bygge dele af ns-3 systemet to gange, ved du nu, hvordan du ændrer konfigurationen og bygger optimeret kode.

For at kontrollere, hvilken profil der er aktiv for denne projektkonfiguration, findes der en kommando:

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

Det ovenfor beskrevne scenarie build.py understøtter også argumenterne --enable-examples og --enable-tests, men andre indstillinger Waf understøttes ikke direkte. For eksempel vil dette ikke virke:

$ ./build.py --disable-python

reaktionen vil være:

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

Imidlertid kan den specielle operator -- bruges til at videregive ekstra parametre gennem waf, så i stedet for ovenstående vil følgende kommando fungere:

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

da den genererer den grundlæggende kommando ./waf configure --disable-python. Her er nogle yderligere indledende tips om Waf.

Håndtering af byggefejl

ns-3-releaser er blevet testet på de nyeste C++-kompilatorer, der er tilgængelige på det tidspunkt, hvor de blev udgivet på almindeligt forekommende Linux- og MacOS-distributioner. Men over tid bliver der udgivet nye distributioner med nye kompilatorer, og disse nyere kompilatorer er typisk mere pedantiske med hensyn til advarsler. ns-3 konfigurerer sin bygning til at behandle alle advarsler som fejl, så nogle gange, hvis du bruger en ældre version på et nyere system, kan en kompilatoradvarsel stoppe bygningen.

For eksempel var der tidligere en ns-3.28-udgivelse til Fedora 28, som inkluderede en ny hovedversion gcc (gcc-8). Bygningen af ns-3.28-udgivelsen eller tidligere versioner til Fedora 28 vil give den følgende fejl, når Gtk2+ er installeret:

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

I versioner fra og med ns-3.28.1, findes der Waf en mulighed for at løse disse problemer. Den deaktiverer flaget "-Werror" i g++ og clang++. Denne mulighed er "--disable-werror", og den skal anvendes under konfiguration:

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

Konfigurere eller bygge

Nogle kommandoer Waf giver mening kun i konfigurationsfasen, mens andre kun virker i byggefasen. For eksempel, hvis du ønsker at bruge ns-3-emuleringsfunktioner, kan du aktivere indstillingen for bit suid ved hjælp af sudo, som beskrevet ovenfor. Dette annullerer konfigurationskommandofasen, så du kan ændre konfigurationen ved at bruge følgende kommando, der også inkluderer eksempler og tests.

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

Hvis du gør dette, Waf kører sudo, for at ændre socket-emuleringsprogrammerne til at køre med rettigheder root. I Waf der er mange andre muligheder tilgængelige for konfigurations- og bygge faserne. For at undersøge mulighederne, skriv:

$ ./waf --help

I næste afsnit vil vi bruge nogle testrelaterede muligheder.

Byggeprofiler

Vi har allerede set, hvordan man kan konfigurere Waf til bygninger debug og optimized:

$ ./waf --build-profile=debug

Der er også en mellembygningprofil, release. Muligheden -d er et synonym for --build-profile. Byggeprofilen styrer brugen af logging, assertions og kompilatoroptimeringsnøgler:

Som man kan se, er logning og påstande kun tilgængelige i udviklingsbygninger. Den anbefalede praksis er at udvikle dit script i fejlsøgnings-tilstand og derefter udføre gentagne kørsel (til statistik eller ændring af parametre) i den optimerede byggeprofil.

Hvis du har kode, der kun skal køres i bestemte byggeprofiler, så brug makroen Code Wrapper Macro:

NS_BUILD_DEBUG (std::cout << "Del af en outputlinje..." << std::flush; timer.Start, !()); DoLongInvolvedComputation ();
NS_BUILD_DEBUG (timer.Stop (); std::cout << "Færdig: " << timer << std::endl;)

Som standard, Waf placerer byggeartefakter i bygge-mappen. Du kan angive en anden output-mappe ved hjælp af indstillingen - -out, for eksempel:

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

Ved at kombinere dette med byggeprofiler kan du nemt skifte mellem forskellige kompilationsindstillinger:

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

Det giver dig mulighed for at arbejde med flere bygninger uden at skrive den seneste bygning om hver gang. Når du skifter til en anden profil, Waf vil den kun kompilere denne, uden at hele projektet bliver genkompileret.

Når du på denne måde skifter byggeprofiler, er det vigtigt at sørge for, at du altid giver de samme konfigurationsparametre. At definere flere miljøvariabler kan hjælpe dig med at undgå fejl:

$ 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

Compiler og flag

I de ovenstående eksempler Waf til bygning ns‑3 bruger C++ compileren fra GCC ( g++). Det er dog muligt at ændre den anvendte Waf C++ compiler ved at definere miljøvariablen CXX. For eksempel for at bruge C++ compileren Clang, clang++,

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

På samme måde kan man konfigurere Waf til at bruge distribueret kompilering med distcc:

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

For mere information om distcc og distribueret kompilering, se projektsiden under afsnittet 'Dokumentation'. For at tilføje kompilatorflag ved konfigurationen af ns‑3, brug miljøvariablen CXXFLAGS_EXTRA.

Installation

Waf kan bruges til at installere biblioteker forskellige steder i systemet. Som standard findes de samlede biblioteker og eksekverbare filer i mappen build, og da Waf kender placeringen af disse biblioteker og eksekverbare filer, er der ikke behov for at installere biblioteker andre steder.

Hvis brugerne foretrækker at installere uden for bygge-mappen, kan de udføre kommandoen ./waf install. Som standard er præfikset for installationen — /usr/local, derfor ./waf install vil installere programmer i /usr/local/bin, biblioteker i /usr/local/lib og header-filer i /usr/local/include. Superbruger-rettigheder kræves normalt for at installere med standardpræfikset, så den typiske kommando vil være sudo ./waf install. Når Waf køres, vil den først foretrække at bruge de delte biblioteker i bygge-mappen og derefter søge efter biblioteker langs biblioteks-stien, der er konfigureret i det lokale miljø. Derfor er det en god praksis at kontrollere, at de rigtige biblioteker anvendes, når man installerer biblioteker i systemet. Brugere kan vælge at installere med et andet præfiks ved at give indstillingen --prefix, for eksempel:

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

Hvis brugeren senere, efter bygningen, indtaster en installationskommando ./waf, vil præfikset /opt/local.

Kommandoen ./waf clean skal bruges før projektet genkonfigureres, hvis installationen skal bruges Waf under et andet præfiks.

Derfor er det ikke nødvendigt at kalde ./waf installfor at bruge ns‑3. De fleste brugere vil ikke have brug for denne kommando, da Waf vil tage de aktuelle biblioteker fra bygge-mappen, men nogle brugere kan finde dette nyttigt, hvis deres arbejde involverer programmer uden for ns‑3-mappen.

Waf er én

Der er kun ét Waf-script på det øverste niveau af ns‑3's kildekodetræ. Når du først er i gang, vil du tilbringe meget tid i mappen scratch/ eller dybere, isrc/... og samtidig have behov for at køre Waf. Du kan bare huske, hvor du er, og køre Waf som følger:

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

men det vil være trættende og fejlbehæftet, så der er bedre løsninger. En almindelig metode er at bruge en teksteditor, såsom emacs eller vim, hvor der åbnes to terminal sessioner, en til at bygge ns‑3, og den anden til at redigere kildekoden. Hvis du kun har tarball, kan miljøvariablen hjælpe:

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

$ cd scratch 
$ waff build

Det kan være fristende at tilføje et trivielt waf-script i modulens mappe som eksempel. exec ../..//waf. Venligst gør ikke dette. Det forvirrer nybegyndere, og hvis det gøres forkert, fører det til vanskelige at opdage byggefejl. De løsninger, der er vist ovenfor, er den rigtige vej at følge.

3.5 Test af ns-3

Du kan køre modulære tests for ns-3-distributionen ved at køre scriptet ./test.py:

$ ./test.py

Disse tests kører parallelt med Waf. I sidste ende skal du se en meddelelse om at

92 af 92 tests bestået (92 bestået, 0 fejlet, 0 krasjet, 0 valgrind-fejl)

Denne meddelelse er vigtig for at identificere nedbrud, krasj eller valgrind-fejl, da den indikerer problemer med koden eller inkompatibilitet mellem værktøjer og kode.

Du vil også se den afsluttende output fra Waf og testeren, som kører hver test, som ser cirka sådan ud:

Waf: Går ind i biblioteket `/path/to/workspace/ns-3-allinone/ns-3-dev/build' 
Waf: Forlader biblioteket `/path/to/workspace/ns-3-allinone/ns-3-dev/build' 
'build' afsluttet med succes (1.799s) 

Moduler bygget:
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 af 92 tests bestået (92 bestået, 0 fejlet, 0 krasjet, 0 valgrind-fejl)

Denne kommando køres normalt af brugere for hurtigt at kontrollere, at ns-3-distributionen er korrekt bygget. (Bemærk, at rækkefølgen af linjerne «PASS: …» kan variere, det er normalt. Det vigtige er, at den sidste linje i rapporten viser, at alle tests er gennemført; ingen test fejlede eller krasjede.) Og Waf, og test.py vil parallelisere arbejdet hen over de tilgængelige CPU-kerner på maskinen.

3.6 Kørsel af script

Normalt kører vi scripts under kontrol af Waf. Dette sikrer, at stierne til fælles biblioteker er indstillet korrekt, og at bibliotekerne er tilgængelige under kørslen. For at køre programmet, brug blot Waf with the parameter - -run. Lad os køre ns-3s ækvivalent til den allestedsnærværende program hello world, ved at indtaste følgende:

$ ./waf --run hello-simulator

Waf vil først kontrollere, at programmet er bygget korrekt, og udføre bygningen om nødvendigt. Derefter Waf vil det udføre programmet, som vil generere den næste output.

Hello Simulator

Tillykke! Nu er du bruger af ns‑3!

Hvad skal jeg gøre, hvis jeg ikke ser resultatet?

Hvis du ser beskeder Waf, der angiver, at bygningen blev gennemført med succes, men ikke ser output «Hello Simulator», er der en chance for, at du i sektionen [Bygning-med-Waf] har skiftet din byggetilstand til optimized, men glemte at skifte tilbage til tilstand debug. Alt konsoloutput, der bruges i denne vejledning, anvender en særlig komponent af ns‑3, der udfører logføring og anvendes til at skrive brugerbeskeder til konsollen. Output fra denne komponent er automatisk deaktiveret ved kompilering af optimeret kode — den er "optimeret". Hvis du ikke ser output "Hello Simulator", skal du indtaste følgende:

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

for at konfigurere Waf til bygning af debug-versioner af ns‑3-programmer, der inkluderer eksempler og tests. Derefter skal du genopbygge den aktuelle debug-version af koden ved at indtaste

$ ./waf

Nu, hvis du kører programmet hello-simulator, skal du se det forventede resultat.

3.6.1 Kommandolinjeargumenter

For at videregive kommandolinjeargumenter til ns‑3-programmet, brug følgende skabelon:

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

Erstat med navnet på dit program og med argumenterne. Argumentet - -command-template for Waf er dybest set en opskrift til at opbygge den faktiske kommandolinje Waf der bruges til at udføre programmet. Waf kontrollerer, at bygningen er afsluttet, sætter stier til den delte bibliotek, og ved at bruge den angivne kommandolinjeskabelon og indsætte programmets navn i stedet for pladsholderen %s, kalder den eksekverbare fil. Hvis denne syntaks virker kompliceret, er der en enklere mulighed, som inkluderer ns‑3-programmet og dets argumenter indkapslet i enkle citationstegn:

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

Et andet, særligt nyttigt eksempel er selektiv kørsel af testsæt. Lad os antage, at der er et testsæt (suite) mytest (som ikke findes i virkeligheden). Ovenfor brugte vi scriptet .\/test.py til parallelt at køre en række tests, der gentagne gange kalder testprogrammet test-runner. Opkald test-runner direkte for at udføre en test:

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

Argumenterne vil blive givet til programmet test-runner. Da mytest ikke findes, vil der blive genereret en fejlmeddelelse. For at udskrive de tilgængelige parametre for test-runner skriv:

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

3.6.2 Fejlretning

For at køre ns-3 programmer under et andet værktøj, som en debugger (for eksempel gdb) eller et hukommelseskontrolværktøj (for eksempel valgrind), brug et lignende format - -command-template = "…". For eksempel for at køre din program hello-simulator ns-3 med argumenterne: gdb $ ./waf --run=hello-simulator --command-template="gdb %s --args "

Bemærk, at navnet på ns-3 programmet kommer med argumentet

, og styringsværktøjet (her - -run) er den første token i argumentet gdb- -args - -command-template. Muligheden , så resten af kommandolinjen tilhører "den lavere" program. (Nogle versioner rapporterer gdbforstår ikke mulighederne gdb . I så fald fjern argumenterne fra programmet , så resten af kommandolinjen tilhører "den lavere" program. (Nogle versionerog brug en kommandosætning - -command-template .) Vi kan kombinere denne opskrift og den forrige for at køre testen under debuggeren: gdb args$ ./waf --run test-runner --command-template="gdb %s --args --suite=mytest --verbose"

Waf skal køres fra sin placering i toppen af ns-3 træet. Denne mappe bliver arbejdsmappen, hvor outputfilerne vil blive skrevet. Men hvad skal man gøre, hvis du ønsker at gemme disse filer uden for ns-3 kildekoden? Brug argumentet

3.6.3 Arbejdsmappe

- -cwd $ ./waf --cwd=...:

Måske ville det være lettere for dig at få outputfilerne i din arbejdsmappen. I så fald kan et indirekte skridt hjælpe:

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

Denne dekoration af den tidligere versions kommando bevarer den aktuelle arbejdsmappen, skifter til mappen

, og instruerer derefter Waftil at ændre arbejdsmappen tilbage til den gemte før programmet køres fra den aktuelle arbejdsmappen. Vi nævner kommandoen Waf for at være grundige, de fleste brugere kører bare Waf fra topmappen og genererer outputfiler der. $ ./waf --cwd=... Fortsættelse: kapitel 4

🥇 Tutorial om ns-3 netværkssimulator. Kapitel 3 | ProHoster

Kilde: habr.com