🥇ns-3 võrgu simulaatori õpetus. Peatükk 5

peatükid 1,2
peatükk 3
peatükk 4

5 Seadistus
5.1 Logimise mooduli kasutamine
5.1.1 Logimise ülevaade
5.1.2 Logimise lubamine
5.1.3 Logimise lisamine teie koodile
5.2 Käskluste argumetide kasutamine
5.2.1 Vaikimisi atribuutide väärtuste ülekirjutamine
5.2.2 Teie enda käskluste püüdmine
5.3 Jälgimissüsteemi kasutamine
5.3.1 ASCII jälgimine
ASCII jälgimise analüüs
5.3.2 PCAP jälgimine

Peatükk 5

Seadistamine

5.1 Logimise mooduli kasutamine

Oleme juba lühidalt vaadanud ns‑3 logimise moodulit, vaadates skripti first.cc. Käesolevas peatükis uurime lähemalt logimise alam-süsteemi kasutamise võimalusi.

5.1.1 Logimise ülevaade

Paljud suured süsteemid toetavad mingit tüüpi sõnumite registreerimise vahendit ning ns‑3 ei ole erand. Mõnel juhul salvestatakse „operaatori konsoolisse“ (mis tavaliselt on stderr Unix-põhistes süsteemides) ainult veateateid. Muudes süsteemides võivad väljenduda hoiatussõnumid ja ka põhjalikum teave. Mõnel juhul kasutatakse logimise vahendeid tõrkeotsingu sõnumite väljundiks, mis võivad kiiresti väljundi "uduseks" muuta.

ns‑3-s kasutatav logimisprotsess eeldab, et kõik need teavitustasemed on kasulikud, ning pakume valikulist, mitmetasandilist lähenemist sõnumite registreerimisele. Logimine võib olla täielikult välja lülitatud, aktiveeritud üksikutele komponentidele või globaalses mõõtkavas. Selleks on kohandatavad teavitustasemed. ns‑3 logimismodul pakub suhteliselt lihtsat viisi kasuliku teabe saamiseks teie simuleerimisest.

Te peaksite mõistma, et pakume universaalset mehhanismi — jälgimist — andmete väljavõtmiseks teie mudelitest, mille tuleks eelistada simuleerimise käigus (meie jälgimissüsteemi kohta lisainfoks vaadake õpetuse peatükki 5.3). Logimine peaks olema eelistatud meetod, millega saada tõrketeavet, hoiatusi, veateateid või kiiresti edastada sõnumeid oma stsenaariumidest või mudelitest igal ajal.

Praegu on süsteemis määratletud seitse logisõnumite taset (tüüpi) teavitustaseme järgi kasvavas järjekorras.

LOG_ERROR — veateadete registreerimine (seotud makro: NS_LOG_ERROR);
LOG_WARN — hoiatuste registreerimine (seotud makro: NS_LOG_WARN);
LOG_DEBUG — suhteliselt harvaesinevate spetsiaalsete tõrketeadete registreerimine (seotud makro: NS_LOG_DEBUG);
LOG_INFO — teabe registreerimine programmi käitamise kohta (seotud makro: NS_LOG_INFO);
LOG_FUNCTION — iga kutsutud funktsiooni kirjeldavate teadete registreerimine (kaks seotud makrot: NS_LOG_FUNCTION, mida kasutatakse liikmete funktsioonide jaoks, ja NS_LOG_FUNCTION_NOARGS, mida kasutatakse staatiliste funktsioonide jaoks);
LOG_LOGIC — funktsiooni sees toimuva loogilise voolu kirjeldavate teadete registreerimine (seotud makro: NS_LOG_LOGIC);
LOG_ALL — kõigi ülaltoodud registreerimine (seotud makrot ei ole).
Iga tüübi (LOG_TYPE) jaoks on olemas ka LOG_LEVEL_TYPE, mis, kui seda kasutatakse, lubab registreerida lisaks oma tasemele kõik kõrgemad tasemed. (Seega on LOG_ERROR ja LOG_LEVEL_ERROR ning LOG_ALL ja LOG_LEVEL_ALL funktsionaalselt ekvivalentsed.) Näiteks LOG_INFO lubamine lubab ainult NS_LOG_INFO makrotoimingutega esitatud sõnumeid, samas kui LOG_LEVEL_INFO lubamine hõlmab ka NS_LOG_DEBUG, NS_LOG_WARN ja NS_LOG_ERROR makrotoimingutega esitatud sõnumeid.

Pakume ka tingimusteta logimise makrot, mis kuvatakse alati, olenemata logimistaseme või komponentide valikust.

NS_LOG_UNCOND — tingimusteta logimine seotud sõnumi jaoks (ilma seotud logimistaseta).

Iga taset saab küsida eraldi või kumulatiivselt. Logimist saab konfigureerida keskkonnamuutujaga NS_LOG või süsteemifunktsiooni registreerimise kaudu. Nagu eespool näidatud, on logimisüsteemil Doxygeni dokumentatsioon ja nüüd on see õige aeg seda vaadata, kui te pole seda veel teinud.

Nüüd, kui olete dokumentatsiooni väga põhjalikult läbi lugenud, kasutame neid teadmisi, et saada huvitavat teavet näidisstsenaariumi põhjal. scratch/myfirst.cc, mille olete juba kompileerinud.

5.1.2 Logimise lubamine

Kasutame keskkonnamuutujat NS_LOG, et käivitada veel mõned logid, kuid kõigepealt, et orienteeruda, käivitage viimane skript nagu te varem tegite,

$ ./waf --run scratch/myfirst

Te peaksite nägema juba tuttavat väljundit esimese näidisprogrammi kohta ns-3.

