Guida al simulatore di rete ns-3. Capitolo 3

capitoli 1, 2

3 Iniziare a lavorare
3.1 Panoramica
3.2 Requisiti preliminari
3.2.1 Scaricare il rilascio di ns-3 come archivio sorgenti
3.3 Scaricare ns-3 utilizzando Git
3.3.1 Scaricare ns-3 utilizzando Bake
3.4 Compilare ns-3
3.4.1 Compilare con build.py
3.4.2 Compilare con Bake
3.4.3 Compilare con Waf
3.5 Testing di ns-3
3.6 Eseguire lo script
3.6.1 Argomenti della riga di comando
3.6.2 Debugging
3.6.3 Directory di lavoro

Capitolo 3

Iniziare a lavorare

Questo capitolo è progettato per preparare il lettore a lavorare con un computer su cui ns‑3 potrebbe non essere mai stato installato. La dissertazione copre le piattaforme supportate, i requisiti preliminari, i modi per ottenere ns‑3, i metodi per compilare ns‑3 e le modalità per verificare la vostra compilazione ed eseguire semplici programmi.

3.1 Panoramica

Il simulatore ns‑3 è costruito come un sistema di librerie software che lavorano insieme. Durante la compilazione, il codice dei programmi utente viene collegato a queste librerie. I linguaggi di programmazione utilizzati per scrivere programmi utente sono C++ o Python.

Ns-3 è distribuito come codice sorgente, il che significa che il sistema di destinazione deve avere un ambiente di sviluppo software per prima cosa compilare le librerie e poi compilare il programma personalizzato. In linea di massima, ns-3 può essere distribuito come librerie pronte per sistemi specifici, e in futuro potrebbe essere distribuito in questo modo. Ma attualmente molti utenti svolgono effettivamente il loro lavoro modificando ns-3 stesso, quindi è utile avere il codice sorgente per compilare le librerie. Se qualcuno desidera svolgere il lavoro di creazione di librerie e pacchetti pronti per i sistemi operativi, per favore contattate la mailing list. ns-developers.

Analizzeremo tre modalità per scaricare e costruire ns‑3. La prima consiste nel scaricare e costruire la versione ufficiale dal sito principale. La seconda è quella di selezionare e costruire copie delle versioni di sviluppo della versione base di ns‑3. La terza è l'utilizzo di strumenti di compilazione aggiuntivi per scaricare un numero maggiore di estensioni per ns‑3. Esamineremo ciascuna di esse, poiché gli strumenti sono leggermente diversi.

Gli utenti esperti di Linux potrebbero chiedersi perché ns‑3 non sia fornito come pacchetto, come la maggior parte delle altre librerie che utilizzano un gestore di pacchetti. Anche se esistono pacchetti binari per varie distribuzioni Linux (come Debian), la maggior parte degli utenti alla fine modifica le librerie e deve ricompilare ns‑3 da solo, quindi la disponibilità del codice sorgente è conveniente. Per questo motivo, ci concentreremo sull'installazione dal codice sorgente.

Per la maggior parte delle applicazioni, ns‑3 non richiede privilegi; si raccomanda di utilizzare un account utente non privilegiato. root non sono richiesti, si consiglia di utilizzare un account utente non privilegiato.

3.2 Requisiti preliminari

L'intero set di librerie disponibili per ns‑3 ha una serie di dipendenze da librerie di terze parti, ma per lo più ns‑3 può essere compilato e utilizzato con il supporto di diversi componenti comuni (spesso preinstallati di default): il compilatore C++, Python, un editor di codice sorgente (ad esempio, vim, emacs o Eclipse) e, se si utilizzano repository di sviluppo, sistemi di controllo versione come Git. La maggior parte degli utenti principianti non deve preoccuparsi se la loro configurazione segnala alcune funzionalità aggiuntive mancanti in ns‑3, ma per coloro che desiderano un'installazione completa, il progetto fornisce una wiki che include pagine con molti consigli e suggerimenti utili. Una di queste pagine è la pagina 'Installazione' con istruzioni per l'installazione su diversi sistemi, disponibili all'indirizzo: https://www.nsnam.org/wiki/Installation.

La sezione 'Requisiti' di questa pagina wiki spiega quali pacchetti sono necessari per supportare le opzioni comuni di ns‑3 e fornisce anche i comandi utilizzati per installarli nelle varianti Linux o macOS più diffuse.

È possibile approfittare di opportunità come consultare la wiki di ns‑3 o il sito web principale: https://www.nsnam.org, poiché ci sono molte informazioni. A partire dall'ultima versione di ns‑3 (ns‑3.29), sono necessari i seguenti strumenti per eseguire ns‑3:

Strumento Pacchetto/versione

• Compilatore C++
  clang++ o g++ (g++ versione 4.9 o superiore)
• Python
  python2 versione >= 2.7.10, o python3 versione >= 3.4
• Git
  qualunque versione recente (per accedere a ns‑3 su GitLab.com)
• tar
  qualunque versione recente (per estrarre il rilascio di ns‑3)
• bunzip2
  qualunque versione recente (per estrarre il rilascio di ns‑3)

Per controllare la versione di Python installata di default, digitare python -V. Per controllare la versione di g++, digitare g++ -v. Se alcuni strumenti mancassero o fossero obsoleti, consultare il manuale di installazione nella wiki di ns‑3.

A questo punto, supponiamo che il lettore stia lavorando su Linux, MacOS o un emulatore di Linux, e abbia almeno gli strumenti suddetti.

3.2.1 Scaricare il rilascio di ns-3 come archivio sorgenti

