ns-3 võrgusimulatori õpetus. Peatükk 5

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

5 Seadistamine
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äskude rida argumentide kasutamine
5.2.1 Vaikimisi atribuudi väärtuste ümbersettemine
5.2.2 Oma käskude 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

Lühipeatükk 5

Seadistamine

5.1 Logimise mooduli kasutamine

Oleme juba lühidalt tutvunud ns‑3 logimise mooduliga, vaadates läbi skripti first.cc. Selles peatükis vaatame lähemalt logimise alamsüsteemi kasutamisvõimalusi.

5.1.1 Logimise ülevaade

Paljud suured süsteemid toetavad mingit tüüpi sõnumite logimise vahendit, ning ns‑3 ei ole erand. Mõnel juhul salvestatakse ainult veateated «operaatori konsooli» (mis on tavaliselt stderr Unix-süsteemides). Teistes süsteemides võivad samuti ilmuda hoiatusteated ja põhjalikum teave. Mõnel juhul kasutatakse logimise vahendeid silumiseteate väljundiks, mis võivad kiiresti «udustada» väljundit.

ns‑3-s kasutatav lähenemine eeldab, et kõik need informatiivsuse tasemed on kasulikud, ja me pakume valikulist, mitme tasandi lähenemist sõnumite logimisele. Logimine võib olla täielikult keelatud, lubatud üksikutele komponentidele või globaalsetes määkmetes. Selleks on kohandatavad informatiivsuse tasemed. ns‑3 logimise moodul pakub suhteliselt lihtsat viisi kasuliku teabe saamiseks teie simuleerimisest.

Te peaksite mõistma, et me pakume universaalset mehhanismi - jälgimist - teie mudelitest andmete saamiseks, mis peaks olema prefektsionaalne väljundiks modelleerimisel (kõige põhjalikuma teabe saamiseks meie jälgimissüsteemi kohta vaadake õpikute osa 5.3). Logimine peaks olema eelmainitud meetod silumiseteabe, hoiatusteate, veateadete saamiseks või sõnumite kiireks väljundiks teie skriptidest või mudelitest igal hetkel.

Praegu on süsteemis määratletud seitse sõnumi logimise taset (tüüpi) informatiivsuse järjekorras.

• LOG_ERROR — vigade registreerimise tegemine (seotud makro: NS_LOG_ERROR);
• LOG_WARN — hoiatavate sõnumite registreerimise tegemine (seotud makro: NS_LOG_WARN);
• LOG_DEBUG — haruldaste eraldi tõrkeotsingu sõnumite registreerimise tegemine (seotud makro: NS_LOG_DEBUG);
• LOG_INFO — teabe registreerimise tegemine programmide käivitamise käigust (seotud makro: NS_LOG_INFO);
• LOG_FUNCTION — sõnumite registreerimise tegemine, mis kirjeldab iga kutsutud funktsiooni (kaks seotud makrot: NS_LOG_FUNCTION, mida kasutatakse liikmeliste funktsioonide jaoks, ja NS_LOG_FUNCTION_NOARGS, mida kasutatakse staatiliste funktsioonide jaoks);
• LOG_LOGIC — sõnumite registreerimise tegemine, mis kirjeldab funktsiooni sees toimuvat loogilist voogu (seotud makro: NS_LOG_LOGIC);
• LOG_ALL — kõigi eespool loetletud registreerimine (seotud makrot pole).
  Iga tüübi (LOG_TYPE) jaoks on samuti tüüp LOG_LEVEL_TYPE, mille kasutamisel võimaldab registreerida lisaks oma tasemele ka kõik tasemed üle selle. (Seega on LOG_ERROR ja LOG_LEVEL_ERROR ning LOG_ALL ja LOG_LEVEL_ALL funktsionaalselt ekvivalentsed.) Näiteks LOG_INFO sisselogimine lubab ainult registreeritud sõnumeid makro NS_LOG_INFO kaudu, kui LOG_LEVEL_INFO on lubatud, hõlmatakse ka sõnumid, mille on edastanud makrod NS_LOG_DEBUG, NS_LOG_WARN ja NS_LOG_ERROR.

Pakume ka tingimusteta logimise makrot, mis kuvatakse alati, olenemata logimise tasemest või valitud komponendist.

• NS_LOG_UNCOND — tingimusteta registreerimine seotud sõnumi jaoks (ilma seotud logimise tasemeta).

Iga taset saab küsida eraldi või kumulatiivselt. Logimist saab seadistada keskkonnamuutujaga NS_LOG või registreerimise kaudu süsteemi funktsiooni kutsega. Nagu eelnevalt näidatud, on logimissüsteemil Doxygeni dokumentatsioon, ja nüüd on õige aeg seda vaadata, kui te pole seda veel teinud.

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

5.1.2 Logimise lubamine

Kasutame keskkonnamuutujat NS_LOG, et käivitada veel mõned logid, kuid esmalt, lihtsalt selleks, et orienteeruda, käitage viimane skript, nagu te varem tegite.

$ ./waf --run scratch/myfirst

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

$ Waf: Sisen kataloog `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Lahkumine kataloogist `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build' 'build'
valmistamine lõppes edukalt (0.413s)
Saadetud 1024 baiti aadressile 10.1.1.2
Saadi 1024 baiti aadressilt 10.1.1.1
Saadi 1024 baiti aadressilt 10.1.1.2