$ Waf: sisenemine katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: väljumine kataloogist `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' 'build'
valmis edukalt (0.413s)
Saadetud 1024 baiti aadressile 10.1.1.2
Saadetud 1024 baiti aadressilt 10.1.1.1
Saadetud 1024 baiti aadressilt 10.1.1.2

Leidub, et 'saadetud' ja 'vastu võetud' sõnumid, mida näete ülal, on tegelikult logitud sõnumid rakendusest UdpEchoClientApplication ja UdpEchoServerApplication. Näiteks võime paluda kliendirakendusel trükkida lisainfot, seadistades selle logimise taseme keskkonnamuutujaga NS_LOG.

Olen nüüd veendunud, et kasutate sh-sarnast kest, mis kasutab süntaksi „VARIABLE = value“. Kui kasutate csh-sarnast kesta, peate mu näited teisendama süntaksiks „setenv variable value“, mida need kestad nõuavad.

Praegu vastab UDP ehekliendi rakendus järgmisele koodireale scratch/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

See aktiveerib LOG_LEVEL_INFO logimistaseme. Kui me edastame logimistaseme lippu, lülitame me tegelikult selle taseme ja kõik madalamad tasemed sisse. Antud juhul oleme sisse lülitanud NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN ja NS_LOG_ERROR. Saame logimistaset tõsta ja rohkem teavet saada, ilma skripti muutmata ja uuesti kompileerimata, seadistades keskkonnamuutujat NS_LOG järgmiselt:

$ export NS_LOG=UdpEchoClientApplication=level_all

Nii seadistame sh-keskkonna muutujale NS_LOG järgmise väärtuse.

UdpEchoClientApplication=level_all

Vasak pool määramisest on registreeritava komponendi nimi, mida soovime seadistada, ja parem pool on lipp, mida soovime selle jaoks rakendada. Antud juhul kavatseme rakenduses aktiveerida kõik tõrkeotsingu tasemed. Kui käitate skripti selliselt seadistatud NS_LOG-iga, võtab ns-3 logimissüsteem muudatused vastu ja peaksite nägema järgmist väljundit:

Waf: Sisenemine katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Väljumine kataloogist `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' lõppes edukalt (0.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Saadetud 1024 baiti aadressile 10.1.1.2
Saadetud 1024 baiti aadressilt 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Saadetud 1024 baiti aadressilt 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Rakenduse pakutav täiendav tõrkeotsingu teave vastab nüüd NS_LOG_FUNCTION tasemele. See näitab igat funktsiooni kutsumise juhtumit skripti käitamise ajal. Üldiselt on funktsioonide puhul eelistatav kasutada (vähemalt)NS_LOG_FUNCTION (this). Kasutage NS_LOG_FUNCTION_NOARGS ()
ainult staatilistes funktsioonides. Siiski, pidage meeles, et ns‑3 süsteemis ei ole nõudeid mis tahes logimise funktsionaalsuse säilitamiseks. Otsus, kui palju teavet registreeritakse, jääb mudeli arendaja otsustada. Kaja rakenduste puhul on logimiseks saadaval suur hulk väljundit.

Nüüd saate vaadata rakenduse poolt tehtud funktsioonikutsumise logi. Kui vaatate tähelepanelikult, märkate kahe punkti vahel rida UdpEchoClientApplication ja meetodi nime, seal, kus olete võib-olla oodanud näha C++ nähtavuse operaatorit (::). See on tehtud sihikindlalt.

Tegelikult ei ole see klassi nimi, vaid logimise komponendi nimi. Kui lähtefaili ja klassi vahel on vastavus, on see tavaliselt klassi nimi, kuid peate mõistma, et see ei ole tegelikult klassi nimi, ja seal on üks käik, mitte kaks. See on viis aidata teil konceptuaalselt eristada logimise komponendi nime klassi nimest.

Siiski, mõnel juhul võib olla keeruline kindlaks teha, milline meetod tegelikult logi sõnumi genereerib. Kui vaatate ülaltoodud teksti, tekib teil küsimus, kust tuli rida „Treceived 1024 bytes from 10.1.1.2”. Selle probleemi lahendamiseks saate seadistada taseme prefix_func NS_LOG keskkonnamuutujasse. Proovige järgmist,

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Pange tähele, et jutumärgid on vajalikud, kuna vertikaalne joon, mida kasutame ORE-operatsiooni tähistamiseks, on ka Unix'i torude ühendaja. Nüüd, kui käitate skripti, näete, et logimissüsteem tagab, et iga antud logi sõnumil on komponendi nimel eelfikseer.

Waf: Sisen katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Lahkumas katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' lõpetati edukalt (0.417 s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SeadistaAndmeSuurus(1024)
UdpEchoClientApplication:AlustaRakendust()
UdpEchoClientApplication:AjakavaEdastamine()
UdpEchoClientApplication:Saata()
UdpEchoClientApplication:Saata(): Saadetud 1024 baiti aadressile 10.1.1.2
Saadud 1024 baiti aadressilt 10.1.1.1
UdpEchoClientApplication:KäsitleRead(0x6241e0, 0x624a20)
UdpEchoClientApplication:KäsitleRead(): Saadud 1024 baiti aadressilt 10.1.1.2
UdpEchoClientApplication:PeataRakendus()
UdpEchoClientApplication:KäivitaHävitamine()
UdpEchoClientApplication:~UdpEchoClient()

Nüüd saate näha, et kõik UDP echo-klientrakendusest saadetud sõnumid on tähistatud vastavaks. Sõnum „Treceived 1024 bytes from 10.1.1.2“ on nüüd selgelt määratletud kui echo-kliendilt saadetud. Ülejäänud sõnum peab tulema UDP echo-serveri rakendusest. Saame selle komponendi kaasata, sisestades NS_LOG keskkonnamuutujasse komponente, mis on eraldatud kolonidega.

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func:
               UdpEchoServerApplication=level_all|prefix_func'

