Handbok för nätverkssimulatorn ns-3. Kapitel 3

kapitel 1,2

3 Börja arbeta
3.1 Översikt
3.2 Förutsättningar
3.2.1 Ladda ner ns-3 som ett källkodsarkiv
3.3 Ladda ner ns-3 med Git
3.3.1 Ladda ner ns-3 med Bake
3.4 Bygga ns-3
3.4.1 Bygga med build.py
3.4.2 Bygga med Bake
3.4.3 Bygga med Waf
3.5 Testa ns-3
3.6 Köra skript
3.6.1 Kommandoradsargument
3.6.2 Felsökning
3.6.3 Arbetskatalog

Kapitel 3

Börja arbeta

Detta kapitel syftar till att förbereda läsaren för arbete, med en dator där ns-3 kanske aldrig tidigare har installerats. Presentationen täcker stödda plattformar, förutsättningar, sätt att få ns-3, sätt att bygga ns-3 och sätt att kontrollera din byggnad och köra enkla program.

3.1 Översikt

ns-3-simulatorn är konstruerad som ett system av samarbetande programbibliotek. Vid byggande länkas koden för användarprogram med dessa bibliotek. För att skriva användarprogram används programmeringsspråken C++ eller Python.

ns-3 distribueras som källkod, vilket innebär att målsystemet måste ha en programvaruutvecklingsmiljö för att först bygga biblioteken och sedan bygga användarprogrammet. I princip kan ns-3 distribueras som färdiga bibliotek för specifika system, och i framtiden kan de distribueras på det sättet. Men för närvarande utför många användare faktiskt sitt arbete genom att redigera själva ns-3, så det är bra att ha källkoden för att bygga biblioteken. Om någon skulle vilja ta på sig jobbet att skapa färdiga bibliotek och paket för operativsystem, vänligen kontakta e-postlistan. ns-developers.

Här kommer vi att 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. Den andra är att välja och bygga kopior av utvecklingsversionerna av grundinstallationen av ns-3. Den tredje är att använda ytterligare byggverktyg för att ladda ner fler tillägg för ns-3. Vi kommer att gå igenom var och en, eftersom verktygen något skiljer sig åt.

Erfarna Linux-användare kan undra varför ns-3 inte erbjuds som ett paket, som de flesta andra bibliotek som använder paketmanagern? Trots att det finns binärpaket för olika Linux-distributioner (t.ex. Debian), slutar de flesta användarna till slut med att redigera biblioteken och måste själva kompilera ns-3, så tillgången till källkoden är bekväm. Av denna anledning kommer vi att fokusera på installation från källkod.

För de flesta tillämpningar behövs inte ns-3-licenser root och det rekommenderas att använda ett icke-privilegerat användarkonto.

3.2 Förutsättningar

Hela uppsättningen av tillgängliga ns-3-bibliotek har en rad beroenden av externa bibliotek, men i de flesta fall kan ns-3 kompileras och användas med stöd för flera vanliga (ofta förinstallerade) komponenter: C++-kompilator, Python, källkodsredigerare (t.ex. vim, emacs eller Eclipse) och, om utvecklingsförråd används, versionshanteringssystemet Git. De flesta nybörjare behöver inte bekymra sig om deras konfiguration rapporterar några saknade extra funktioner för ns-3, men för dem som önskar en fullständig installation erbjuder projektet en wiki som inkluderar sidor med många användbara tips och råd. En sådan sida är "Installations"-sidan med installationsinstruktioner för olika system, tillgängliga på: https://www.nsnam.org/wiki/Installation.

Avsnittet "Förutsättningar" på denna wiki-sida förklarar vilka paket som krävs för att stödja allmänna ns-3-alternativ, och ger även kommandon som används för att installera dem i vanliga Linux- eller macOS-varianter.

Du kan dra nytta av möjligheten att utforska ns-3:s wiki-sida eller den huvudsakliga webbplatsen: 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:

Verktyg Paket/version

• C++-kompilator
  clang++ eller g++ (g++ version 4.9 eller högre)
• Python
  python2 version >= 2.7.10, eller python3 version >=3.4
• Git
  vilken senaste version som helst (för åtkomst till ns-3 på GitLab.com)
• tar
  vilken senaste version som helst (för att packa upp ns-3-release)
• bunzip2
  vilken senaste version som helst (för att packa upp ns-3-release)

För att kontrollera den standardinstallerade versionen av Python, skriv python -VFör att kontrollera versionen av g++, skriv g++ -v. Om några verktyg saknas eller är för gamla, hänvisa till installationsguiden på ns-3:s wiki-sida.

Från och med nu antar vi att läsaren arbetar i Linux, MacOS eller en Linux-emulator och har minst de ovan nämnda verktygen.

3.2.1 Ladda ner ns-3 som ett källkodsarkiv

Detta är en handlingsplan för en ny användare som vill ladda ner och experimentera med de senaste utgivnings- och paketversionerna av ns-3. Utgåvor av ns-3 publiceras i form av komprimerade källkodspaket, ibland kallade tarball. tarball — ett speciellt format för programarkiv där flera filer sammanfogas. Arkivet är vanligtvis komprimerat. Processen för att ladda ner ns-3 via tarball är enkel; du behöver bara välja en utgåva, ladda ner och packa upp den.

