ProHoster > Blog > Administrácia > Návod na simulátor siete ns-3. Kapitola 5

Návod na simulátor siete ns-3. Kapitola 5

Návod na simulátor siete ns-3. Kapitola 5
kapitola 1,2
kapitola 3
kapitola 4

5 Nastavenia
5.1 Používanie logovacieho modulu
5.1.1 Prehľad protokolovania
5.1.2 Povoliť protokolovanie
5.1.3 Pridanie logovania 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 Zachytenie vlastných príkazov
5.3 Používanie systému sledovania
5.3.1 Sledovanie ASCII
Analýza ASCII stôp
5.3.2 Sledovanie PCAP

Kapitola 5

nastavenie

5.1 Používanie logovacieho modulu

Už sme sa krátko pozreli na protokolovací modul ns-3 pri pohľade na skript first.cc. V tejto kapitole sa bližšie pozrieme na možné využitie logovacieho subsystému.

5.1.1 Prehľad protokolovania

Mnoho veľkých systémov podporuje nejaký druh zariadenia na zaznamenávanie správ a ns-3 nie je výnimkou. V niektorých prípadoch sa do „konzoly operátora“ (ktorá je zvyčajne stderr na systémoch založených na Unixe) zapisujú iba chybové hlásenia. Na iných systémoch sa môžu zobrazovať varovné správy, ako aj podrobnejšie informácie. V niektorých prípadoch sa používajú protokolovacie nástroje na výstup ladiacich správ, ktoré môžu výstup rýchlo rozmazať.

SubHRD použitý v ns-3 predpokladá, že všetky tieto úrovne informačného obsahu sú užitočné a poskytujeme selektívny, vrstvený prístup k zaznamenávaniu správ. Protokolovanie je možné úplne zakázať, povoliť pre jednotlivé komponenty alebo globálne. Na tento účel sa používajú nastaviteľné úrovne informačného obsahu. Logovací modul ns-3 poskytuje relatívne jednoduchý spôsob, ako získať užitočné informácie z vašej simulácie.

Mali by ste pochopiť, že poskytujeme všeobecný mechanizmus – sledovanie – na extrahovanie údajov z vašich modelov, čo by malo byť preferovaným výstupom pre simulácie (viac informácií o našom systéme sledovania nájdete v sekcii s tutoriálom 5.3). Protokolovanie by malo byť preferovanou metódou na získavanie informácií o ladení, varovaní, chybových hlásení alebo na rýchly výstup správ z vašich skriptov alebo modelov kedykoľvek.

V súčasnosti systém definuje sedem úrovní (typov) protokolových správ v rastúcom poradí informačného obsahu.

  • LOG_ERROR - protokolovanie chybových správ (súvisiace makro: NS_LOG_ERROR);
  • LOG_WARN - Protokolovať varovné správy (súvisiace makro: NS_LOG_WARN);
  • LOG_DEBUG - Zaprotokolovať relatívne zriedkavé špeciálne ladiace správy (súvisiace makro: NS_LOG_DEBUG);
  • LOG_INFO - registrácia informačných správ o priebehu programu (súvisiace makro: NS_LOG_INFO);
  • LOG_FUNCTION - Zaznamenáva správy popisujúce každú volanú funkciu (dve súvisiace makrá: NS_LOG_FUNCTION, používané pre členské funkcie, a NS_LOG_FUNCTION_NOARGS, používané pre statické funkcie);
  • LOG_LOGIC - protokolovanie správ popisujúcich logický tok v rámci funkcie (súvisiace makro: NS_LOG_LOGIC);
  • LOG_ALL - Zaznamenáva všetko vyššie uvedené (žiadne priradené makro).
    Pre každý typ (LOG_TYPE) existuje aj LOG_LEVEL_TYPE, ktorý, ak sa použije, umožňuje okrem jeho vlastnej úrovne zaprotokolovať aj všetky úrovne nad ním. (V dôsledku toho sú LOG_ERROR a LOG_LEVEL_ERROR a LOG_ALL a LOG_LEVEL_ALL funkčne ekvivalentné.) Napríklad povolenie LOG_INFO povolí iba správy poskytované makrom NS_LOG_INFO, zatiaľ čo povolenie LOG_LEVEL_INFO bude zahŕňať aj správy poskytované makrami NS_LOG_DEBUG, NS_LOGOR_WARN_NS_LOGOR_WARN

Poskytujeme tiež nepodmienené protokolovacie makro, ktoré sa zobrazuje vždy, bez ohľadu na úroveň protokolovania alebo komponent výberu.

  • NS_LOG_UNCOND - Bezpodmienečné protokolovanie súvisiacej správy (žiadna pridružená úroveň protokolovania).