Hoiatus: ülaltoodud tekstinäidises peate uue rea sümboli (: ) eemaldama, kuna see on kasutatud dokumendi vormindamiseks. Nüüd, kui teil on skript käivitatud, näete kõiki logiteateid kliendi- ja serveri-eho rakendustest. See võib olla väga kasulik silumise käigus.

Waf: Sisenemine katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Väljumine kataloogist `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' lõpetatud edukalt (0.406s)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoServerApplication:StartApplication()
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Saadeti 1024 bitti aadressile 10.1.1.2
UdpEchoServerApplication:HandleRead(): Vastatud 1024 bitti aadressilt 10.1.1.1
UdpEchoServerApplication:HandleRead(): Pakett peegeldatakse
UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
UdpEchoClientApplication:HandleRead(): Vastatud 1024 bitti aadressilt 10.1.1.2
UdpEchoServerApplication:StopApplication()
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Samuti on mõnikord kasulik näha simulatsiooni aega, millal logiteade loodi. Sa saad seda teha, lisades ILI bitti. prefix_time:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func|prefix_time: UdpEchoServerApplication=level_all|prefix_func|prefix_time'

Pealegi peate eemaldama eelneva reavahe. Kui nüüd skripti käivitate, peaksite nägema järgmist väljundit:

Waf: Siseneme katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Lahkume kataloogist `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' lõpetati edukalt (0.418s)
0s UdpEchoServerApplication:UdpEchoServer()
0s UdpEchoClientApplication:UdpEchoClient()
0s UdpEchoClientApplication:SetDataSize(1024)
1s UdpEchoServerApplication:StartApplication()
2s UdpEchoClientApplication:StartApplication()
2s UdpEchoClientApplication:ScheduleTransmit()
2s UdpEchoClientApplication:Send()
2s UdpEchoClientApplication:Send(): Saadeti 1024 baiti aadressile 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Vastatud 1024 baiti aadressilt 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Paketi kajastamine
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Vastatud 1024 baiti aadressilt 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Pange tähele, et konstruktori jaoks UdpEchoServer kutsuti simuleerimise 0 sekundi ajal. See toimub tegelikult enne simuleerimise algust, kuid see aeg kuvatakse kui null sekundit. Sama kehtib ka konstruktori sõnumi kohta UdpEchoClient.

