Handledning för ns-3 nätverkssimulator. Kapitel 3

kapitel 1,2

3 Komma igång
3.1 Översikt
3.2 Förutsättningar
3.2.1 Ladda ner ns-3-versionen som ett källarkiv
3.3 Ladda ner ns-3 med Git
3.3.1 Ladda ns-3 med Bake
3.4 Montering ns-3
3.4.1 Bygga med build.py
3.4.2 Bygga med bakning
3.4.3 Bygg med Waf
3.5 Testa ns-3
3.6 Köra skriptet
3.6.1 Kommandoradsargument
3.6.2 Felsökning
3.6.3 Arbetskatalog

Kapitel 3

Komma igång

Detta kapitel är avsett att förbereda läsaren för att börja med en dator som kanske aldrig har installerat ns-3. Den täcker plattformar som stöds, förutsättningar, hur man skaffar ns-3, hur man bygger ns-3 och hur man testar sin konstruktion och kör enkla program.

3.1 Översikt

ns-3-simulatorn är byggd som ett system av samarbetande programvarubibliotek. Under monteringen länkas användarprogrammens kod till dessa bibliotek. Programmeringsspråken C++ eller Python används för att skriva anpassade program.

Ns-3 distribueras som källkod, vilket innebär att målsystemet måste ha en mjukvaruutvecklingsmiljö för att först bygga biblioteken och sedan bygga användarprogrammet. I princip skulle ns-3 kunna distribueras som färdiga bibliotek för ett specifikt system, och i framtiden kan de distribueras på detta sätt. Men nuförtiden gör många användare faktiskt sitt arbete genom att redigera själva ns-3, så det är användbart att ha källkoden för att bygga biblioteken. Om någon skulle vilja ta sig an arbetet med att skapa färdiga bibliotek och paket för operativsystem, vänligen kontakta e-postlistan ns-utvecklare.

Därefter ska vi titta på tre sätt att ladda ner och bygga ns-3. Den första är att ladda ner och bygga den officiella versionen från huvudsidan. Det andra är valet och sammansättningen av kopior av utvecklingsversioner av den grundläggande ns-3-installationen. Den tredje är att använda ytterligare byggverktyg för att ladda fler tillägg för ns-3. Vi kommer att gå igenom var och en eftersom verktygen är lite olika.

Erfarna Linux-användare kanske undrar varför ns-3 inte tillhandahålls som ett paket som de flesta andra bibliotek som använder en pakethanterare? Även om det finns binära paket för olika Linux-distributioner (t.ex. Debian), slutar de flesta användare med att redigera biblioteken och måste bygga om ns-3 själva, så att ha källkoden tillgänglig är praktiskt. Av denna anledning kommer vi att fokusera på att installera från källan.

För de flesta applikationer ns-3 rättigheter rot inte behövs, det rekommenderas att använda ett oprivilegierat användarkonto.

3.2 Förutsättningar

Hela uppsättningen tillgängliga ns-3-bibliotek har ett antal beroenden av tredjepartsbibliotek, men för det mesta kan ns-3 byggas och användas med stöd för flera vanliga (ofta installerade som standard) komponenter: en C++-kompilator, Python, en källkodsredigerare (till exempel, vim, emacs eller Eclipse) och, om utvecklingsförråd används, Git versionskontrollsystem. De flesta förstagångsanvändare behöver inte oroa sig om deras konfiguration rapporterar att vissa ns-3 avancerade funktioner saknas, men för de som vill ha en fullständig installation tillhandahåller projektet en wiki som innehåller sidor med massor av användbara tips och tricks. En sådan sida är installationssidan, med installationsinstruktioner för olika system, tillgänglig på: https://www.nsnam.org/wiki/Installation.

Avsnittet Förutsättningar i denna wiki förklarar vilka paket som krävs för att stödja vanliga ns-3-alternativ och tillhandahåller även kommandona som används för att installera dem på vanliga varianter av Linux eller macOS.