Questo è il modo di procedere per un nuovo utente che desidera scaricare e sperimentare con le ultime versioni rilasciate e dei pacchetti di ns‑3. Le versioni di ns‑3 vengono pubblicate come archivi compressi di sorgente, a volte chiamati tarball. tarball — è un formato speciale di archivio software in cui più file sono combinati insieme. L'archivio è solitamente compresso. Il processo di download di ns‑3 tramite tarball è semplice, devi solo scegliere la versione, scaricarla e decomprimerla.

Supponiamo che tu, come utente, voglia compilare ns‑3 in una directory locale chiamata workspace. Potrai ottenere una copia lavorativa della versione inserendo nella console di Linux quanto segue (naturalmente sostituendo i numeri di versione appropriati)

$ 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 

Nota l'utilità utilizzata sopra wget, che è uno strumento da linea di comando per scaricare oggetti da Internet. Se non l'hai installato, puoi utilizzare il browser per farlo.

Seguendo questi passaggi, accederai alla directory ns-allinone-3.29, dove dovresti vedere diversi file e directory

$ 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

Ora sei pronto per compilare la distribuzione base di ns‑3 e puoi passare alla sezione dedicata alla compilazione di ns‑3.

3.3 Scaricare ns-3 utilizzando Git

Il codice ns‑3 è disponibile nei repository Git su GitLab.com all'indirizzo https://gitlab.com/nsnam/. Il gruppo nsnam unisce diversi repository utilizzati dal progetto open source.

Il modo più semplice per iniziare a utilizzare i repository Git è fare un fork o clonare l'ambiente. ns‑3-allinone. Questo è un insieme di script che gestisce il download e la costruzione delle sottosistemi più comunemente usati di ns‑3. Se sei un neofita di Git, i termini "fork" e "clonazione" potrebbero esserti estranei; in tal caso, ti consigliamo di clonare (creare una tua copia) il repository su GitLab.com come segue:

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

A questo punto, l'aspetto della tua directory ns‑3-allinone è leggermente diverso dalla directory sopra descritta con l'archivio di rilascio. Dovrebbe apparire più o meno così:

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

Nota la presenza dello script download.py, che estrarrà ulteriormente ns‑3 e il codice sorgente associato. Qui hai due opzioni: scaricare l'ultima istantanea di sviluppo di ns‑3:

$ python download.py

o preferire la versione di ns‑3, utilizzando il flag -n per specificare il numero di rilascio:

$ python download.py -n ns-3.29

Dopo questo passaggio, la directory ns‑3-allinone saranno caricati repository aggiuntivi ns‑3, bake, pybindgen e netanim.

Nota
Sulla macchina con una pulita Ubuntu 16.04, ho dovuto modificare il comando in questo modo: $ sudo python3 download.py -n ns-3.29 (qui e oltre, note del traduttore).

3.3.1 Scaricare ns-3 utilizzando Bake

I due metodi sopra menzionati (archivio sorgente o repository ns‑3-allinone tramite Git) sono utili per ottenere la più semplice installazione di ns‑3 con alcuni addon,pybindgen per generare binding Python e netanim per l'animazione di rete). Il terzo repository, fornito di default in ns‑3-allinone, si chiama bake.

Bake — è uno strumento per la costruzione coordinata di software da più repository, progettato per il progetto ns‑3. Bake può essere utilizzato per ottenere versioni da sviluppatore di ns‑3, così come per scaricare e costruire estensioni della versione base della distribuzione ns‑3, come l'ambiente Direct Code Execution, CradleNetwork Simulation Cradle, la possibilità di creare nuovi binding Python e varie "applicazioni" ns‑3.

Nota
CradleNetwork Simulation Cradle è un framework che consente di utilizzare stack di rete reali TCP/IP all'interno di un simulatore di rete.

Se prevedi che la tua installazione di ns-3 debba avere funzionalità avanzate o aggiuntive, puoi seguire questo percorso di installazione.

Nelle ultime versioni di ns-3 Bake è stato aggiunto nel rilascio tar. È incluso un file di configurazione che consente di scaricare le versioni del software aggiornate al momento della creazione del rilascio. Ad esempio, la versione Bake, distribuita con il rilascio di ns-3.29, può essere utilizzata per ottenere componenti per questo rilascio di ns-3 o per rilasci precedenti, ma non può essere utilizzata per estrarre componenti per rilasci successivi (a meno che il file di descrizione del pacchetto bakeconf.xml non venga aggiornato).

Puoi anche ottenere l'ultima copia bake, inserendo il seguente comando nella tua console Linux (a condizione che tu abbia installato Git):

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

Durante l'esecuzione del comando git, dovresti vedere qualcosa di simile a quanto segue:

Clonazione in 'bake'...
remoto: Enumerazione oggetti: 2086, completato. 
remoto: Conteggio oggetti: 100% (2086/2086), completato. 
remoto: Compressione oggetti: 100% (649/649), completato. 
remoto: Totale 2086 (delta 1404), riutilizzati 2078 (delta 1399) 
Ricezione oggetti: 100% (2086/2086), 2.68 MiB | 3.82 MiB/s, completato. 
Risoluzione dei delta: 100% (1404/1404), completato.

Dopo il completamento del comando clone dovrebbe apparire una directory con il nome bake, il cui contenuto dovrebbe apparire circa così:

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

Si prega di notare che hai caricato diversi script Python, un modulo Python chiamato bake e un file di configurazione XML. Il passo successivo sarà utilizzare questi script per scaricare e costruire il pacchetto ns‑3 di tua scelta. Sono disponibili diversi obiettivi di configurazione:

1. ns‑3.29: modulo corrispondente alla versione; caricherà componenti simili al rilascio nel tarball;

2. ns‑3-dev: un modulo simile, ma utilizzando il codice dall'albero di sviluppo;

3. ns-allinone-3.29: un modulo che include altre funzionalità aggiuntive, come Click routing e Network Simulation Cradle, Openflow per ns-3.

4. ns‑3-allinone: simile alla versione di rilascio del modulo allinone, ma per il codice di sviluppo.

Nota
Click — architettura software modulare per la creazione di router.

Openflow — protocollo di gestione del processo di elaborazione dei dati trasmessi attraverso la rete dai router e switch, implementando la tecnologia delle reti a configurazione programmabile.

L'attuale snapshot di sviluppo (non rilasciato) di ns‑3 può essere trovato all'indirizzo:https://gitlab.com/nsnam/ns-3-dev.git.

Gli sviluppatori si impegnano a mantenere questi repository in uno stato di lavoro coerente, ma si trovano in fase di sviluppo e contengono codice non rilasciato. Pertanto, se non pianificate di utilizzare le nuove funzionalità, scegliete la versione ufficiale.

Potete trovare l'ultima versione del codice esaminando l'elenco dei repository oppure visitando la pagina web «ns‑3 Releases»:https://www.nsnam.org/releases/ e cliccando sul link dell'ultima versione. In questo esempio continueremo con ns‑3.29.

Ora, per ottenere i componenti di cui abbiamo bisogno per ns‑3, utilizzeremo lo strumento Bake. Alcune parole introduttive sul funzionamento di Bake.

Bake funziona caricando i sorgenti dei pacchetti nella directory source e installando le librerie nella directory di build. Bake si può avviare facendo riferimento al file binario, ma se si desidera eseguire Bake non dalla directory in cui è stato scaricato, è consigliabile aggiungere il percorso a bake alla vostra variabile di percorso (PATH), ad esempio nel seguente modo (esempio per la shell Linux bash). Andate nella directory «bake» e poi impostate le seguenti variabili ambiente:

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

Questo posizionerà il programma bake.py nella variabile di ambiente e permetterà ad altri programmi di trovare i file eseguibili e le librerie che hai creato bake. In alcuni casi d'uso bake, l'impostazione di PATH e PYTHONPATH sopra descritta non è necessaria, ma per una build completa di ns‑3-allinone (con pacchetti aggiuntivi) è generalmente richiesta.

Accedi alla directory di lavoro e inserisci nella console quanto segue:

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

Poi ti chiederemo Bake di controllare se abbiamo gli strumenti necessari per scaricare i vari componenti. Digita:

$ ./bake.py check

Dovresti vedere qualcosa di simile a questo:

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

In particolare, strumenti di download come Mercurial, CVS, Git e Bazaar sono fondamentali in questo passaggio, in quanto ci permettono di ottenere il codice. In questa fase, installa gli strumenti mancanti in modo consueto per il tuo sistema (se lo sai fare) o chiedi aiuto al tuo amministratore di sistema.

Prova quindi a scaricare il software:

$ ./bake.py download

il risultato dovrebbe essere qualcosa di simile a:

>> Ricerca della dipendenza di sistema setuptools - OK 
>> Ricerca della dipendenza di sistema libgoocanvas2 - OK 
>> Ricerca della dipendenza di sistema gi-cairo - OK 
>> Ricerca della dipendenza di sistema pygobject - OK 
>> Ricerca della dipendenza di sistema pygraphviz - OK 
>> Ricerca della dipendenza di sistema python-dev - OK 
>> Ricerca della dipendenza di sistema qt - OK 
>> Ricerca della dipendenza di sistema g++ - OK 
>> Download di pybindgen-0.19.0.post4+ng823d8b2 (directory di destinazione: pybindgen) - OK 
>> Download di netanim-3.108 - OK 
>> Download di ns-3.29 - OK

Questo significa che sono stati scaricati tre sorgenti. Ora vai nella directory source e digita ls; dovresti vedere:

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

Ora sei pronto per compilare il pacchetto ns-3.

3.4 Compilare ns-3

Come per il download di ns-3, ci sono diversi modi per compilare ns-3. È importante sottolineare che ns-3 viene compilato utilizzando uno strumento di compilazione chiamato Waf, descritto di seguito. La maggior parte degli utenti lavorerà con Waf, ma ci sono diversi script utili che possono aiutarti a iniziare o organizzare compilazioni più complesse. Pertanto, ti preghiamo di leggere prima di tutto riguardo a Waf, dai un'occhiata a build.py e la compilazione con bake.

3.4.1 Compilare con build.py

Attenzione! Questo passo di compilazione è disponibile solo dalla versione dell'archivio sorgente ottenuta come descritto sopra; e non scaricata tramite git o bake.

Quando si utilizza l'archivio di rilascio tarball, nel ns-3-allinone è disponibile uno script conveniente che può semplificare la costruzione dei componenti. Si chiama build.py. Questo programma configurerà il progetto nel modo più utile per te. Tuttavia, tieni presente che configurazioni più complesse e lavoro con ns‑3 spesso richiedono l'uso del proprio sistema di build di ns‑3, Waf, che verrà presentato più avanti in questa guida.

Se hai scaricato utilizzando tarball, nella tua directory ~/workspace dovrebbe apparire una directory con un nome simile a ns-allinone-3.29. Digita quanto segue:

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