Waf: Siseneme katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Lahkume kataloogist `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' lõpetati edukalt (0.418s)
0s UdpEchoServerApplication:UdpEchoServer()
0s UdpEchoClientApplication:UdpEchoClient()
0s UdpEchoClientApplication:SetDataSize(1024)
1s UdpEchoServerApplication:StartApplication()
2s UdpEchoClientApplication:StartApplication()
2s UdpEchoClientApplication:ScheduleTransmit()
2s UdpEchoClientApplication:Send()
2s UdpEchoClientApplication:Send(): Saadeti 1024 baiti aadressile 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Vastatud 1024 baiti aadressilt 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Paketi kajastamine
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Vastatud 1024 baiti aadressilt 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Tuletame meelde, et skript scratch/first.cc käivitab koheselt ökoserveri rakenduse ühe sekundi jooksul simuleerimise algusest. Nüüd näete, et meetod StartApplication serverit kutsutakse tegelikult välja esimese sekundi jooksul. Samuti võite märgata, et ökokliendi käivitamine toimub simuleerimise teisel sekundil, nagu soovisime skriptis.

Nüüd saate jälgida simuleerimise kulgu kutsumise kaudu ScheduleTransmit kliendis, mis kutsub esile Send tagasikutsumise HandleRead ökoserveri rakenduses. Pange tähele, et kahesuunalise lingi kaudu paketi saatmise aeg on 3,69 millisekundit. On näha, et ökoserver logib teadet, et ta vastas paketile, ja seejärel, pärast kanaliseretardi, näete, et ökokliendi HandleRead meetodis saabub öko-pakett.

Selles simuleerimises toimub palju, mis jääb teile märkamatuks. Kuid saate kogu protsessi väga lihtsalt jälgida, lubades süsteemis kõikide komponentide logimist. Proovige määrata muutuja NS_LOG järgmine väärtus,

$ export 'NS_LOG=*=level_all|prefix_func|prefix_time'

Yllä oleva tähti on lokikomponentin wildcard, joka mahdollistaa kaikkien lokimerkintöjen sisällyttämisen kaikista komponenteista simulaatiossa. En toista tulostusta täällä (artikkelin kirjoitushetkellä se tuottaa 1265 riviä tulostusta yhdelle echo-paketille), mutta voit ohjata tämän tiedon tiedostoon ja tarkastella sitä suosikkieditorissasi.

$ ./waf --run scratch/myfirst > log.out 2>&1

Ma kasutan seda ülimalt detailsed logimise versiooni, kui mul tekib probleem ja mul pole aimugi, kus midagi valesti läks. Ma saan koodi täitmist üsna lihtsalt jälgida, ilma et peaksin seadma katkestuspunktide ja samm-sammult koodi jõudma tõrkedebugeerijasse. Ma võin lihtsalt väljundit mu lemmiktoimetajas redigeerida ja otsida seda, mida ootan, ja näha, mis toimub, mida ma ei oodanud. Kui mul on üldine ettekujutus sellest, mis valesti läheb, siis lähen ma tõrkedebugeerijasse, et probleemile süvitsi minna. Selline väljund võib olla eriti kasulik, kui teie skript teeb midagi täiesti ootamatut. Kui kasutate ainult tõrkedebugeerijat, võite ootamatud pöörded täielikult tähelepanuta jätta. Logimine teeb need pöörded märgatavaks.

5.1.3 Logimise lisamine teie koodile

Saate lisada oma simuleerimisse uusi kirjeid, tehes log komponendi üleskutsed mitmest makrotest. Teeme seda skriptis myfirst.cc, mida me omaniku „puhas“ kaustas. Tuletame meelde, et oleme sellel skriptil määratlenud logimise komponendi:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Teadsite, et saate selle komponendi kõigi sõnumite logimise lubamiseks seada keskkonnamuutujat NS_LOG erinevatele tasanditele. Jätkame ja lisame mõned kirjed skripti. Makro, mida kasutatakse teatesõnumite logimiseks, on NS_LOG_INFO. Lisame sõnumi (vahetult enne, kui hakkame sõlme looma), mis ütleb teile, et stsenaarium on topoloogia loomise etapis ("Creating Topology"). See tehakse järgmises koodifragmendis,
Avage scratch/myfirst.cc oma lemmiktoimetajas ja lisage rida,
NS_LOG_INFO ("Creating Topology");
otse ridade ees,

NodeContainer nodes;
nodes.Create (2);

Nüüd kompileerige skript, kasutades waf, ja tühjendage muutujat NS_LOG, et keelata logimisvoog, mille me varem lubasime:

$ ./waf
$ export NS_LOG=
Nüüd, kui te käivitate skripti,
$ ./waf --run scratch/myfirst

, siis te ei näe uut sõnumit, kuna seotud logimise komponent (FirstScriptExample) ei olnud lubatud. Et näha teie sõnumit, peate lubama logimiskomponendi FirstScriptExample logitase taseme seadistamine peab olema vähemalt NS_LOG_INFO. Kui soovite lihtsalt näha seda konkreetset logimist, saate selle sisse lülitada nii,

$ export NS_LOG=FirstScriptExample=info

Kui käivitate skripti nüüd, näete uut sõnumit «Loome topoloogiat»,

Waf: Sisenen kausta `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Lahkun kaustast `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' lõpetati edukalt (0.404s)
Loome topoloogiat
Saadetud 1024 baiti aadressile 10.1.1.2
Saadi 1024 baiti aadressilt 10.1.1.1
Saadi 1024 baiti aadressilt 10.1.1.2

5.2 Käskluste argumetide kasutamine

5.2.1 Vaikimisi atribuutide väärtuste ülekirjutamine

Teine viis ns‑3 skriptide käitumise muutmiseks ilma redigeerimise ja kompileerimiseta on kasutada käsurea argumente. Me pakume mehhanismi, mis tõlgendab käsurea argumente ja seadistab automaatselt kohalikke ja globaalseid muutujaid vastavalt tulemustele.

Esimene samm käsurea argumentide süsteemi kasutamisel on käsurea parsimise programmi kuulutamine. Seda on üsna lihtne teha (oma põhiprogrammis), nagu järgmises koodis,

int
main (int argc, char *argv[])
{
...
CommandLine cmd;
cmd.Parse (argc, argv);
...
}

See lihtne kahekohaline fragment on tegelikult iseenesest väga kasulik. See avab ukse globaalsetele muutujaile ns‑3 ja atribuutide süsteemile. Lisaime skripti peafunktsiooni algusesse kaks rida koodi. scratch/myfirst.ccLiikudes edasi, kompileerime stsenaariumi ja käivitame selle, käivitamisel teeme abiküsimuse järgmiselt:

$ ./waf --run "scratch/myfirst --PrintHelp"

See käsk palub Waf käivitada skripti scratch/myfirst ja edastada sellele käsurida argument —PrintHelp. Ümberkütsed on vajalikud, et näidata, mille jaoks see argument mõeldud on. Käskude parsimisprotsess avastab argumendi —PrintHelp ja väljastab vastuse.

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.413s)
TcpL4Protocol:TcpStateMachine()
CommandLine:HandleArgument(): Handle arg name=PrintHelp value=
--PrintHelp: Print this help message.
--PrintGroups: Print the list of groups.
--PrintTypeIds: Print all TypeIds.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintGlobals: Print the list of globals.

Nüüd vaatame valikut —PrintAttributes. Oleme juba maininud ns‑3 atribuutide süsteemi, kui uurisime skripti first.cc. Oleme näinud järgmisi koodi ridu,

PointToPointHelper pointToPoint;
pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));
pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));

ja öeldi, et DataRate on tegelikult atribuut PointToPointNetDevice. Rakendame argumentide analüüsijat atribuutide vaatamiseks PointToPointNetDevice. Abilisti kohaselt peame esitama TypeId. See on klassi nimi, millele huvipakkuvad atribuudid kuuluvad. Meie puhul on see ns3::PointToPointNetDevice. Liigume edasi, sisestage

$ ./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointNetDevice"

Süsteem prindib välja kõik selle tüüpi võrgu seadme atribuudid. Näete, et loendis on atribuutide seas

--ns3::PointToPointNetDevice::DataRate=[32768bps]:
Vaikimisi andmeedastuskiirus punkt-punkti ühenduste jaoks

See on vaikimisi väärtus, mida süsteem kasutab objekti loomisel PointToPointNetDevice. Üle kirjutame selle vaikimisi väärtuse parameetriga Attribute ühes PointToPointHelper üle. Kasutame vaikimisi väärtusi punkt-punkt seadmete ja kanalite jaoks. Selleks eemaldame kutsed SetDeviceAttribute ja SetChannelAttribute kohast myfirst.cc, mis meil on puhtas kataloogis.

Teie skript peaks nüüd lihtsalt deklareerima PointToPointHelper ja mitte teha mingeid installimisoperatsioone, nagu on näidatud allpool olevas näites,

...
NodeContainer nodes;
nodes.Create (2);
PointToPointHelper pointToPoint;
NetDeviceContainer devices;
devices = pointToPoint.Install (nodes);
...

Jätkake ja looge uus skript koos Waf (./waf) ja naeme tagasi ja lülitame sisse mõned kirjed UDP kaja serveri rakendusest ning lülitame ajamärgenduse sisse.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Kui käivitate skripti, peaksite nägema järgmist väljundit:

Waf: Sisenedes katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Välja sisenedes katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' lõpetamine õnnestus (0.405s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Saadetud 1024 bitti aadressile 10.1.1.2
2.25732s Vastatud 1024 bitti aadressilt 10.1.1.1
2.25732s Kaja pakett
Vastatud 1024 bitti aadressilt 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Kordame, et eelmisel korral, kui me vaatasime simulatsiooni aega, hetkel, kui kaja server võttis paketi vastu, oli see 2,00369 sekundit.

2.00369s UdpEchoServerApplication:HandleRead(): Vastatud 1024 bitti aadressilt 10.1.1.1

Nüüd saab ta paketi 2.25732 sekundi jooksul. See on tingitud sellest, et me lihtsalt vähendasime PointToPointNetDevice edastuskiirus viiest megabitsist sekundis vaikimisi väärtuseni, mis on 32768 bitti sekundis. Kui me paneksime uue DataRate käsureale, saaksime meie modelleerimise uuesti kiirendada. Teeme seda järgmiselt vastavalt abi elemendi soovitatud valemile:

$ ./waf --run "scratch/myfirst --ns3::PointToPointNetDevice::DataRate=5Mbps"

Tulemuseks naaseb DataRate atribuut vaikimisi viiesse megabitti sekundis. Kas olete tulemusega üllatunud? Selgub, et algse skripti käitumise taastamiseks peame samuti seadma kanali viivituse vastavaks valguse kiirusale. Saame paluda käsureal süsteemil printida kanali atribuute, samuti nagu me tegime võrgu seadme puhul:

$ ./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointChannel"

Me leiame, et kanali viivituse atribuudi seadistus on järgmine:

--ns3::PointToPointChannel::Delay=[0ns]:
Edastamise viivitus läbi kanali

Seejärel saame käsurea kaudu kahe variandi vaikimisi väärtused seadistada,

$ ./waf --run "scratch/myfirst
--ns3::PointToPointNetDevice::DataRate=5Mbps
--ns3::PointToPointChannel::Delay=2ms"

Selles juhul taastame aja, mis meil oli, kui me seadsime DataRate ja Delay skriptis selgelt:

Waf: Sisenemine katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Väljumine katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' lõpetatud eduka lõpp-punktiga (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Saadetud 1024 baiti aadressile 10.1.1.2
2.00369s Vastatud 1024 baiti aadressilt 10.1.1.1
2.00369s Paketi peegeldamine
Vastatud 1024 baiti aadressilt 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Pange tähele, et pakk on taas serveri poolt saadud 2.00369 sekundi pärast. Tegelikult võiksime sellisel viisil seada mis tahes skriptis kasutatavate atribuutide väärtusi. Eriti võiksime seada MaxPackets atribuutide väärtusi erinevaks kui üks UdpEchoClient.

Kuidas seda kasutaksite? Proovige. Pidage meeles, et peate kommenteerima koha, kus me määrame kasutusele atribuudi vaikeväärtuse ja seame selle selgelt. MaxPackets stenaariumis. Seejärel peate skripti uuesti ehitama. Samuti saate käsurealt abi uue vaikeatribuutide väärtuse seadistamiseks. Kui olete selle selgeks saanud, saate hallata käsureal kuvatavate pakettide arvu. Kuna me oleme põhjalikud, peaks meie käsurea välimus olema umbes selline:

$ ./waf --run "scratch/myfirst
--ns3::PointToPointNetDevice::DataRate=5Mbps
--ns3::PointToPointChannel::Delay=2ms
--ns3::UdpEchoClient::MaxPackets=2"

Loomulik küsimus, mis siin esile kerkib, on, kuidas teada saada kõigi nende atribuutide olemasolust. Taaskord on käsureal selle probleemi lahendamiseks abifunktsioon. Kui küsime käsurealt abi, peaksime nägema:

$ ./waf --run "scratch/myfirst --PrintHelp"
myfirst [Program Arguments] [General Arguments]
General Arguments:
--PrintGlobals: Print the list of globals.
--PrintGroups: Print the list of groups.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintTypeIds: Print all TypeIds.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintHelp: Print this help message.

Kui valite argumendi „PrintGroups”, peaksite nägema kõigi registreeritud gruppide loendit. TypeId. Gruppide nimed vastavad moodulite nimedele lähtekaustas (kuigi suurtähega). Kõigi andmete printimine korraga oleks liiga mahukas, seetõttu on saadaval täiendav filter andmete prindimiseks gruppide kaupa. Keskendudes taas moodulile „punktist punkti”:

./waf --run "scratch/myfirst --PrintGroup=PointToPoint"
TypeIds grupis PointToPoint:
ns3::PointToPointChannel
ns3::PointToPointNetDevice
ns3::PointToPointRemoteChannel
ns3::PppHeader

Siit võite leida saadaval olevad TypeId nimed atribuutide otsimiseks, näiteks
--PrintAttributes = ns3 :: PointToPointChannel, nagu eespool näidatud.

Teine viis atribuutide kohta teabe saamiseks on läbi Doxygen ns‑3. Seal on leht, mis loetleb kõik simulatsioonis registreeritud atribuudid.

5.2.2 Teie enda käskluste püüdmine

Samuti saate käsurea kaudu lisada oma konksud. See on üsna lihtne, kasutades käsurea parsimise meetodit AddValue.
Kasutame seda võimalust, et määrata pakettide arv, mida tuleb kuvada, täiesti teisel viisil. Lisame kohaliku muutuja nimega nPackets funktsiooni main. Me seame selle üheks, et see vastaks meie eelmisele vaikekäitumisele. Selleks, et lubada käsurea parseril seda väärtust muuta, peame selle väärtuse parserisse jäädvustama. Teeme seda, lisades kutsungi AddValue. Minge ja muutke skripti scratch/myfirst.cc nii, et see algab järgmistest koodidest,

int
main (int argc, char *argv[])
{
uint32_t nPackets = 1;
CommandLine cmd;
cmd.AddValue("nPackets", "Pakettide arv, mida kajastada", nPackets);
cmd.Parse(argc, argv);
...

Kerige alla punkti, kus me määrame atribuudi MaxPackets ja muutke seda nii, et see oleks seadistatud muutujale nPackets, mitte konstandile 1, nagu allpool näidatud.

echoClient.SetAttribute ("MaxPackets", UintegerValue(nPackets));

Nüüd, kui käitate skripti ja sisestate argumendi —PrintHelp, peaksite nägema uut kasutajaargumenti, mis kuvatakse abi ekraanil. Sisestage,

$ ./waf --run "scratch/myfirst --PrintHelp"
Waf: Sisenen kausta `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Väljun kaustast `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' lõpetatud edukalt (0.403s)
--PrintHelp: Kuvab selle abi sõnumi.
--PrintGroups: Kuvab rühmade loendi.
--PrintTypeIds: Kuvab kõik TypeId-d.
--PrintGroup=[group]: Kuvab kõik TypeId-d grupist.
--PrintAttributes=[typeid]: Kuvab kõik atribuudid typeid kohta.
--PrintGlobals: Kuvab globaalsete loendi.
Kasutaja argumendid:
--nPackets: Pakettide arv, mida kajastada

Kui soovite muuda edastatavate pakettide arvu, saate seda teha, seadistades käsurea argumendi - -nPackets.

$ ./waf --run "scratch/myfirst --nPackets=2"

Nüüd peaksite nägema

Waf: Sisenemine katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Lahkumine katalooge `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' lõpetatud edukalt (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Saadetud 1024 baiti aadressile 10.1.1.2
2.25732s 1024 baiti saadud aadressilt 10.1.1.1
2.25732s Paketi peegeldamine
Saadud 1024 baiti aadressilt 10.1.1.2
Saadetud 1024 baiti aadressile 10.1.1.2
3.25732s 1024 baiti saadud aadressilt 10.1.1.1
3.25732s Paketi peegeldamine
Saadud 1024 baiti aadressilt 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Olete nüüd saatnud kaks paketti. Üsna lihtne, eks?
Nägite, et ns‑3 kasutajana saate käsurea argumendi süsteemi abil hallata globaalsete väärtuste ja atribuutide seadistusi. Kui olete mudeli autor, saate oma objektidele uusi atribuute lisada, mis on automaatselt kasutajate jaoks käsurea süsteemi kaudu kohandatavad. Kui olete skripti autor, saate lisada uusi muutujaid oma skriptidesse ja neid probleemideta oma käsurea süsteemiga ühendada.