Každá úroveň môže byť dopytovaná jednotlivo alebo kumulatívne. Protokolovanie je možné nakonfigurovať pomocou premennej prostredia sh NS_LOG alebo protokolovaním volania systémovej funkcie. Ako bolo uvedené vyššie, protokolovací systém má dokumentáciu Doxygen a teraz je ten správny čas na jej preskúmanie, ak ste tak ešte neurobili.

Teraz, keď ste si veľmi podrobne prečítali dokumentáciu, poďme využiť tieto znalosti na získanie zaujímavých informácií z príkladu skriptu scratch/myfirst.ccktoré ste už zostavili.

5.1.2 Povoliť protokolovanie

Použime premennú prostredia NS_LOG na spustenie ďalších protokolov, ale najprv, aby ste sa zorientovali, spustite posledný skript ako predtým,

$ ./waf --run scratch/myfirst

Mali by ste vidieť známy výstup z prvého vzorového programu ns-3

$ 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)
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2

Ukazuje sa, že „odoslané“ a „prijaté“ správy, ktoré vidíte vyššie, sú v skutočnosti zaznamenané správy od Aplikácia UdpEchoClient и Aplikácia UdpEchoServer. Klientsku aplikáciu môžeme napríklad požiadať o vytlačenie dodatočných informácií nastavením úrovne protokolovania prostredníctvom premennej prostredia NS_LOG.

Odteraz budem predpokladať, ž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 na syntax "hodnoty premennej setenv", ktorú tieto shelly vyžadujú.

V súčasnosti klientska aplikácia UDP echo odpovedá na nasledujúci riadok kódu scratch/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Umožňuje úroveň protokolovania LOG_LEVEL_INFO. Keď prejdeme príznakom úrovne protokolovania, v skutočnosti povolíme túto úroveň a všetky nižšie úrovne. V tomto prípade sme povolili 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 zmien skriptu a rekompilácie nastavením premennej prostredia NS_LOG takto:

$ export NS_LOG=UdpEchoClientApplication=level_all

Nastavili sme teda premennú sh shell NS_LOG na nasledujúcu hodnotu,

UdpEchoClientApplication=level_all

Na ľavej strane zadania je názov prihláseného komponentu, ktorý chceme nakonfigurovať, a na pravej strane je príznak, ktorý chceme použiť. V tomto prípade povolíme v aplikácii všetky úrovne ladenia. Ak spustíte skript s takto nastaveným NS_LOG, protokolovací systém ns-3 prijme zmeny a mali by ste vidieť nasledujúci výstup:

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.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Received 1024 bytes from 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Ďalšie informácie o ladení poskytované aplikáciou sú teraz na úrovni NS_LOG_FUNCTION. Zobrazuje každú inštanciu volania funkcie počas vykonávania skriptu. Ako všeobecné pravidlo platí, že vo funkciách metódy je vhodnejšie použiť (minimálne)NS_LOG_FUNCTION (this)... Použite NS_LOG_FUNCTION_NOARGS ()
len v statických funkciách. Upozorňujeme však, že systém ns-3 nemusí podporovať žiadnu funkciu protokolovania. Rozhodnutie o množstve zaznamenaných informácií je ponechané na individuálnom vývojárovi modelu. V prípade echo aplikácií je k dispozícii veľké množstvo protokolovacích výstupov.

Teraz môžete zobraziť protokol volaní funkcií, ktoré aplikácia uskutočnila. Ak sa pozriete pozorne, medzi čiarou si všimnete dvojbodku Aplikácia UdpEchoClient a názov metódy, kde by ste mohli očakávať, že uvidíte operátor rozsahu C++ (: :). Toto je zámerné.

Toto v skutočnosti nie je názov triedy, ale názov logovacieho komponentu. Keď existuje zhoda medzi zdrojovým súborom a triedou, je to zvyčajne názov triedy, ale mali by ste si uvedomiť, že to v skutočnosti nie je názov triedy a namiesto dvojitej dvojbodky je tam jedna dvojbodka. Toto je spôsob, ktorý vám pomôže koncepčne oddeliť názov logovacej fazule od názvu triedy relatívne jemným spôsobom.

V niektorých prípadoch však môže byť ťažké určiť, ktorá metóda skutočne generuje správu denníka. Ak sa pozriete na text vyššie, možno sa čudujete, kde je riadok „Received 1024 bytes from 10.1.1.2" Tento problém môžete vyriešiť nastavením úrovne prefix_func do premennej prostredia NS_LOG. Vyskúšajte nasledovné:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Všimnite si, že úvodzovky sú potrebné, pretože zvislá čiara, ktorú používame na znázornenie operácie OR, je tiež spojka potrubia Unix. Ak teraz spustíte skript, uvidíte, že protokolovací systém zabezpečuje, že každá správa v danom protokole má predponu s názvom komponentu.

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.417s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Teraz môžete vidieť, že všetky správy prichádzajúce z klientskej aplikácie UDP echo sú ako také identifikované. správa "Received 1024 bytes from 10.1.1.2“ je teraz jasne identifikovaný ako pochádzajúci z klientskej aplikácie echo. Zostávajúca správa musí pochádzať z aplikácie servera UDP echo. Tento komponent môžeme povoliť zadaním zoznamu komponentov oddelených dvojbodkou do premennej prostredia NS_LOG.

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