Quando chiamato build.py abbiamo applicato argomenti della riga di comando per compilare gli esempi e i test utilizzati in questa guida, che in ns‑3 non vengono compilati di default. Per impostazione predefinita, il programma costruisce anche tutti i moduli disponibili. Poi, se lo desideri, puoi compilare ns‑3 senza esempi e test o escludere i moduli che non sono necessari per il tuo lavoro.

Vedrai molti messaggi di output del compilatore visualizzati dallo script durante la costruzione delle varie parti che hai scaricato. All'inizio, lo script tenterà di compilare l'animatore netanim, quindi il generatore di binding pybindgen e, infine, ns‑3. Al termine del processo, dovresti vedere quanto segue:

Waf: Uscita dalla directory '/path/to/workspace/ns-allinone-3.29/ns-3.29/build'
'build' completato con successo (6m25.032s) 

Moduli costruiti:
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 

Moduli non costruiti (vedi il tutorial ns-3 per spiegazioni):
brite                  click                    openflow 
Uscita dalla directory ./ns-3.29

Negli ultimi tre righe dell'output vediamo un messaggio sui moduli che non sono stati costruiti:

Moduli non costruiti (vedi il tutorial ns-3 per spiegazioni):
brite                     click

Questo significa semplicemente che alcuni moduli ns‑3, che dipendono da librerie esterne, potrebbero non essere stati costruiti, oppure che per questa configurazione la loro costruzione non è necessaria. Non significa che il simulatore non si sia costruito o che i moduli costruiti non funzioneranno correttamente.

3.4.2 Compilare con Bake

Se sopra hai utilizzato bake per ottenere il codice sorgente dai repository del progetto, puoi continuare a usarlo anche per compilare ns‑3. Digita:

$ ./bake.py build

e dovresti vedere qualcosa del tipo:

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

Suggerimento: puoi anche eseguire entrambi i passaggi, download e compilazione, richiamando «bake.py deploy».

Durante la compilazione di tutti i componenti potrebbero verificarsi errori, ma il processo di compilazione continuerà se il componente non è obbligatorio. Ad esempio, un problema recente di portabilità riguardava il fatto che castxml può essere compilato con strumenti bake su tutte le piattaforme. In tal caso verrà visualizzato un messaggio simile a:

>> Building castxml - Problema 
> Problema: Dipendenza opzionale, il modulo "castxml" è fallito
Questo potrebbe ridurre le funzionalità della compilazione finale.
Tuttavia, bake continuerà poiché "castxml" non è una dipendenza essenziale.
Per ulteriori informazioni chiama bake con -v o -vvv, per la modalità dettagliata completa.

Tuttavia castxml è necessario solo se desideri creare binding Python aggiornati. Per la maggior parte degli utenti non c'è bisogno (perlomeno fino a quando non iniziano a modificare ns‑3), quindi tali avvisi possono essere ignorati per ora.

Se si verifica un errore, il comando successivo ti darà un suggerimento sulle dipendenze mancanti:

$ ./bake.py show

Verranno elencate varie dipendenze dei pacchetti che stai cercando di compilare.

3.4.3 Compilare con Waf

Fino a questo punto, per iniziare la compilazione di ns-3, abbiamo utilizzato o uno script build.py, oppure uno strumento bake. Questi strumenti sono utili per compilare ns-3 e supportare le librerie. Infatti, per la compilazione, eseguono uno strumento di build Waf dalla directory di ns-3. Waf è installato insieme al codice sorgente di ns-3. La maggior parte degli utenti passa rapidamente all'uso diretto Waf. Quindi, per continuare, si prega di accedere alla directory di ns-3 che hai creato inizialmente.

Al momento non è strettamente necessario, ma sarà utile fare una breve digressione su come apportare modifiche alla configurazione del progetto. Probabilmente, la modifica della configurazione più utile che puoi fare sarà quella di creare una versione ottimizzata del codice. Per impostazione predefinita, hai configurato il tuo progetto per costruire la versione di debug. Esaminiamo il progetto per creare una build ottimizzata. Per spiegare a Waf che deve effettuare build ottimizzate includendo esempi e test, dovrai eseguire i seguenti comandi:

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

Questo avvierà Waf al di fuori della directory locale (per tua comodità). Il primo comando esegue la pulizia dalla build precedente, non è necessariamente rigorosamente necessario, ma è una buona pratica (vedi anche i profili di build qui sotto); rimuoverà le librerie e i file oggetto precedentemente creati presenti nella directory build/. Quando il progetto è riconfigurato e il sistema di build controlla le varie dipendenze, dovresti vedere un output simile al seguente:

Impostando la directory principale su : /home/ns3user/workspace/bake/source/ns-3-dev
Impostando la directory di output su : /home/ns3user/workspace/bake/source/ns-3-dev/build
Controllando 'gcc' (compilatore C) : /usr/bin/gcc 
Controllando la versione di cc : 7.3.0 
Controllando 'g++' (compilatore C++) : /usr/bin/g++ 
Controllando il supporto per il flag di compilazione -march=native : ok 
Controllando il supporto per il flag di compilazione -Wl,--soname=foo : ok 
Controllando il supporto per il flag di compilazione -std=c++11 : ok 
Controllando le includi di boost : intestazioni non trovate, fornire un argomento --boost-includes (vedi aiuto) 
Controllando le includi di boost : intestazioni non trovate, fornire un argomento --boost-includes (vedi aiuto) 
Controllando il programma 'python' : /usr/bin/python 
Controllando la versione di python >= 2.3 : 2.7.15 python-config : /usr/bin/python-config
Richiedendo a python-config i flag '--cflags --libs --ldflags' per pyembed : sì
Testando la configurazione di pyembed : sì
Richiedendo a python-config i flag '--cflags --libs --ldflags' per pyext : sì
Testando la configurazione di pyext : sì