5.3 Jälgimissüsteemi kasutamine

Simulation's core purpose is to generate output for further examination, and the ns-3 tracing system is the primary mechanism for this. Since ns-3 is a C++ program, standard C++ output generation techniques can be utilized.

#include <iostream>
...
int main ()
{
...
std::cout << "The value of x is " << x << std::endl;
...
}

You can even use a logging module to add a bit of structure to your solution. Many issues can arise from this approach, and to address those, we provide a common event tracing subsystem.

The main objectives of the ns-3 tracing system:

For basic tasks, the tracing system should allow users to generate standard traces for popular sources and select the objects that generate the traces.
Intermediate users should be able to extend the tracing system to modify the output format or to insert new tracing sources without modifying the core of the simulator.
Kogenud kasutajad saavad simulaatori põhikoode modifitseerida, et lisada uusi jälgimisallikaid ja vastuvõtjaid. ns-3 jälgimisse süsteem põhineb sõltumatute jälgimisallikate ja vastuvõtjate põhimõtetel, samuti ühtsel mehhanismil allikate ühendamiseks tarbijatega.

ns-3 jälgimisse süsteem põhineb sõltumatute jälgimisallikate ja vastuvõtjate põhimõtetel, samuti ühtsal mehhanismil allikate ühendamiseks vastuvõtjatega. Jälgimisallikateks on objektid, mis suudavad signaalida sündmusi, mis toimuvad simuleerimisel ning tagada juurdepääsu huvipakkuvatele aluseks olevatele andmetele. Näiteks võib jälgimisallikas näidata, millal võrgu seade sai paketi ja tagada juurdepääsu paketi sisule huvipakkuvatele jälgimisvastuvõtjatele.