Upozornenie: Vo vyššie uvedenom vzorovom texte budete musieť odstrániť znak nového riadku za dvojbodkou (:), ktorý sa používa na formátovanie dokumentu. Ak teraz spustíte skript, uvidíte všetky protokolové správy z aplikácií klienta a servera. Môžete vidieť, že to môže byť veľmi užitočné pri ladení.

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.406s)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoServerApplication:StartApplication()
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
UdpEchoServerApplication:HandleRead(): Echoing packet
UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
UdpEchoServerApplication:StopApplication()
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Niekedy je tiež užitočné vidieť čas simulácie, v ktorom bola vygenerovaná správa protokolu. Môžete to urobiť pridaním bitu OR 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: 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.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(): Sent 1024 bytes to 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 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 bola počas simulácie volaná 0 sekúnd. V skutočnosti sa to stane pred spustením simulácie, ale čas je zobrazený ako nula sekúnd. To isté platí pre správu konštruktora UdpEchoClient.

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.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(): Sent 1024 bytes to 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Pripomeňme si, že skript scratch/first.cc spustil aplikáciu echo server jednu sekundu pred začiatkom simulácie. Teraz môžete vidieť, že metóda Spustite aplikáciu server je skutočne volaný v prvej sekunde. Môžete si tiež všimnúť, že klient echo sa spustí v druhej sekunde simulácie, ako sme sa pýtali v skripte.

Teraz môžete počas hovoru sledovať priebeh simulácie ScheduleTransmit v klientovi, ktorý volá HandleRead callback Send v aplikácii echo server. Všimnite si, že uplynutý čas na odoslanie paketu cez spojenie bod-bod je 3,69 milisekúnd. Môžete vidieť, že echo server zaprotokoluje správu, že odpovedal na paket, a potom, po oneskorení kanála, uvidíte, že echo klient dostane echo paket vo svojej metóde HandleRead.

V tejto simulácii sa veľa deje bez toho, aby ste si to všimli. Celý proces však môžete sledovať veľmi jednoducho povolením všetkých protokolovacích komponentov v systéme. Skúste nastaviť premennú NS_LOG na nasledujúcu hodnotu,

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

Vyššie uvedená hviezdička je zástupný znak pre komponent protokolovania. To bude zahŕňať všetky položky vo všetkých komponentoch použitých v simulácii. Nebudem tu reprodukovať výstup (v čase písania tohto článku produkuje 1265 riadkov výstupu pre jeden echo paket), ale tieto informácie môžete presmerovať do súboru a zobraziť si ich vo svojom obľúbenom editore.

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

Osobne používam túto extrémne podrobnú verziu protokolovania, keď mám problém a netuším, kde sa stala chyba. Spustenie kódu môžem sledovať celkom jednoducho bez nastavovania bodov prerušenia a prechádzania kódom v debuggeri. Môžem len upraviť výstup v mojom obľúbenom editore a hľadať, čo očakávam, a vidím, že sa stane niečo, čo som nečakal. Keď mám všeobecnú predstavu o tom, čo sa deje, skočím do debuggera, aby som sa dostal do problému. Tento typ výstupu môže byť obzvlášť užitočný, keď váš skript urobí niečo úplne neočakávané. Ak používate iba debugger, môže vám úplne uniknúť zvrat. Vďaka registrácii sú takéto odbočky viditeľné.

5.1.3 Pridanie logovania do vášho kódu

Do svojich simulácií môžete pridať nové položky volaním komponentu protokolu z viacerých makier. Urobme to v scenári myfirst.cc, ktorý máme v adresári „čisté“. Pripomeňme, že v tomto scenári sme definovali komponent protokolovania:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Uvedomujete si, že protokolovanie všetkých správ z tohto komponentu môžete povoliť nastavením premennej prostredia NS_LOG na rôznych úrovniach. Poďme ďalej a do skriptu pridáme niekoľko záznamov. Makro používané na pridávanie správ na informačnej úrovni do protokolu je NS_LOG_INFO. Pridajme správu (tesne predtým, než začneme vytvárať uzly), ktorá vám povie, že skript je vo fáze „Vytváranie topológie“. Toto sa vykonáva v nasledujúcom útržku kódu,
Otvorte scratch/myfirst.cc vo svojom obľúbenom editore a pridajte riadok,
NS_LOG_INFO ("Creating Topology");
tesne pred čiarami,