Selgub, et "saadetud" ja "saadud" sõnumid, mida te ülal näete, on tegelikult registreeritud sõnumid UdpEchoClientApplication ja UdpEchoServerApplication. Näiteks võime paluda kliendi rakendusel välja printida lisainfot, seadistades selle logimistase keskkonnamuutuja NS_LOG kaudu.

Alates sellest hetkest eeldan, et kasutate sh-sarnast shelli, mis kasutab süntaksit „VARIABLE = value”. Kui kasutate csh-sarnast shelli, peate minu näidised ümber seadistama süntaksile „setenv переменная значение”, mida need shellid nõuavad.

Praegu vastab UDP eho klient järgmisele koodireale scratch/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

See aktiveerib logimistase LOG_LEVEL_INFO. Kui me edastame logimistase lippu, aktiveerime tegelikult selle taseme ja kõik madalamad tasemed. Antud juhul aktiveerisime NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN ja NS_LOG_ERROR. Saame tõsta logimistaset ja saada rohkem teavet, ilma et skripti muutaksime ja uuesti kompileerime, seades keskkonnamuutuja NS_LOG järgmisel viisil:

$ export NS_LOG=UdpEchoClientApplication=level_all

Nii me seadistame järgmise sh-shelile määratud NS_LOG väärtuse,

UdpEchoClientApplication=level_all

Vasak külg määramisest on logitava komponendi nimi, mida soovime seadistada, ja parem külg on lipp, mida tahame selle jaoks kasutada. Antud juhul kavatseme rakenduses aktiveerida kõik silumisastmed. Kui käitate skripti seadistatud NS_LOG-iga, aktsepteerib ns‑3 logimise süsteem muudatused ja peaksite nägema järgmisi väljundeid:

Waf: Sisenemine katalooge `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Lahkumine kataloogist `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' lõpetati edukalt (0.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Saadetud 1024 baiti aadressile 10.1.1.2
Saadi 1024 baiti aadressilt 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Saadi 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 iga funktsiooni väljakutsumist skripti täitmise ajal. Üldjuhul on funktsioonides-moodulites eelistatav kasutada (vähemalt)NS_LOG_FUNCTION (this). Kasutage NS_LOG_FUNCTION_NOARGS ()
ainult staatilistes funktsioonides. Samas tuleb märkida, et ns‑3 süsteemis ei ole nõudeid mingite ajakirjanduse funktsionaalsuste säilitamiseks. Otsus, kui palju teavet registreerida, jääb mudeli arendaja otsustada. Kaja rakenduste puhul on saadaval suur hulk ajakirjanduse väljundit.

Nüüd saate vaadata rakenduse tehtud funktsioonikutsumiste logi. Kui vaatate tähelepanelikult, siis märkate kahepunkti kirja UdpEchoClientApplication ja meetodi nime vahel, seal, kus võib-olla ootasite näha C++ ulatusoperaatorit (::). See on tehtud meelega.

Tegelikult ei ole see klassi nimi, vaid logimise komponentide nimi. Kui allika faili ja klassi vahel on seos, on see tavaliselt klassi nimi, kuid peate mõistma, et see ei ole tegelikult klassi nimi, ja seal on üks kahepunkt, mitte kaks. See on viis, kuidas aidata teil suhteliselt õhukeselt kontseptuaalselt eristada logimise komponendi nime klassi nimest.

Kuid mõnel juhul võib olla keeruline kindlaks teha, milline meetod tegelikult logimis sõnumi genereerib. Kui vaatate ülaltoodud teksti, siis võib teil olla küsimus, kust tuli string "Received 1024 bytes from 10.1.1.2". Saate selle probleemi lahendada, seades taseme prefix_func NS_LOG keskkonnaparameetrisse. Proovige järgmist,

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Pange tähele, et jutumärgid on vajalikud, sest vertikaalne joon, mida kasutame ORE-operatsiooni tähistamiseks, on samuti Unix'i toru ühendaja. Nüüd, kui käitate skripti, näete, et logimis süsteem tagab, et iga antud logistiku sõnumil on eelnev komponentide nimele.

Waf: Sisen katalooge `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build' 
Waf: Lahkub kataloogist `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build' 
'build' lõpetatud edukalt (0.417s) 
UdpEchoClientApplication:UdpEchoClient() 
UdpEchoClientApplication:SetDataSize(1024) 
UdpEchoClientApplication:StartApplication() 
UdpEchoClientApplication:ScheduleTransmit() 
UdpEchoClientApplication:Send() 
UdpEchoClientApplication:Send(): Saadetud 1024 baidi 10.1.1.2 
Vastuvõetud 1024 baidi 10.1.1.1 
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20) 
UdpEchoClientApplication:HandleRead(): Vastuvõetud 1024 baidi 10.1.1.2 
UdpEchoClientApplication:StopApplication() 
UdpEchoClientApplication:DoDispose() 
UdpEchoClientApplication:~UdpEchoClient()

Nüüd võite näha, et kõik UDP eho-klientrakendusest saadetud sõnumid on tuvastatud kui sellised. Sõnum „Received 1024 bytes from 10.1.1.2“ on nüüd selgelt määratletud kui tulemas eho-klientrakendusest. Ülejäänud sõnum peaks tulema UDP eho-serverist. Saame selle komponendi aktiivseks teha, sisestades keskkonnamuutujasse NS_LOG komponente, mille vahel on koolonid.

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