Jälgimisallikad on iseenesest kasutud, kui need ei ole „seotud“ koodi muude osadega, mis teevad sidujate poolt antud teabega midagi kasulikku. Jälgijad on jälgimisallikate poolt pakutavate sündmuste ja andmete tarbijad. Näiteks võib luua jälgijate jaoks, mis on ühendatud eelmise näite jälgimisallikaga, printimise, et kuvada huvipakkuvaid osi saadud paketist.

Sellise selge eristuse mõistlik alus on võimaldada kasutajatel ühendada uusi tüüpe jälgijaid olemasolevate jälgimisallikatega ilma simulaatori põhijuurde editimata ja uuesti kompileerimata. Seega saab kasutaja ülaltoodud näites määrata uue jälgija oma skriptis ja ühendada selle olemasoleva jälgimisallikaga, mis on määratletud simuleerimise yhi põhikoodis, lihtsalt muutes kasutaja skripti.

Käesolevas juhendis käsitleme mõned määratud allikad ja vastuvõtjad ning näitame, kuidas neid võimalikult vähese kasutaja pingutusega seadistada. Lisainfot eraldi konfiguratsiooni jälgimise kohta leiate ns-3 juhendist või juhiste jaotistest.

5.3.1 ASCII jälgimine

ns-3 pakub abifunktsioone, mis pakuvad madalat jälgimisse süsteemi, et aidata teil hallata lihtsate paketijälgimiste detaile. Kui see funktsioon on lubatud, näete väljundit ASCII failides. Need, kes on tuttavad ns-2 väljundiga, peaksid teadma, et see tüüpi jälgimine on sarnane out.tr, mis on genereeritud arvukate skriptide abil.