NodeContainer nodes;
nodes.Create (2);

Teraz zostavte skript pomocou WAFa vymažte premennú NS_LOG, aby ste zakázali stream protokolovania, ktorý sme povolili predtým:

$ ./waf
$ export NS_LOG=
Теперь, если вы запустите скрипт,
$ ./waf --run scratch/myfirst

Novú správu neuvidíte, pretože priradený komponent protokolovania (FirstScriptExample) nebol povolený. Ak chcete zobraziť svoju správu, musíte povoliť komponent protokolovania FirstScriptExample s úrovňou nie nižšou ako NS_LOG_INFO. Ak chcete iba vidieť túto konkrétnu úroveň protokolovania, môžete ju povoliť takto,

$ export NS_LOG=FirstScriptExample=info

Ak teraz spustíte skript, uvidíte novú správu „Vytváram topológiu“,

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.404s)
Creating Topology
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2

5.2 Používanie argumentov príkazového riadku

5.2.1 Prepísanie predvolených hodnôt atribútov

Ďalším spôsobom, ako zmeniť správanie skriptov ns-3 bez úprav alebo vytvárania, je použitie argumentov príkazového riadku. Poskytujeme mechanizmus na analýzu argumentov príkazového riadka a automatické nastavenie lokálnych a globálnych premenných na základe výsledkov.

Prvým krokom pri používaní argumentačného systému príkazového riadku je deklarácia analyzátora príkazového riadku. Je to celkom jednoduché (vo vašom hlavnom programe), ako v nasledujúcom kóde,

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

Tento jednoduchý dvojriadkový úryvok je skutočne veľmi užitočný sám o sebe. Otvára dvere do globálneho systému premenných a atribútov ns-3. Pridajme dva riadky kódu na začiatok funkcie hlavného skriptu scratch/myfirst.cc. Pokračujeme, skompilujeme skript a spustíme ho, pri spustení požiadame o pomoc nasledovne,

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

Tento príkaz sa vás opýta WAF spustiť skript škrabanec/môj prvý a odovzdajte mu argument príkazového riadku -Pomocník pre tlač. Úvodzovky sú potrebné na označenie programu, pre ktorý je argument určený. Analyzátor príkazového riadku zistí argument -Pomocník pre tlač a zobrazí odpoveď,

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.

Teraz sa pozrime na možnosť —PrintAtributes. Systém atribútov ns-3 sme už spomenuli pri štúdiu skriptu first.cc. Videli sme nasledujúce riadky kódu,

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

a povedali to Rýchlosť prenosu dát je vlastne atribút PointToPointNetDevice. Na zobrazenie atribútov použijeme analyzátor argumentov príkazového riadka PointToPointNetDevice. Zoznam pomoci hovorí, čo musíme poskytnúť TypeId. Toto je názov triedy, do ktorej patria atribúty záujmu. V našom prípade to tak bude ns3::PointToPointNetDevice. Pokračujme vpred, vstúpme,

$ ./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 v zozname sú

--ns3::PointToPointNetDevice::DataRate=[32768bps]:
The default data rate for point to point links

Toto je predvolená hodnota, ktorú systém použije pri vytváraní objektu PointToPointNetDevice. Túto predvolenú hodnotu prepíšeme pomocou parametra atribút в PointToPointHelper vyššie. Použime predvolené hodnoty pre zariadenia a kanály point-to-point. Za týmto účelom vymažeme hovory SetDeviceAttribute и SetChannelAttribute z myfirst.cc, ktorý máme v čistom adresári.

Váš skript by mal teraz jednoducho deklarovať PointToPointHelper a nevykonávajte žiadne inštalačné operácie, ako je uvedené v príklade nižšie,

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

Pokračujte a vytvorte nový skript pomocou WAF (./waff) a vráťme sa späť a zahrňte nejaký záznam z aplikácie servera UDP echo a zahrňte predponu času.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Ak spustíte skript, mali by ste vidieť nasledujúci výstup:

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.405s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.25732s Received 1024 bytes from 10.1.1.1
2.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Pripomeňme, že keď sme sa naposledy pozreli na čas simulácie, v momente prijatia paketu serverom echo to bolo 2,00369 sekúnd.

2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1

Teraz dostane paket za 2.25732 sekundy. Je to preto, že sme jednoducho resetovali dátovú rýchlosť PointToPointNetDevice z piatich megabitov za sekundu na predvolenú hodnotu, ktorá je 32768 bitov za sekundu. Ak by sme nahradili nový DataRate pomocou príkazového riadku, mohli by sme našu simuláciu opäť urýchliť. Urobíme to takto, podľa vzorca, ktorý implikuje prvok help:

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