Anta att du som användare vill bygga ns-3 i en lokal katalog som heter workspace. Du kan få en arbetskopia av utgåvan genom att skriva följande i Linux-konsolen (självklart med de korrekta versionsnumren)

$ 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 

Tänk på utilityn som användes ovan, wgetsom ä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.

Genom att följa dessa steg kommer du att gå till katalogen ns-allinone-3.29, där du bör 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

Nu är du redo att bygga basdistributionsversionen av ns-3 och kan gå vidare till avsnittet som handlar om att bygga ns-3.

3.3 Ladda ner ns-3 med Git

Koden för ns-3 finns på Git-repositorier på GitLab.com på adressen https://gitlab.com/nsnam/. Gruppen nsnam samlade olika repositorier som används av det öppna källkodsprojektet.

Det enklaste sättet att börja använda Git-repositorier är att göra en fork eller klona miljön ns-3-allinone. Detta är en samling skript som hanterar nedladdningen och byggandet av de mest använda delsystemen i ns-3. Om du är ny på Git kan termerna "fork" och "kloning" vara okända för dig; om så är fallet rekommenderar vi att du bara klonar (skapar en egen kopia) av lagret som finns på GitLab.com på följande sätt:

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

Vid denna tidpunkt ser din katalog ut så här ns-3-allinone skiljer sig något från den ovan beskrevna katalogen med versionsarkivet. Den ska se ut ungefär så här:

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

Observera att skriptet download.py, som dessutom hämtar ns-3 och den medföljande källkoden. Här har du val: antingen ladda ner den senaste utvecklingssnapshoten av ns-3:

$ python download.py

eller föredra versionen av ns-3, med hjälp av flaggan -n för att ange versionsnumret:

$ python download.py -n ns-3.29

Efter detta steg kommer ytterligare förvar att laddas ner till katalogen ns-3-allinone ns-3 bake, pybindgen, netanim och På en ren Ubuntu16.04-maskin behövde jag ändra kommandot till följande:.

Anmärkning
$ sudo python3 download.py -n ns-3.29 (här och framöver översättarens kommentarer). De två ovan nämnda metoderna (källkodens arkiv eller förvaret

3.3.1 Ladda ner ns-3 med Bake

genom Git) är användbara för att erhålla den enklaste installationen av ns-3 med flera tillägg ( ns-3-allinone för att generera Python-bindningar ochnetanim för att animera nätverket). Det tredje förvaret, som tillhandahålls som standard i ns-3-allinone, kallas På en ren Ubuntu16.04-maskin behövde jag ändra kommandot till följande: Bake pybindgen.

— ett verktyg för samordnad mjukvarubyggnad från flera förvar, utvecklat för ns-3-projektet. kan användas för att få utvecklingsversioner av ns-3, samt för att ladda ner och bygga tillägg för basversionen av ns-3-distributionen, som miljön — ett verktyg för samordnad mjukvarubyggnad från flera förvar, utvecklat för ns-3-projektet. Direct Code Execution CradleNetwork Simulation Cradle, , möjligheten att skapa nya Python-bindningar och olika "appar" av ns-3.CradleNetwork Simulation Cradle är en ramverk som tillåter att använda verkliga nätverksstackar TCP / IP inom nätverkssimulatorn.

Anmärkning
Om du förväntar dig att din installation av ns-3 ska ha avancerade eller extra funktioner kan du följa denna installationsväg.

I de senaste versionerna av ns-3

har det lagts till i tar-versionen. I versionen ingår en konfigurationsfil som möjliggör nedladdning av aktuella programvaruversioner vid tidpunkten för versionens skapande. Det betyder till exempel att versionen — ett verktyg för samordnad mjukvarubyggnad från flera förvar, utvecklat för ns-3-projektet. , som distribueras med versionen ns-3.29, kan användas för att få komponenter för denna version av ns-3 eller tidigare, men kan inte användas för att hämta komponenter för senare versioner (om paketbeskrivningsfilen — ett verktyg för samordnad mjukvarubyggnad från flera förvar, utvecklat för ns-3-projektet.bakeconf.xml inte har uppdaterats). Du kan också få den senaste kopian

, genom att ange följande kommando i din Linux-konsol (förutsatt att du har Git installerat): pybindgen, skriv 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 som liknar följande:

Klonar in i 'bake'...
remote: Uppräkning av objekt: 2086, klart. 
remote: Räkning av objekt: 100% (2086/2086), klart. 
remote: Komprimering av objekt: 100% (649/649), klart. 
remote: Totalt 2086 (delta 1404), återanvända 2078 (delta 1399) 
Mottar objekt: 100% (2086/2086), 2.68 MiB | 3.82 MiB/s, klart. 
Löser deltan: 100% (1404/1404), klart.

När kommandot har slutförts clone ska du ha en katalog med namnet pybindgen, vars innehåll ska 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 ner flera Python-skript, en Python-modul med namnet pybindgen och en konfigurationsfil i XML. Nästa steg blir att använda dessa skript för att ladda ner och bygga den ns-3-distribution du väljer. Det finns flera konfigurationsmål tillgängliga:

1. ns-3.29: en modul som motsvarar en version; den kommer att ladda ner komponenter som liknar versionen i tarball;

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

3. ns-allinone-3.29: en modul som inkluderar andra tilläggsfunktioner, såsom Click-routing och Network Simulation Cradle, Openflow för ns-3.

4. ns-3-allinone: liknande den stabila versionen av modulen allinone, men för utvecklingskoden.

Anmärkning
Click — en modulär programvaruarkitektur för att skapa routrar.

Openflow är en protokoll för hantering av processen för databehandling som passerar genom datanätverk av routrar och switchar, vilket implementerar teknik för programvarukonfigurerade nätverk.

Den aktuella utvecklingssnapshot (icke-releaserad) av ns-3 kan hittas på:https://gitlab.com/nsnam/ns-3-dev.git.

Utvecklarna strävar efter att hålla dessa arkiv i ett sammanhängande arbetsförhållande, men de är under utveckling och innehåller icke-releasad kod, så om du inte planerar att använda nya funktioner bör du välja den officiella releasen.

Du kan hitta den senaste versionen av koden genom att bläddra igenom listan över arkiv, eller genom att besöka webbplatsen för 'ns-3 Releases':https://www.nsnam.org/releases/ och klicka på länken för den senaste versionen. I det här exemplet kommer vi att fortsätta med ns-3.29.

Nu för att få de nödvändiga komponenterna av ns-3, kommer vi att använda verktyget — ett verktyg för samordnad mjukvarubyggnad från flera förvar, utvecklat för ns-3-projektet.. Låt oss säga några inledande ord om hur — ett verktyg för samordnad mjukvarubyggnad från flera förvar, utvecklat för ns-3-projektet..

Bake fungerar, genom att ladda ner källfiler för paketen till katalogen source och installera biblioteken i byggkatalogen. — ett verktyg för samordnad mjukvarubyggnad från flera förvar, utvecklat för ns-3-projektet. kan startas genom att referera till den binära filen, men om du vill köra — ett verktyg för samordnad mjukvarubyggnad från flera förvar, utvecklat för ns-3-projektet. inte från den katalog den laddades upp till, det är önskvärt att lägga till sökvägen till pybindgen din sökväg (miljövariabel PATH), till exempel på följande sätt (exempel för kommandotolk Linux bash). 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 i kommandotolkens sökväg och tillåta andra program att hitta de körbara filer och bibliotek som skapades av pybindgen. I vissa användningsfall pybindgen, den ovan beskrivna installationen av PATH och PYTHONPATH krävs inte, men för en fullständig installation av ns‑3-allinone (med ytterligare paket) är den vanligtvis nödvändig.

Gå till arbetskatalogen och skriv följande i kommandotolken:

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

Sedan kommer vi att be — ett verktyg för samordnad mjukvarubyggnad från flera förvar, utvecklat för ns-3-projektet. att kontrollera om vi har tillräckligt med verktyg för att ladda ner olika komponenter. Skriv:

$ ./bake.py check

Du bör se något liknande 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 
> Sökväg som söks för verktyg: /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin ...

Specifikt är laddningsverktyg som Mercurial, CVS, Git och Bazaar grundläggande i detta steg, eftersom de gör det möjligt för oss att hämta koden. Vid detta stadium installerar du de saknade verktygen på det vanliga sättet för ditt system (om du kan) eller ber om hjälp från din systemadministratör.

Försök sedan ladda ner programvaran:

$ ./bake.py download

resultatet bör vara något i stil med:

>> Söker efter systemberoende setuptools - OK 
>> Söker efter systemberoende libgoocanvas2 - OK 
>> Söker efter systemberoende gi-cairo - OK 
>> Söker efter systemberoende pygobject - OK 
>> Söker efter systemberoende pygraphviz - OK 
>> Söker efter systemberoende python-dev - OK 
>> Söker efter systemberoende qt - OK 
>> Söker efter systemberoende g++ - OK 
>> Laddar ner pybindgen-0.19.0.post4+ng823d8b2 (målkatalog: pybindgen) - OK 
>> Laddar ner netanim-3.108 - OK 
>> Laddar ner ns-3.29 - OK

Detta betyder att tre källkoder har laddats ner. Gå nu till källkatalogen och skriv ls; du bör se:

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

Nu är du redo att bygga distributionen av ns‑3.

3.4 Bygga ns-3

Precis som vid nedladdning av ns‑3 finns det flera sätt att bygga ns‑3. Det viktigaste är att vi vill betona att ns‑3 byggs med ett byggverktyg som kallas Waf, beskrivet nedan. De flesta användare kommer att arbeta med Waf, men det finns flera användbara skript som kan hjälpa dig att komma igång eller organisera mer komplexa byggen. Så, vänligen läs först om Waf, ta en titt på build.py och bygget med pybindgen.

3.4.1 Bygga med build.py

Varning! Detta byggsteg är endast tillgängligt från versionspaketet som erhållits enligt ovan, och inte nedladdat via git eller bake.

