5 Nastavenie
5.1 Používanie modulu protokolovania
5.1.1 Prehľad protokolovania
5.1.2 Povolenie protokolovania
5.1.3 Pridávanie protokolovania do vášho kódu
5.2 Používanie argumentov príkazového riadku
5.2.1 Prepísanie predvolených hodnôt atribútov
5.2.2 Zachytávanie vlastných príkazov
5.3 Používanie systémového trasovania
5.3.1 ASCII Trasovanie
Parsenie ASCII trasovania
5.3.2 Trasovanie PCAP
Hlava 5
Nastavenie
5.1 Používanie modulu protokolovania
Už sme sa stručne pozreli na modul protokolovania ns‑3, pričom sme prechádzali skriptom first.cc. V tejto kapitole sa bližšie pozrieme na možnosti využitia subsystému protokolovania.
5.1.1 Prehľad protokolovania
Mnohé veľké systémy podporujú nejaký prostriedok registrácie správ a ns‑3 nie je výnimkou. V niektorých prípadoch sú do 'konzoly operátora' (ktorá je zvyčajne stderr v systémoch založených na Unixe) zapisované iba chybové správy. V iných systémoch môžu byť zobrazované aj varovné správy a podrobnejšie informácie. V niektorých prípadoch sa prostriedky protokolovania používajú na zobrazovanie ladenia, ktoré môžu rýchlo „zamieňať“ výstup.
Prístup používaný v ns‑3 predpokladá, že všetky tieto úrovne informativnosti sú užitočné a poskytujeme selektívny, viacúrovňový prístup k registrácii správ. Protokolovanie môže byť úplne vypnuté, zapnuté pre jednotlivé komponenty alebo na globálnej úrovni. Na tento účel slúžia prispôsobiteľné úrovne informativnosti. Modul protokolovania ns‑3 poskytuje relatívne jednoduchý spôsob, ako získať užitočné informácie z vašej simulácie.
Musíte pochopiť, že poskytujeme mechanizmus všeobecného použitia — trasovanie — na extrakciu údajov z vašich modelov, ktorý by mal byť preferovaný na výstup pri modelovaní (pre podrobnejšie informácie o našom systéme trasovania pozri časť 5.3 učebnice). Protokolovanie by malo byť preferovanou metódou na získavanie ladenia, varovaní, chybových správ alebo na rýchly výstup správ z vašich scénarov alebo modelov kedykoľvek.
V súčasnosti je v systéme definovaných sedem úrovní (typov) správ protokolu podľa vzrastajúcej informativnosti.
- LOG_ERROR — registrácia chybových správ (súvisiaci makro: NS_LOG_ERROR);
- LOG_WARN — registrácia varovných správ (súvisiaci makro: NS_LOG_WARN);
- LOG_DEBUG — registrácia relatívne zriedkavých špeciálnych správ o ladení (súvisiaci makro: NS_LOG_DEBUG);
- LOG_INFO — registrácia informačných správ o priebehu programu (súvisiaci makro: NS_LOG_INFO);
- LOG_FUNCTION — registrácia správ popisujúcich každú vyvolanú funkciu (dva súvisiace makro: NS_LOG_FUNCTION, používané pre členové funkcie, a NS_LOG_FUNCTION_NOARGS, používané pre statické funkcie);
- LOG_LOGIC — registrácia správ popisujúcich logický tok v rámci funkcie (súvisiaci makro: NS_LOG_LOGIC);
- LOG_ALL — registrácia všetkého vyššie uvedeného (súvisiace makro chýba).
Pre každý typ (LOG_TYPE) existuje tiež typ LOG_LEVEL_TYPE, ktorý, ak sa používa, umožňuje registráciu všetkých úrovní nad ním okrem tej jeho vlastnej. (Ako dôsledok, LOG_ERROR a LOG_LEVEL_ERROR, ako aj LOG_ALL a LOG_LEVEL_ALL sú funkčne ekvivalentné.) Napríklad, povolenie LOG_INFO povolí iba správy poskytnuté makrom NS_LOG_INFO, pričom pri zapnutí LOG_LEVEL_INFO budú zahrnuté aj správy poskytnuté makrami NS_LOG_DEBUG, NS_LOG_WARN a NS_LOG_ERROR.
Taktiež poskytujeme makro bezpodmienečného zaznamenávania, ktoré sa zobrazuje vždy, nezávisle od úrovne zaznamenávania alebo vybraného komponentu.
- NS_LOG_UNCOND — bezpodmienečná registrácia súvisiacej správy (bez súvisiacej úrovne zaznamenávania).
Každá úroveň môže byť požadovaná samostatne alebo kumulatívne. Zaznamenávanie je možné nastaviť pomocou premennej prostredia sh NS_LOG alebo registráciou volania systémovej funkcie. Ako bolo uvedené skôr, systém zaznamenávania má dokumentáciu Doxygen a teraz je ten správny čas, aby ste si ju prezreli, ak ste to ešte neurobili.
Teraz, keď ste prečítali dokumentáciu veľmi podrobne, poďme využiť tieto vedomosti, aby sme získali niektoré zaujímavé informácie z príkladového skriptu scratch/myfirst.cc, ktorý ste už kompilovali.
5.1.2 Povolenie protokolovania
Poďme využiť premennú prostredia NS_LOG, aby sme spustili niekoľko ďalších záznamov, ale najprv, len pre orientáciu, spustite posledný skript, ako ste to robili predtým,
$ ./waf --run scratch/myfirstMali by ste vidieť už známy výstup prvej príkladovej program ns-3.
$ Waf: Vstup do adresára `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Opustenie adresára `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' 'build'
úplné úspešne (0.413s)
Odoslané 1024 bajty na 10.1.1.2
Prijaté 1024 bajty z 10.1.1.1
Prijaté 1024 bajty z 10.1.1.2Ukazuje sa, že „odoslané“ a „prijaté“ správy, ktoré vidíte vyššie, sú v skutočnosti registrované správy od UdpEchoClientApplication a UdpEchoServerApplication. Napríklad, môžeme požiadať klientskú aplikáciu, aby vytlačila ďalšie informácie nastavením jej úrovne protokolovania prostredníctvom premennej prostredia NS_LOG.
Od tohto okamihu predpokladám, že používate shell podobný sh, ktorý používa syntax `VARIABLE=value`. Ak používate shell podobný csh, potom budete musieť previesť moje príklady do syntaxe `setenv VARIABLE value`, ktorú vyžaduje tento shell.
V tejto chvíli aplikácia UDP echo klienta reaguje na nasledujúci riadok kódu v scratch/myfirst.cc,
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);Aktivuje úroveň protokolovania LOG_LEVEL_INFO. Keď odovzdáme príznak úrovne protokolovania, v skutočnosti zapíname túto úroveň a všetky nižšie úrovne. V tomto prípade sme zapli NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN a NS_LOG_ERROR. Môžeme zvýšiť úroveň protokolovania a získať viac informácií bez zmeny skriptu a recompilácie tak, že nastavíme premennú prostredia NS_LOG nasledovne:
$ export NS_LOG=UdpEchoClientApplication=level_allTýmto spôsobom nastavujeme nasledujúcu hodnotu premennej NS_LOG shellu sh.
UdpEchoClientApplication=level_allĽavá časť priradenia je názov protokolovaného komponentu, ktorý chceme nastaviť, a pravá časť je príznak, ktorý chceme pre toto nastaviť. V tomto prípade plánujeme zapnúť vo všetkých úrovniach ladenia aplikácie. Ak spustíte skript so svojím nastavením NS_LOG, protokolovanie ns-3 prijme zmeny a mali by ste vidieť nasledujúci výstup:
Waf: Vstup do adresára `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Opustenie adresára `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' úplné úspešne (0.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Odoslané 1024 bajty na 10.1.1.2
Prijaté 1024 bajty z 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Prijaté 1024 bajty z 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()Dodatočné ladenie informácií poskytovaných aplikáciou teraz zodpovedá úrovni NS_LOG_FUNCTION. Zobrazuje každý prípad volania funkcií počas vykonávania skriptu. Vo všeobecnosti je v metódach funkcií odporúčané použiť (minimálne)NS_LOG_FUNCTION (this). Použite NS_LOG_FUNCTION_NOARGS ()
iba v statických funkciách. Však si uvedomte, že v systéme ns‑3 nie sú požiadavky na zachovanie akýchkoľvek funkčných vlastností logovania. Rozhodnutie o tom, koľko informácií sa registruje, zostáva na individuálnej zodpovednosti vývojára modelu. V prípade echo aplikácií je k dispozícii veľké množstvo výstupných údajov na logovanie.
Teraz si môžete prezrieť log volaní funkcií, ktoré boli vykonané aplikáciou. Ak sa pozriete pozorne, všimnete si dvojbodku medzi riadkom UdpEchoClientApplication a názvom metódy, na mieste, kde by ste pravdepodobne očakávali vidieť operátor rozsahu C++ (::). Toto bolo urobené zámerne.
V skutočnosti to nie je názov triedy, ale názov komponentu logovania. Keď existuje zhoda medzi zdrojovým súborom a triedou, zvyčajne je to názov triedy, ale mali by ste chápať, že to nie je v skutočnosti názov triedy, a tam je jedno dvojbodka namiesto dvojitej dvojbodky. Je to spôsob, ako vám relatívne jemne oddeliť názov komponentu logovania od názvu triedy.
V niektorých prípadoch môže byť však ťažké určiť, ktorá metóda skutočne generuje hlásenie logu. Ak sa pozriete na text vyššie, môžete mať otázku, odkiaľ pochádza riadok „Received 1024 bytes from 10.1.1.2“. Túto otázku môžete vyriešiť nastavením úrovne prefix_func v premennej prostredia NS_LOG. Skúste urobiť nasledovné,
$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'Upozorňujeme, že úvodzovky sú potrebné, pretože vertikálna čiaru, ktorú používame na označenie operácie ALEBO, je tiež spájajúci symbol Unixu. Teraz, ak spustíte skript, uvidíte, že systém logovania zabezpečí, aby každé hlásenie z daného logu malo prefix s názvom komponentu.
Waf: Vstup do adresára `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Opustenie adresára `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' úspešne dokončené (0.417s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Odoslaných 1024 bajtov na 10.1.1.2
Prijatých 1024 bajtov z 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
UdpEchoClientApplication:HandleRead(): Prijatých 1024 bajtov z 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()Teraz môžete vidieť, že všetky správy prichádzajúce z aplikácie UDP echo klienta sú identifikované ako také. Správa „Received 1024 bytes from 10.1.1.2“ je teraz jasne definovaná ako prichádzajúca z aplikácie echo klienta. Zostávajúca správa by mala prichádzať z aplikácie UDP echo servera. Môžeme tento komponent zapnúť zadaním zoznamu komponentov oddelených dvojbodkami do premennej prostredia NS_LOG.
$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func:
UdpEchoServerApplication=level_all|prefix_func'Varovanie: V uvedenom príklade textu bude potrebné odstrániť znak nového riadku za dvojbodkou (:), ktorý bol použitý na formátovanie dokumentu. Teraz, ak spustíte skript, uvidíte všetky správy protokolu z klientskej a serverovej echo aplikácie. Môžete vidieť, že to môže byť veľmi užitočné pri ladení.
Waf: Vstup do adresára `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Opustenie adresára `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' úspešne dokončené (0.406s)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoServerApplication:StartApplication()
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Odoslaných 1024 bajtov na 10.1.1.2
UdpEchoServerApplication:HandleRead(): Prijatých 1024 bajtov z 10.1.1.1
UdpEchoServerApplication:HandleRead(): Odpovedanie na paket
UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
UdpEchoClientApplication:HandleRead(): Prijatých 1024 bajtov z 10.1.1.2
UdpEchoServerApplication:StopApplication()
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()Tiež je niekedy užitočné mať možnosť vidieť čas simulácie, v ktorom bola správa protokolu vytvorená. Môžeš to urobiť pridaním alebo bitu prefix_time:
$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func|prefix_time: UdpEchoServerApplication=level_all|prefix_func|prefix_time'Opäť, budete musieť odstrániť vyššie uvedený znak nového riadku. Ak teraz spustíte skript, mali by ste vidieť nasledujúci výstup:
Waf: Vstup do priečinka `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Opustenie priečinka `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
`build` úspešne dokončené (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(): Odoslaných 1024 bajtov na 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Prijatých 1024 bajtov z 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Prijatých 1024 bajtov z 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()Upozorňujeme, že konštruktor pre UdpEchoServer bol vyvolaný počas simulácie 0 sekúnd. To sa skutočne deje pred začiatkom simulácie, ale tento čas je zobrazený ako nula sekúnd. Podobne je to aj s konštruktorom UdpEchoClient.
Waf: Vstup do priečinka `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Opustenie priečinka `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
`build` úspešne dokončené (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(): Odoslaných 1024 bajtov na 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Prijatých 1024 bajtov z 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Prijatých 1024 bajtov z 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()Pripomíname, že skript scratch/first.cc spustil aplikáciu echo server jednu sekundu pred začiatkom simulácie. Teraz môžete vidieť, že metóda StartApplication servera sa skutočne volá v prvej sekunde. Môžete si tiež všimnúť, že echo klient sa spúšťa v druhej sekunde simulácie, ako sme požiadali v skripte.
Teraz môžete sledovať priebeh simulácie cez volanie ScheduleTransmit v klientovi, ktorý vyvoláva spätné volanie HandleRead v aplikácii echo servera. Upozorňujeme, že uplynulý čas na odoslanie paketov cez bodový link je 3,69 milisekúnd. Je zrejmé, že echo server zaznamenáva správu, že odpovedal na paket, a potom, po oneskorení kanála, vidíte, že echo klient prijíma echo paket vo svojej metóde HandleRead.
V tejto simulácii sa veľa deje bez toho, aby ste to zaregistrovali. Ale môžete veľmi ľahko sledovať celý proces zapnutím všetkých komponentov logovania v systéme. Skúste nastaviť v premennej NS_LOG nasledujúcu hodnotu,
$ export 'NS_LOG=*=level_all|prefix_func|prefix_time'Hvězdička vyššie je zástupným symbolom komponentu logovania. To zapne všetky záznamy vo všetkých komponentoch, ktoré sa používajú v simulácii. Nebudem reprodukovať výstup tu (v čase písania to vytvára 1265 riadkov výstupu pre jeden echo paket), ale môžete presmerovať tieto informácie do súboru a pozrieť sa na ne vo vašom obľúbenom editore,
$ . /waf --run scratch/myfirst > log.out 2>&1Osobne používam túto mimoriadne podrobnú verziu protokolu, keď mám problém a nemám ani poňatia, kde veci išli zle. Môžem pomerne jednoducho sledovať vykonávanie kódu bez nastavovania záchytných bodov a krokovania kódu v debuggery. Môžem jednoducho upraviť výstup vo svojom obľúbenom editore a hľadať to, čo očakávam, a vidieť, že sa deje niečo, čo neočakávam. Keď mám celkovú predstavu o tom, čo ide zle, prechádzam do debuggeru na podrobné preskúmanie problému. Tento typ výstupu môže byť osobitne užitočný, keď váš skript robí niečo úplne neočakávané. Ak používate iba debugger, môžete úplne minúť neočakávaný obrat. Protokolovanie robí také obraty viditeľné.
5.1.3 Pridávanie protokolovania do vášho kódu
Môžete pridať nové záznamy do svojich simulácií, uskutočňovaním volaní komponentu log z niekoľkých makier. Poďme to urobiť v skripte myfirst.cc, ktorý máme v 'čistej' adresári. Pripomeňme, že sme v tomto skripte určili komponent protokolovania:
NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");Viete, že môžete zapnúť protokolovanie všetkých správ tohto komponentu, nastavením premennej prostredia NS_LOG na rôznych úrovniach. Poďme ďalej a pridajme nejaké záznamy do skriptu. Makro, ktoré sa používa na pridanie správ informačnej úrovne do logu, je NS_LOG_INFO. Poďme pridať správu (priamo predtým, ako začneme vytvárať uzly), ktorá vám hovorí, že skript je v štádiu vytvárania topoológie ("Creating Topology"). To sa robí v nasledujúcom úryvku kódu,
Otvorte scratch/myfirst.cc v obľúbenom editore a pridajte riadok,
NS_LOG_INFO ("Creating Topology");
priamo pred riadkami,
NodeContainer nodes;
nodes.Create (2);Teraz skompilujte skript pomocou waf, a vyčistite premennú NS_LOG, aby ste deaktivovali tok protokolovania, ktorý sme zapli predtým:
$ . /waf
$ export NS_LOG=
Teraz, ak spustíte skript,
$ . /waf --run scratch/myfirstneuvidíte novú správu, pretože súvisiaci komponent protokolovania (FirstScriptExample) nebol zapnutý. Aby ste videli svoju správu, musíte zapnúť komponent protokolovania FirstScriptExample s úrovňou nie nižšou ako NS_LOG_INFO. Ak chcete vidieť iba túto konkrétnu úroveň protokolovania, môžete ju zapnúť takto,
$ export NS_LOG=FirstScriptExample=infoAk spustíte skript teraz, uvidíte nové hlásenie „Tvorba topológie“,
Waf: Vstup do adresára `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Opustenie adresára `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' úspešne dokončené (0.404s)
Tvorba topológie
Odoslaných 1024 bajtov na 10.1.1.2
Prijatých 1024 bajtov z 10.1.1.1
Prijatých 1024 bajtov z 10.1.1.25.2 Používanie argumentov príkazového riadku
5.2.1 Prepísanie predvolených hodnôt atribútov
Ďalší spôsob, ako zmeniť správanie skriptov ns-3 bez úprav a kompilácie, je použitie argumentov príkazového riadku. Poskytujeme mechanizmus na parsing argumentov príkazového riadku a automatické nastavenie lokálnych a globálnych premenných na základe výsledkov.
Prvým krokom pri využívaní systému argumentov príkazového riadku je deklarácia parsera príkazového riadku. Je to celkom jednoduché (vo vašej hlavnej aplikácii), ako v nasledujúcom kóde,
int
main (int argc, char *argv[])
{
...
CommandLine cmd;
cmd.Parse (argc, argv);
...
}Tento jednoduchý dvojriadkový fragment je skutočne veľmi užitočný sám o sebe. Otvára dvere k globálnej premennej ns-3 a systému atribútov. Pridajme dve riadky kódu na začiatok hlavnej funkcie skriptu scratch/myfirst.cc. Pokračujeme, skompilujeme skript a spustíme ho, pričom pri spúšťaní vykonáme dopyt na pomoc nasledovne,
$ ./waf --run "scratch/myfirst --PrintHelp"Tento príkaz požiada Waf spustiť skript scratch/myfirst a odovzdať mu argument príkazového riadku --PrintHelp. Úvodzovky sú potrebné, aby ukázali, pre ktorý program je argument určený. Parser príkazového riadku nájde argument --PrintHelp a vypíše odpoveď,
Waf: Vstup do adresára `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Opustenie adresára `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' úspešne dokončené (0.413s)
TcpL4Protocol:TcpStateMachine()
CommandLine:HandleArgument(): Spracovať arg meno=PrintHelp hodnota=
--PrintHelp: Vytlačiť túto pomocnú správu.
--PrintGroups: Vytlačiť zoznam skupín.
--PrintTypeIds: Vytlačiť všetky TypeIds.
--PrintGroup=[group]: Vytlačiť všetky TypeIds skupiny.
--PrintAttributes=[typeid]: Vytlačiť všetky atribúty typeid.
--PrintGlobals: Vytlačiť zoznam globálov.Teraz sa pozrime na možnosť --PrintAttributes. Už sme spomenuli systém atribútov ns-3, pri prehľadávaní skriptu first.cc. Videli sme nasledujúce riadky kódu,
PointToPointHelper pointToPoint;
pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));
pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));a hovorili sme, že DataRate je v skutočnosti atribútom PointToPointNetDevice. Poďme aplikovať parser argumentov príkazového riadku na prezeranie atribútov PointToPointNetDevice. Pomocný zoznam hovorí, že musíme poskytnúť TypeId. Toto je meno triedy, ku ktorej patria zaujímavé atribúty. V našom prípade to bude ns3::PointToPointNetDevice. Pokračujme ďalej, zadajte,
$ .\/waf --run "scratch\/myfirst --PrintAttributes=ns3::PointToPointNetDevice"Systém vytlačí všetky atribúty tohto typu sieťového zariadenia. Uvidíte, že medzi atribútmi zoznamu sú
--ns3::PointToPointNetDevice::DataRate=[32768bps]:
Predvolená prenosová rýchlosť pre bod-bod odkazyToto je predvolené hodnotenie, ktoré sa použije v systéme pri vytváraní objektu PointToPointNetDevice. Tento predvolený údaj predefinujeme pomocou parametra Atribút v PointToPointHelper vyššie. Použime predvolené hodnoty pre zariadenia a kanály s bod-bod. Na tento účel odstránime volania SetDeviceAttribute a SetChannelAttribute z myfirst.cc, ktoré máme v čistom adresári.
Váš skript by teraz mal jednoducho deklarovať PointToPointHelper a nevykonávať žiadne inštalačné operácie, ako je znázornené v nasledujúcom príklade,
...
NodeContainer nodes;
nodes.Create (2);
PointToPointHelper pointToPoint;
NetDeviceContainer devices;
devices = pointToPoint.Install (nodes);
...Pokračujte a vytvorte nový skript s Waf (.\/waf) a vráťme sa späť a zapneme niektoré logovanie z UDP echo aplikácie servera a pridáme predponu času.
$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'Ak spustíte skript, mali by ste vidieť nasledujúci výstup:
Waf: Vstup do adresára `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf: Opustenie adresára `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'build' bolo úspešne dokončené (0.405s)\n0s UdpEchoServerApplication:UdpEchoServer()\n1s UdpEchoServerApplication:StartApplication()\nOdoslané 1024 bajty na 10.1.1.2\n2.25732s Prijaté 1024 bajty z 10.1.1.1\n2.25732s Echoing packet\nPrijaté 1024 bajty z 10.1.1.2\n10s UdpEchoServerApplication:StopApplication()\nUdpEchoServerApplication:DoDispose()\nUdpEchoServerApplication:~UdpEchoServer()Pripomeňme, že poslednýkrát, keď sme sa dívali na čas simulácie, okamih prijatia paketu echo-serverom bol na 2,00369 sekundy.
2.00369s UdpEchoServerApplication:HandleRead(): Prijaté 1024 bajty z 10.1.1.1Teraz prijíma paket v 2.25732 sekundy. Je to preto, že sme jednoducho znížili rýchlosť prenosu PointToPointNetDevice z piatich megabitov za sekundu na predvolené hodnotenie, ktoré je 32768 bitov za sekundu. Keby sme zadali novú prenosovú rýchlosť prostredníctvom príkazového riadku, mohli by sme znova zrýchliť naše modelovanie. Urobíme to nasledovne, podľa vzorca implicitne naznačeného v nápovede:
$ .\/waf --run "scratch\/myfirst --ns3::PointToPointNetDevice::DataRate=5Mbps"V dôsledku toho sa predvolené hodnota atribútu DataRate vráti na päť megabitov za sekundu. Ste prekvapení výsledkom? Očividne, aby sme obnovili pôvodné správanie skriptu, musíme tiež nastaviť oneskorenie kanála na zodpovedajúcu rýchlosť svetla. Môžeme požiadať príkazový riadok, aby vytlačil atribúty kanála, tak ako sme to robili pre sieťové zariadenie:
$ .\/waf --run "scratch\/myfirst --PrintAttributes=ns3::PointToPointChannel"Objavíme, že atribút oneskorenia kanála je nastavený nasledovne:
--ns3::PointToPointChannel::Delay=[0ns]:
Oneskorenie prenosu cez kanálPotom môžeme cez príkazový riadok nastaviť obidve tieto predvolené hodnoty,
$ .\/waf --run "scratch\/myfirst
--ns3::PointToPointNetDevice::DataRate=5Mbps
--ns3::PointToPointChannel::Delay=2ms"v tomto prípade obnovujeme čas, ktorý sme mali, keď sme explicitne nastavili DataRate a Delay v skripte:
Waf: Vstup do adresára `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Opustenie adresára `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' sa úspešne dokončilo (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Poslané 1024 bajtov na 10.1.1.2
2.00369s Prijatých 1024 bajtov z 10.1.1.1
2.00369s Echoing packet
Prijatých 1024 bajtov z 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()Všimnite si, že paket bol opäť prijatý serverom za 2,00369 sekundy. Mohli by sme vlastne nastaviť akýkoľvek z používaných v skripte atribútov týmto spôsobom. Konkrétne by sme mohli nastaviť hodnoty rôzne od jednotky pre atribúty MaxPackets. UdpEchoClient.
Ako by ste to využili? Skúste to. Nezabudnite, že musíte zakomentovať miesto, kde prepisujeme predvolené hodnoty atribútov a explicitne nastaviť MaxPackets v skripte. Potom by ste mali skript prekompilovať. Môžete taktiež získať pomoc prostredníctvom príkazového riadku o syntaxi pre nastavenie novej hodnoty predvoleného atribútu. Ak to pochopíte, budete schopní spravovať počet paketov, ktoré sa zobrazujú na príkazovom riadku. Keďže sme usilovní ľudia, náš príkazový riadok by mal vyzerať približne takto:
$ .\/waf --run "scratch\/myfirst
--ns3::PointToPointNetDevice::DataRate=5Mbps
--ns3::PointToPointChannel::Delay=2ms
--ns3::UdpEchoClient::MaxPackets=2"Prírodná otázka, ktorá v tejto chvíli vzniká, je, ako sa dozvedieť o existencii všetkých týchto atribútov. Opäť, príkazový riadok má v tejto otázke funkciu pomoci. Ak požiadať o pomoc príkazového riadku, mali by sme vidieť:
$ ./waf --run "scratch/myfirst --PrintHelp"
myfirst [Program Arguments] [General Arguments]
General Arguments:
--PrintGlobals: Vytlačte zoznam globálnych premenných.
--PrintGroups: Vytlačte zoznam skupín.
--PrintGroup=[group]: Vytlačte všetky TypeIds skupiny.
--PrintTypeIds: Vytlačte všetky TypeIds.
--PrintAttributes=[typeid]: Vytlačte všetky atribúty typeid.
--PrintHelp: Vytlačte túto pomocnú správu.Ak vyberiete argument „PrintGroups“, mali by ste vidieť zoznam všetkých zaregistrovaných skupín. TypeId. Názvy skupín sú zhodné s názvami modulov v zdrojovom adresári (aj keď s veľkým písmenom). Vytlačenie všetkých informácií naraz by bolo príliš rozsiahle, preto je k dispozícii ďalší filter na tlač informácií podľa skupín. Takže sa znova zameriame na modul „point-to-point“:
./waf --run "scratch/myfirst --PrintGroup=PointToPoint"
TypeIds v skupine PointToPoint:
ns3::PointToPointChannel
ns3::PointToPointNetDevice
ns3::PointToPointRemoteChannel
ns3::PppHeaderTu môžete nájsť dostupné názvy TypeId na vyhľadávanie atribútov, napríklad v
--PrintAttributes = ns3 :: PointToPointChannel, ako je uvedené vyššie.
Ďalší spôsob, ako sa dozvedieť o atribútoch, je cez Doxygen ns‑3. Tam je stránka, ktorá vymenúva všetky zaregistrované atribúty v simulátore.
5.2.2 Zachytávanie vlastných príkazov
Môžete tiež pridať svoje vlastné hooky cez systém príkazového riadku. Robí sa to celkom jednoducho pomocou metódy prparsera príkazového riadku. AddValue.
Poďme využiť túto príležitosť na určenie počtu paketov, ktoré by sa mali zobrazovať, úplne iným spôsobom. Pridajme lokálnu premennú s názvom nPackets do funkcie main. Nastavíme ju na jednotku, aby sa zhodovala s naším predchádzajúcim správaním podľa predvolených hodnot. Aby sme umožnili parserovi príkazového riadku zmeniť túto hodnotu, musíme túto hodnotu zachytiť v parseri. Robíme to pridaním volania AddValue. Prejdite a zmeňte skript scratch/myfirst.cc tak, aby začal so nasledujúcim kódom,
int
main (int argc, char *argv[])
{
uint32_t nPackets = 1;
CommandLine cmd;
cmd.AddValue("nPackets", "Počet paketov na echo", nPackets);
cmd.Parse (argc, argv);
...Posuňte sa nadol do bodu v skripte, kde nastavujeme atribút MaxPackets a zmeňte ho tak, aby bol nastavený na premennú nPackets namiesto konštanty 1, ako je uvedené nižšie.
echoClient.SetAttribute ("MaxPackets", UintegerValue (nPackets));Teraz, ak spustíte skript a zadáte argument —PrintHelp, mali by ste vidieť nový argument používateľa, uvedený na obrazovke nápovedy. Zadajte,
$ ./waf --run "scratch/myfirst --PrintHelp"
Waf: Vstupujem do adresára `home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Opúšťam adresár `home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' sa úspešne dokončil (0.403s)
--PrintHelp: Zobrazí túto pomocnú správu.
--PrintGroups: Zobrazí zoznam skupín.
--PrintTypeIds: Zobrazí všetky TypeIds.
--PrintGroup=[group]: Zobrazí všetky TypeIds skupiny.
--PrintAttributes=[typeid]: Zobrazí všetky atribúty typeid.
--PrintGlobals: Zobrazí zoznam globálnych hodnôt.
Argumenty používateľa:
--nPackets: Počet paketov na zaslanieAk chcete zmeniť počet prenášaných paketov, môžete to urobiť nastavením argumentu -nPackets v príkazovom riadku.
$ ./waf --run "scratch/myfirst --nPackets=2"Teraz by ste mali vidieť
Waf: Vstupujem do adresára `home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Opúšťam adresár `home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' sa úspešne dokončil (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Odoslaných 1024 bajtov na 10.1.1.2
2.25732s Prijatých 1024 bajtov z 10.1.1.1
2.25732s Echoing packet
Prijatých 1024 bajtov z 10.1.1.2
Odoslaných 1024 bajtov na 10.1.1.2
3.25732s Prijatých 1024 bajtov z 10.1.1.1
3.25732s Echoing packet
Prijatých 1024 bajtov z 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()Teraz ste odoslali dva pakety. Celkom jednoduché, nie?
Vidíte, že ako používateľ ns-3 môžete používať systém argumentov príkazového riadku na ovládanie globálnych hodnôt a atribútov. Ak ste autorom modelu, môžete pridať nové atribúty k svojim objektom, a tie budú automaticky k dispozícii na konfiguráciu vašimi používateľmi prostredníctvom systému príkazového riadku. Ak ste autorom skriptu, môžete do svojich skriptov pridávať nové premenné a bezproblémovo ich pripojiť k systému príkazového riadku.
5.3 Používanie systémového trasovania
Celý zmysel modelovania spočíva vo vytváraní výstupov na ďalšie štúdium, a systém trasovania ns-3 je hlavným mechanizmom na tento účel. Keďže ns-3 je program napísaný v C++, je možné využiť štandardné prostriedky generovania výstupov programu v C++:
#include <iostream>
...
int main ()
{
...
std::cout << "The value of x is " << x << std::endl;
...
}Môžete dokonca použiť modul zapisovania na pridanie malej štruktúry do vášho riešenia. Je známych mnoho problémov spôsobených týmto prístupom, a preto sme na riešenie týchto problémov poskytli spoločný subsystém trasovania udalostí.
Hlavné ciele systému trasovania ns-3:
Pre základné úlohy by mal systém trasovania umožniť používateľovi generovať štandardné trasovanie pre populárne zdroje, a vyberať objekty, ktoré generujú trasovanie.
Medzi užívateľmi by mala byť možnosť rozšíriť systém sledovania na zmenu generovaného výstupného formátu alebo na vloženie nových zdrojov sledovania bez modifikácie jadra simulátora;
Skúsení užívatelia môžu upravovať jadro simulátora na pridanie nových zdrojov a prijímačov sledovania. Systém sledovania ns‑3 je postavený na princípoch nezávislých zdrojov sledovania a prijímačov, ako aj na unifikovanom mechanizme pripojenia zdrojov k spotrebiteľom.
Systém sledovania ns-3 je postavený na princípoch nezávislých zdrojov a prijímačov sledovania, ako aj na unifikovanom mechanizme pripojenia zdrojov k prijímačom. Zdroje sledovania sú objekty, ktoré môžu signalizovať udalosti, ktoré sa v simulácii dejú, a poskytnúť prístup k základným údajom, ktoré sú zaujímavé. Napríklad, zdroj sledovania môže indikovať, kedy sieťové zariadenie prijalo paket a poskytne prístup k obsahu paketu pre zaujímavé prijímače sledovania.
Zdroje sledovania sú samy o sebe nepoužiteľné, ak nie sú „spojené“ s inými časťami kódu, ktoré skutočne robia s informáciou, ktorú poskytuje prijímač, niečo užitočné. Sledovače sú spotrebitelia udalostí a údajov poskytnutých zdrojmi sledovania. Napríklad, je možné vytvoriť prijímač sledovania, ktorý (pri pripojení k zdroju sledovania z predchádzajúceho príkladu) vytlačí zaujímavé časti prijatého paketu.
Rozumný dôvod pre takéto jasné rozdelenie spočíva v tom, aby sa umožnilo používateľom pripojiť nové typy prijímačov k existujúcim zdrojom sledovania bez potreby editácie a recompilácie jadra simulátora. Týmto spôsobom môže používateľ v uvedenom príklade definovať nového sledovača vo svojom skripte a pripojiť ho k existujúcemu zdroju sledovania definovanému v jadre simulácie, iba úpravou používateľského skriptu.
V tejto príručke sa pozrieme na niektoré preddefinované zdroje a prijímače a ukážeme, ako ich možno nastaviť s minimálnym úsilím zo strany používateľa. Pozrite si príručku ns‑3 alebo sekcie s pokynmi pre rozšírené konfigurácie sledovania, vrátane rozšírenia priestoru mien sledovania a vytvárania nových zdrojov sledovania.
5.3.1 ASCII Trasovanie
ns‑3 poskytuje pomocnú funkcionalitu, ktorá ponúka nízkoúrovňový systém sledovania, aby vám pomohla s detailmi pri nastavovaní jednoduchých sledovaní paketov. Ak túto funkciu zapnete, uvidíte výstupy v súboroch ASCII. Pre tých, ktorí sú zvyknutí na výstup ns-2, tento typ sledovania je analógový out.tr, ktorý je generovaný množstvom skriptov.
Prejdime k veci a pridajme niektoré výsledky ASCII sledovania do nášho skriptu scratch/myfirst.cc. Tesne pred volaním Simulator::Run(), pridajte nasledujúce riadky kódu:
AsciiTraceHelper ascii;
pointToPoint.EnableAsciiAll(ascii.CreateFileStream("myfirst.tr"));Ako v mnohých iných idiomách ns‑3, tento kód používa pomocný objekt na vytvorenie sledovaní ASCII. Druhý riadok obsahuje dve vnorené volania metódy. Metóda „vnútri“ CreateFileStream() používa idiom anonymného objektu na vytvorenie objektu prúdového súboru na zásobníku (bez mena objektu) a odovzdáva ho volanej metóde. V budúcnosti sa do tohto tématu hlbšie ponoríme, ale všetko, čo potrebujete vedieť v tomto štádiu, je, že vytvárate objekt, ktorý predstavuje súbor s názvom myfirst.tr a predávate ho ns‑3. Ukladáme na ns‑3 starostlivosť o vytvorený objekt počas celej jeho životnosti, počas ktorej sa riešia problémy spôsobené málo známym (úmyselným) obmedzením spojeným s kopírovacími konštruktormi prúdových objektov C++.
Externé volanie EnableAsciiAll() oznamuje pomocníkovi, že chcete zahrnúť do vašej simulácie ASCII sledovanie pre všetky spojenia zariadenia bod-bod a že chcete, aby (uvedení) prijímače sledovania zaznamenávali informácie o pohybe paketov v formáte ASCII.
Pre tých, ktorí sú oboznámení s ns-2, sledované udalosti sú ekvivalentné známych bodom sledovania, ktoré zapisujú udalosti „+“, „-“, „d“ a „r.“
Teraz môžete zostaviť skript a spustiť ho z príkazového riadku:
$ ./waf --run scratch/myfirstKoľkokrát predtým ste videli niekoľko správ od Waf, a potom "build finished successfully" (zhoda úspešne dokončená) so zopár správami od bežiaceho programu.
Pri práci program vytvorí súbor s názvom myfirst.tr. Kvôli špecifikám práce Waf, súbor sa predvolene nevytvára v lokálnom adresári, ale v hornom adresári repozitára. Ak chcete zmeniť cestu, kde sa ukladajú trasovania, môžete na to použiť parameter Waf --cwd. To sme neurobili, takže aby sme sa pozreli na súbor ASCII sledovania myfirst.tr vo vašom obľúbenom editore, musíme prejsť do horného adresára nášho repozitára.
Parsenie ASCII trasovania
Tam je veľa informácií v celkom hustej forme, ale prvé, na čo by ste si mali dávať pozor, je to, že súbor sa skladá z jednotlivých riadkov. To bude zrejmé, ak si okno prehliadača trochu rozšírite.
Každý riadok v súbore zodpovedá udalosti sledovania. V tomto prípade sledovanie udalostí v prenose správy, ktorý je prítomný v každom sieťovom zariadení bod-bod v simulácii. Prenosová fronta je fronta, ktorou musí prejsť každý paket pre kanál bod-bod. Všimnite si, že každý riadok v súbore sledovania začína jediným znakom (a má za ním medzeru). Tento znak bude mať nasledujúci význam:
+: vo fronte zariadenia došlo k operácii zaradenia do fronty;
-: vo fronte zariadenia došlo k operácii vybratia prvku;
d: paket bol odmietnutý, zvyčajne preto, že je fronta plná;
r: paket bol prijatý sieťovým zariadením.
Poďme sa podrobnejšie pozrieť na prvý riadok v súbore sledovania. Rozdelím ho na časti (s odsadením na prehľadnosť) a číslom riadka naľavo:
0 +
1 2
2 /NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue
3 ns3::PppHeader (
4 Point-to-Point Protocol: IP (0x0021))
6 ns3::Ipv4Header (
7 tos 0x0 ttl 64 id 0 protokol 17 offset 0 flagy [žiadne]
8 dĺžka: 1052 10.1.1.1 > 10.1.1.2)
9 ns3::UdpHeader (
10 dĺžka: 1032 49153 > 9)
11 Payload (veľkosť=1024)Prvý segment tejto rozšírenej udalosti sledovania (riadok 0) je operácia. Máme tu znak +, čo zodpovedá operácii zaradenia do fronty na prenos. Druhý segment (riadok 1) je čas simulácie, vyjadrený v sekundách. Môžete si spomenúť, že sme požiadali UdpEchoClientApplication začať odosielanie paketov za dve sekundy. Tu vidíme potvrdenie, že sa to naozaj deje.
V nasledujúcej sekcii príkladu sledovania (zo 2. riadku) je ukázané, ktorý zdroj sledovania vyprodukoval túto udalosť (uvádza sa sledovanie priestoru mien). Môžete si predstavovať priestor mien sledovania približne tak isto, ako priestor mien súborového systému. Koreňom priestoru mien je NodeList. To zodpovedá kontajneru spravovanému hlavným kódom ns-3. Obsahuje všetky uzly, ktoré sú vytvorené v skripte. Rovnako ako súborový systém môže mať v koreňovom adresári, tak aj NodeList môžeme mať množstvo uzlov. Takže riadok /NodeList/0 odkazuje na nulový uzol v NodeList, ktorý zvyčajne rozumieme ako „uzol 0“. V každom uzle je zoznam zariadení, ktoré boli nainštalované. Tento zoznam sa nachádza nasledujúco v priestore mien. Môžete vidieť, že táto udalosť sledovania pochádza z DeviceList/0, ktorý je nulovým zariadením nainštalovaným v uzle.
Nasledujúca podstránka, $ ns3::PointToPointNetDevice, informuje, aké zariadenie sa nachádza na nulovej pozícii: zoznam zariadení nulového uzla. Pripomeňme, že operácia +, ktorá sa nachádzala v riadku 0, znamenala, že do fronty prenosového zariadenia bol pridaný prvok. To je odrazené v posledných segmentoch "cesty sledovania": TxQueue/Enqueue.
Ostatné časti v sledovaní by mali byť dostatočne intuitívne. Riadky 3-4 ukazujú, že paket je zapuzdrený v protokole bod-bod. Riadky 5-7 ukazujú, že paket má hlavičku verzie IP4 a vznikol na IP adrese 10.1.1.1 a je určený pre 10.1.1.2. Riadky 8-9 ukazujú, že tento paket má hlavičku UDP a nakoniec, riadok 10 ukazuje, že náklad — očakávaných 1024 bajtov.
Nasledujúci riadok vo sledovacom súbore ukazuje, že ten istý paket bol extrahovaný z prenosovej fronty na tom istom uzle.
Tretí riadok vo sledovacom súbore ukazuje, že paket bol prijatý sieťovým zariadením na uzle s echo serverom. Toto podujatie som reprodukoval nižšie.
0 r
1 2.25732
2 /NodeList/1/DeviceList/0/$ns3::PointToPointNetDevice/MacRx
3 ns3::Ipv4Header (
4 tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
5 length: 1052 10.1.1.1 > 10.1.1.2)
6 ns3::UdpHeader (
7 length: 1032 49153 > 9)
8 Payload (size=1024)Všimnite si, že operácia sledovania je teraz r a čas simulácie sa zvýšil na 2,25732 sekundy. Ak ste starostlivo sledovali pokyny tutoriálu, znamená to, že ste nechali hodnoty DataRate sieťových zariadení a latenciu kanála na predvolenej úrovni. Tento čas by mal byť známy, pretože ste ho už videli v predchádzajúcej časti.
Záznam priestoru názvov zdroja sledovania (riadok 2) bol zmenený, aby odrážal, že táto udalosť pochádza z uzla 1 (/NodeList/1) и пакет принят источником трассировки (/MacRx). Malo by byť dosť ľahké sledovať pohyb paketov cez topológiu pozorovaním zvyšných záznamov v súbore sledovania.
5.3.2 Trasovanie PCAP
Pomocníci zariadení ns-3 sa tiež dajú použiť na vytváranie súborov sledovania vo formáte .pcap. Akronym pcap (zvyčajne napísané malými písmenami) znamená zachytávanie paketov a predstavuje API, ktoré zahŕňa definíciu formátu súboru .pcap. Najpopulárnejší program, ktorý dokáže čítať a zobrazovať tento formát, je Wireshark (predtým nazývaný Ethereal). Napriek tomu existuje mnoho analyzátorov sledovania, ktoré používajú tento formát paketov. Odporúčame používateľom používať množstvo nástrojov dostupných na analýzu pcap sledovania. V tejto príručke sa sústredíme na prezeranie pcap sledovania pomocou tcpdump.
Povolenie pcap sledovania sa vykonáva jedným riadkom kódu.
pointToPoint.EnablePcapAll ("myfirst");Vložte tento riadok kódu po riadku kódu sledovania ASCII, ktorý sme práve pridali do scratch/myfirst.cc. Všimnite si, že sme zadali iba reťazec „myfirst“, nie „myfirst.pcap“ alebo niečo podobné. To je preto, že parameter je prefix, nie celé meno súboru. Počas simulácie pomocník skutočne vytvorí súbor sledovania pre každé zariadenie point-to-point. Názvy súborov budú zostavené pomocou prefixu, čísla uzla, čísla zariadenia a prípony „.pcap».
V našom príklade skriptu nakoniec uvidíme súbory s názvami „myfirst-0-0.pcap“ a „myfirst-1-0.pcap“, ktoré sú pcap sledovaniami pre uzol 0-zariadenie 0 a uzol 1-zariadenie 0. Po pridaní riadku kódu na povolenie pcap sledovania môžete spustiť skript tradičným spôsobom:
$ ./waf --run scratch/myfirstAk sa pozriete do hornej úrovne vášho distribučného adresára, mali by ste vidieť tri súbory: súbor sledovania ASCII, myfirst.trktorý sme predtým preskúmali, súbory myfirst-0-0.pcap a myfirst-1-0.pcap — nové pcap súbory, ktoré sme práve vygenerovali.
Čítanie výstupu pomocou tcpdump
Momentálne je najjednoduchšie prehliadať pcap súbory pomocou tcpdump.
$ tcpdump -nn -tt -r myfirst-0-0.pcap
čítanie zo súboru myfirst-0-0.pcap, linkový typ PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, dĺžka 1024
2.514648 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, dĺžka 1024
tcpdump -nn -tt -r myfirst-1-0.pcap
čítanie zo súboru myfirst-1-0.pcap, linkový typ PPP (PPP)
2.257324 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, dĺžka 1024
2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, dĺžka 1024V dump-e myfirst-0-0.pcap (klientské zariadenie) môžete vidieť, že echo paket je odoslaný po 2 sekundách simulácie. Ak sa pozriete na druhý dump (myfirst-1-0.pcap), uvidíte, že paket je prijatý v momente 2,257324 sekundy. Vo druhom dump-e uvidíte, že paket sa vracia v momente 2.257324 sekundy, a nakoniec, že paket bol prijatý klientom späť v prvom dump-e v momente 2.514648 sekundy.
Čítanie výstupu pomocou Wireshark
Ak nie ste oboznámení s Wireshark, existuje webová stránka, z ktorej si môžete stiahnuť programy a dokumentáciu: . Wireshark — to je grafické používateľské rozhranie, ktoré môžete použiť na zobrazenie týchto súborov sledovania. Ak máte Wireshark, môžete otvoriť ktorýkoľvek z týchto súborov sledovania a zobraziť obsah, akoby ste zachytili pakety pomocou analyzátora paketov.
Zdroj: habr.com
