Učebnice simulátoru sítě ns-3. Kniha 5

kapitoly 1,2
kapitola 3
kapitola 4

5 Nastavení
5.1 Použití modulu protokolování
5.1.1 Přehled protokolování
5.1.2 Povolení protokolování
5.1.3 Přidání protokolování do vašeho kódu
5.2 Použití argumentů příkazového řádku
5.2.1 Přepis hodnot výchozích atributů
5.2.2 Zachycení vašich vlastních příkazů
5.3 Použití systému sledování
5.3.1 ASCII Sledování
Parsování ASCII sledů
5.3.2 Sledování PCAP

Kapitola 5

Nastavení

5.1 Použití modulu protokolování

Již jsme stručně prozkoumali modul protokolování ns‑3, zatímco jsme se dívali na skript first.cc. V této kapitole se podíváme podrobněji na možné varianty využití subsystému protokolování.

5.1.1 Přehled protokolování

Mnohé velké systémy podporují nějaký prostředek pro registraci zpráv a ns‑3 není výjimkou. V některých případech se do „konzoly operátora“ (která obvykle odpovídá stderr v UNIXových systémech) zapisují pouze chybové zprávy. V jiných systémech se mohou zobrazovat varovné zprávy a také podrobnější informace. V některých případech se prostředky protokolování používají k výstupu ladicích zpráv, které mohou rychle „zkreslit“ výstup.

Přístup používaný v ns‑3 předpokládá, že všechny tyto úrovně informovanosti jsou užitečné, a poskytujeme selektivní, vícestupňový přístup k registraci zpráv. Protokolování může být zcela vypnuto, zapnuto pro jednotlivé komponenty nebo v celosvětovém měřítku. K tomu slouží konfigurovatelné úrovně informovanosti. Modul protokolování ns‑3 poskytuje relativně jednoduchý způsob získávání užitečných informací z vaší simulace.

Musíte pochopit, že poskytujeme mechanismus obecného účelu — sledování — pro extrakci dat z vašich modelů, který by měl být preferován pro výstup při modelování (pro více informací o našem systému sledování viz oddíl příručky 5.3). Protokolování by mělo být preferovanou metodou pro získávání ladicích informací, varování, chybových zpráv nebo pro rychlý výstup zpráv z vašich scénářů nebo modelů kdykoliv.

V současné době je v systému definováno sedm úrovní (typů) zpráv protokolu podle vzestupu informovanosti.

• LOG_ERROR — registrace chybových zpráv (spojený makro: NS_LOG_ERROR);
• LOG_WARN — registrace varovných zpráv (spojený makro: NS_LOG_WARN);
• LOG_DEBUG — registrace relativně vzácných speciálních ladicích zpráv (spojený makro: NS_LOG_DEBUG);
• LOG_INFO — registrace informačních zpráv o průběhu programu (spojený makro: NS_LOG_INFO);
• LOG_FUNCTION — registrace zpráv popisujících každou vyvolanou funkci (dva spojené makra: NS_LOG_FUNCTION, používané pro členské funkce, a NS_LOG_FUNCTION_NOARGS, používané pro statické funkce);
• LOG_LOGIC — registrace zpráv popisujících logický tok uvnitř funkce (spojený makro: NS_LOG_LOGIC);
• LOG_ALL — registrace všeho výše uvedeného (spojené makro není).
  Pro každý typ (LOG_TYPE) existuje také typ LOG_LEVEL_TYPE, který, pokud je použit, umožňuje registrovat kromě jeho vlastního úrovně všechny úrovně nad ním. (Jako důsledek, LOG_ERROR a LOG_LEVEL_ERROR, stejně jako LOG_ALL a LOG_LEVEL_ALL jsou funkčně ekvivalentní.) Například, povolení LOG_INFO umožní pouze zprávy poskytované makrem NS_LOG_INFO, při povolení LOG_LEVEL_INFO budou také zahrnuty zprávy poskytované makry NS_LOG_DEBUG, NS_LOG_WARN a NS_LOG_ERROR.

Nabízíme také makro bezpodmínečného protokolování, které se zobrazuje vždy, nezávisle na úrovni protokolování nebo komponentu výběru.

• NS_LOG_UNCOND — bezpodmínečná registrace spojené zprávy (bez spojené úrovně protokolování).

Každá úroveň může být požadována individuálně nebo kumulativně. Protokolování lze nastavit pomocí proměnné prostředí sh NS_LOG nebo registrací volání systémové funkce. Jak bylo ukázáno dříve, systém protokolování má Doxygen dokumentaci a je nyní správný čas podívat se na něj, pokud jste tak ještě neučinili.

Nyní, když jste pečlivě přečetli dokumentaci, pojďme využít tyto znalosti k získání zajímavých informací z příkladového skriptu scratch/myfirst.cc, který jste již zkompilovali.

5.1.2 Povolení protokolování

Pojďme použít proměnnou prostředí NS_LOG k provádění dalších protokolů, ale nejprve, jen pro orientaci, spusťte poslední skript, jak jste to dělali dříve,

$ ./waf --run scratch/myfirst

Měli byste vidět již známý výstup první příkladové programu ns-3.