Toto vráti predvolený atribút DataRate na päť megabitov za sekundu. Ste prekvapení výsledkom? Ukazuje sa, že aby sme vrátili pôvodné správanie skriptu, musíme tiež nastaviť oneskorenie kanála tak, aby zodpovedalo rýchlosti svetla. Môžeme požiadať systém príkazového riadku, aby vypísal atribúty kanála, rovnako ako v prípade sieťového zariadenia:

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

Zistíme, že atribút oneskorenia kanála je nastavený takto:

--ns3::PointToPointChannel::Delay=[0ns]:
Transmission delay through the channel

Potom môžeme cez systém príkazového riadku nastaviť obe tieto predvolené hodnoty.

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

v tomto prípade obnovíme čas, ktorý sme mali, keď sme v skripte explicitne nastavili DataRate a Delay:

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.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.00369s Received 1024 bytes from 10.1.1.1
2.00369s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Všimnite si, že paket prijme server znova po 2,00369 sekundách. Týmto spôsobom by sme vlastne mohli nastaviť ktorýkoľvek z atribútov použitých v skripte. Najmä by sme mohli nastaviť atribúty MaxPackets na iné ako jednu hodnotu UdpEchoClient.

Ako by ste to využili? Pokúsiť sa. Nezabudnite, že musíte zakomentovať miesto, kde prepíšeme predvolenú hodnotu atribútu a explicitne nastavíme MaxPackets v scenári. Potom musíte skript znova zostaviť. Môžete tiež použiť príkazový riadok na získanie pomoci so syntaxou na nastavenie novej predvolenej hodnoty atribútu. Keď to pochopíte, môžete ovládať počet balíkov zobrazených na príkazovom riadku. Keďže sme usilovní ľudia, náš príkazový riadok by mal vyzerať asi takto:

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

Prirodzená otázka, ktorá v tomto bode vyvstáva, je, ako vedieť o existencii všetkých týchto atribútov. Systém príkazového riadka má v tejto veci opäť funkciu pomocníka. Ak požiadame príkazový riadok o pomoc, mali by sme vidieť:

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

Ak vyberiete argument "PrintGroups", mali by ste vidieť zoznam všetkých registrovaných skupín TypeId. Názvy skupín sú konzistentné s názvami modulov v zdrojovom adresári (hoci sú veľké. Tlač všetkých informácií naraz by bola príliš objemná, preto je k dispozícii dodatočný filter na tlač informácií podľa skupín. Opäť sa teda zamerajte na modul point-to-point:

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

Tu nájdete dostupné názvy TypeId pre vyhľadávanie atribútov, napríklad v
--PrintAttributes = ns3 :: PointToPointChannelako je uvedené vyššie.

Ďalším spôsobom, ako sa dozvedieť o atribútoch, je cez Doxygen ns‑3. Existuje stránka, ktorá obsahuje zoznam všetkých atribútov zaregistrovaných v simulátore.

5.2.2 Zachytenie vlastných príkazov

Môžete tiež pridať svoje vlastné háčiky prostredníctvom systému príkazového riadku. To sa robí celkom jednoducho pomocou metódy analyzátora príkazového riadku Pridaná hodnota.
Využime túto funkciu na určenie počtu balíkov, ktoré sa majú zobraziť úplne iným spôsobom. Pridajme lokálnu premennú tzv nPackets do funkcie hlavné. Nastavíme ho na hodnotu jedna, aby zodpovedala nášmu predchádzajúcemu predvolenému správaniu. Aby mohol syntaktický analyzátor príkazového riadka zmeniť túto hodnotu, musíme túto hodnotu zachytiť v analyzátore. Robíme to pridaním hovoru Pridaná hodnota. Choďte a zmeňte skript scratch/myfirst.cc takže začať s nasledujúcim kódom,

int
main (int argc, char *argv[])
{
uint32_t nPackets = 1;
CommandLine cmd;
cmd.AddValue("nPackets", "Number of packets to echo", nPackets);
cmd.Parse (argc, argv);
...

Prejdite 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));

Ak teraz spustíte skript a zadáte argument -PrintHelp, mali by ste vidieť argument nového používateľa. uvedené na displeji pomocníka. vstúpiť,

$ ./waf --run "scratch/myfirst --PrintHelp"
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.403s)
--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.
User Arguments:
--nPackets: Number of packets to echo

Ak chcete zmeniť počet prenášaných paketov, môžete tak urobiť nastavením argumentu príkazového riadka - -nPackets.

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