Du kan dra nytta av denna möjlighet att utforska ns-3 wiki-sidan eller huvudwebbplatsen: https://www.nsnam.org, eftersom det finns mycket information där. Från och med den senaste versionen av ns-3 (ns-3.29), krävs följande verktyg för att köra ns-3:

Verktygspaket/version

• C++ kompilator
  clang++ eller g++ (g++ version 4.9 eller senare)
• Python
  python2 version >= 2.7.10, eller python3 version >=3.4
• gå
  valfri senaste version (för att komma åt ns-3 på GitLab.com)
• tjära
  valfri senaste version (för uppackning av ns-3-versionen)
• bunzip2
  någon senaste version (för uppackning av ns-3-versionen)

För att kontrollera standardversionen av Python, skriv python -V. För att kontrollera g++-versionen, skriv g++ -v. Om några verktyg saknas eller är för gamla, se installationsguiden på ns-3 wiki-sidan.

Från och med nu antar vi att läsaren kör Linux, MacOS eller en Linux-emulator och har åtminstone ovanstående verktyg.

3.2.1 Ladda ner ns-3-versionen som ett källarkiv

Detta är tillvägagångssättet för en ny användare som vill ladda ner och experimentera med den senaste utgåvan och paketversionerna av ns-3. ns-3-utgåvor publiceras som komprimerade källarkiv, ibland kallade tarball. tarball är ett speciellt programvaruarkivformat där flera filer kombineras. Arkivet är vanligtvis komprimerat. ns-3 startprocess via tarball är enkelt, du behöver bara välja en version, ladda ner och packa upp den.

Låt oss anta att du som användare vill bygga ns-3 i en lokal katalog som heter arbetsyta. Du kan få en arbetskopia av utgåvan genom att ange följande i Linux-konsolen (byta ut lämpliga versionsnummer, naturligtvis)

$ 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 

Var uppmärksam på verktyget som används ovan wget, som är ett kommandoradsverktyg för att ladda ner objekt från Internet. Om du inte har installerat det kan du använda din webbläsare för detta.

Om du följer dessa steg kommer du till katalogen ns-allinone-3.29, där bör du se flera filer och 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 är nu redo att bygga ns-3 basdistribution och kan gå vidare till avsnittet om att bygga ns-3.

3.3 Ladda ner ns-3 med Git

ns-3-koden är tillgänglig i Git-arkiven på GitLab.com på https://gitlab.com/nsnam/. Grupp nsnam samlar de olika arkiven som används av ett projekt med öppen källkod.

Det enklaste sättet att börja använda Git-repositories är att klona eller klona miljön ns-3-allinon. Detta är en uppsättning skript som hanterar laddning och montering av de vanligaste ns-3-undersystemen. Om du är ny på Git kan termerna "gaffel" och "klona" vara obekanta för dig; i så fall rekommenderar vi att du helt enkelt klonar (gör din egen kopia) förvaret som finns på GitLab.com så här:

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

I detta skede, vyn av din katalog ns-3-allinon något annorlunda än utgivningsarkivkatalogen som beskrivs ovan. Det borde se ut ungefär så här:

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

Observera att det finns ett manus download.py, som dessutom extraherar ns-3 och tillhörande källkod. Här har du ett val: antingen ladda ner den senaste ns-3 utvecklingsbilden:

$ python download.py

eller föredrar ns-3 releasen med flaggan -n för att ange releasenummer:

$ python download.py -n ns-3.29

Efter detta steg till katalogen ns-3-allinon ytterligare förråd kommer att laddas ner ns-3, baka, pybindgen и netanim.

Notera
På en maskin med ren Ubuntu16.04 behövde jag ändra kommandot till detta: $ sudo python3 download.py -n ns-3.29 (nedan översättarens anteckningar).

3.3.1 Ladda ns-3 med Bake

Ovanstående två metoder (källarkiv eller arkiv ns-3-allinon via Git) är användbara för att få den enklaste ns-3-installationen med flera tillägg(pybindgen för att generera Python-bindningar och netanim för nätverksanimering). Det tredje förvaret som tillhandahålls som standard i ns-3-allinone anropas baka.