$ Waf: Vstup do adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Opustit adresář `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' 'build'
úspěšně dokončeno (0.413s)
Odesláno 1024 bajtů na 10.1.1.2
Přijato 1024 bajtů z 10.1.1.1
Přijato 1024 bajtů z 10.1.1.2

Ukazuje se, že „odeslané“ a „přijaté“ zprávy, které vidíte výše, jsou ve skutečnosti registrovanými zprávami od UdpEchoClientApplication a UdpEchoServerApplication. Například můžeme požádat klientskou aplikaci, aby vytiskla další informace, nastavením její úrovně hlášení prostřednictvím proměnné prostředí NS_LOG.

Od této chvíle předpokládám, že používáte shell podobný sh, který používá syntaxi „VARIABLE = value“. Pokud používáte shell podobný csh, budete muset přizpůsobit mé příklady k syntaxi „proměnná hodnota setenv“, kterou tyto shelly vyžadují.

V tuto chvíli klientská aplikace UDP echo reaguje na následující řádek kódu v scratch/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Tím aktivujeme úroveň hlášení LOG_LEVEL_INFO. Když předáváme příznak úrovně hlášení, ve skutečnosti tím zapnou tuto úroveň i všechny úrovně nižší. V tomto případě jsme zapnuli NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN a NS_LOG_ERROR. Můžeme zvýšit úroveň hlášení a získat více informací, bez změn ve skriptu a překladu, nastavením proměnné prostředí NS_LOG následujícím způsobem:

$ export NS_LOG=UdpEchoClientApplication=level_all

Takto nastavujeme následující hodnotu proměnné NS_LOG sh-shellu,

UdpEchoClientApplication=level_all

Levá část přiřazení je název hlášené komponenty, kterou chceme nakonfigurovat, a pravá část je příznak, který chceme pro tuto aplikovat. V tomto případě chceme zahrnout do aplikace všechny úrovně ladění. Pokud skript spustíte se takto nastaveným NS_LOG, systém hlášení ns-3 přijme změny a měli byste vidět následující výstup:

Waf: Vstup do adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Opustit adresář `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' úspěšně dokončeno (0.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Odesláno 1024 bajtů na 10.1.1.2
Přijato 1024 bajtů z 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Přijato 1024 bajtů z 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Dodatečné ladicí informace poskytované aplikací nyní odpovídají úrovni NS_LOG_FUNCTION. Ukazuje každý případ volání funkcí během běhu skriptu. Obecně platí, že v metodách funkcí je vhodné používat (alespoň)NS_LOG_FUNCTION (this). Používejte NS_LOG_FUNCTION_NOARGS ()
pouze ve statických funkcích. Nicméně mějte na paměti, že v systému ns‑3 neexistuje požadavek na podporu jakékoliv funkčnosti logování. Rozhodnutí o tom, kolik informací se registruje, zůstává na jednotlivci, který model vyvíjí. V případě echo aplikací je k dispozici velké množství výstupních informací pro logování.

Nyní můžete zkontrolovat protokol funkcí, které byly volány aplikací. Pokud se dobře podíváte, všimnete si dvojtečky mezi řádkem UdpEchoClientApplication a názvem metody, na místě, kde byste možná očekávali vidět operátor oblasti viditelnosti C++ (::). To bylo uděláno záměrně.

Ve skutečnosti to není název třídy, ale název logovací komponenty. Když existuje shoda mezi zdrojovým souborem a třídou, obvykle to bývá název třídy, ale měli byste rozumět tomu, že to ve skutečnosti není název třídy a tam je jedna dvojtečka místo dvojité dvojtečky. Je to způsob, jak vám pomoci relativně jemným způsobem koncepčně oddělit jméno logovací komponenty od názvu třídy.

Nicméně v některých případech může být obtížné určit, která metoda ve skutečnosti generuje protokolovou zprávu. Když se podíváte na výše uvedený text, můžete se ptát, odkud se vzala řetězec „Received 1024 bytes from 10.1.1.2“. Tento problém můžete vyřešit nastavením úrovně prefix_func do proměnné prostředí NS_LOG. Zkuste udělat následující,

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Mějte na paměti, že uvozovky jsou nezbytné, protože svislá čára, kterou používáme k označení operace NEBO, je také spojovníkem unixových kanálů. Nyní, pokud spustíte skript, uvidíte, že systém logování zaručuje, že každá zpráva z daného protokolu má prefix s názvem komponenty.

Waf: Vstup do adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Opouštění adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' úspěšně dokončeno (0.417s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Odesláno 1024 bajtů na 10.1.1.2
Přijato 1024 bajtů z 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
UdpEchoClientApplication:HandleRead(): Přijato 1024 bajtů z 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Nyní můžete vidět, že všechna zpráva přicházející od aplikace UDP echo klienta jsou identifikována jako takové. Zpráva „Received 1024 bytes from 10.1.1.2“ je nyní jasně určena jako přicházející od aplikace echo klienta. Zbylá zpráva by měla přicházet z aplikace UDP echo serveru. Tento komponent můžeme aktivovat zadáním seznamu komponent oddělených dvojtečkami do proměnné prostředí NS_LOG.

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

Upozornění: V uvedeném výše příkladu textu budete muset odstranit znak nového řádku po dvojtečce (:), byl použit pro formátování dokumentu. Nyní, pokud spustíte skript, uvidíte všechny zprávy protokolu z klientských a serverových echo aplikací. Můžete si všimnout, že to může být velmi užitečné při ladění.