Teraz by ste mali vidieť

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.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.25732s Received 1024 bytes from 10.1.1.1
2.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
Sent 1024 bytes to 10.1.1.2
3.25732s Received 1024 bytes from 10.1.1.1
3.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Teraz ste odoslali dva balíky. Celkom jednoduché, nie?
Môžete vidieť, že ako používateľ ns-3 môžete použiť systém argumentov príkazového riadku na manipuláciu s globálnymi hodnotami a atribútmi. Ak ste autorom modelu, môžete do svojich objektov pridať nové atribúty a budú automaticky dostupné na konfiguráciu vašim používateľom prostredníctvom systému príkazového riadka. Ak ste autorom skriptov, môžete do svojich skriptov pridávať nové premenné a bez problémov ich zapájať do systému príkazového riadka.

5.3 Používanie systému sledovania

Celý zmysel modelovania je generovať výstup pre ďalšie štúdium a systém sledovania ns-3 je na to hlavným mechanizmom. Keďže ns-3 je program v C++, možno použiť štandardné prostriedky na generovanie výstupu z programu C++:

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

Môžete dokonca použiť protokolovací modul na pridanie malej štruktúry do vášho riešenia. Existuje mnoho známych problémov spôsobených týmto prístupom, a preto sme poskytli všeobecný podsystém sledovania udalostí na vyriešenie týchto problémov.

Hlavné ciele systému sledovania ns-3 sú:

  • Pre základné úlohy by mal systém sledovania umožňovať používateľovi generovať štandardné sledovanie pre populárne zdroje a vyberať objekty, ktoré generujú sledovanie;

  • Stredne pokročilí používatelia by mali byť schopní rozšíriť systém sledovania tak, aby zmenil vygenerovaný výstupný formát alebo vložil nové zdroje sledovania bez úpravy jadra simulátora;

  • Pokročilí používatelia môžu upraviť jadro simulátora a pridať nové zdroje sledovania a záchytky. Systém sledovania ns-3 je postavený na princípoch nezávislých zdrojov a prijímačov sledovania, ako aj na jednotnom mechanizme pripojenia zdrojov k spotrebiteľom.

Trasovací systém ns-3 je vybudovaný na princípoch nezávislých trasovacích zdrojov a prijímačov, ako aj na jednotnom mechanizme pripájania zdrojov k prijímačom. Zdroje sledovania sú objekty, ktoré môžu signalizovať udalosti vyskytujúce sa v simulácii a poskytnúť prístup k základným údajom, ktoré nás zaujímajú. Zdroj sledovania môže napríklad indikovať, kedy sieťové zariadenie prijalo paket, a sprístupniť obsah paketu zainteresovaným prijímačom sledovania.

Samotné zdroje sledovania sú k ničomu, pokiaľ nie sú „spojené“ s inými časťami kódu, ktoré skutočne robia niečo užitočné s informáciami poskytovanými umývadlom. Sledovače sú konzumentmi udalostí a údajov poskytovaných zdrojmi sledovania. Môžete napríklad vytvoriť zásobník sledovania, ktorý (po pripojení k zdroju sledovania z predchádzajúceho príkladu) vytlačí časti, ktoré vás zaujímajú v prijatom pakete.

Dôvodom tohto explicitného oddelenia je umožniť používateľom pripojiť nové typy umývadiel k existujúcim zdrojom sledovania bez toho, aby museli upravovať a prekompilovať jadro simulátora. Takže vo vyššie uvedenom príklade môže užívateľ definovať nový sledovač vo svojom skripte a pripojiť ho k existujúcemu zdroju sledovania definovanému v simulačnom jadre iba úpravou užívateľského skriptu.

V tomto návode si prejdeme niektoré z preddefinovaných zdrojov a umývadiel a ukážeme si, ako ich možno nakonfigurovať s čo najmenším úsilím zo strany používateľa. Informácie o pokročilej konfigurácii sledovania vrátane rozšírenia priestoru názvov sledovania a vytvárania nových zdrojov sledovania nájdete v príručke ns-3 alebo v sekciách s návodmi.

5.3.1 Sledovanie ASCII

ns-3 poskytuje pomocnú funkciu, ktorá poskytuje nízkoúrovňový systém sledovania, ktorý vám pomôže s podrobnosťami pri nastavovaní jednoduchých sledovania paketov. Ak povolíte túto funkciu, výstup uvidíte v súboroch ASCII. Pre tých, ktorí poznajú výstup ns-2, je tento typ sledovania podobný out.tr, ktorý je generovaný mnohými skriptami.

Poďme k veci a do nášho skriptu scratch/myfirst.cc pridajte niekoľko výsledkov sledovania ASCII. Tesne pred hovorom Simulator :: Run (), pridajte nasledujúce riadky kódu:
AsciiTraceHelper ascii;

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