Baka är ett verktyg för samordnad uppbyggnad av mjukvara från flera repositories, utvecklat för ns-3-projektet. Baka kan användas för att erhålla utvecklingsversioner av ns-3, samt för att ladda ner och bygga tillägg av basversionen av ns-3-distributionen, såsom miljön Direkt kodexekvering, CradleNetwork Simulation Cradle, möjligheten att skapa nya Python-bindningar och olika ns-3 "appar".

Notera
CradleNetwork Simulation Cradle är ett ramverk som låter dig använda riktiga TCP/IP-nätverksstackar i en nätverkssimulator.

Om du förväntar dig att din ns-3-installation har avancerade eller ytterligare funktioner kan du följa den här installationsvägen.

I de senaste ns-3-utgåvorna Baka lades till tjäravgivningen. Utgåvan innehåller en konfigurationsfil som låter dig ladda ner de aktuella programvaruversionerna vid tidpunkten för utgivningen. Det är till exempel versionen Baka, som distribueras med release ns-3.29, kan användas för att hämta komponenter för den versionen av ns-3 eller tidigare, men kan inte användas för att hämta komponenter för senare versioner (om paketbeskrivningsfilen bakeconf.xml inte uppdaterad).

Du kan också få det senaste exemplaret bakagenom att ange följande kommando i din Linux-konsol (förutsatt att du har Git installerat):

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

När du kör git-kommandot bör du se något i stil med följande:

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.

När kommandot är klart klona du bör ha en katalog som heter baka, vars innehåll bör se ut ungefär så här:

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

Observera att du har laddat flera Python-skript, en Python-modul som heter baka och en XML-konfigurationsfil. Nästa steg är att använda dessa skript för att ladda ner och bygga den ns-3-distribution du väljer. Flera anpassningsmål är tillgängliga:

1. ns-3.29: modul som motsvarar releasen; det kommer att ladda ner komponenter som liknar utgåvan i tarballen;

2. ns-3-dev: en liknande modul, men med kod från utvecklingsträdet;

3. ns-allinon-3.29: En modul som innehåller andra ytterligare funktioner som klickrouting och Network Simulation Cradle, Openflow för ns-3.

4. ns-3-allinon: liknande versionen av modulen allinone, men för utvecklingskod.

Notera
Klicka — Modulär mjukvaruarkitektur för att skapa routrar.

Openflow är ett protokoll för att hantera processen att bearbeta data som överförs över ett datanätverk av routrar och switchar, som implementerar mjukvarudefinierad nätverksteknik.

Den aktuella utvecklingsögonblicksbilden (icke-release) ns-3 finns på:https://gitlab.com/nsnam/ns-3-dev.git.

Utvecklarna försöker hålla dessa förråd i ett konsekvent fungerande skick, men de finns i utvecklingsområdet och innehåller kod som inte har släppts, så om du inte planerar att använda nya funktioner, välj sedan den officiella utgåvan.

Du kan hitta den senaste versionen av koden genom att bläddra i listan över arkiv eller genom att gå till ns-3 Releases webbsida:https://www.nsnam.org/releases/ och klicka på den senaste versionslänken. I det här exemplet fortsätter vi med ns-3.29.

Nu, för att få de ns-3-komponenter vi behöver, använder vi verktyget Baka. Låt oss säga några inledande ord om arbetet Baka.

Bake fungerar genom att ladda paketkällor i en katalog källa och installera biblioteken i build-katalogen. Baka kan köras genom att referera till binären, men om du vill köra Baka inte från katalogen där den laddades ner, det är lämpligt att lägga till sökvägen till baka till din sökväg (PATH miljövariabel), till exempel enligt följande (exempel för Linux bash-skal). Gå till katalogen "bake" och ställ sedan in följande miljövariabler:

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