Asume aga asja kallale ja lisame mõned ASCII jälgimise tulemused meie skripti scratch/myfirst.cc. Just enne Simulator::Run(), lisage järgmised koodiread:
AsciiTraceHelper ascii;

pointToPoint.EnableAsciiAll(ascii.CreateFileStream("myfirst.tr"));

Nagu paljudes teistes ns‑3 idiomides, kasutab see kood abieksekti ASCII jälgimise loomiseks. Teises reas on kaks vähemasti meetodi kutsumist. CreateFileStream () kasutab anonüümse objekti idiomi, et luua faili voogude objekt virnas (ilma objekti nime) ja edastab selle kutsutud meetodile. Tulevikus süveneme sellesse, kuid kõik, mida peate selle etapi kohta teadma, on see, et loote objekti, mis esindab faili nimega myfirst.tr ja edastama selle ns‑3-le. Me usaldame ns‑3-nendel kaetud objektide haldamise kogu nende eluea jooksul, mille jooksul lahendatakse C++ voogude objektide kopeerimise konstruktoritega seotud vähe tuntud (eesmärgiliselt) piirangud.

Väline kutsumine EnableAsciiAll() teavitab abieksekti, et soovite oma simulatsioonis lubada ASCII jälgimist kõigi punkt-punkt seadmeühenduste jaoks ja et soovite, et (määratud) jälgijad salvestaksid teavet pakettide edasiviimise kohta ASCII formaadis.

Ns-2-iga tuttavatele on jälgitavad sündmused võrdsed tuntud jälgimispunktidega, mis logivad sündmusi „+“, „-“, „d“ ja „r“.
Nüüd saate skripti kokku panna ja käivitada selle käsurealt:

$ ./waf --run scratch/myfirst

Nagu ka varem, näete mitmeid Wafi teateid ja seejärel „'build' finished successfully“ (ehitamine õnnestus) koos arvukate teadete osalevast programmist.

Töötades loob programm faili nimega myfirst.tr. Erinevuste tõttu Waf, loodetakse vaikimisi, et fail ei luuakse kohalikus kataloogis, vaid ülemise taseme hoidlas. Kui soovite muuta teed, kuhu jälgimisfailid salvestatakse, saate Wafi jaoks kasutada parameetrit --cwd. Kui me seda ei teinud, peame, et vaadata ASCII jälgimisfaili myfirst.tr oma lemmikredaktoris, minema ülemise taseme hoidla katalooge.

ASCII jälgimise analüüs

Seal on palju teavet üsna tihedas vormis, kuid esimesena, millele tähelepanu pöörata, on see, et fail koosneb eraldi ridadest. See muutub selgelt nähtavaks, kui laiendate vaatamisaknate.

Iga rida failis vastab jälgimisüritusele. Antud juhul jälgime ülekande järjekorras tekkivaid sündmusi, mis on olemas igas võrkuühenduspunktis simuleerimisel. Ülekande järjekord on järjekord, mille kaudu peab iga pakett minema punkt-punkt kanali jaoks. Pange tähele, et iga rida jälgimisfailis algab ühekordse sümboliga (ja selle järel on tühik). See sümbol will have the following meaning:

+: seadme järjekorras toimus järjekorda panemise operatsioon;
-: seadme järjekorras toimus elemendi eemaldamise operatsioon;
d: pakett oli tagasi lükatud, tavaliselt selle tõttu, et järjekord on täis;
r: pakett oli võrkuühendusse saadetud seadme poolt saadud.

Vaatame jälgimisfaili esimest rida lähemalt. Jagame selle osadeks (selguse huvides) ja ridade numbritega vasakul:

0 +
1 2
2 /NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue
3 ns3::PppHeader (
4   Punkt-punkt protokoll: IP (0x0021))
6   ns3::Ipv4Header (
7     tos 0x0 ttl 64 id 0 protokoll 17 offset 0 flags [none]
8     pikkus: 1052 10.1.1.1 > 10.1.1.2)
9     ns3::UdpHeader (
10      pikkus: 1032 49153 > 9)
11      Koormus (suurus=1024)

Selle pikendatud jälgimise sündmuse esimene jaotis (rida 0) on tehing. Siin on meil sümbol +, mis vastab edastusjärjekorda panemise tehingule. Teine jaotis (rida 1) on simuleerimise aeg, väljendatuna sekundites. Te võite meenutada, et palusime UdpEchoClientApplication alustada pakettide saatmist kahe sekundi pärast. Siin näeme kinnitust, et see tõepoolest toimub.

Järgmisest jälgimisnäite jaotusest (alates reast 2) selgub, milline jälgimisallikas selle sündmuse tekitab (näidatakse jälgimisruumi nime). Võite kujutada, et jälgimisruum on rohkem nagu failisüsteemi ruum. Jälgimisruumi juur on NodeList. See vastab konteinerile, mida haldab peamine ns-3 kood. Sellesse kuuluvad kõik sõlmed, mis skriptis loodakse. Nii nagu failisüsteemis võivad juured sisaldada ka kaustu, NodeList meil võib olla mitu sõlme. Seega, rida /NodeList/0 viitab null sõlmele NodeList'is, mida me tavaliselt mõtleme kui 'sõlm 0'. Igal sõlmel on seadmete loetelu, mis on paigaldatud. See loetelu asub järgmises nimekirjas. Näete, et see jälgimise sündmus pärineb DeviceList/0, mis on seadme null, mis on paigaldatud sõlmes.

Järgmine alamrida, $ ns3 :: PointToPointNetDevice, teatab, milline seade asub null positsioonis: seadmete loetelu null sõlmes. Tuletame meelde, et operatsioon +, mis asus real 0, tähendas, et seadme edastusjärjekorda lisati element. See peegeldub viimastes 'rada jälgimise' segmentides: TxQueue/Enqueue.