Ako mnoho iných idiómov ns-3, aj tento kód používa pomocný objekt na vytváranie ASCII stôp. Druhý riadok obsahuje dve vnorené volania metódy. Metóda „vnútri“. CreateFileStream() používa idióm anonymného objektu na vytvorenie objektu toku súboru v zásobníku (bez názvu objektu) a odovzdá ho volanej metóde. V budúcnosti sa tomu budeme venovať hlbšie, ale v tejto chvíli potrebujete vedieť len to, že vytvárate objekt, ktorý predstavuje súbor s názvom myfirst.tr a preniesť ho do ns-3. ns-3 poverujeme starostlivosťou o vytvorený objekt na celú dobu jeho životnosti, počas ktorej rieši problémy spôsobené málo známym (zámerným) obmedzením spojeným s konštruktormi kopírovania streamovaných objektov C++.

Externý hovor EnableAsciiAll() povie asistentovi, že chcete zahrnúť sledovanie ASCII do vašej simulácie pre všetky pripojenia zariadení typu point-to-point a že chcete, aby (špecifikované) prijímače sledovania zaznamenávali informácie o pohybe paketov vo formáte ASCII.

Pre tých, ktorí poznajú ns-2, sú sledované udalosti ekvivalentné známym sledovacím bodom, ktoré zaznamenávajú udalosti "+", "-", "d" a "r".
Teraz môžete vytvoriť skript a spustiť ho z príkazového riadku:

$ ./waf --run scratch/myfirst

Ako už mnohokrát predtým, uvidíte niekoľko správ od Waf a potom „build“ úspešne dokončený s niekoľkými správami zo spusteného programu.

Pri spustení program vytvorí súbor s názvom myfirst.tr. Vzhľadom na charakter práce WAF, v predvolenom nastavení sa súbor nevytvorí v lokálnom adresári, ale v adresári najvyššej úrovne úložiska. Ak chcete zmeniť cestu, kde sa ukladajú stopy, môžete ju určiť pomocou parametra Waf --cwd. Neurobili sme to, takže ak si chcete pozrieť súbor sledovania ASCII myfirst.tr vo vašom obľúbenom editore, budeme musieť prejsť do adresára najvyššej úrovne nášho úložiska.

Analýza ASCII stôp

Je tam veľa informácií v pomerne hustej forme, no ako prvé si treba všimnúť, že súbor pozostáva z jednotlivých riadkov. To bude jasne viditeľné, ak rozšírite zobrazovacie okno.

Každý riadok v súbore zodpovedá udalosti sledovania. V tomto prípade sledujeme udalosti vo fronte prenosov prítomných v každom zariadení siete point-to-point v simulácii. Prenosový front je front, cez ktorý musí prejsť každý paket pre spojenie bod-bod. Všimnite si, že každý riadok v súbore sledovania začína jedným znakom (a za ním je medzera). Tento symbol bude mať nasledujúci význam:

+: vo fronte zariadení sa vyskytla operácia zaradenia do frontu;
-: vo fronte zariadení sa vyskytla operácia načítania prvkov;
d: paket bol zrušený, zvyčajne preto, že front bol plný;
r: Paket bol prijatý sieťovým zariadením.

Pozrime sa bližšie na prvý riadok v sledovacom súbore. Rozdelím to na časti (s odsadením kvôli prehľadnosti) a číslom riadku vľ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 protocol 17 offset 0 flags [none]
8     length: 1052 10.1.1.1 > 10.1.1.2)
9     ns3::UdpHeader (
10      length: 1032 49153 > 9)
11      Payload (size=1024)

Prvá časť tejto udalosti rozšíreného sledovania (riadok 0) je operácia. Máme tu symbol +, ktorý zodpovedá fungovaniu radenia na prenos. Druhá časť (riadok 1) je čas simulácie vyjadrený v sekundách. Možno si pamätáte, čo sme sa pýtali Aplikácia UdpEchoClient začnite odosielať pakety do dvoch sekúnd. Tu vidíme potvrdenie, že sa to naozaj deje.

Nasledujúca časť príkladu sledovania (z riadku 2) ukazuje, ktorý zdroj sledovania vygeneroval túto udalosť (s uvedením sledovania priestoru názvov). Menný priestor sledovania si môžete predstaviť podobne ako menný priestor súborového systému. Koreňom menného priestoru je NodeList. To zodpovedá kontajneru spravovanému v hlavnom kóde 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 adresáre, NodeList môžeme mať veľa uzlov. Takže riadok /NodeList/0 odkazuje na nulový uzol v zozname NodeList, ktorý zvyčajne považujeme za "uzol 0". Každý uzol má zoznam zariadení, ktoré boli nainštalované. Tento zoznam sa nachádza ďalej v mennom priestore. Môžete vidieť, že táto udalosť sledovania pochádza z DeviceList/0, čo je nulové zariadenie nainštalované v uzle.

Ďalší podreťazec, $ ns3 :: PointToPointNetDevice, hovorí, ktoré zariadenie je na pozícii nula: zoznam zariadení s nulovým uzlom. Pripomeňme, že operácia + nájdená v riadku 0 znamenala, že prvok bol pridaný do vysielacieho frontu zariadenia. To sa odráža v posledných segmentoch „trasy“: TxQueue/Enqueue.