Detta kommer att placera programmet bake.py till skalsökvägen och kommer att tillåta andra program att hitta de körbara filerna och biblioteken som den skapade baka. I vissa användningsfall baka, inställningen PATH och PYTHONPATH som beskrivs ovan krävs inte, men en komplett version av ns-3-allinone (med ytterligare paket) kräver det vanligtvis.

Gå till din arbetskatalog och skriv in följande i konsolen:

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

Nästa kommer vi att fråga Baka kontrollera om vi har tillräckligt med verktyg för att ladda de olika komponenterna. Ringa:

$ ./bake.py check

Du bör se något i stil med följande:

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

I synnerhet är uppladdningsverktyg som Mercurial, CVS, Git och Bazaar viktiga i detta steg eftersom de tillåter oss att få koden. Installera nu de saknade verktygen på det vanliga sättet för ditt system (om du vet hur) eller kontakta din systemadministratör för hjälp.

Prova sedan att ladda ner programvaran:

$ ./bake.py download

resultatet borde bli något i stil med:

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

Detta kommer att innebära att tre källor har laddats ner. Gå nu till källkatalogen och skriv ls; Du borde se:

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

Nu är du redo att bygga ns-3-distributionen.

3.4 Montering ns-3

Precis som med att ladda ner ns-3 finns det flera sätt att bygga ns-3. Det viktigaste vi vill betona är att ns-3 är byggd med ett byggverktyg som heter WAFbeskrivet nedan. De flesta användare kommer att arbeta med WAF, men det finns några praktiska skript som hjälper dig att komma igång eller organisera mer komplexa byggen. Så snälla, innan du läser om WAF, ta en titt på build.py och montering med baka.

3.4.1 Bygga med build.py

Varning! Det här byggsteget är endast tillgängligt från källarkivversionen som erhålls enligt beskrivningen ovan; och inte laddas ner via git eller bake.

När man arbetar med ett releasearkiv tarballI ns-3-allinon Det finns ett praktiskt skript som kan göra det enklare att montera komponenterna. Det heter build.py. Detta program kommer att skapa projektet åt dig på det mest användbara sättet. Observera dock att mer avancerad installation och arbete med ns-3 vanligtvis innebär att man använder ns-3:s eget byggsystem, Waf, som kommer att introduceras senare i denna handledning.

Om du laddade ner med tarball, sedan i din katalog ~/arbetsyta en katalog med ett namn ungefär ns-allinon-3.29. Skriv följande:

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

När du ringer build.py Vi använde kommandoradsargument för att bygga de exempel och tester som används i denna handledning, som inte är byggda som standard i ns-3. Som standard bygger programmet också alla tillgängliga moduler. Sedan kan du, om du vill, bygga ns-3 utan exempel och tester, eller exkludera moduler som inte behövs för ditt arbete.

Du kommer att se många kompilatorutdatameddelanden som visas av skriptet när det bygger de olika delarna du har laddat. Först kommer manuset att försöka bygga animatören netanim, sedan bindningsgeneratorn pybindgen och slutligen ns-3. När processen är klar bör du se följande:

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

På de sista tre raderna i listan ser vi ett meddelande om moduler som inte byggdes:

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

Detta betyder helt enkelt att vissa ns-3-moduler som är beroende av externa bibliotek kanske inte har byggts, eller att de inte behöver byggas för denna konfiguration. Detta betyder inte att simulatorn inte är monterad eller att de monterade modulerna inte kommer att fungera korrekt.

3.4.2 Bygga med bakning

Om du använde bake ovan för att hämta källkod från projektförråden, kan du fortsätta att använda den för att bygga ns-3. Ringa:

$ ./bake.py build

och du borde se något i stil med:

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

prompt: Du kan också göra både nedladdnings- och byggstegen på en gång genom att anropa "bake.py deploy".

Montering av alla komponenter kan misslyckas, men monteringen kommer att fortsätta om en komponent inte krävs. Till exempel var ett problem med portabilitet nyligen det castxml kan monteras med verktyg baka inte på alla plattformar. I det här fallet kommer ett meddelande som detta att visas:

>> 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 behövs bara om du vill skapa uppdaterade Python-bindningar. För de flesta användare finns det inget behov av detta (åtminstone tills de ändrar ns-3), så sådana varningar kan säkert ignoreras för tillfället.

Om det misslyckas kommer följande kommando att ge dig en ledtråd om saknade beroenden:

$ ./bake.py show

De olika beroenden för paketen du försöker bygga kommer att listas.

3.4.3 Bygg med Waf

Fram till denna punkt, för att börja bygga ns-3, använde vi antingen skriptet build.py, eller verktyg baka. Dessa verktyg är användbara för att bygga ns-3 och underhålla bibliotek. Faktum är att de kör byggverktyget för att bygga WAF från katalogen ns-3. WAF installerad med ns-3 källkoden. De flesta användare går snabbt vidare till direkt användning för att konfigurera och montera ns-3 WAF. Så för att fortsätta, gå till ns-3-katalogen som du ursprungligen skapade.

Detta är inte strikt nödvändigt för närvarande, men det kommer att vara användbart att backa lite och se hur man gör ändringar i projektkonfigurationen. Den förmodligen mest användbara konfigurationsändringen du kan göra är att skapa en optimerad version av koden. Som standard har du konfigurerat ditt projekt för att bygga en felsökningsversion. Låt oss titta på ett projekt för att skapa en optimerad sammansättning. För att förklara för Waf att det ska göra optimerade builds som inkluderar exempel och tester, måste du köra följande kommandon:

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

Detta kommer att starta WAF utanför den lokala katalogen (för din bekvämlighet). Det första kommandot rensar upp från det tidigare bygget, detta är vanligtvis inte strikt nödvändigt, men det är god praxis (se även byggprofiler nedan); detta tar bort tidigare skapade bibliotek och objektfiler som finns i katalogen bygga/. När projektet är omkonfigurerat och byggsystemet kontrollerar de olika beroenden, bör du se utdata som liknar följande:

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)

Observera den sista delen av listan ovan. Vissa ns-3-alternativ är inte aktiverade som standard eller kräver systemstöd för att fungera korrekt. Till exempel, för att aktivera XmlTo, måste biblioteket finnas på systemet libxml-2.0. Om det här biblioteket inte hittades och motsvarande ns-3-funktion inte var aktiverad, kommer ett meddelande att visas. Observera också att det är möjligt att använda kommandot sudo för att ställa in suid-biten "ställ in grupp-ID vid körning" för vissa program. Den är inte aktiverad som standard och därför visas den här funktionen som "ej aktiverad". Slutligen, för att få en lista över aktiverade alternativ, använd WAF med parameter --check-config.

Låt oss nu gå tillbaka och byta tillbaka till felsökningsbygget som innehåller exemplen och testerna.

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

Byggsystemet är nu konfigurerat och du kan bygga felsökningsversioner av ns-3-program genom att helt enkelt skriva:

$ ./waf

Stegen ovan kan ha tvingat dig att bygga en del av ns-3-systemet två gånger, men nu vet du hur du ändrar konfigurationen och bygger optimerad kod.

För att kontrollera vilken profil som är aktiv för en given projektkonfiguration finns ett kommando:

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

Ovanstående scenario build.py stödjer också argument --enable-examples и --enable-tests, men andra alternativ WAF den stöder inte direkt. Detta kommer till exempel inte att fungera:

$ ./build.py --disable-python

reaktionen blir så här:

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

Den speciella operatören - - kan dock användas för att skicka ytterligare parametrar via WAFså istället för ovanstående kommer följande kommando att fungera:

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

eftersom det genererar huvudkommandot ./waf configure --disable-python. Här är några fler inledande tips om WAF.

Hantera byggfel

ns-3-utgåvor testas på de senaste C++-kompilatorerna som är tillgängliga vid tidpunkten för utgivningen på vanliga Linux- och MacOS-distributioner. Men med tiden släpps nya distributioner med nya kompilatorer, och dessa nyare kompilatorer tenderar att vara mer pedantiska när det gäller varningar. ns-3 konfigurerar sin build för att behandla alla varningar som fel, så ibland om du kör en äldre version på ett nyare system kan en kompilatorvarning stoppa bygget.