Ülejäänud lõigud jälgimises peaksid olema piisavalt arusaadavad. Rida 3-4 näitab, et pakett on kapseldatud punkt-punkt protokollis. Rida 5-7 näitab, et paketil on IP4 versiooni pealkiri ja see pärineb IP-aadressist 10.1.1.1 ja on suunatud 10.1.1.2. Rida 8-9 näitab, et sellel paketil on UDP pealkiri ja viimaks rida 10 näitab, et kasuliku koormuse oodatud suurus on 1024 baiti.

Järgmine rida jälgimisfailis näitab, et sama pakk on välja võetud edastusjärjekorrast samas sõlmes.

Kolmas rida jälgimisfailis näitab, et pakk on vastu võetud võrgu seadme poolt sõlmes, kus asub kaja-server. Ma olen selle sündmuse allpool uuesti esitanud.

0 r
1 2.25732
2 /NodeList/1/DeviceList/0/$ns3::PointToPointNetDevice/MacRx
3   ns3::Ipv4Header (
4     tos 0x0 ttl 64 id 0 protokoll 17 offset 0 flags [none]
5     pikkus: 1052 10.1.1.1 > 10.1.1.2)
6     ns3::UdpHeader (
7       pikkus: 1032 49153 > 9)
8       Kasutajaandmed (suurus=1024)

Pange tähele, et jälgimisoperaator on nüüd r, ja simulatsiooni aeg on suurenenud 2,25732 sekundini. Kui olete täpselt järginud õpikuteavet, siis see tähendab, et olete jätnud võrgu seadmete andmeedastuskiirus ja kanali latentsuse nende vaikeseadetesse. See aeg peaks olema tuttav, nagu olete juba eelnevas osas näinud.

Jälgimise nimekiri (rida 2) on muudetud, et peegeldada, et see sündmus pärineb sõlmest 1 (/NodeList/1) и пакет принят источником трассировки (/MacRx). Te peaksite olema suhteliselt lihtne jälgida paki liikumist läbi topoloogia, vaadates jälgimisfailist jäetud andmeid.

5.3.2 PCAP jälgimine

ns-3 seadmete abivahendeid saab kasutada ka .pcap formaadis jälgimisfailide loomiseks. Lühend pcap (tavaliselt kirjutatakse väike täht) tähistab paketisid ning on tegelikult API, mis hõlmab .pcap faili formaadi määratlemist. Kõige populaarsem programm, mis suudab seda formaati lugeda ja kuvada, on Wireshark (varem tuntud kui Ethereal). Siiski on palju liiklusjälgimise analüsereid, mis kasutavad seda paketi formaati. Soovitame kasutajatel kasutada mitmeid tööriistu, mis on saadaval pcap jälgede analüüsimiseks. Selles juhendis keskendume pcap jälgede vaatamisele koos tcpdump.

pcap jälgimise aktiveerimine toimub ühe koodireaga.

pointToPoint.EnablePcapAll ("myfirst");

Sisestage see koodirida pärast ASCII jälgimise koodi, mille me just lisasime scratch/myfirst.cc. Pange tähele, et edastasime ainult stringi 'myfirst', mitte 'myfirst.pcap' või midagi sarnast. See on sellepärast, et parameeter on prefiks, mitte täielik faili nimi. Simulatsiooni käigus loob assistent tegelikult jälgimisfaili iga punkt-punkt seadme jaoks. Failide nimed koostatakse prefiksi, sõlme numbri, seadme numbri ja sufiksi ' vastu.pcap».

Meie näites näeme lõpuks faile nimega „myfirst-0-0.pcap» ja «myfirst-1-0.pcap”, mis on 0-seadmest 0 ja 1-seadmest 0 vastavad pcap jälgimise failid. Pärast seda, kui olete lisanud koodi rea pcap jälgimise kaasamiseks, võite skripti tavalises vormis käivitada:

$ ./waf --run scratch/myfirst

Kui vaadata teie distributsiooni tippkatalooge, peaksite nägema kolme faili: ASCII jälgimisfaili myfirst.tr, mille oleme eelnevalt uurinud, faile myfirst-0-0.pcap ja myfirst-1-0.pcap — uusi pcap faile, mille me just genereerisime.

Väljundi lugemine tcpdumpiga

Praegu on pcap failide vaatamiseks kõige lihtsam kasutada tcpdumpi.

$ tcpdump -nn -tt -r myfirst-0-0.pcap
lugemine failist myfirst-0-0.pcap, link-tüüp PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, pikkus 1024
2.514648 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, pikkus 1024
tcpdump -nn -tt -r myfirst-1-0.pcap
lugemine failist myfirst-1-0.pcap, link-tüüp PPP (PPP)
2.257324 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, pikkus 1024
2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, pikkus 1024

Dumpis myfirst-0-0.pcap (kliendi seade) näete, et kaja-pakett saadetakse 2 sekundi jooksul simuleerimise jooksul. Kui vaatate teist dumpi (myfirst-1-0.pcap), näete, et pakett võetakse vastu hetkel 2,257324 sekundit. Teises dumpis näete, et pakett tagastatakse hetkel 2.257324 sekundit ning lõpuks, et pakett saadeti kliendile tagasi esimeses dumpis hetkel 2.514648 sekundit.

Väljundi lugemine Wiresharki abil

Kui te ei ole tuttav Wireshark, on veebisait, kust saate alla laadida programme ja dokumentatsiooni: http://www.wireshark.org/. Wireshark — see on graafiline kasutajaliides, mida saab kasutada nende jälgimisfailide kuvamiseks. Kui teil on Wireshark, saate avada ükskõik millise jälgimisfaili ja kuvada sisu, nagu oleksite paki analüsaatorit kasutades pakette kinni püüdnud.

Allikas: habr.com