Controllando il supporto per il flag di compilazione -fvisibility=hidden : ok 
Controllando il supporto per il flag di compilazione -Wno-array-bounds : ok 
Controllando la posizione di pybindgen : ../pybindgen ,!(stimato) 
Controllando il modulo python 'pybindgen' : 0.19.0. ,!post4+g823d8b2 
Controllando la versione di pybindgen : 0.19.0. ,!post4+g823d8b2 
Controllando il frammento di codice : sì 
Controllando l'equivalenza dei tipi uint64_t e unsigned long : no 
Controllando il frammento di codice : no 
Controllando l'equivalenza dei tipi uint64_t e unsigned long long : sì 
Controllando gli apidefs utilizzabili per i binding Python : gcc-LP64 
Controllando il cxxabi interno di GCC : completo 
Controllando il modulo python 'pygccxml' : non trovato 
Controllando la posizione di click : non trovato 
Controllando il programma 'pkg-config' : /usr/bin/pkg- ,!config 
Controllando 'gtk+-3.0' : non trovato 
Controllando 'libxml-2.0' : sì 
Controllando uint128_t : non trovato 
Controllando __uint128_t : sì 
Controllando implementazione ad alta precisione : intero a 128 bit ,!(default) 
Controllando l'intestazione stdint.h : sì 
Controllando l'intestazione inttypes.h : sì 
Controllando l'intestazione sys/inttypes.h : non trovato 
Controllando l'intestazione sys/types.h : sì 
Controllando l'intestazione sys/stat.h : sì 
Controllando l'intestazione dirent.h : sì 
Controllando l'intestazione stdlib.h : sì 
Controllando l'intestazione signal.h : sì 
Controllando l'intestazione pthread.h : sì 
Controllando l'intestazione stdint.h : sì 
Controllando l'intestazione inttypes.h : sì 
Controllando l'intestazione sys/inttypes.h : non trovato
Controllando la libreria rt : sì 
Controllando l'intestazione sys/ioctl.h : sì 
Controllando l'intestazione net/if.h : sì 
Controllando l'intestazione net/ethernet.h : sì 
Controllando l'intestazione linux/if_tun.h : sì 
Controllando l'intestazione netpacket/packet.h : sì 
Controllando la posizione di NSC : non trovato 
Controllando 'sqlite3' : non trovato 
Controllando l'intestazione linux/if_tun.h : sì 
Controllando il modulo python 'gi' : 3.26.1 
Controllando il modulo python 'gi.repository.GObject' : ok 
Controllando il modulo python 'cairo' : ok 
Controllando il modulo python 'pygraphviz' : 1.4rc1 
Controllando il modulo python 'gi.repository.Gtk' : ok 
Controllando il modulo python 'gi.repository.Gdk' : ok 
Controllando il modulo python 'gi.repository.Pango' : ok 
Controllando il modulo python 'gi.repository.GooCanvas' : ok 
Controllando il programma 'sudo' : /usr/bin/sudo 
Controllando il programma 'valgrind' : non trovato 
Controllando 'gsl' : non trovato python-config : non trovato 
Controllando il supporto per il flag di compilazione -fstrict-aliasing : ok 
Controllando il supporto per il flag di compilazione -fstrict-aliasing : ok 
Controllando il supporto per il flag di compilazione -Wstrict-aliasing : ok 
Controllando il supporto per il flag di compilazione -Wstrict-aliasing : ok 
Controllando il programma 'doxygen' : /usr/bin/doxygen
---- Riepilogo delle funzionalità opzionali di ns-3:
Profilo di build : ottimizzato
Directory di build : 
Integrazione BRITE : non abilitata (BRITE non abilitato (vedi opzione --with-,!brite)) 
Raccolta eventi di metriche DES : non abilitata (predefinito disabilitato) 
Dispositivo FdNetDevice di emulazione : abilitato 
Esempi : abilitati 
Dispositivo NetDevice di file descriptor : abilitato 
Libreria scientifica GNU (GSL) : non abilitata (GSL non trovato) 
Libreria Gcrypt : non abilitata
(lbgcrypt non trovato: puoi usare ,!libgcrypt-config per trovare la sua posizione.) GtkConfigStore : non abilitato (libreria 'gtk+-3.0 >= 3.0' non trovata)
Supporto MPI : non abilitato (opzione --enable-mpi non selezionata)
Integrazione ns-3 Click : non abilitata (nsclick non abilitato (vedi opzione --with-,!nsclick))
Integrazione ns-3 OpenFlow : non abilitata (librerie boost richieste non trovate) 
Culla di simulazione di rete : non abilitata (NSC non trovato (vedi opzione --with-nsc))
Dispositivo FdNetDevice di PlanetLab : non abilitato (sistema operativo PlanetLab non rilevato ,!(vedi opzione --force-planetlab)) Visualizzatore PyViz : abilitato 
Supporto per la scansione dell'API Python : non abilitato (Modulo Python 'pygccxml' mancante)
Binding Python : abilitato 
Simulatore in tempo reale : abilitato 
Output dei dati statistici SQlite : non abilitato (libreria 'sqlite3' non trovata)
Bridge Tap : abilitato 
Dispositivo FdNetDevice Tap : abilitato
Test : abilitati 
Primitivi di threading : abilitati 
Usa sudo per impostare il bit suid : non abilitato (opzione --enable-sudo non selezionata)
XmlIo : abilitato
'configure' completato con successo (6.387s)