Till exempel fanns det tidigare en utgåva av ns-3.28 för Fedora 28, som inkluderade en ny huvudversion gcc (GCC-8). När du bygger utgåvan ns-3.28 eller tidigare versioner under Fedora 28, med Gtk2+ installerat, kommer följande fel att uppstå:

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

I utgåvor från ns-3.28.1, in WAF ett alternativ finns tillgängligt för att lösa dessa problem. Det inaktiverar inställning av "-Werror"-flaggan i g++ och clang++. Detta är alternativet "--disable-werror" och måste tillämpas under konfigurationen:

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

Konfigurera eller montera

Några kommandon WAF har betydelse endast i konfigurationsfasen, och vissa är endast giltiga i byggfasen. Om du till exempel vill använda ns-3-emuleringsfunktionerna kan du aktivera bitinställningen suid använder sig av sudo, som beskrivits ovan. Detta kommer att åsidosätta konfigurationsstegets kommandon, och därför kan du ändra konfigurationen med följande kommando, som också inkluderar exempel och tester.

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

Om du gör detta WAF kommer att starta sudoför att ändra program för att skapa socket för emuleringskod så att de körs med behörigheter rot. I WAF Det finns många andra alternativ tillgängliga för konfigurations- och byggstegen. För att utforska dina alternativ, skriv in:

$ ./waf --help

I nästa avsnitt kommer vi att använda några testrelaterade alternativ.

Monteringsprofiler

Vi har redan sett hur du kan konfigurera WAF för sammansättningar felsöka и optimerad:

$ ./waf --build-profile=debug

Det finns också en mellanliggande monteringsprofil, frigöra. Alternativ -d är en synonym --build-profile. Byggprofilen styr användningen av växlar för loggning, påståenden och kompilatoroptimering:

Som du kan se är loggning och påståenden endast tillgängliga i felsökningsbyggen. Rekommenderad praxis är att utveckla ditt skript i felsökningsläge och sedan utföra upprepade körningar (för statistik eller parameterändringar) i en optimerad byggprofil.

Om du har kod som bara ska köras i vissa byggprofiler, använd kodinpackningsmakrot:

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;)

Standard, WAF placerar byggartefakter i byggkatalogen. Du kan ange en annan utdatakatalog med alternativet - -out, till exempel:

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

Genom att kombinera detta med byggprofiler kan du enkelt växla mellan olika kompileringsalternativ:

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

Vilket gör att du kan arbeta med flera sammansättningar utan att behöva skriva om den senaste sammansättningen varje gång. När du byter till en annan profil, WAF kommer bara att kompilera det, utan att helt kompilera om allt.

När du byter byggprofiler på detta sätt måste du vara noga med att ge samma konfigurationsalternativ varje gång. Att definiera flera miljövariabler hjälper dig att undvika misstag:

$ 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 och flaggor

I exemplen ovan WAF för att bygga ns-3 använder man C++ kompilatorn från GCC ( g ++). Du kan dock ändra den du använder WAF C++-kompilator, genom att definiera miljövariabeln CXX. Till exempel, för att använda C++-kompilatorn Clang, clang++,

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

På samma sätt kan du konfigurera WAF att använda distribuerad kompilering med hjälp av distcc:

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

Mer information om distcc och distribuerad sammanställning finns på projektsidan i avsnittet Dokumentation. För att lägga till kompilatorflaggor när du konfigurerar ns-3, använd miljövariabeln CXXFLAGS_EXTRA.

Installation

WAF kan användas för att installera bibliotek på olika platser i systemet. Som standard finns de kompilerade biblioteken och körbara filerna i katalogen SLUTRESULTAT, och eftersom Waf känner till var dessa bibliotek och körbara filer finns finns det inget behov av att installera biblioteken någon annanstans.