Vid arbete med release-paketet tarball, i ns‑3‑allinone finns det ett användbart skript som kan förenkla uppbyggnaden av komponenter. Det heter build.py. Detta program kommer att konfigurera projektet på det mest användbara sättet för dig. Observera dock att mer komplexa konfigurationer och arbete med ns‑3 vanligtvis involverar användning av det egna byggsystemet ns‑3, Waf, som kommer att presenteras senare i denna handbok.

Om du har laddat ner via tarball, bör det finnas en katalog i din mapp ~/workspace med ett namn som är något i stil med ns-allinone-3.29. Skriv följande:

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

Vid anrop av build.py vi tillämpade kommandoradsargument för att bygga de exempel och tester som används i denna handbok, vilka inte byggs som standard i ns‑3. Som standard bygger programmet även alla tillgängliga moduler. Sedan, om du önskar, kan du bygga ns‑3 utan exempel och tester eller utesluta moduler som inte behövs för ditt arbete.

Du kommer att se många utdata från kompileraren som visas av skriptet när det bygger olika delar som du har laddat ner. Först kommer skriptet att försöka bygga animatorn På en ren Ubuntu16.04-maskin behövde jag ändra kommandot till följande:, sedan bindningsgeneratorn netanim 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) 

Built modules:
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 sista tre raderna av listan ser vi ett meddelande om moduler som inte har byggts:

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

Det betyder helt enkelt att vissa ns-3-moduler som är beroende av externa bibliotek kanske inte har kompilerats, eller att deras kompilering inte krävs för den aktuella konfigurationen. Det betyder inte att simulatorn har misslyckats med att byggas eller att de kompilerade modulerna kommer att fungera felaktigt.

3.4.2 Bygga med Bake

Om du använde bake för att hämta källkoden från projektets repositories, kan du fortsätta använda det för att bygga ns-3. Skriv:

$ ./bake.py build

och du bör se något liknande:

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

Tips: du kan också utföra båda stegen, nedladdning och byggande, genom att anropa "bake.py deploy".

Vid byggande av alla komponenter kan det uppstå fel, men byggandet fortsätter om komponenten inte är obligatorisk. Till exempel var ett nyligen problem med portabilitet att castxml kan kompileras med verktyget pybindgen inte på alla plattformar. I så fall kommer ett meddelande som följer:

>> Bygger castxml - Problem 
> Problem: Valfri beroende, modul "castxml" misslyckades
Detta kan minska funktionaliteten i den slutliga byggnaden.
Dock kommer bake att fortsätta eftersom "castxml" inte är en väsentlig beroende.
För mer information, kör bake med -v eller -vvv för fullt detaljerat läge.

Men castxml är endast nödvändig om du vill skapa uppdaterade Python-bindningar. För de flesta användare är detta inte nödvändigt (åtminstone tills de börjar ändra ns-3), så sådana varningar kan för tillfället säkert ignoreras.

Om ett fel inträffar, kommer nästa kommando att ge dig en antydan om saknade beroenden:

$ ./bake.py show

Olika paketberoenden som du försöker bygga kommer att listas.

3.4.3 Bygga med Waf

Vid denna tidpunkt, för att påbörja byggandet av ns-3, har vi använt antingen skriptet build.py, eller verktyget pybindgen. Dessa verktyg är användbara för att bygga ns-3 och hantera biblioteken. Faktiskt kör de byggverktyget Waf från ns-3-katalogen. Waf följer med källkoden för ns-3. De flesta användare går snabbt över till direkt användning av Waf. Så för att fortsätta, vänligen gå till ns-3-katalogen som du först skapade.

För tillfället är detta inte strängt nödvändigt, men det kan vara bra att göra en liten avstickare och titta på hur man gör ändringar i projektkonfigurationen. Troligtvis är det mest användbara ändringen av konfigurationen som du kan göra att skapa en optimerad version av koden. Som standard har du ställt in ditt projekt för att bygga en debug-version. Låt oss titta på projektet för att skapa en optimerad byggning. För att förklara för Waf att det ska göra optimerade byggningar som inkluderar exempel och tester, behöver du köra följande kommandon:

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

Detta kommer att köra Waf utanför den lokala katalogen (för din bekvämlighet). Det första kommandot utför en rengöring av den tidigare byggningen, vilket vanligtvis inte är strängt nödvändigt, men det är en bra praxis (se också byggprofilerna nedan); detta kommer att ta bort tidigare skapade bibliotek och objektfiler som finns i katalogen build/. När projektet har omkonfigurerats och byggsystemet kontrollerar olika beroenden, bör du se en utskrift som liknar följande:

Ställer in top till      : \/home\/ns3user\/workspace\/bake\/source\/ns-3-dev
Ställer ut till      : \/home\/ns3user\/workspace\/bake\/source\/ns-3-dev\/build
Kontrollerar för 'gcc' (C kompilator)        : \/usr\/bin\/gcc 
Kontrollerar för cc-version                : 7.3.0 
Kontrollerar för 'g++' (C++ kompilator)      : \/usr\/bin\/g++ 
Kontrollerar för kompilering flagga -march=native stöd : ok 
Kontrollerar för kompilering flagga -Wl,--soname=foo stöd : ok 
Kontrollerar för kompilering flagga -std=c++11 stöd       : ok 
Kontrollerar boost-includes   : rubriker hittades inte, vänligen,!ange en --boost-includes argument (se hjälp) 
Kontrollerar boost-includes   : rubriker hittades inte, vänligen,!ange en --boost-includes argument (se hjälp) 
Kontrollerar för program 'python'            : \/usr\/bin\/python 
Kontrollerar för python-version >= 2.3       : 2.7.15 python-config                                                                     : \/usr\/bin\/python-config
Frågar python-config för pyembed '--cflags --libs --ldflags' flaggor : yes
Testar pyembed konfiguration                                      : yes
Frågar python-config för pyext '--cflags --libs --ldflags' flaggor   : yes
Testar pyext konfiguration                                        : yes