Waf: Vstup do adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Opouštění adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' úspěšně dokončeno (0.406s)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoServerApplication:StartApplication()
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Odesláno 1024 bajtů na 10.1.1.2
UdpEchoServerApplication:HandleRead(): Přijato 1024 bajtů z 10.1.1.1
UdpEchoServerApplication:HandleRead(): Odpovídání na paket
UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
UdpEchoClientApplication:HandleRead(): Přijato 1024 bajtů z 10.1.1.2
UdpEchoServerApplication:StopApplication()
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Také je někdy užitečné mít možnost vidět čas simulace, ve kterém byla zpráva protokolu vytvořena. Můžete to udělat přidáním bitu ILI prefix_time:

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

Opět budete muset odstranit výše uvedený znak nového řádku. Pokud nyní spustíte skript, měli byste vidět následující výstup:

Waf: Vstup do adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Opouštění adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
`build` úspěšně dokončeno (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(): Odesláno 1024 bajtů na 10.1.1.2
2.00369s UdpEchoServerApplication: HandleRead(): Přijato 1024 bajtů z 10.1.1.1
2.00369s UdpEchoServerApplication: HandleRead(): Echoing packet
2.00737s UdpEchoClientApplication: HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication: HandleRead(): Přijato 1024 bajtů z 10.1.1.2
10s UdpEchoServerApplication: StopApplication()
10s UdpEchoClientApplication: StopApplication()
UdpEchoClientApplication: DoDispose()
UdpEchoServerApplication: DoDispose()
UdpEchoClientApplication: ~UdpEchoClient()
UdpEchoServerApplication: ~UdpEchoServer()

Všimněte si, že konstruktor pro UdpEchoServer byl volán během simulace 0 sekund. To se ve skutečnosti děje před zahájením simulace, ale tento čas se zobrazuje jako nula sekund. Totéž platí pro zprávu konstruktora UdpEchoClient.

Waf: Vstup do adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Opouštění adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
`build` úspěšně dokončeno (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(): Odesláno 1024 bajtů na 10.1.1.2
2.00369s UdpEchoServerApplication: HandleRead(): Přijato 1024 bajtů z 10.1.1.1
2.00369s UdpEchoServerApplication: HandleRead(): Echoing packet
2.00737s UdpEchoClientApplication: HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication: HandleRead(): Přijato 1024 bajtů z 10.1.1.2
10s UdpEchoServerApplication: StopApplication()
10s UdpEchoClientApplication: StopApplication()
UdpEchoClientApplication: DoDispose()
UdpEchoServerApplication: DoDispose()
UdpEchoClientApplication: ~UdpEchoClient()
UdpEchoServerApplication: ~UdpEchoServer()

Připomeňme, že skript scratch/first.cc spustil aplikaci echo server jednu sekundu před zahájením simulace. Nyní můžete vidět, že metoda StartApplication serveru je ve skutečnosti volána na první sekundě. Můžete si také všimnout, že echo klient je spuštěn ve druhé sekundě simulace, jak jsme v skriptu požadovali.

Nyní můžete sledovat průběh simulace podle volání ScheduleTransmit v klientovi, který vyvolává metodu Send pro zpětné volání HandleRead v aplikaci echo serveru. Všimněte si, že doba trvání pro odeslání paketu přes bodový spoj činí 3,69 milisekund. Vidíte, že echo server zaznamenává zprávu o tom, že odpověděl na paket, a poté, po zpoždění kanálu, vidíte, že echo klient dostává echo paket ve své metodě HandleRead.

Během této simulace se mnohé události odehrávají pro vás nenápadně. Ale můžete velmi snadno sledovat celý proces tím, že v systému zapnete všechny komponenty protokolování. Zkuste nastavit proměnné NS_LOG následující hodnotou,

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

Hvězdička výše je zástupným symbolem pro komponentu protokolování. To zapne všechny zápisy ve všech komponentách používaných v simulaci. Nezobrazím zde výstup (v době psaní tohoto článku produkuje 1265 řádků výstupu pro jeden echo paket), ale můžete tyto informace přesměrovat do souboru a prohlédnout je v oblíbeném editoru.

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

Osobně používám tuto extrémně podrobnou verzi protokolování, když narazím na problém a nemám představu, kde se stala chyba. Mám poměrně snadnou možnost sledovat provádění kódu, aniž bych musel nastavovat zarážky a krokovat kód v ladicím nástroji. Mohu jednoduše upravit výstup v oblíbeném editoru a vyhledávat to, co očekávám, a vidět, co se děje, když se něco neočekávaného objeví. Jakmile mám obecným přehled o tom, co se pokazilo, přepínám do ladicího nástroje pro podrobnější prozkoumání problému. Tento typ výstupu může být obzvláště užitečný, když váš skript dělá něco zcela neočekávaného. Když používáte pouze ladicí nástroj, můžete zcela přehlédnout překvapivý zvrat. Protokolování tyto zvraty činí viditelnými.

5.1.3 Přidání protokolování do vašeho kódu

Můžete přidat nové záznamy do vašich simulací voláním komponenty log z několika makro příkazů. Pojďme to udělat ve skriptu myfirst.cc, který máme v "čistém" adresáři. Připomeňme, že jsme v tomto skriptu definovali komponentu protokolování:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Je vám známo, že můžete zapnout protokolování všech zpráv této komponenty nastavením proměnné prostředí NS_LOG na různých úrovních. Pojďme pokračovat a přidat některé záznamy do skriptu. Makro používané k přidání zpráv informační úrovně do protokolu je NS_LOG_INFO. Přidejme zprávu (přímo před tím, než začneme vytvářet uzly), která vám říká, že skript je ve fázi vytváření topologie ("Creating Topology"). To se dělá v následujícím fragmentu kódu,
Otevřete scratch/myfirst.cc ve vašem oblíbeném editoru a přidejte řádek,
NS_LOG_INFO ("Creating Topology");
přímo před řádky,

NodeContainer nodes;
nodes.Create (2);

Nyní zkompilujte skript pomocí waf, a vymažte proměnnou NS_LOG, abyste vypnuli protokolovací tok, který jsme zapnuli dříve:

$ ./waf
$ export NS_LOG=
Nyní, když spustíte skript,
$ ./waf --run scratch/myfirst

neuvidíte novou zprávu, protože související komponenta protokolování (FirstScriptExample) nebyla zapnuta. Abyste viděli vaši zprávu, musíte aktivovat komponentu protokolování FirstScriptExample s úrovní alespoň NS_LOG_INFO. Pokud chcete pouze vidět tuto konkrétní úroveň protokolování, můžete ji zapnout takto,

$ export NS_LOG=FirstScriptExample=info

Pokud nyní spustíte skript, uvidíte novou zprávu „Vytváření topologie“.

Waf: Vstup do adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Opouštění adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' úspěšně dokončeno (0.404s)
Vytváření topologie
Odesláno 1024 bajtů na 10.1.1.2
Přijato 1024 bajtů z 10.1.1.1
Přijato 1024 bajtů z 10.1.1.2

5.2 Použití argumentů příkazového řádku

5.2.1 Přepis hodnot výchozích atributů

Další způsob, jak změnit chování skriptů ns-3 bez úprav a sestavení, je použití argumentů příkazového řádku. Poskytujeme mechanismus pro analýzu argumentů příkazového řádku a automatické nastavení lokálních a globálních proměnných na základě výsledků.

Prvním krokem k použití systému argumentů příkazového řádku je deklarace analyzátoru příkazového řádku. Je to docela jednoduché (ve vaší hlavní aplikaci), jak je ukázáno v následujícím kódu,

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

Tento jednoduchý dvoutřídový fragment je skutečně velmi užitečný sám o sobě. Otevírá dveře k globální proměnné ns-3 a systému atributů. Přidejme dvě řádky kódu na začátek hlavní funkce skriptu. scratch/myfirst.cc. Pokračujeme, kompilujeme skript a spouštíme ho, při spuštění dáváme žádost o nápovědu následujícím způsobem,

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

Tento příkaz požádá Waf o spuštění skriptu scratch/myfirst a předání mu argumentu příkazového řádku —PrintHelp. Uvozovky jsou nezbytné k tomu, aby bylo jasné, pro jaký program je argument určen. Analyzátor příkazového řádku zjistí argument —PrintHelp a zobrazí odpověď,

Waf: Vstup do adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Opouštění adresáře `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' úspěšně dokončeno (0.413s)
TcpL4Protocol:TcpStateMachine()
CommandLine:HandleArgument(): Zpracovat arg jméno=PrintHelp hodnota=
--PrintHelp: Vytisknout tuto nápovědní zprávu.
--PrintGroups: Vytisknout seznam skupin.
--PrintTypeIds: Vytisknout všechny TypeIds.
--PrintGroup=[group]: Vytisknout všechny TypeIds skupiny.
--PrintAttributes=[typeid]: Vytisknout všechny atributy typeid.
--PrintGlobals: Vytisknout seznam globálních proměnných.

Nyní zvážíme možnost —PrintAttributes. Již jsme zmínili systém atributů ns-3 při zkoumání skriptu first.cc. Viděli jsme následující řádky kódu,

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

a mluvili jsme o tom, že DataRate je ve skutečnosti atributem PointToPointNetDevicePojďme použít analyzátor argumentů příkazového řádku k prozkoumání atributů. PointToPointNetDeviceNápovědní seznam říká, že musíme poskytnout TypeIdToto je název třídy, které patří zajímavé atributy. V našem případě to bude ns3::PointToPointNetDevice. Pokračujme dál, zadejte,

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

Systém vytiskne všechny atributy tohoto typu síťového zařízení. Uvidíte, že mezi atributy v seznamu jsou,

--ns3::PointToPointNetDevice::DataRate=[32768bps]:
Výchozí datová rychlost pro spoje bod-bod

Toto je výchozí hodnota, která bude použita v systému při vytváření objektu PointToPointNetDevice. Tuto výchozí hodnotu přepíšeme pomocí parametru Atribut v PointToPointHelper výše. Použijme výchozí hodnoty pro bod-bod zařízení a kanály. K tomu odstraníme volání SetDeviceAttribute a SetChannelAttribute z myfirst.cc, které máme v čistém adresáři.

Váš skript by nyní měl pouze deklarovat PointToPointHelper a nevykonávat žádné nastavení, jak je ukázáno v příkladu níže,

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

Pokračujte a vytvořte nový skript s Waf (. /waf) a pojďme se vrátit a zapnout nějaké logování z UDP echo aplikace serveru a zapnout časovou značku.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Pokud spustíte skript, měli byste vidět následující výstup:

Waf: Vstup do adresáře ` /home/craigdo/repos/ns-3-allinone/ns-3-dev/build '
Waf: Opouští adresář ` /home/craigdo/repos/ns-3-allinone/ns-3-dev/build '
'build' úspěšně dokončeno (0.405s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Odesláno 1024 bajtů na 10.1.1.2
2.25732s Přijato 1024 bajtů od 10.1.1.1
2.25732s Odezva paketu
Přijato 1024 bajtů od 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Připomeňme, že minule, když jsme se dívali na čas simulace, okamžik, kdy echo server přijal paket, to bylo v 2.00369 sekund.

2.00369s UdpEchoServerApplication:HandleRead(): Přijato 1024 bajtů od 10.1.1.1

Nyní přijímá paket v 2.25732 sekundách. Je to proto, že jsme právě snížili datovou rychlost PointToPointNetDevice z pěti megabitů za sekundu na výchozí hodnotu, která je 32768 bitů za sekundu. Kdybychom zadali novou DataRate pomocí příkazového řádku, mohli bychom naše modelování znovu zrychlit. Uděláme to následujícím způsobem, podle vzorce implicitně uvedeného v nápovědě:

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

Výsledkem bude, že výchozí hodnota atributu DataRate se vrátí na pět megabitů za sekundu. Jste překvapeni výsledkem? Ukazuje se, že k obnovení původního chování skriptu musíme také nastavit zpoždění kanálu na odpovídající rychlost světla. Můžeme požádat systém příkazového řádku, aby vypsal atributy kanálu, stejně jako jsme to dělali pro síťové zařízení:

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

Zjistíme, že atribut zpoždění kanálu je nastaven následujícím způsobem:

--ns3::PointToPointChannel::Delay=[0ns]:
Přenosové zpoždění přes kanál

Poté můžeme prostřednictvím systému příkazového řádku nastavit obě tyto výchozí hodnoty,

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

v tomto případě obnovujeme čas, který jsme měli, když jsme výslovně nastavili DataRate a Delay ve skriptu:

Waf: Vstup do adresáře `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build' 
Waf: Opouští adresář `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build' 
'build' úspěšně dokončeno (0.417s) 
0s UdpEchoServerApplication:UdpEchoServer() 
1s UdpEchoServerApplication:StartApplication() 
Odesláno 1024 bajtů na 10.1.1.2 
2.00369s Přijato 1024 bajtů od 10.1.1.1 
2.00369s Echoing packet 
Přijato 1024 bajtů od 10.1.1.2 
10s UdpEchoServerApplication:StopApplication() 
UdpEchoServerApplication:DoDispose() 
UdpEchoServerApplication:~UdpEchoServer()

Všimněte si, že paket byl znovu přijat serverem po 2,00369 sekundách. Ve skutečnosti bychom mohli nastavit jakýkoli z atributů používaných ve skriptu tímto způsobem. Zejména bychom mohli nastavit hodnoty atributu MaxPackets odlišné od jedné UdpEchoClient.

Jak byste to použili? Zkuste to. Nezapomeňte, že musíte zakomentovat místo, kde přepisujeme výchozí hodnotu atributu a výslovně nastavit MaxPackets ve skriptu. Poté byste měli skript znovu sestavit. Také můžete prostřednictvím příkazového řádku získat pomoc o syntaxi pro nastavení nové výchozí hodnoty atributu. Pokud se v tom vyznáte, budete moci řídit počet paketů zobrazených v příkazovém řádku. Protože jsme pilní lidé, měl by náš příkazový řádek vypadat přibližně takto:

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

Přirozená otázka, která v tomto místě vyvstává, je, jak se dozvědět o existenci všech těchto atributů. Opět má systém příkazového řádku funkci nápovědy na toto téma. Pokud požádáme o pomoc příkazového řádku, měli bychom vidět:

$ ./waf --run "scratch/myfirst --PrintHelp"
myfirst [Program Arguments] [General Arguments]
General Arguments:
--PrintGlobals: Vytisknout seznam globálních proměnných.
--PrintGroups: Vytisknout seznam skupin.
--PrintGroup=[group]: Vytisknout všechny TypeIds skupiny.
--PrintTypeIds: Vytisknout všechny TypeIds.
--PrintAttributes=[typeid]: Vytisknout všechny atributy typeid.
--PrintHelp: Vytisknout tuto nápovědu.

Pokud zvolíte argument „PrintGroups“, měli byste vidět seznam všech registrovaných skupin. TypeId. Jména skupin se shodují se jmény modulů v původním adresáři (i když s velkým písmenem). Vytisknutí všech informací najednou by bylo příliš rozsáhlé, proto je k dispozici další filtr pro tisk informací podle skupin. Zaměřme se znovu na modul „point-to-point“:

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

Zde můžete najít dostupné názvy TypeId pro vyhledání atributů, například v
--PrintAttributes = ns3 :: PointToPointChannel, jak je uvedeno výše.

Další způsob, jak se dozvědět o atributech, je prostřednictvím Doxygen ns‑3. Existuje stránka, která uvádí všechny registrované atributy v simulátoru.

5.2.2 Zachycení vašich vlastních příkazů

Můžete také prostřednictvím systému příkazového řádku přidat své vlastní hooky. To se provádí poměrně jednoduše pomocí metody parseru příkazového řádku. AddValue.
Použijme tuto možnost k určení počtu paketů, které mají být zobrazeny, zcela jiným způsobem. Přidejme lokální proměnnou nazvanou nPackets do funkce main. Nastavíme ji na jednu, abychom odpovídali našemu předchozímu chování ve výchozím nastavení. Aby mohl parser příkazového řádku tuto hodnotu změnit, musíme ji zachytit v parseru. Děláme to přidáním volání AddValue. Přejděte a upravte skript scratch/myfirst.cc tak, aby začínal následujícím kódem,

int
main (int argc, char *argv[])
{
uint32_t nPackets = 1;
CommandLine cmd;
cmd.AddValue("nPackets", "Počet paketů k echo", nPackets);
cmd.Parse (argc, argv);
...

Posuňte se dolů do bodu ve skriptu, kde nastavujeme atribut MaxPackets a změňte ho tak, aby byl nastaven na proměnnou nPackets místo konstanty 1, jak je uvedeno níže.

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

Nyní, pokud spustíte skript a zadáte argument --PrintHelp, měli byste vidět nový uživatelský argument uvedený na obrazovce nápovědy. Zadejte,

$ .\/waf --run "scratch\/myfirst --PrintHelp"
Waf: Vstup do adresáře `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Opouštění adresáře `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' bylo úspěšně dokončeno (0.403s)
--PrintHelp: Vypište tuto nápovědu.
--PrintGroups: Vypište seznam skupin.
--PrintTypeIds: Vypište všechna TypeIds.
--PrintGroup=[group]: Vypište všechna TypeIds ve skupině.
--PrintAttributes=[typeid]: Vypište všechny atributy typeid.
--PrintGlobals: Vypište seznam globálních hodnot.
Uživatelské argumenty:
--nPackets: Počet paketů k odeslání

Pokud chcete změnit počet přenášených paketů, můžete to udělat tak, že nastavíte argument -nPackets v příkazovém řádku.

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

Nyní byste měli vidět

Waf: Vstup do adresáře `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Opouštění adresáře `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' bylo úspěšně dokončeno (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Odesláno 1024 bajtů na 10.1.1.2
2.25732s Přijato 1024 bajtů z 10.1.1.1
2.25732s Echoing packet
Přijato 1024 bajtů z 10.1.1.2
Odesláno 1024 bajtů na 10.1.1.2
3.25732s Přijato 1024 bajtů z 10.1.1.1
3.25732s Echoing packet
Přijato 1024 bajtů z 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Nyní jste odeslali dva pakety. Docela jednoduché, že?
Můžete vidět, že jako uživatel ns‑3 můžete používat systém argumentů příkazového řádku k řízení globálních hodnot a atributů. Pokud jste autorem modelu, můžete přidat nové atributy k vašim objektům, které budou automaticky dostupné pro nastavení vašimi uživateli prostřednictvím systému příkazového řádku. Pokud jste autorem skriptu, můžete do vašich skriptů přidávat nové proměnné a bezproblémově je připojit k systému příkazového řádku.

5.3 Použití systému sledování

Celý smysl modelování spočívá v generování výstupů pro další studium a systém sledování ns‑3 je hlavním mechanismem pro to. Vzhledem k tomu, že ns‑3 je program napsaný v C++, mohou být použity standardní prostředky generování výstupů pro programy v C++:

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

Dokonce můžete použít modul protokolování k přidání malé struktury do vašeho řešení. Je známo, že tento přístup způsobuje mnoho problémů a proto jsme poskytli obecnou podsystém sledování událostí pro řešení těchto problémů.

Hlavní cíle systému sledování ns‑3:

• Pro základní úkoly by měl systém sledování umožňovat uživateli generovat standardní sledování pro populární zdroje a vybírat objekty, které generují sledování.

• Mezile uživatelé by měli mít schopnost rozšiřovat systém sledování pro změnu generovaného výstupního formátu nebo pro přidání nových zdrojů sledování, aniž by bylo nutné měnit jádro simulátoru;

• Zkušení uživatelé mohou upravit jádro simulátoru pro přidání nových zdrojů a přijímačů sledování. Systém sledování ns-3 je založen na principech nezávislých sledovacích zdrojů a přijímačů, stejně jako na jednotném mechanismu připojení zdrojů k spotřebitelům.

Systém sledování ns-3 je založen na principech nezávislých zdrojů a přijímačů sledování, stejně jako na jednotném mechanismu připojení zdrojů k přijímačům. Sledovacími zdroji jsou objekty, které mohou signalizovat události probíhající v simulaci a zajistit přístup k zajímavým základním datům. Například sledovací zdroj může naznačit, kdy síťové zařízení obdrželo paket, a poskytuje přístup k obsahu paketu pro zúčastněné přijímače sledování.

Sledovací zdroje samy o sobě jsou k ničemu, pokud nejsou „propojeny“ s jinými částmi kódu, které skutečně dělají něco užitečného s informacemi poskytnutými přijímačem. Sledovače jsou spotřebiteli událostí a dat, které poskytují sledovací zdroje. Například lze vytvořit sledovací přijímač, který bude (při připojení k předchozímu sledovacímu zdroji) tisknout zajímavé části obdrženého paketu.

Rozumným důvodem pro toto jasné oddělení je umožnit uživatelům připojovat nové typy přijímačů k existujícím sledovacím zdrojům bez nutnosti editace a rekombinace jádra simulátoru. Takže v uvedeném příkladu může uživatel definovat nový sledovač ve svém skriptu a připojit ho k existujícímu sledovacímu zdroji definovanému v jádře simulace, pouze úpravou uživatelského skriptu.

V této příručce se podíváme na některé předdefinované zdroje a přijímače a ukážeme, jak je lze nastavit s minimálním úsilím uživatele. Viz Příručka ns‑3 nebo části s pokyny pro informace o pokročilé konfiguraci trasování, včetně rozšíření jmenného prostoru trasování a vytváření nových zdrojů trasování.

5.3.1 ASCII Sledování

ns‑3 poskytuje pomocnou funkcionalitu, která nabízí nízkoúrovňový systém trasování, aby vám pomohla s detaily při nastavování jednoduchých trasování paketů. Pokud tuto funkci zapnete, uvidíte výstupy v ASCII souborech. Pro ty, kteří jsou obeznámeni s výstupem ns-2, je tento typ trasování podobný out.tr, který je generován mnoha skripty.

Pojďme se dostat k věci a přidat nějaké výsledky ASCII trasování do našeho skriptu scratch/myfirst.cc. Přímo před voláním Simulator :: Run (), přidejte následující řádky kódu:
AsciiTraceHelper ascii;

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

Stejně jako v mnoha dalších idiomech ns‑3, tento kód používá pomocný objekt k vytváření ASCII trasování. Druhý řádek obsahuje dva vnořené volání metody. Metoda „uvnitř“ CreateFileStream () používá idiom anonymního objektu k vytvoření objektu streamu souboru na zásobníku (bez jména objektu) a předává ho volané metodě. V budoucnu se této problematice budeme věnovat podrobněji, ale vše, co potřebujete znát v této fázi, je, že vytváříte objekt reprezentující soubor s názvem myfirst.tr a předáváte ho ns‑3. Odpovědnost za vytvořený objekt přenášíme na ns‑3 po celou dobu jeho životnosti, během níž se vyřeší otázky vyplývající z málo známého (úmyslného) omezení spojeného s kopírovacími konstruktory streamových objektů C++.

Externí volání EnableAsciiAll() sděluje pomocníkovi, že chcete zahrnout v rámci vaší simulace ASCII trasování pro všechny spojení zařízení point-to-point a že chcete, aby (určení) přijímače trasování zapisovaly informace o pohybu paketů v ASCII formátu.

Pro ty, kteří jsou obeznámeni s ns-2, sledované události odpovídají známým trasovacím bodům, které zapisují události „+“, „-“, „d“ a „r“.
Nyní můžete skript zkompilovat a spustit ho z příkazového řádku:

$ ./waf --run scratch/myfirst

Kolikrát jste již viděli několik zpráv od Waf a poté "'build' finished successfully" (kompilace byla úspěšně dokončena) s několika zprávami od běžícího programu.

Během práce program vytvoří soubor s názvem myfirst.tr. Kvůli povaze práce se soubor ve výchozím nastavení nevytváří v místním adresáři, ale v nejvyšším adresáři repozitáře. Pokud chcete změnit cestu, kde se ukládají stopy, můžete pro Waf použít parametr Waf--cwd . To jsme neudělali, takže abychom se podívali na soubor ASCII trasování myfirst.tr ve vašem oblíbeném editoru, budeme muset přejít do nejvyššího adresáře našeho repozitáře.Je tam spousta informací v poměrně husté formě, ale první věc, na kterou je třeba se zaměřit, je, že soubor se skládá z jednotlivých řádků. Bude to zřetelně viditelné, pokud okno prohlížení rozšíříte.

Parsování ASCII sledů

Každý řádek v souboru odpovídá události trasování. V tomto případě trasujeme události v přenosové frontě, která je přítomná v každém síťovém zařízení point-to-point v simulaci. Přenosová fronta je fronta, kterou musí každé paket projít pro kanál point-to-point. Všimněte si, že každý řádek v souboru trasování začíná jedním znakem (a má za ním mezeru). Tento znak bude mít následující význam:

+: došlo k operaci vkládání do fronty zařízení;

-: došlo k operaci vyjmutí prvku z fronty zařízení;
d: paket byl zahozen, obvykle protože byla fronta přeplněna;
r: paket byl přijat síťovým zařízením.
Podívejme se podrobněji na první řádek v souboru trasování. Rozložím ho na části (s odsazením pro přehlednost) a číslem řádku nalevo:

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)

První část této rozšířené události trasování (řádek 0) je operace. Máme zde znak +, což odpovídá operaci vkládání do fronty pro přenos. Druhá část (řádek 1) je čas simulace vyjádřený v sekundách. Můžete si vzpomenout, že jsme požádali

První část této rozšířené události sledování (řádek 0) je operace. Zde máme symbol +, což odpovídá operaci zařazení do fronty pro přenos. Druhá část (řádek 1) je doba modelování vyjádřená v sekundách. Můžete si vzpomenout, že jsme požádali UdpEchoClientApplication zahájit odesílání paketů za dvě sekundy. Zde vidíme potvrzení, že se to skutečně děje.

V následující části příkladu sledování (od řádku 2) se ukazuje, který zdroj sledování vyvolal tuto událost (je uvedeno sledování prostor názvů). Můžete si představit prostor názvů sledování podobně jako prostor názvů souborového systému. Kořenem prostoru názvů je NodeList. To odpovídá kontejneru, který je spravován v hlavním kódu ns-3. Obsahuje všechny uzly, které jsou vytvořeny ve skriptu. Stejně jako souborový systém může mít v kořeni adresáře, v NodeList můžeme mít mnoho uzlů. Takže řádek /NodeList/0 se odkazuje na nultý uzel v NodeList, který obvykle chápeme jako „uzel 0“. V každém uzlu je seznam zařízení, která byla nainstalována. Tento seznam se nachází hned v dalším prostoru názvů. Můžete vidět, že tato událost sledování pochází z DeviceList/0, což je nulté zařízení nainstalované v uzlu.

Další podřetězec, $ ns3::PointToPointNetDevice, uvádí, které zařízení je na nulté pozici: seznam zařízení nultého uzlu. Připomínáme, že operace +, která se nacházela v řádku 0, znamenala, že do fronty přenosu zařízení byl přidán prvek. To se odráží v posledních segmentech „cesty sledování“: TxQueue/Enqueue.

Ostatní části sledování by měly být dostatečně intuitivní. Řádky 3-4 ukazují, že paket je zapouzdřen v protokolu bod-bod. Řádky 5-7 ukazují, že paket má hlavičku verze IP4 a vznikl na IP adrese 10.1.1.1 a je určen pro 10.1.1.2. Řádky 8-9 ukazují, že tento paket má hlavičku UDP a nakonec řádek 10 ukazuje, že užitečná zátěž má očekávaných 1024 bytů.

Další řádek v souboru sledování ukazuje, že stejný paket byl vytažen z fronty přenosu na tom samém uzlu.

Třetí řádek v souboru sledování ukazuje, že paket byl přijat síťovým zařízením na uzlu s echo serverem. Toto jsem reprodukoval níže.

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

Vezměte na vědomí, že operace trasování je nyní r a doba simulace byla zvýšena na 2,25732 sekundy. Pokud jste pečlivě sledovali pokyny v tutoriálu, znamená to, že jste hodnoty DataRate síťových zařízení a zpoždění kanálu nechali na jejich výchozích hodnotách. Tato doba by vám měla být známá, jak jste ji již viděli v předchozí části.

Záznam prostoru názvů zdrojového trasování (řádek 2) byl změněn, aby odrážel, že tato událost pochází z uzlu 1 (/NodeList/1) и пакет принят источником трассировки (/MacRx). Mělo by být docela snadné sledovat pohyb paketu přes topologii, když procházíte zbytkem souboru tras.

5.3.2 Sledování PCAP

Zařízení ns‑3 lze také použít k vytváření trasovacích souborů ve formátu .pcap. Zkratka pcap obvykle psaná malými písmeny se označuje jako záchyt paketů a fakticky jde o API, které zahrnuje definici formátu souboru .pcap. Nejpopulárnějším programem, který může tento formát číst a zobrazovat, je Wireshark (dříve nazývaná Ethereal). Existuje však mnoho analyzátorů trasování, které tento formát paketů používají. Doporučujeme uživatelům používat různé nástroje dostupné pro analýzu pcap tras. V této příručce se zaměříme na prohlížení pcap tras pomocí tcpdump.

Povolení pcap trasování se provádí jedním řádkem kódu.

pointToPoint.EnablePcapAll ("myfirst");

Vložte tento řádek kódu po kódu ASCII trasování, který jsme právě přidali v scratch/myfirst.cc. Mějte na paměti, že jsme předali pouze řetězec „myfirst“, nikoli „myfirst.pcap“ nebo něco podobného. To proto, že parametr je prefixem, nikoli celým názvem souboru. Během simulace asistent skutečně vytvoří trasovací soubor pro každé zařízení point-to-point. Názvy souborů budou sestaveny pomocí prefixu, čísla uzlu, čísla zařízení a přípony „.pcap».

Pro náš příklad scénáře nakonec uvidíme soubory pojmenované „myfirst-0-0.pcap“ a „myfirst-1-0.pcap“, které jsou pcap trasování pro uzel 0 - zařízení 0 a uzel 1 - zařízení 0, respektive. Jakmile přidáte řádek kódu pro povolení pcap trasování, můžete skript spustit běžným způsobem:

$ ./waf --run scratch/myfirst

Pokud se podíváte do nejvyšší úrovně vašeho distribuce, měli byste vidět tři soubory: soubor ASCII trasování myfirst.tr, který jsme předtím zkoumali, soubory myfirst-0-0.pcap a myfirst-1-0.pcap — nové pcap soubory, které jsme právě vygenerovali.

Čtení výstupu pomocí tcpdump

V současné době je nejjednodušší použít tcpdump k prohlížení pcap souborů.

$ 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

V dumpu myfirst-0-0.pcap (klientské zařízení) můžete vidět, že echo paket je odeslán po 2 sekundách simulace. Pokud se podíváte na druhý dump (myfirst-1-0.pcap), uvidíte, že paket je přijat v momentě 2,257324 sekundy. Ve druhém dumpu uvidíte, že paket je vrácen v momentě 2.257324 sekundy a nakonec, že paket byl klientem znovu přijat v prvním dumpu v momentě 2.514648 sekund.

Čtení výstupu pomocí Wireshark

Pokud nejste obeznámeni s Wireshark, existuje webová stránka, ze které si můžete stáhnout programy a dokumentaci: http://www.wireshark.org/. Wireshark — to je grafické uživatelské rozhraní, které můžete použít k zobrazení těchto souborů trasování. Pokud máte Wireshark, můžete otevřít libovolný z trasovacích souborů a zobrazit obsah, jako byste zachytili pakety pomocí analyzátoru paketů.

Zdroj: habr.com