Fai attenzione all'ultima parte dell'elenco sopra. Alcune opzioni di ns-3 non sono abilitate di default oppure richiedono un supporto da parte del sistema per funzionare correttamente. Ad esempio, per abilitare XmlTo, deve essere presente la libreria libxml-2.0. Se questa libreria non è stata trovata e la corrispondente funzione ns-3 non è stata abilitata, verrà mostrato un messaggio. Tieni presente anche che è possibile utilizzare il comando sudo per impostare il bit suid «set group ID on execution» su alcuni programmi. Questa opzione non è attivata di default e quindi appare come «non abilitata» («not enabled»). Infine, per ottenere un elenco delle opzioni abilitate, utilizza Waf con il parametro --check-config.

Ora torniamo e riprendiamo la build di debug che contiene esempi e test.

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

Il sistema di build è ora configurato, e puoi compilare le versioni di debug dei programmi ns-3 semplicemente digitando:

$ ./waf

Anche se i passaggi descritti sopra ti hanno costretto a compilare parte del sistema ns-3 due volte, ora sai come modificare la configurazione e costruire codice ottimizzato.

Per verificare quale profilo è attivo per la data configurazione del progetto, esiste il comando:

$ ./waf --check-profile 
Waf: Entrando nella directory `/path/to/ns-3-allinone/ns-3.29/build' 
Profilo di build: debug

Lo scenario esaminato sopra build.py supporta anche gli argomenti --enable-examples e --enable-tests, ma non supporta direttamente altre opzioni. Waf Ad esempio, questo non funzionerà:

$ ./build.py --disable-python

la reazione sarà la seguente:

build.py: errore: nessuna opzione: --disable-python

Tuttavia, l'operatore speciale -- può essere usato per passare parametri aggiuntivi tramite waf, quindi invece di quanto sopra funzionerà il seguente comando:

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

poiché genera il comando principale ./waf configure --disable-python. Ecco alcuni consigli introduttivi su Waf.

Gestione degli errori di build

Le release di ns‑3 sono testati sugli ultimi compilatori C++ disponibili al momento del rilascio su distribuzioni Linux e MacOS comuni. Tuttavia, nel tempo, vengono rilasciate nuove distribuzioni con nuovi compilatori, e questi compilatori più recenti tendono a essere più rigorosi riguardo agli avvisi. ns‑3 imposta la propria build per trattare tutti gli avvisi come errori, quindi, a volte, se utilizzi una versione più vecchia su un sistema più nuovo, un avviso del compilatore potrebbe fermare la costruzione.

Ad esempio, in precedenza c'era il rilascio di ns‑3.28 per Fedora 28, che includeva una nuova versione principale gcc (gcc-8). La costruzione del rilascio ns‑3.28 o delle versioni precedenti su Fedora 28, con Gtk2+ installato, genererà il seguente errore:

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

Nei rilasci a partire da ns‑3.28.1, Waf è disponibile un'opzione per affrontare questi problemi. Disabilita l'impostazione del flag "-Werror" in g++ e clang++. Questa opzione è "--disable-werror" e deve essere applicata durante la configurazione:

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

Configurare o costruire

Alcuni comandi Waf hanno senso solo nella fase di configurazione, mentre alcuni agiscono solo nella fase di costruzione. Ad esempio, se desideri utilizzare le funzionalità di emulazione di ns-3, puoi abilitare l'installazione del bit suid usando sudo, come descritto sopra. Questo annullerà i comandi della fase di configurazione, permettendoti così di cambiare la configurazione usando il seguente comando, che include anche esempi e test.

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

Se fai questo, Waf avvierà sudo, per modificare i programmi di generazione dei socket di codice di emulazione per l'esecuzione con diritti root. In Waf sono disponibili molte altre opzioni per le fasi di configurazione e costruzione. Per esplorare le opzioni, inserisci:

$ ./waf --help

Nella sezione successiva utilizzeremo alcune opzioni relative ai test.

Profili di costruzione

Abbiamo già visto come configurare Waf per le costruzioni debug e ottimizzate:

$ ./waf --build-profile=debug

Esiste anche un profilo di costruzione intermedio, release. L'opzione -d è un sinonimo di --build-profile. Il profilo di costruzione gestisce l'uso della registrazione, delle asserzioni e delle chiavi di ottimizzazione del compilatore:

Come puoi notare, il logging e le asserzioni sono disponibili solo nelle build di debug. La prassi consigliata è di sviluppare il tuo script in modalità di debug e poi eseguire esecuzioni successive (per statistiche o per modificare parametri) in un profilo di build ottimizzato.

Se hai del codice che deve essere eseguito solo in determinati profili di build, usa il macro Code Wrapper Macro:

NS_BUILD_DEBUG (std::cout << "Parte di una riga di output..." << std::flush; timer.Start ,!()); DoLongInvolvedComputation();
NS_BUILD_DEBUG (timer.Stop (); std::cout << "Fatto: " << timer << std::endl;)

Per impostazione predefinita, Waf colloca gli artefatti di build nella directory di build. Puoi specificare una directory di output diversa usando l'opzione - -out, ad esempio:

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

Combinando questo con i profili di build, puoi facilmente passare tra diverse impostazioni di compilazione:

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

Il che ti consente di lavorare con più build senza dover riscrivere ogni volta l'ultima build. Quando passi a un altro profilo, Waf compila solo quello, senza una completa ricompilazione di tutto.

Quando si cambiano i profili di compilazione in questo modo, è importante fornire gli stessi parametri di configurazione ogni volta. La definizione di più variabili d'ambiente può aiutarti a evitare errori:

$ 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

Compilatori e flag

Negli esempi sopra Waf per la compilazione ns-3 utilizza il compilatore C++ di GCC ( g++). Tuttavia, è possibile cambiare il compilatore C++ utilizzato, definendo la variabile d'ambiente CXX. Ad esempio, per utilizzare il compilatore C++ Clang, clang++, Waf $ CXX="clang++" ./waf configure $ ./waf build

Allo stesso modo, puoi configurare 

per utilizzare la compilazione distribuita con Waf distcc $ CXX="distcc g++" ./waf configure $ ./waf build:

Ulteriori informazioni su distcc e sulla compilazione distribuita sono disponibili nella pagina del progetto nella sezione "Documentazione". Per aggiungere flag del compilatore durante la configurazione di ns-3, utilizza la variabile d'ambiente CXXFLAGS_EXTRA.

Maggiore informazioni su distcc e sulla compilazione distribuita possono essere trovate nella pagina del progetto nella sezione "Documentazione". Per aggiungere i flag del compilatore durante la configurazione di ns-3, utilizzare la variabile di ambiente CXXFLAGS_EXTRA.

Installazione

Waf può essere utilizzato per installare librerie in diverse posizioni del sistema. Per impostazione predefinita, le librerie e i file eseguibili compilati si trovano nella directory build, e poiché Waf conosce la posizione di queste librerie e file eseguibili, non è necessario installare le librerie da nessun'altra parte.

Se gli utenti preferiscono installare al di fuori della directory di compilazione, possono eseguire il comando ./waf install. Per impostazione predefinita, il prefisso per l'installazione è /usr/local, quindi ./waf install installerà i programmi in /usr/local/bin, le librerie in /usr/local/lib e i file header in /usr/local/include. In genere, è necessario avere i privilegi di superutente per installare con il prefisso predefinito, quindi il comando tipico sarà sudo ./waf install. Al momento dell'esecuzione, Waf darà la priorità all'utilizzo delle librerie comuni nella directory di compilazione, quindi cercherà le librerie nei percorsi delle librerie configurati nell'ambiente locale. Pertanto, durante l'installazione delle librerie nel sistema, è buona pratica verificare che vengano utilizzate le librerie corrette. Gli utenti possono scegliere di installare con un altro prefisso passando durante la configurazione l'opzione --prefix, ad esempio:

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

Se successivamente, dopo la compilazione, l'utente immette il comando di installazione ./waf, verrà utilizzato il prefisso /opt/local.

Team ./waf clean deve essere utilizzato fino a quando il progetto non viene riconfigurato, se l'installazione sarà effettuata Waf con un altro prefisso.

Pertanto, per utilizzare ns-3 non è necessario invocare ./waf install. La maggior parte degli utenti non avrà bisogno di questo comando, poiché Waf recupererà le librerie correnti dalla directory di compilazione, ma alcuni utenti potrebbero trovarlo utile, se la loro attività include l'uso di programmi al di fuori della directory ns-3.

Waf è unico

Nella parte superiore della gerarchia del codice sorgente di ns-3 esiste solo uno script Waf. Iniziare a lavorare significa trascorrere molto tempo nella directory scratch/ o più in profondità insrc/... e avere bisogno di lanciare Waf. Puoi semplicemente ricordare dove sei e avviare Waf nel seguente modo:

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

ma questo sarà noioso e soggetto a errori, quindi ci sono soluzioni migliori. Uno dei modi comuni è utilizzare un editor di testo come emacs o vim, che apre due sessioni del terminale, una utilizzata per compilare ns‑3 e l'altra per modificare il codice sorgente. Se hai solo tarball, allora può aiutarti la variabile d'ambiente:

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

$ cd scratch 
$ waff build

Nella directory del modulo potrebbe sembrare allettante aggiungere uno script waf triviale del tipo exec ../../waf. Per favore, non farlo. Questo confonde i principianti e, se eseguito male, porta a errori di compilazione difficili da individuare. Le soluzioni mostrati sopra sono il percorso da seguire.

3.5 Testing di ns-3

Puoi eseguire i test modulari della distribuzione ns‑3 lanciando lo script ./test.py:

$ ./test.py

Questi test vengono eseguiti in parallelo con Waf. Alla fine dovresti vedere un messaggio che indica che

92 di 92 test superati (92 passati, 0 falliti, 0 crash, 0 errori di valgrind)

Questo è un messaggio importante per identificare guasti, crash o errori di valgrind, indica problemi con il codice o incompatibilità tra gli strumenti e il codice.

Vedrai anche il riepilogo finale da Waf e dal tester che esegue ogni test, che apparirà circa così:

Waf: Entrando nella directory `/path/to/workspace/ns-3-allinone/ns-3-dev/build`
Waf: Uscendo dalla directory `/path/to/workspace/ns-3-allinone/ns-3-dev/build`
'build' completato con successo (1.799s)

Moduli costruiti:
aodv           applicazioni          bridge
click          config-store         core
csma           csma-layout          dsdv
emu            energia              flow-monitor
internet       lte                 mesh
mobilità       mpi                 netanim
rete           nix-vector-routing   ns3tcp
ns3wifi        olsr                openflow
point-to-point point-to-point-layout propagazione
spectrum       stats               tap-bridge
template       test                strumenti
topology-read  uan                 virtual-net-device
visualizer     wifi                wimax

PASS: TestSuite ns3-wifi-interference
PASS: TestSuite istogramma

...

PASS: TestSuite oggetto
PASS: TestSuite generatori-di-numeri-casuali
92 su 92 test superati (92 superati, 0 falliti, 0 bloccati, 0 errori valgrind)

Questo comando viene solitamente eseguito dagli utenti per una rapida verifica della correttezza della costruzione del pacchetto ns-3. (Si noti che l'ordine delle righe "PASS: ..." può variare, questo è normale. L'importante è che nella riga finale alla fine del rapporto tutti i test siano stati superati; nessun test ha fallito o è andato in crash.) E Waf, e test.py verranno parallelizzati tramite i core disponibili della macchina.

3.6 Eseguire lo script

Di solito eseguiamo script sotto controllo Waf. Questo consente al sistema di build di garantire che i percorsi verso la libreria condivisa siano impostati correttamente e che le librerie siano disponibili al momento dell'esecuzione. Per avviare il programma, basta utilizzare Waf con il parametro -run. Avviamo per ns-3 l'equivalente del programmino universale hello world, digitando quanto segue:

$ ./waf --run hello-simulator

Waf verificherà prima che il programma sia compilato correttamente e, se necessario, eseguirà la compilazione. Quindi Waf eseguirà il programma, che produrrà il seguente output.

Hello Simulator

Congratulazioni! Ora sei un utente di ns-3!

Cosa devo fare se non vedo il risultato?

Se vedi messaggi Waf, che indicano che la compilazione è stata completata con successo, ma non vedi l'output "Hello Simulator", c'è la probabilità che tu abbia cambiato la modalità di build nella sezione [Build-with-Waf] ottimizzate, ma hai saltato il passaggio per tornare alla modalità debug. Tutto l'output della console utilizzato in questa guida utilizza un componente speciale ns-3, che gestisce la registrazione dei log e viene utilizzato per stampare messaggi personalizzati nella console. L'output di questo componente è automaticamente disabilitato quando si compila il codice ottimizzato - è "ottimizzato". Se non vedi l'output "Hello Simulator", inserisci quanto segue:

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

per configurare Waf la costruzione delle versioni di debug dei programmi ns-3, che includono esempi e test. Quindi devi ricompilare l'attuale versione di debug del codice, digitando

$ ./waf

Ora, se esegui il programma hello-simulator, dovresti vedere il risultato atteso.

3.6.1 Argomenti della riga di comando

Per passare argomenti da riga di comando al programma ns-3, usa questo modello:

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

Sostituisci con il nome del tuo programma e con gli argomenti. L'argomento -command-template per Waf è, sostanzialmente, una ricetta per costruire la riga di comando effettiva. Waf utilizzato per eseguire il programma. Waf verifica che la compilazione sia completata, imposta i percorsi della libreria condivisa e, utilizzando il modello di riga di comando fornito e sostituendo il nome del programma al posto del segnaposto %s, chiama l'eseguibile. Se questo tipo di sintassi ti sembra complesso, esiste un'alternativa più semplice che include il programma ns-3 e i suoi argomenti racchiusi tra virgolette singole:

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

Un altro esempio particolarmente utile è l'esecuzione selettiva di set di test. Supponiamo che ci sia un insieme di test (suite) mytest (che in realtà non esiste). Sopra, abbiamo utilizzato lo script ./test.py per eseguire parallelamente una serie di test, che chiama ripetutamente il programma di test test-runner. Chiamarlo test-runner direttamente per eseguire un singolo test:

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

Gli argomenti saranno passati al programma test-runner. Poiché mytest non esiste, verrà generato un messaggio di errore. Per stampare i parametri disponibili di test-runner, inserisci:

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

3.6.2 Debugging

Per eseguire programmi ns‑3 con un'altra utility, come un debugger (ad esempio, gdb) o uno strumento di verifica della memoria (ad esempio, valgrind), utilizza una forma simile - -command-template = "…". Ad esempio, per eseguire il debugger gdb il tuo programma hello-simulator ns‑3 con gli argomenti:

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

Nota che il nome del programma ns‑3 viene fornito con un argomento -run, e l'utility di gestione (qui gdb) è il primo token nell'argomento -command-template. L'opzione - -args riporta gdb, il che significa che il resto della riga di comando appartiene al "programma inferiore". (Alcune versioni gdb non comprendono l'opzione - -args. In questo caso, rimuovi gli argomenti del programma da -command-template e utilizza il set di comandi gdb args.) Possiamo combinare questa ricetta e la precedente per eseguire un test sotto il debugger:

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

3.6.3 Directory di lavoro

Waf deve essere eseguito dalla sua posizione nella parte superiore della directory ns‑3. Questa cartella diventa la directory di lavoro, dove verranno scritti i file di output. Ma cosa fare se desideri mantenere questi file al di fuori della directory sorgente ns‑3? Usa l'argomento - -cwd:

$ ./waf --cwd=...

Potrebbe esserti più comodo ricevere i file di output nella tua directory di lavoro. In questo caso, un'azione indiretta potrebbe essere d'aiuto:

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

Questa decorazione della versione precedente del comando preserva la directory di lavoro attuale, passa alla directory Waf, e poi istruisce Waf per riportare la directory di lavoro alla posizione salvata prima di lanciare il programma nella directory di lavoro attuale. Menzioniamo il comando - -cwd per completezza, la maggior parte degli utenti esegue semplicemente Waf dalla directory principale e genera i file di output lì.

Continua: capitolo 4

Fonte: habr.com