Kontrollerar för kompilering flagga -fvisibility=hidden stöd          : ok 
Kontrollerar för kompilering flagga -Wno-array-bounds stöd            : ok 
Kontrollerar för pybindgen plats          : ..\/pybindgen ,!(gissat) 
Kontrollerar för python modul 'pybindgen'   : 0.19.0. ,!post4+g823d8b2 
Kontrollerar för pybindgen version           : 0.19.0. ,!post4+g823d8b2 
Kontrollerar för kodsnutt                : yes 
Kontrollerar för typer uint64_t och unsigned long ekvivalens : no 
Kontrollerar för kodsnutt                                 : no 
Kontrollerar för typer uint64_t och unsigned long long ekvivalens     : yes 
Kontrollerar för apidefs som kan användas för Python bindningar                       : gcc-LP64 
Kontrollerar för intern GCC cxxabi         : komplett 
Kontrollerar för python modul 'pygccxml'    : inte hittad 
Kontrollerar för klick plats              : inte hittad 
Kontrollerar för program 'pkg-config'        : \/usr\/bin\/pkg- ,!config 
Kontrollerar för 'gtk+-3.0'                  : inte hittad 
Kontrollerar för 'libxml-2.0'                : yes 
kontrollerar för uint128_t                   : inte hittad 
kontrollerar för __uint128_t                 : yes 
Kontrollerar hög precision implementering   : 128-bit integer ,!(standard) 
Kontrollerar för header stdint.h             : yes 
Kontrollerar för header inttypes.h           : yes 
Kontrollerar för header sys\/inttypes.h       : inte hittad 
Kontrollerar för header sys\/types.h          : yes 
Kontrollerar för header sys\/stat.h           : yes 
Kontrollerar för header dirent.h             : yes 
Kontrollerar för header stdlib.h             : yes 
Kontrollerar för header signal.h             : yes 
Kontrollerar för header pthread.h            : yes 
Kontrollerar för header stdint.h             : yes 
Kontrollerar för header inttypes.h           : yes 
Kontrollerar för header sys\/inttypes.h       : inte hittad
Kontrollerar för bibliotek rt                  : yes 
Kontrollerar för header sys\/ioctl.h          : yes 
Kontrollerar för header net\/if.h             : yes 
Kontrollerar för header net\/ethernet.h       : yes 
Kontrollerar för header linux\/if_tun.h       : yes 
Kontrollerar för header netpacket\/packet.h   : yes 
Kontrollerar för NSC plats                : inte hittad 
Kontrollerar för 'sqlite3'                   : inte hittad 
Kontrollerar för header linux\/if_tun.h       : yes 
Kontrollerar för python modul 'gi'          : 3.26.1 
Kontrollerar för python modul 'gi.repository.GObject'      : ok 
Kontrollerar för python modul 'cairo'                      : ok 
Kontrollerar för python modul 'pygraphviz'                 : 1.4rc1 
Kontrollerar för python modul 'gi.repository.Gtk'          : ok 
Kontrollerar för python modul 'gi.repository.Gdk'          : ok 
Kontrollerar för python modul 'gi.repository.Pango'        : ok 
Kontrollerar för python modul 'gi.repository.GooCanvas'    : ok 
Kontrollerar för program 'sudo'                             : \/usr\/bin\/sudo 
Kontrollerar för program 'valgrind'                         : inte hittad 
Kontrollerar för 'gsl' : inte hittad python-config            : inte hittad 
Kontrollerar för kompilering flagga -fstrict-aliasing stöd : ok 
Kontrollerar för kompilering flagga -fstrict-aliasing stöd : ok 
Kontrollerar för kompilering flagga -Wstrict-aliasing stöd : ok 
Kontrollerar för kompilering flagga -Wstrict-aliasing stöd : ok 
Kontrollerar för program 'doxygen'                          : \/usr\/bin\/doxygen
---- Sammanfattning av valfria ns-3-funktioner:
Byggprofil : optimerad
Byggkatalog : 
BRITE Integration : inte aktiverad (BRITE inte aktiverad (se alternativ --with- ,!brite)) 
DES Metrics händelseinsamling : inte aktiverad (standardeinställningar till inaktiverad) 
Emulation FdNetDevice        : aktiverad 
Exempel                     : aktiverad 
Filbeskrivare NetDevice    : aktiverad 
GNU Scientific Library (GSL) : inte aktiverad (GSL hittades inte) 
Gcrypt bibliotek               : inte aktiverad
(libgcrypt hittades inte: du kan använda ,!libgcrypt-config för att hitta dess plats.) GtkConfigStore               : inte aktiverad (bibliotek 'gtk+-3.0 >= 3.0' inte hittades)
MPI Stödt                  : inte aktiverad (alternativ --enable-mpi inte valt)
ns-3 Click Integration       : inte aktiverad (nsclick inte aktiverad (se alternativ --with- ,!nsclick))
ns-3 OpenFlow Integration   : inte aktiverad (Krävde boost-bibliotek hittades inte) 
Network Simulation Cradle    : inte aktiverad (NSC hittades inte (se alternativ --with-nsc))
PlanetLab FdNetDevice         : inte aktiverad (PlanetLab operativsystem upptäcktes inte ,!(se alternativ --force-planetlab)) PyViz visualizer : aktiverad 
Python API Skanning Stöd   : inte aktiverad (missing 'pygccxml' python-modul)
Python Bindningar : aktiverad 
Real Time Simulator           : aktiverad 
SQlite stats data utdata      : inte aktiverad (bibliotek 'sqlite3' hittades inte)
Tap Bridge                    : aktiverad 
Tap FdNetDevice               : aktiverad
Tester                         : aktiverad 
Trådning Primtiver          : aktiverad 
Använd sudo för att ställa in suid bit   : inte aktiverad (alternativ --enable-sudo inte valt)
XmlIo                         : aktiverad
'configure' avslutades framgångsrikt (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 libxml-2.0vara närvarande. Om detta bibliotek inte kunde hittas och motsvarande ns-3-funktion inte var aktiverad, kommer ett meddelande att visas. Observera också att det finns möjlighet att använda kommandot sudo för att ställa in suid-bit, "installera grupp-ID vid körning", på vissa program. Denna funktion är inte aktiverad som standard och visas därför som "inte aktiverad". Slutligen, för att få en lista över aktiverade alternativ, använd Waf med parametern --check-config.

Låt oss nu gå tillbaka och växla tillbaka till debug-byggnaden som innehåller exempel och tester.

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

Byggsystemet är nu konfigurerat, och du kan kompilera debug-versioner av ns-3-program helt enkelt genom att skriva:

$ .\/waf

Även om de ovan beskrivna stegen tvingade dig att bygga delar av ns-3-systemet två gånger, vet du nu hur man ändrar konfigurationen och bygger optimerad kod.

För att kontrollera vilken profil som är aktiv för den aktuella projektkonfigurationen finns det ett kommando:

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

Det scenari som diskuterats ovan build.py stöder också argumenten --enable-examples och --enable-tests, men andra alternativ Waf stöder den inte direkt. Till exempel, detta kommer inte att fungera:

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

reaktionen kommer att vara:

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

Det bör noteras att specialoperatorn - - kan användas för att skicka ytterligare parametrar genom waf, så 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 ytterligare inledande råd om Waf.

Felhantering vid kompilering

ns-3-utgåvor har testats på de senaste tillgängliga C++-kompilatorerna vid tidpunkten för utgivning på vanliga Linux- och MacOS-distributioner. Med tiden släpps nya distributioner med nya kompilatorer, och dessa nyare kompilatorer är vanligtvis mer nogräknade när det kommer till varningar. ns-3 konfigurerar sin byggprocess för att behandla alla varningar som fel, så ibland, om du använder en äldre version på ett nyare system, kan en kompilatorvarning stoppa bygget.

Till exempel fanns tidigare ns-3.28 tillgänglig för Fedora 28, som inkluderade en ny huvudversion. gcc (gcc-8). Att bygga ns-3.28 eller tidigare versioner under Fedora 28, med Gtk2+ installerat, kan leda till följande fel:

/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 och med ns-3.28.1 Waf finns det ett alternativ för att lösa dessa problem. Det inaktiverar installationen av flaggan "-Werror" i g++ och clang++. Det här alternativet "--disable-werror" ska användas under konfigurationen:

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

Att konfigurera eller bygga

Vissa kommandon Waf är meningsfulla endast under konfigurationsfasen, medan andra fungerar bara under byggfasen. Till exempel, om du vill använda ns-3:s emuleringsfunktioner, kan du aktivera bitinställningen suid genom att använda sudo, som beskrivits ovan. Detta kommer att ogiltigförklara kommandon från konfigurationssteget, och så 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 köra sudo, för att ändra program för att skapa emuleringssockel för att köras med rättigheter. root. I Waf Det finns många andra alternativ för konfigurations- och byggstegen. För att utforska alternativen, skriv:

$ ./waf --help

I nästa avsnitt kommer vi att använda några alternativ relaterade till testning.

Byggprofiler

Vi har redan sett hur man kan anpassa Waf för byggen. debug och optimized:

$ ./waf --build-profile=debug

Det finns också en mellanprofil för byggen, release. Alternativet -d är en synonym för --build-profile. Byggprofilen styr användningen av loggning, assertions och kompilatorns optimeringsnycklar:

Som man kan se är loggning och påståenden endast tillgängliga i debugbyggnader. Den rekommenderade metoden är att utveckla ditt skript i debugläge och sedan utföra flera körningar (för statistik eller parameterändringar) i den optimerade byggprofilen.

Om du har kod som endast ska köras i vissa byggprofiler, använd makrot Code Wrapper Macro:

NS_BUILD_DEBUG (std::cout << "En del av en utmatningsrad..." << std::flush; timer.Start ,!()); DoLongInvolvedComputation ();
NS_BUILD_DEBUG (timer.Stop (); std::cout << "Färdig: " << timer << std::endl;)

Som standard, Waf placerar byggartefakter i byggmappen. Du kan ange en annan utmatningsmapp med hjälp av alternativet - -out, till exempel:

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

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

$ ./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 byggnader utan att behöva skriva om den senaste byggningen varje gång. När du växlar till en annan profil, Waf kommer den endast att kompilera den, utan att återkompilera allt.

När du på detta sätt växlar byggprofiler, krävs det att du alltid anger samma konfigurationsparametrar. Du kan undvika misstag genom att definiera flera miljövariabler:

$ 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 ovanstående exempel Waf för att bygga ns-3 används C++-kompilatorn från GCC ( g++). Men det går att ändra den använda Waf C++-kompilatorn genom att definiera miljövariabeln CXX. Till exempel, för att använda C++-kompilatorn Clang, clang++,

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

På liknande sätt kan du konfigurera Waf för att använda distribuerad kompilering med hjälp av distcc:

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

Mer information om distcc och distribuerad kompilering finns på projektets sida under avsnittet "Dokumentation". För att lägga till kompilatorflaggor vid konfiguration av ns-3, använd miljövariabeln CXXFLAGS_EXTRA.

Installation

Waf kan användas för att installera bibliotek på olika ställen i systemet. Som standard ligger de insamlade biblioteken och körbara filer i katalogen build, och eftersom Waf känner till platsen för dessa bibliotek och körbara filer, finns det inget behov av att installera biblioteken någon annanstans.

Om användarna föredrar att installera utanför byggkatalogen kan de köra kommandot .\/waf install. Som standard är prefixet för installationen — /usr/local, därför .\/waf install kommer att installera program i /usr/local/bin, bibliotek i /usr/local/lib och header-filer i /usr/local/include. Superanvändarrättigheter behövs vanligtvis för att installera med standardprefix, så det vanliga kommandot blir sudo .\/waf install. När Waf körs kommer det först att föredra att använda gemensamma bibliotek i byggkatalogen, och sedan leta efter bibliotek i bibliotekssökvägen som är inställd i den lokala miljön. Så när bibliotek installeras i systemet är det bra praxis att kontrollera att de rätta biblioteken används. Användarna kan välja att installera med ett annat prefix genom att skicka alternativet --prefix, till exempel:

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

Om användaren senare, efter byggandet, kör installationskommandot .\/waf, kommer prefixet att användas /opt/local.

Team .\/waf clean bör användas innan projektet omkonfigureras om installationen skall göras Waf med ett annat prefix.

Således finns det inget behov av att kalla på ns‑3 .\/waf install. För de flesta användare kommer det här kommandot att vara onödigt, eftersom Waf kommer att plocka de aktuella biblioteken från byggkatalogen, men vissa användare kan tycka att det är användbart om deras verksamhet involverar arbete med program utanför ns‑3 katalogen.

Waf är enhetlig

I toppnivån av ns‑3:s källkodsträd finns det bara ett Waf-skript. När du har börjat arbeta kommer du att spendera mycket tid i katalogen scratch\/ eller djupare, isrc\/... och du kommer att behöva köra Waf. Du kan helt enkelt komma ihåg var du är och köra Waf på följande sätt:

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

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

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

$ cd scratch 
$ waff build

I modulens katalog kan det se frestande ut att lägga till ett trivialt waf-skript som exempel exec ..\/..\/waf. Vänligen gör inte detta. Det förvirrar nybörjare och kan leda till svårupptäckta byggfel om det görs dåligt. Lösningarna som visas ovan är vägen att följa.

3.5 Testa ns-3

Du kan köra modultester av ns‑3-distributionen genom att köra skriptet .\/test.py:

$ .\/test.py

Dessa tester körs parallellt med Waf. I slutändan ska du se ett meddelande om att

92 av 92 tester passerade (92 passerade, 0 misslyckades, 0 kraschade, 0 valgrind-fel)

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

Du kommer också att se slutlig utdata från Waf och testaren som kör varje test, vilket kommer att se ut ungefär så här:

Waf: Går in i katalogen `\/path\/to\/workspace\/ns-3-allinone\/ns-3-dev\/build' 
Waf: Lämnar katalogen `\/path\/to\/workspace\/ns-3-allinone\/ns-3-dev\/build' 
'built' avslutad framgångsrikt (1.799s) 

Byggda moduler:
aodv           applikationer          bro
click          config-store          kärna
csma           csma-layout           dsdv
emu            energi                flow-monitor
internet       lte                   mesh
mobility       mpi                   netanim
nätverk        nix-vector-routing    ns3tcp
ns3wifi        olsr                  openflow
punkt-till-punkt punkt-till-punkt-layout propagation
spektrum       stats                 tap-bridge
mall          test                  verktyg
topologi-läsa  uan                   virtuell-nätdel
visualizer     wifi                  wimax

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

...

PASS: TestSuite objekt
PASS: TestSuite slump-numer-generatorer
92 av 92 tester passerade (92 passerade, 0 misslyckades, 0 kraschade, 0 valgrind-fel)

Detta kommando körs vanligtvis av användare för att snabbt kontrollera att ns‑3-distributionens byggnad är korrekt. (Observera att ordningen på raderna "PASS: ..." kan variera, detta är normalt. Viktigt är att den slutgiltiga raden i slutet av rapporten visar att alla kontroller passerade; ingen test misslyckades eller kraschade.) Och Waf, och test.py kommer att parallellisera arbetet över de tillgängliga kärnorna i maskinens processor.

3.6 Köra skript

Vanligtvis kör vi skript under kontroll av Waf. Detta gör att byggsystemet kan garantera att vägar till gemensamma bibliotek är korrekt inställda och att biblioteken finns tillgängliga under körning. För att köra programmet, använd bara Waf med parametern - -run. Vi kommer att köra motsvarigheten till den allestädes närvarande programmet för ns‑3 hej världen, genom att skriva in följande:

$ .\/waf --run hello-simulator

Waf kommer först att kontrollera att programmet är korrekt sammanställt och kommer att utföra sammanställningen vid behov. Sedan Waf kommer det att köra programmet som ger följande utdata.

Hello Simulator

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

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

Om du ser meddelanden Waf, som indikerar att sammanställningen lyckades, men du inte ser utdata «Hello Simulator», finns det en möjlighet att du i avsnittet [Sammanställning-s-Waf] har bytt din sammanställningsläge till optimized, men missade att återgå till läget debug. All utdata från konsolen som används i denna handledning använder en speciell komponent ns-3 som loggar och används för att skriva ut användarmeddelanden i konsolen. Utdata från denna komponent är automatiskt avstängt när den optimerade koden kompileras — den är "optimerad". Om du inte ser utdata "Hello Simulator", skriv följande:

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

för att konfigurera Waf för en sammanställning av debugversioner av ns-3-program som inkluderar exempel och tester. Du bör sedan återkompilera den aktuella debugversionen av koden genom att skriva

$ .\/waf

Nu, om du kör programmet hello-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 mall:

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

Ersätt med namnet på ditt program och med argumenten. Argumentet - -command-template för Waf är i själva verket ett recept för att bygga den faktiska kommandoraden Waf som används för att köra programmet. Waf kontrollerar att sammanställningen är klar, ställer in sökvägar till det gemensamma biblioteket, och sedan, med hjälp av den angivna kommandoradsmallen och placerar programmets namn istället för platsinnehavaren %s, anropar det körbar fil. Om du tycker att detta syntax verkar komplicerat, finns det ett enklare alternativ som inkluderar ns-3-programmet och dess argument inneslutna i enkla citattecken:

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

Ett annat, särskilt användbart, exempel är att selektivt köra testuppsättningar. Anta att det finns en testuppsättning (suite) mytest (som inte egentligen finns). Tidigare använde vi skriptet .\/test.py för att parallellt köra en hel uppsättning tester, vilket flera gånger anropar testprogrammet test-runner. Anrop test-runner direkt för att köra ett test:

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

Argumenten kommer att skickas till programmet test-runner. Eftersom mytest inte finns, kommer ett felmeddelande att genereras. För att skriva ut tillgängliga parametrar för test-runner, skriv:

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

3.6.2 Felsökning

För att starta ns-3 program under kontroll av ett annat verktyg, som en debugger (till exempel, gdb) eller minneskontrollverktyg (till exempel, valgrind), använd en liknande form - -command-template = "…". Till exempel för att starta debuggern gdb ditt ns-3-program hello-simulator med argument:

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

Observera att namnet på ns-3-programmet följs av argumentet - -run, och kontrollverktyget (här gdb) är den första token i argumentet - -command-template. Alternativet - -args rapporterar gdb, vilket innebär att resten av kommandoraden tillhör det "lägre" programmet. (Vissa versioner gdb förstår inte alternativet - -args. I så fall ta bort programmets argument från - -command-template och använd kommandosatsen gdb args.) Vi kan kombinera detta recept och det föregående för att köra testet under en debugger:

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

3.6.3 Arbetskatalog

Waf måste köras från sin plats högst upp i ns-3-trädet. Denna mapp blir arbetskatalogen där utdatafilerna kommer att sparas. Men vad händer om du vill spara dessa filer utanför källkodsträdet för ns-3? Använd argumentet - -cwd:

$ .\/waf --cwd=...

Det kan vara bekvämare för dig att få utdatafilerna i din arbetskatalog. I så fall kan en sådan indirekt åtgärd hjälpa:

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

Denna dekoration av den tidigare kommandot bevarar nuvarande arbetskatalog, går till katalogen Waf, och instruerar Waf att återställa arbetskatalogen till den som sparades innan programmet startades. Vi nämner kommandot - -cwd för fullständighetens skull, de flesta användare kör helt enkelt Waf från översta nivån och genererar där utdatafiler.

Fortsättning: kapitel 4

Källa: habr.com