Zostávajúce sekcie v stope by mali byť pomerne intuitívne. Riadky 3-4 označujú, že paket je zapuzdrený v protokole point-to-point. Riadky 5-7 ukazujú, že paket má hlavičku verzie IP4 a pochádza z adresy IP 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 užitočné zaťaženie je očakávaných 1024 bajtov.

Ďalší riadok v súbore sledovania ukazuje, že rovnaký paket bol stiahnutý z prenosového frontu na rovnakom uzle.

Tretí riadok v súbore sledovania ukazuje, že paket bol prijatý sieťovým zariadením na hostiteľovi servera echo. Udalosť 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 sekúnd. Ak ste pozorne postupovali podľa návodu, znamená to, že ste ponechali DataRate a Link Delay sieťových zariadení na ich predvolených hodnotách. Tento čas by mal byť známy, ako ste videli v predchádzajúcej časti.

Položka priestoru názvov zdroja sledovania (riadok 2) bola upravená tak, aby odrážala, že táto udalosť pochádza z uzla 1 (/NodeList/1) a paket je prijatý zdrojom sledovania (/MacRx). Malo by byť pre vás pomerne jednoduché sledovať pohyb paketu cez topológiu tak, že sa pozriete na zostávajúce stopy v súbore.

5.3.2 Sledovanie PCAP

Pomocníkov zariadenia ns-3 možno použiť aj na vytváranie súborov sledovania vo formáte .pcap. Skratka pcap (zvyčajne písané malými písmenami) znamená zachytávanie paketov a je to vlastne API, ktoré zahŕňa definovanie formátu súboru .pcap. Najpopulárnejší program, ktorý dokáže čítať a zobrazovať tento formát, je Wireshark (predtým tzv éterický). Existuje však veľa analyzátorov sledovania prevádzky, ktoré používajú tento formát paketov. Odporúčame používateľom, aby používali množstvo dostupných nástrojov na analýzu stôp pcap. V tomto návode sa zameriame na prezeranie stôp pcap pomocou tcpdump.

Povolenie sledovania pcap sa vykonáva pomocou jedného riadku kódu.

pointToPoint.EnablePcapAll ("myfirst");

Prilepte tento riadok kódu za kód sledovania ASCII, ktorý sme práve pridali scratch/myfirst.cc. Všimnite si, že sme odovzdali iba reťazec "myfirst", nie "myfirst.pcap" alebo niečo podobné. Dôvodom je, že parameter je predpona, nie úplný názov súboru. Počas simulácie asistent skutočne vytvorí súbor sledovania pre každé zariadenie typu point-to-point. Názvy súborov budú vytvorené pomocou predpony, čísla uzla, čísla zariadenia a prípony ".pcap".

V našom príklade skriptu nakoniec uvidíme súbory s názvom "myfirst-0-0.pcap"A"myfirst-1-0.pcap“, čo sú stopy pcap pre uzol 0 – zariadenie 0 a uzol 1 – zariadenie 0. Po pridaní riadku kódu na povolenie sledovania pcap môžete skript spustiť obvyklým spôsobom:

$ ./waf --run scratch/myfirst

Ak sa pozriete do adresára najvyššej úrovne vašej distribúcie, mali by ste vidieť tri súbory: súbor sledovania ASCII myfirst.tr, ktoré sme predtým študovali, súbory myfirst-0-0.pcap и myfirst-1-0.pcap - nové súbory pcap, ktoré sme práve vygenerovali.

Čítanie výstupu pomocou tcpdump

V súčasnosti je najjednoduchším spôsobom zobrazenia súborov pcap použiť tcpdump.

$ 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

Na smetisku myfirst-0-0.pcap (klientske zariadenie) môžete vidieť, že echo paket je odoslaný po 2 sekundách simulácie. Ak sa pozriete na druhú skládku (myfirst-1-0.pcap), uvidíte, že paket je prijatý o 2,257324 sekúnd. V druhom výpise uvidíte, že paket je vrátený v 2.257324 sekundách a nakoniec, že ​​paket bol prijatý späť klientom v prvom výpise v 2.514648 sekundách.

Výstup čítania pomocou Wireshark

Ak nie ste oboznámení s Wireshark, existuje webová stránka, z ktorej si môžete stiahnuť programy a dokumentáciu: http://www.wireshark.org/. Wireshark je GUI, ktoré možno použiť na zobrazenie týchto sledovacích súborov. Ak máte Wireshark, môžete otvoriť ktorýkoľvek zo sledovacích súborov a zobraziť obsah, ako keby ste pakety zachytili pomocou paketového sledovača.

Zdroj: hab.com

Pridať komentár