Hoiatus: ülaltoodud tekstis näete, et peate eemaldama uue rea sümboli pärast koolonit (:), see on dokumendi vormindamiseks. Nüüd, kui käivitada skript, näete kõiki logisõnumeid nii kliendi kui ka serveri eho-rakendustest. See võib osutuda väga kasulikuks tõrgete leidmisel.

Waf: Siseneb katalooge `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build' 
Waf: Lahkub 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(): Saadetud 1024 baidi 10.1.1.2 
UdpEchoServerApplication:HandleRead(): Vastuvõetud 1024 baidi 10.1.1.1 
UdpEchoServerApplication:HandleRead(): Peegeldades paketti 
UdpEchoClientApplication:HandleRead(0x624920, 0x625160) 
UdpEchoClientApplication:HandleRead(): Vastuvõetud 1024 baidi 10.1.1.2 
UdpEchoServerApplication:StopApplication() 
UdpEchoClientApplication:StopApplication() 
UdpEchoClientApplication:DoDispose() 
UdpEchoServerApplication:DoDispose() 
UdpEchoClientApplication:~UdpEchoClient() 
UdpEchoServerApplication:~UdpEchoServer()

Samuti võib mõnikord olla kasulik näha simulatsiooni aega, millal logisõnum loodi. Selle saavutamiseks võite lisada või bit prefix_time:

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

Jällegi peate ülaltoodud uue rea sümboli eemaldama. Kui nüüd skripti käivitate, peaksite nägema järgmist väljundit:

Waf: Sisene kausta `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` Waf: Jätab kausta `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 'build' lõpetatud 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(): Vastuvõetud 1024 baiti aadressilt 10.1.1.1 2.00369s UdpEchoServerApplication:HandleRead(): Paketi peegeldamine 2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0) 2.00737s UdpEchoClientApplication:HandleRead(): Vastuvõetud 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 konstruktor UdpEchoServer kutsuti välja simulatsiooni 0 sekundil. See juhtub tegelikult enne simulatsiooni algust, kuid seda aega näidatakse kui null sekundit. Sama kehtib ka konstruktorite kohta UdpEchoClient.