Om användare föredrar att installera utanför byggkatalogen kan de köra kommandot ./waf installera. Standardprefixet för installation är / Usr / localSå ./waf installera kommer att installera program i / Usr / local / bin, bibliotek i / Usr / local / lib och header-filer i /usr/local/include. Superanvändarrättigheter behöver vanligtvis ställas in med ett standardprefix, så ett typiskt kommando skulle vara det sudo ./waf installera. När Waf lanseras kommer Waf först att välja att använda de delade biblioteken i build-katalogen och sedan leta efter bibliotek längs vägen till biblioteken som är konfigurerade i den lokala miljön. Så när du installerar bibliotek på ett system är det en god praxis att kontrollera att rätt bibliotek används. Användare kan välja att installera med ett annat prefix genom att skicka alternativet under konfigurationen --prefix, till exempel:

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

Om användaren senare, efter bygget, anger installationskommandot ./waf, kommer prefixet att användas /opt/local.

Team ./waf clean måste användas innan du konfigurerar om projektet om installationen kommer att använda WAF under ett annat prefix.

För att använda ns-3 behöver du alltså inte ringa ./waf install. De flesta användare behöver inte detta kommando eftersom WAF hämtar de aktuella biblioteken från build-katalogen, men vissa användare kan tycka att detta är användbart om deras aktiviteter involverar att arbeta med program utanför ns-3-katalogen.

Waf singel

På den översta nivån i ns-3-källträdet finns det bara ett Waf-skript. När du väl börjar arbeta kommer du att spendera mycket tid i katalogen scratch/ eller djupare insrc/... och samtidigt måste springa WAF. Du kan bara komma ihåg var du är och springa WAF enligt följande:

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

men detta kommer att vara tråkigt och felbenäget, så det finns bättre lösningar. Ett vanligt sätt är att använda en textredigerare som t.ex emacs eller vim, där två terminalsessioner öppnas, en används för att bygga ns-3, och den andra används för att redigera källkoden. Om du bara har tarball, då kan en miljövariabel hjälpa:

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

$ cd scratch 
$ waff build

I modulkatalogen kan det vara frestande att lägga till ett trivialt waf-skript som exec ../../waf. Snälla gör inte det. Detta är förvirrande för nybörjare och, när det görs dåligt, leder det till svårupptäckta byggfel. Lösningarna som visas ovan är den väg som bör användas.

3.5 Testa ns-3

Du kan köra ns-3-distributionens enhetstester genom att köra skriptet ./test.py:

$ ./test.py

Dessa tester körs parallellt med WAF. Så småningom bör du se ett meddelande som säger:

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

Detta är ett viktigt meddelande för att identifiera valgrind-krascher, krascher eller fel, vilket indikerar problem med koden eller inkompatibilitet mellan verktyg och kod.

Du kommer också att se den slutliga utgången från WAF och en testare som kör varje test, som kommer att se ut ungefär så här:

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)

Detta kommando körs vanligtvis av användare för att snabbt verifiera att ns-3-distributionen är korrekt byggd. (Observera att ordningen på "PASS: ..."-raderna kan vara annorlunda, detta är normalt. Det viktiga är att sammanfattningsraden i slutet av rapporten visar att alla tester godkänts; inga tester misslyckades eller kraschade.) Och WAFOch test.py kommer att parallellisera arbetet över maskinens tillgängliga processorkärnor.

3.6 Köra skriptet

Vi brukar köra skript under kontroll WAF. Detta gör att byggsystemet kan säkerställa att delade biblioteksvägar är korrekt inställda och att biblioteken är tillgängliga under körning. För att köra programmet, använd helt enkelt WAF med parameter - -run. Låt oss köra ns-3-motsvarigheten till det allestädes närvarande programmet hallå världengenom att skriva följande:

$ ./waf --run hello-simulator

Waf kommer först att kontrollera att programmet är korrekt byggt och bygga om det behövs. Sedan WAF kommer att köra ett program som producerar följande utdata.

Hello Simulator

Grattis! Du är nu en ns-3 användare!