Waf: Sisene kausta `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` Waf: Jätab kausta `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 'build' lõpetatud 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(): Vastuvõetud 1024 baiti aadressilt 10.1.1.1 2.00369s UdpEchoServerApplication:HandleRead(): Paketi peegeldamine 2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0) 2.00737s UdpEchoClientApplication:HandleRead(): Vastuvõetud 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äivitas echo-serveri rakenduse ühe sekundi jooksul enne simulatsiooni algust. Nüüd näete, et meetod StartApplication serveri jaoks kutsutakse tegelikult esimesel sekundil. Samuti võite märgata, et echo-client käivitub simulatsiooni teisel sekundil, nagu me skriptis soovisime.

Nüüd saate jälgida simulatsiooni kulgu, kutsudes ScheduleTransmit kliendis, mis kutsub üles saatma tagasiside käsitluse ehitus serveris. Pange tähele, et kahepunkti lingi kaudu paketi saatmiseks kulunud aeg on 3,69 millisekundit. Näete, et echo-server registreerib sõnumi, et ta vastas paketile, ja seejärel, pärast kanalit, näete, et echo-client saab echo-paketi oma käsitluses HandleRead.

Selles simulatsioonis toimub palju, mis jääb teie jaoks märkamatuks. Kuid saate kogu protsessi väga hõlpsasti jälgida, lubades süsteemis kõik koostisosade logimise. Proovige seada muutuja NS_LOG järgmisele väärtusele,

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

Asterisk eespool on logimisosa asendussümbol. See lülitab sisse kõik salvestused kõikides komponentides, mida kasutatakse simulatsioonis. Ma ei hakka siin väljundi esitama (artikli kirjutamise hetkeks genereerib see 1265 rida väljundit ühe echo-paketi jaoks), kuid saate selle teabe suunata faili ja vaadata seda oma lemmikredaktoris.

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

Ma kasutan isiklikult seda äärmiselt mahukat ajakirja versiooni, kui mul on probleem ja mul pole aimugi, kus asjad läksid valesti. Ma suudan koodi täitmist hõlpsasti jälgida, ilma et peaksin seadma siin ja seal katkestuspunktid ning esitama koodi silurisse. Ma saan lihtsalt oma lemmikredaktoris väljundit redigeerida ja otsida seda, mida ootan, ning näha, et juhtub midagi ootamatut. Kui mul on üldine ülevaade sellest, mis valesti läheb, lähen silurisse, et probleemi üksikasjalikult uurida. See tüüpi väljund võib olla eriti kasulik, kui teie skript teeb midagi täiesti ootamatut. Kui kasutate ainult silurit, võite täiesti mööda lasta ootamatust pöördest. Ajakirjastamine muudab sellised pöörded märgatavaks.

5.1.3 Logimise lisamine teie koodile

Saate lisada uusi kirjeid oma simuleerimisse, tehes log komponendi hüvesid erinevatelt makroilt. Teeme seda skriptis myfirst.cc, mille meil on 'puhtas' kataloogis. Küsime meeles, et oleme selles skriptis määratlenud ajakirjakomponendi:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Teate, et saate lubada selle komponendi kõikide sõnumite ajakirjastamise, määrates keskkonnamuutuj NS_LOG erinevatel tasemetel. Jätkame ja lisame skripti mõned märgid. Makrot, mida kasutatakse teabe taseme sõnumite ajakirjastamiseks — NS_LOG_INFO. Lisame sõnumi (otse enne, kui hakkame sõlmi looma), mis ütleb teile, et skript on topoloogia loomise etapis ("Loodud topoloogia"). See tehakse järgmises koodilõigus,
Avage scratch/myfirst.cc oma lemmikredaktoris ja lisage rida,
NS_LOG_INFO ("Creating Topology");
otse enne ridasid,

NodeContainer nodes;
nodes.Create (2);

Nüüd kompileerige skript, kasutades waf, ja puhastage keskkonnamuutuja NS_LOG, et keelata ajakirja voog, mille me varem lubasime:

$ ./waf
$ export NS_LOG=

Nüüd, kui käitate skripti, $ ./waf --run scratch/myfirst ei näe te uut teadet, kuna seotud ajakirjakomponent (FirstScriptExample) ei olnud lubatud. Et näha oma sõnumit, peate lubama ajakirjakomponendi FirstScriptExample, mis on tasemel madalam kui NS_LOG_INFO. Kui soovite lihtsalt näha seda konkreetset ajakir Jenkinsimise taset, saate selle lubada nii,

$ export NS_LOG=FirstScriptExample=info

Kui skripti nüüd käivitada, näete uut sõnumit "Loome topoloogiat".

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õpetati edukalt (0.404s)
Loome topoloogiat
Saadetud 1024 baiti aadressile 10.1.1.2
Saadud 1024 baiti aadressilt 10.1.1.1
Saadud 1024 baiti aadressilt 10.1.1.2

5.2 Käskude rida argumentide kasutamine

5.2.1 Vaikimisi atribuudi väärtuste ümbersettemine

Teine viis ns-3 skriptide käitumise muutmiseks ilma redigeerimise ja kompileerimiseta on käsurea argumentide kasutamine. Pakume mehhanismi käsurea argumentide analüüsimiseks ja lokaalsete ning globaalsete muutujate automaatseks seadmiseks, tuginedes tulemustele.

Esmalt tuleb käsurea argumentide süsteemi kasutamiseks välja kuulutada käsurea analüsaator. See on üsna lihtne teha (teie põhiprogrammis), nagu näites koodis,

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

See lihtne kahe rea fragment on tegelikult iseenesest väga kasulik. See avab ukse globaalsele ns-3 muutujale ja atribuutide süsteemile. Lisame peamise funktsiooni algusesse kaks rida koodi scratch/myfirst.cc. Liikudes edasi, kompilime skripti ja käivitame selle, tehes käivitamisel päringu abi küsimiseks järgmisega,

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

See käsk palub Waf käivitada skripti scratch\/myfirst ja edastada sellele käsurea argument --PrintHelp. Tsitaadid on vajalikud, et näidata, mille jaoks argument mõeldud on. Käsurea analüsaator tuvastab argumendi --PrintHelp ja prindib vastuse,

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õpetati edukalt (0.413s)
TcpL4Protocol:TcpStateMachine()
CommandLine:HandleArgument(): Töödelda arg nimega=PrintHelp väärtus=
--PrintHelp: Prindib selle abi sõnumi.
--PrintGroups: Prindib gruppide nimekirja.
--PrintTypeIds: Prindib kõik TypeId-d.
--PrintGroup=[gruppe]: Prindib kõik TypeId-d gruppide kohta.
--PrintAttributes=[typeid]: Prindib kõik attribuudid typeid kohta.
--PrintGlobals: Prindib globaalide nimekirja.

Nüüd vaatame valikut --PrintAttributes. Oleme juba maininud ns-3 attribuutide süsteemi, kui uurisime skripti first.cc. Oleme näinud järgmisi koodirekke,

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

ja rääkisime, et DataRate on tegelikult atribuut PointToPointNetDevice. Rakendame nüüd käsurea argumentide analüsaatori atribuutide vaatamiseks. PointToPointNetDevice. Abi nimekiri ütleb, et peame esitama TypeId. See klass, millele kuuluvad huvitatud atribuudi. Meie puhul on see ns3::PointToPointNetDevice. Jätkame edasi, sisestage

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

Süsteem prindib välja kõik selle tüübi võrgu seadme atribuudid. Te näete, et nende atribuutide nimekirjas on

--ns3::PointToPointNetDevice::DataRate=[32768bps]:
Kohustuslik andmeedastuskiirus punkt-punkti linkide jaoks

See on vaikeväärtus, mida süsteem kasutab objekti loomisel PointToPointNetDevice. Me määratleme selle vaikeväärtuse uuesti parameetriga Atribuut ja PointToPointHelper üle. Kasutame vaikimisi väärtusi punkt-punkt seadmete ja kanalite jaoks. Selleks eemaldame kutsed SetDeviceAttribute ja SetChannelAttribute API-s myfirst.cc, mis meil on puhtas kataloogis.

Teie skript peaks nüüd lihtsalt kuulutama PointToPointHelper ja mitte tegema mingeid seadistuste operatsioone, nagu on näidatud allolevas näites

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

Jätkake ja looge uus skript Waf (./waf) ja laske meil tagasi minna ning sisestada mõned logid UDP eho-serveri rakendusest ja sisse lülitada ajasilt.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Kui käitate skripti, peate nägema järgmist väljundit:

Waf: Sisenemine kataloogi `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Lahkumine kataloogi `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' lõpetatud edukalt (0.405s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Saadetud 1024 baiti aadressile 10.1.1.2
2.25732s Vastuvõetud 1024 baiti aadressilt 10.1.1.1
2.25732s Peegeldan paketti
Vastuvõetud 1024 baiti aadressilt 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Meenutame, et viimati, kui vaatasime simuleerimise aega, oli hetk, mil eho-server sai paketi, see oli 2,00369 sekundit.

2.00369s UdpEchoServerApplication:HandleRead(): Vastuvõetud 1024 baiti aadressilt 10.1.1.1

Nüüd saab ta paketi 2.25732 sekundil. See on sellepärast, et me lihtsalt vähendasime PointToPointNetDevice edastuskiirus viis megabitti sekundis vaikeväärtuseni, mis on 32768 bitti sekundis. Kui me oleksime uue DataRate seadnud käsurealt, võiksime oma simulatsiooni taas kiirendada. Teeme seda järgmiselt, vastavalt abielementide vihjele:

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

Seetõttu naaseb DataRate atribuudi väärtus vaikimisi viie megabiti sekundis. Kas tulemus üllatab teid? Selgub, et et tagastada skripti algne käitumine, peame ka kanali viivituse seadma vastavaks valguse kiirusel. Saame paluda käsureal välja printida kanalite atribuute, nagu me tegime võrgu seadmega:

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

Avastame, et kanali viivituse atribuut on seadistatud järgmiselt:

--ns3::PointToPointChannel::Delay=[0ns]:
Viivituse edastamine kanali kaudu

Seejärel saame käsurea kaudu need kaks vaikeseadet määrata,

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

sellisel juhul taastame aja, mis meil oli, kui määrasime DataRate ja Delay skriptis selgelt:

Waf: Siseneb katalooge `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Väljub kataloogist `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' lõppes eduka lõpetamisega (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Saadetud 1024 baiti aadressile 10.1.1.2
2.00369s Saadud 1024 baiti aadressilt 10.1.1.1
2.00369s Toimub paketi peegeldamine
Saadud 1024 baiti aadressilt 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Pange tähele, et pakett saadetakse serverile tagasi 2,00369 sekundi pärast. Saaksime tegelikult määrata mistahes skriptis kasutatavat atribuutide väärtust. Eriti võiksime seada MaxPackets atribuudi väärtused erinevaks kui üks. UdpEchoClient.

Kuidas te seda kasutaksite? Proovige. Pidage meeles, et peate kommenteerima koha, kus me ületame vaikimisi atribuudi väärtuse ja määrame selle selgelt. MaxPackets skriptis. Seejärel peate skripti uuesti kompileerima. Samuti saate käsurea kaudu abi uue vaikimisi atribuudi väärtuse seadmiseks. Olles sellega tuttav, suudate hallata käsureal kuvatavate pakettide arvu. Kuna oleme korralikud inimesed, peaks meie käsurea käesolev välja nägema umbes selline:

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

Loomulik küsimus, mis sel hetkel tõuseb, on, kuidas teada saada kõigi nende atribuudi olemasolust. Jällegi, käsureal on selle probleemiga seotud abifunktsioon. Kui me küsime käsurealt abi, peaksime nägema:

$ .\/waf --run "scratch\/myfirst --PrintHelp"
myfirst [Program Arguments] [General Arguments]
General Arguments:
--PrintGlobals: Trüki globaalsete loend.
--PrintGroups: Trüki grupi loend.
--PrintGroup=[group]: Trüki grupi kõik TypeId-d.
--PrintTypeIds: Trüki kõik TypeId-d.
--PrintAttributes=[typeid]: Trüki kõik typeid atribuudid.
--PrintHelp: Prindi see abitekst.

Kui valite argumendi „PrintGroups“, peaksite nägema kõigi registreeritud rühmade nimekirja. TypeId. Rühmade nimed vastavad moodulite nimedele lähtekaustas (kuigi suurtähega). Kõikide andmete kohe väljastamine oleks liiga mahukas, seetõttu on saadaval lisafiltrite süsteem grupi andmete väljatrükkimiseks. Näiteks keskendudes taas „punkt-punkt“ moodulile:

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

Siit leiate saadaval olevad TypeId nimed atribuutide leidmiseks, näiteks:
--PrintAttributes = ns3 :: PointToPointChannel, nagu eespool näidatud.

Teine viis atribuutide tundmaõppimiseks on Doxygen ns-3 kaudu. Seal on leht, mis loetleb kõik simulaatoris registreeritud atribuudid.

5.2.2 Oma käskude püüdmine

Samuti saate oma konksud käsurea süsteemi kaudu lisada. Seda on üsna lihtne teha käsureaparseri meetodi abil. AddValue.
Kasutame seda võimalust, et määrata näidatud pakettide arv täiesti teistsugusel viisil. Lisa kohaliku muutuja nimega nPackets funktsiooni main. Määrame selle väärtuseks üksteist, et see vastaks meie eelmisele vaikimisi käitumisele. Et võimaldada käsureaparseril seda väärtust muuta, peame selle muutujaga parserisse hõivama. Teeme seda, lisades kutse AddValue. Mine ja muuda skripti scratch/myfirst.cc nii, et see algab järgnevast koodist,

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

Kerige alla punktini skriptis, kus määrame atribuudiks MaxPackets, ja muuda see nii, et see lähtuks muutujast nPackets, mitte konstantist 1, nagu allpool näidatud.

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

Nüüd, kui käitate skripti ja lisate argumendi —PrintHelp, peaksite nägema uut kasutajaargumenti, mis on kuvatud abinäidikute loendis. Sisestage,

$ .\/waf --run "scratch\/myfirst --PrintHelp"
Waf: Sisen kaust `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Lahkub kaust `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' õnnestus edukalt (0.403s)
--PrintHelp: Prindi see abiteade.
--PrintGroups: Prindi rühmade loend.
--PrintTypeIds: Prindi kõik TypeId'd.
--PrintGroup=[group]: Prindi kõik TypeId'd grupist.
--PrintAttributes=[typeid]: Prindi kõik atribuudid typeid'le.
--PrintGlobals: Prindi globaalsete objektide loend.
Kasutaja argumendid:
--nPackets: Pakettide arv, mis tuleb kopeerida

Kui soovite muuta edastatavate paketide arvu, saate seda teha, seadistades käsurealt argumendi -nPackets.

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

Nüüd peate nägema

Waf: Siseneb kausta `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Lahkub kaust `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' õnnestus edukalt (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Saadetud 1024 baiti aadressile 10.1.1.2
2.25732s Saadud 1024 baiti aadressilt 10.1.1.1
2.25732s Kaja pakett
Saadud 1024 baiti aadressilt 10.1.1.2
Saadetud 1024 baiti aadressile 10.1.1.2
3.25732s Saadud 1024 baiti aadressilt 10.1.1.1
3.25732s Kaja pakett
Saadud 1024 baiti aadressilt 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Olete nüüd saatnud kaks paketti. Hästi lihtne, eks?
Võite näha, et ns-3 kasutajana saate kasutada käsurea argumentide süsteemi globaalsete väärtuste ja atribuutide haldamiseks. Kui olete mudeli autor, saate lisada uusi atribuutide oma objektidele ning need saavad automaatselt olema konfigureeritavad teie kasutajate poolt käsureas. Kui olete skripti autor, saate oma skriptidesse lisada uusi muutujaid ning neid valutult oma käsurea süsteemiga ühendada.

5.3 Jälgimissüsteemi kasutamine

Modelleerimise peamine eesmärk on genereerida väljundandmed edasisteks uurimisteks ning ns-3 jälgimissüsteem on selle peamine mehhanism. Kuna ns-3 on C++ programmeerimiskeeles, võib kasutada standardseid väljundandmete genereerimise vahendeid C++ programmis:

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

Te võite isegi kasutada logimismoduuli, et lisada oma lahendusele veidi struktuuri. Sellest lähenemisest tulenevaid probleeme on palju ning nende lahendamiseks oleme pakkunud üldist sündmuste jälgimise alam-süsteemi.

Ns-3 jälgimissüsteemi põhieesmärgid:

• Põhitegevuse jaoks peab jälgimissüsteem võimaldama kasutajal genereerida standardset jälgimist populaarsetelt allikatelt ning valima, millised objektid genereerivad jälgimist;

• Vahe kasutajad peavad saama jälgimisse süsteemi laiendada, et muuta genereeritud väljundi formaati või lisada uusi jälgimise allikaid ilma simulatori tuuma modifitseerimiseta;

• Kogenud kasutajad saavad simulatori tuuma modifitseerida, et lisada uusi jälgimise allikaid ja vastuvõtjaid. Ns-3 jälgimisse süsteem põhineb sõltumatute jälgimise allikate ja vastuvõtjate põhimõtetel ning ühtsel mehhanismil allikate ühendamiseks tarbijatega.

Ns-3 jälgimisse süsteem on rajatud sõltumatute jälgimise allikate ja vastuvõtjate põhimõtetele ning ühtsele mehhanismile allikate ühendamiseks vastuvõtjatega. Jälgimise allikad on objektid, mis suudavad signaalida sündmusi, mis toimuvad simulatsioonis, ja tagada ligipääsu huvitavatele põhikohtadele. Näiteks võib jälgimise allikas näidata, millal võrguseade sai paketi ja pakkuda ligipääsu paketi sisule huvipakkuvatele jälgimise vastuvõtjatele.

Jälgimise allikad on enda iseenesest kasutud, kui nad pole 'ühendatud' koodi teiste osadega, mis tegelikult töötlevad informatsiooni, mille vastuvõtja pakub, mingi kasuliku tegevuse jaoks. Jälgijad on sündmuste ja andmete tarbijad, mida jälgimise allikad pakuvad. Näiteks võib luua jälgimise vastuvõtja, mis (kui see on ühendatud eelnevas näites oleva jälgimise allikaga) printib huvitavaid osi saadud paketist.

Tõsine põhjus sellise selge eristamise osas on võimaldada kasutajatel liita uusi vastuvõtjaid olemasolevatele jälgimise allikatele, ilma simulatori tuuma redigeerimise ja uuesti kompileerimise vajaduseta. Seega võib eeltoodud näites kasutaja defineerida uue jälgija oma skriptis ja ühendada selle olemasoleva jälgimise allikaga, mis on määratletud simulatsiooni tuumas, lihtsalt muutes kasutaja skripti.

Selles juhendis tutvustame mõningaid määratletud allikaid ja vastuvõtjaid ning näitame, kuidas neid seadistada, kasutades võimalikult vähe kasutaja pingutusi. Vaadake juhendit ns‑3 või juhised täiendava jälgimise seadistamise kohta, sealhulgas jälgimisruumi laiendamine ja uute jälgimisallikate loomine.

5.3.1 ASCII jälgimine

ns‑3 pakub abifunktsioone, mis pakuvad madala taseme jälgimissüsteemi, et aidata teil pakettide jälgimise lihtsate seadistuste detailidega. Kui aktiveerite selle funktsiooni, näete väljundit ASCII-failides. Neile, kes tunnevad ns-2 väljundit, on see jälgimistüüp sarnane out.tr, mis on genereeritud mitme skripti poolt.

Liigume edasi ja lisame mõned ASCII jälgimistulemused meie skripti scratch/myfirst.cc. Just enne meetodi kutsumist Simulator::Run(), lisage järgmised koodiread:
AsciiTraceHelper ascii;

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

Nagu paljudes teistes ns‑3 idiomides, kasutab see kood abistavat objekti ASCII jälgimiste loomisel. Teises reas on kaks sisemist meetodi kutsumist. Meetod "sisemine" CreateFileStream() kasutab anonüümse objekti idiomat, et luua stekki faili voog objekti (ilma objekti nime) ja edastada selle kutsutavale meetodile. Tulevikus süveneme sellesse, kuid kõik, mida peate selle etapi jaoks teadma, on see, et loote objekti, mis esindab faili nimega myfirst.tr ja edastate selle ns‑3-le. Usaldame ns‑3-le loodud objekti hooldamise kogu selle eluaja, mille jooksul lahendatakse probleemid, mis on tingitud vähe tuntud (teadlikust) piirangust, mis on seotud C++ voogude objektide koopiate konstruktoritega.

Väline kutse EnableAsciiAll() annab abistajale teada, et soovite oma simulatsioonis aktiveerida ASCII jälgimise kõikidele punkt-punkt seadme ühendustele ning et soovite, et (määratud) jälgijad salvestaksid pakettide liikumise teavet ASCII formaadis.

Neile, kes tunnevad ns-2, 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 seda käsurealt:

$ ./waf --run scratch/myfirst

Kui palju kordi olete varem näinud mitmeid sõnumeid Waf-i poolt ja seejärel "‘build’ finished successfully" (ehitamine õnnestus) koos selle töötava programmi sõnumitega.

Töötamise käigus loob programm faili nimega myfirst.tr. Töö olemuse tõttu Waf, luuakse vaikimisi fail mitte kohalikus kataloogis, vaid reposi ülemises kataloogis. Kui soovite muuta teed, kuhu jäljed salvestatakse, saate Waf-i jaoks määrata tee paranmeetriga --cwd. Me ei teinud seda, seega, et vaadata ASCII jälgimisfaili myfirst.tr oma lemmiktoimetajas, peame minema meie reposi ülemisse kataloogi.

ASCII jälgimise analüüs

Seal on palju teavet üsna tihedas vormis, kuid esimene asi, millele tähelepanu pöörata, on see, et fail koosneb eraldi ridadest. See saab selgelt nähtavaks, kui laiendate vaateaken laiemaks.

Iga rida failis vastab jälgimise sündmusele. Antud juhul jälgime edastamise järjekorra sündmusi, mis esinevad igas võrgu punkti-punkt seadmes simuleerimise ajal. Edastamisjärjekord on järjekord, mille kaudu peab igasugune pakett punkti-punkt kanali jaoks läbima. Pange tähele, et iga rida jälgimisfailis algab ühekordse sümboliga (ja selle järel on tühi koht). See sümbol omab järgmisi väärtusi:

+: seadme järjekorras toimus järjekorda panemise operatsioon;
-: seadme järjekorras toimus elemendi tõstmise operatsioon;
d: pakk jäi hülgatud, peamiselt seetõttu, et järjekord oli täis;
r: pakk anti võrgu seadmele vastuvõetuks.

Vaatame jälgimisfaili esimest rida detailsemalt. Jagame selle osadeks (vaate mugavuse tagamiseks sisse tõstetud) ja number vasakul:

0 +
1 2
2 /NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue
3 ns3::PppHeader (
4   Punkt-to-punktprotokoll: IP (0x0021))
6   ns3::Ipv4Header (
7     tos 0x0 ttl 64 id 0 protokoll 17 offset 0 lipud [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 laiendatud jälgimise sündmuse esimene osa (rida 0) on operatsioon. Meil on siin sümbol +, mis vastab edastamisse järjekorda panemise operatsioonile. Teine osa (rida 1) on simuleerimise aeg, väljendatuna sekundites. Sa võid mäletada, et palusime UdpEchoClientApplication pakettide saatmine algab kahe sekundi pärast. Siin näeme kinnitust, et see tõepoolest toimub.

Järgmisel jälgimise näite jaotises (read 2) näidatakse, millisest jälgimise allikast see sündmus tekkis (jälgimisruum on märgitud). Sa saad esitada jälgimisruumi veidi nagu failisüsteemi ruumi. Jälgimisruumi juur on NodeList. See vastab konteinerile, mida kontrollib peamine ns-3 kood. Selles sisaldub kõik sõlmed, mis skriptis loodud on. Nii nagu failisüsteemil võib juure all olla kausta, võib NodeList meil olla palju sõlmi. Seega viitab rida /NodeList/0 nullsõlmele NodeListis, mida me tavaliselt mõistame kui "sõlm 0". Igas sõlmes on seadmete loetelu, mis on paigaldatud. See loetelu asub järgmises ruumis. Sa võid näha, et see jälgimisüritus pärineb DeviceList/0, mis on seadme null, mis on paigaldatud sõlmes.

Järgmine alarida, $ ns3::PointToPointNetDevice, näitab, milline seade asub nullasendis: nullsõlme seadmete loendis. Tuletame meelde, et rida +, mis oli reas 0, tähendas, et seadme edastamisjärjekorras toimus elemendi lisamine. See kajastub viimastes aadressi jälgimise segmentides: TxQueue/Enqueue.

Ülejäänud osad jälgimises peaksid olema piisavalt intuitiivsed. Ridu 3-4 näitavad, et pakk on kapseldatud punkti-punkti protokollis. Rida 5-7 näitavad, et pakk sisaldab IP4 versioonipealkirja ja pärineb IP-aadressilt 10.1.1.1 ja on mõeldud 10.1.1.2. Ridu 8-9 näitavad, et see pakk sisaldab UDP pealkirja ja lõpuks näitab rida 10, et koormus on oodatud 1024 baiti.

Järgmine rida jälgimisfailis näitab, et sama pakk võeti edastusjärjekorrast sama sõlme juures.

Kolmas rida jälgimisfailis näitab, et pakk aktsepteeriti võrgu seadme poolt sõlmes, kus on kaja server. Reprodutseerin selle sündmuse allpool.

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 lipud [none]
5     pikkus: 1052 10.1.1.1 > 10.1.1.2)
6     ns3::UdpHeader (
7       pikkus: 1032 49153 > 9)
8       Koormus (suurus=1024)

Pöörake tähelepanu, et jälgimisoperatsioon on nüüd r ja simuleerimise aeg on pikenenud 2,25732 sekundini. Kui olete õpetuse juhistele tähelepanelikult järgnenud, tähendab see, et olete jätnud võrgu seadmete DataRate ja kanalide hilinemise vaikesätted. See aeg peaks olema tuttav, nagu olete juba eelnevas osas näinud.

Jälgimispinna nimirida (rida 2) on muudetud, et peegeldada, et see sündmus pärineb sõlmost 1 (/NodeList/1) и пакет принят источником трассировки (/MacRx). Te peaksite olema üsna kerge jälgida paketi liikumist topoloogias, vaadates failis jäävaid jälgi.

5.3.2 PCAP jälgimine

Seadmete ns-3 abil saab samuti luua jälgimisfaile .pcap formaadis. Akroüm pcap (tavaliselt kirjutatakse väikeste tähtedega) tähistab pakettide püüdmiseks ja on tegelikult API, mis sisaldab failiformaadi .pcap määratlemist. Kõige populaarsem programm, mis suudab seda vormingut lugeda ja kuvada, on Wireshark (varem tuntud kui Ethereal). Siiski on palju liikluse jälgimise analüsaatoreid, mis kasutavad seda paketti vormingut. Soovitame kasutajatel kasutada mitmeid tööriistu, mis on saadaval pcap jälgimise analüüsimiseks. Selles juhendis keskendume pcap jälgimise vaatamisele kasutades tcpdump.

Pcap jälgimise lubamine toimub ühe koodireaga.

pointToPoint.EnablePcapAll("myfirst");

Lisage see koodirida pärast ASCII jälgimise koodi, mille me just eri scratch/myfirst.cc. Pange tähele, et oleme edastanud ainult stringi «myfirst», mitte «myfirst.pcap» või midagi sarnast. See on seetõttu, et parameeter on eellause, mitte failinimi. Simuleerimise ajal loob assistent tegelikult jälgimisfaili iga punkti vahelise seadme jaoks. Failide nimed koostatakse eellause, sõlme numbri, seadme numbri ja sufiksi „pcap».

Meie stsenaariumi näite puhul näeme lõpuks faile nimedega „myfirst-0-0.pcap" ja "myfirst-1-0.pcap”, mis on pcap jälgimised sõlme 0-seade 0 ja sõlme 1-seade 0 suhtes vastavalt. Pärast selle koodirea lisamist pcap jälgimise lubamiseks saate skripti tavalise viisi kohaselt käivitada:

$ ./waf --run scratch/myfirst

Kui vaatate oma jaotuse ülemise taseme katalooge, peaksite nägema kolme faili: ASCII jälgimisfaili myfirst.tr, mille me varem uurisime, failid myfirst-0-0.pcap ja myfirst-1-0.pcap — uued pcap-failid, mille me just genereerisime.

Väljastuse lugemine tcpdumpiga

Hetkel on pcap-failide vaatamine kõige lihtsam tcpdumpiga.

$ tcpdump -nn -tt -r myfirst-0-0.pcap
reading from file myfirst-0-0.pcap, link-type PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, length 1024
2.514648 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 1024
tcpdump -nn -tt -r myfirst-1-0.pcap
reading from file myfirst-1-0.pcap, link-type PPP (PPP)
2.257324 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, length 1024
2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 1024

Dumphis myfirst-0-0.pcap (klientseade) näete, et echo-pakett saadetakse 2 sekundi simuleerimise jooksul. Kui vaatate teist dumphi (myfirst-1-0.pcap), näete, et pakett võetakse vastu hetkel 2,257324 sekundit. Teises dumphis näete, et pakett tagastatakse hetkel 2,257324 sekundit ja lõpuks, et pakett sai kliendilt tagasi esimese dumphi hetkel 2,514648 sekundit.

Väljastuse lugemine Wiresharkiga

Kui te ei tunne 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 pakette kinni püüdnud, kasutades paketianalüsaatorit.

Allikas: habr.com