Vad ska jag göra om jag inte ser resultat?

Om du ser meddelanden WAFindikerar att byggnaden slutfördes framgångsrikt, men du ser inte utdata "Hej Simulator", då finns det en möjlighet att du ändrade ditt byggläge i avsnittet [Bygg-med-Waf] optimerad, men missade att byta tillbaka till läget felsöka. All konsolutdata som används i denna handledning använder en speciell ns-3-komponent som utför loggning och används för att skriva ut anpassade meddelanden till konsolen. Utdata från denna komponent inaktiveras automatiskt när optimerad kod kompileras - den är "optimerad". Om du inte ser "Hello Simulator"-utgången anger du följande:

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

att konfigurera WAF att bygga felsökningsversioner av ns-3-program, som inkluderar exempel och tester. Du bör sedan bygga om den aktuella felsökningsversionen av koden genom att skriva

$ ./waf

Nu om du kör programmet hej-simulator, bör du se det förväntade resultatet.

3.6.1 Kommandoradsargument

För att skicka kommandoradsargument till ns-3-programmet, använd följande mönster:

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

Byta ut till namnet på ditt program och till argumenten. Argument - -command-template för WAF är i huvudsak ett recept för att bygga den faktiska kommandoraden WAF används för att köra programmet. Waf kontrollerar att konstruktionen är klar, ställer in de delade biblioteksvägarna, använder sedan den medföljande kommandoradsmallen och ersätter programnamnet för %s platshållaren för att anropa den körbara filen. Om du tycker att den här syntaxen är komplicerad finns det en enklare version som involverar programmet ns-3 och dess argument omslutna av enkla citattecken:

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

Ett annat särskilt användbart exempel är att köra testsviter selektivt. Låt oss anta att det finns en testsvit som heter mytest (det finns det faktiskt inte). Ovan använde vi ./test.py-skriptet för att köra ett antal tester parallellt, vilket upprepade gånger anropar testprogrammet testlöpare. Ring upp testlöpare direkt för att köra ett test:

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

Argument kommer att skickas till programmet testlöpare. Eftersom mytest inte existerar kommer ett felmeddelande att genereras. För att skriva ut de tillgängliga testkörningsalternativen anger du:

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

3.6.2 Felsökning

För att köra ns-3-program under ett annat verktyg, till exempel en debugger (t.ex. gdb) eller ett minnestestverktyg (t.ex. valgrind), använd en liknande form - -command-template = "…". Till exempel att köra i felsökaren gdb ditt hello-simulator ns-3-program med argument:

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

Observera att ns-3-programnamnet kommer med argumentet - -run, och hanteringsverktyget (här gdb) är den första symbolen i argumentet - -command-template. Alternativ - -args rapporter gdbatt resten av kommandoraden tillhör det "lägre" programmet. (Vissa versioner gdb förstår inte alternativet - -args. Ta i så fall bort programargumenten från - -command-template och använd kommandouppsättningen gdb argumenterar.) Vi kan kombinera detta recept och det föregående för att köra testet under felsökaren:

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

3.6.3 Arbetskatalog

Waf bör avfyras från sin plats i toppen av ns-3-trädet. Den här mappen blir arbetskatalogen där utdatafilerna kommer att skrivas. Men vad händer om du vill hålla dessa filer utanför ns-3 källträdet? Använd argument - -cwd:

$ ./waf --cwd=...

Du kanske tycker att det är bekvämare att få utdatafilerna i din arbetskatalog. I det här fallet kan följande indirekta åtgärd hjälpa:

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

Denna dekoration av den tidigare versionen av kommandot bevarar den nuvarande arbetskatalogen, går till katalogen WAFoch instruerar sedan WAF för att ändra arbetskatalogen tillbaka till den aktuella arbetskatalogen som sparats innan programmet startas. Vi nämner laget - -cwd För fullständighetens skull kör de flesta användare helt enkelt Waf från toppnivåkatalogen och genererar utdatafiler där.

Fortsättning: Kapitel 4

Källa: will.com