Tutorial simulator de rețea ns-3. capitolul 5

capitolul 1,2
capitolul 3
capitolul 4

5 Setare
5.1 Utilizarea modulului de înregistrare
5.1.1 Prezentare generală a jurnalizării
5.1.2 Activați înregistrarea în jurnal
5.1.3 Adăugarea de logare la codul dvs
5.2 Utilizarea argumentelor liniei de comandă
5.2.1 Suprascrierea valorilor atributelor implicite
5.2.2 Capturarea propriilor comenzi
5.3 Utilizarea sistemului de urmărire
5.3.1 Urmărirea ASCII
Analizarea urmelor ASCII
5.3.2 Urmărire PCAP

Capitolul 5

ajustare

5.1 Utilizarea modulului de înregistrare

Ne-am uitat deja pe scurt la modulul de înregistrare ns-3, uitându-ne la script mai întâi.cc. În acest capitol, vom arunca o privire mai atentă asupra posibilelor utilizări ale subsistemului de logare.

5.1.1 Prezentare generală a jurnalizării

Multe sisteme mari acceptă un fel de facilitate de înregistrare a mesajelor, iar ns-3 nu face excepție. În unele cazuri, doar mesajele de eroare sunt scrise în „consola operatorului” (care este de obicei stderr pe sistemele bazate pe Unix). Pe alte sisteme, pot fi afișate mesaje de avertizare, precum și informații mai detaliate. În unele cazuri, instrumentele de înregistrare sunt folosite pentru a afișa mesaje de depanare care pot estompa rapid rezultatul.

SubHRD utilizat în ns-3 presupune că toate aceste niveluri de conținut de informații sunt utile și oferim o abordare selectivă, stratificată, a înregistrării mesajelor. Înregistrarea poate fi dezactivată complet, activată pe o componentă sau la nivel global. În acest scop, sunt utilizate niveluri reglabile de conținut informațional. Modulul de înregistrare ns-3 oferă o modalitate relativ simplă de a obține informații utile din simulare.

Ar trebui să înțelegeți că oferim un mecanism de uz general - urmărire - pentru extragerea datelor din modelele dvs., care ar trebui să fie rezultatul preferat pentru simulări (pentru mai multe informații despre sistemul nostru de urmărire, consultați secțiunea tutorial 5.3). Înregistrarea ar trebui să fie metoda preferată pentru a obține informații de depanare, avertismente, mesaje de eroare sau pentru a trimite rapid mesaje din scripturile sau modelele dvs. în orice moment.

În prezent, sistemul definește șapte niveluri (tipuri) de mesaje de jurnal în ordinea crescândă a conținutului de informații.

• LOG_ERROR - mesaje de eroare de înregistrare (macrocomandă asociată: NS_LOG_ERROR);
• LOG_WARN - Jurnalul mesajelor de avertizare (macrocomandă asociată: NS_LOG_WARN);
• LOG_DEBUG - Înregistrează mesaje speciale de depanare relativ rare (macrocomandă asociată: NS_LOG_DEBUG);
• LOG_INFO - înregistrarea mesajelor informative despre progresul programului (macro aferentă: NS_LOG_INFO);
• LOG_FUNCTION - Înregistrează mesajele care descriu fiecare funcție apelată (două macrocomenzi înrudite: NS_LOG_FUNCTION, utilizată pentru funcțiile membre și NS_LOG_FUNCTION_NOARGS, utilizată pentru funcții statice);
• LOG_LOGIC - mesaje de logare care descriu fluxul logic în cadrul unei funcții (macrocomandă aferentă: NS_LOG_LOGIC);
• LOG_ALL - Înregistrează tot ce s-a menționat mai sus (fără macrocomandă asociată).
  Pentru fiecare tip (LOG_TYPE) există și un LOG_LEVEL_TYPE care, dacă este utilizat, permite ca toate nivelurile de deasupra acestuia să fie înregistrate în plus față de propriul nivel. (În consecință, LOG_ERROR și LOG_LEVEL_ERROR și LOG_ALL și LOG_LEVEL_ALL sunt echivalente din punct de vedere funcțional.) De exemplu, activarea LOG_INFO va permite numai mesajele furnizate de macrocomanda NS_LOG_INFO, în timp ce activarea LOG_LEVEL_INFO va include, de asemenea, mesajele furnizate de macrocomenzile NS_LOGNS.

De asemenea, oferim o macrocomandă de înregistrare necondiționată care este întotdeauna afișată, indiferent de nivelul de înregistrare sau de componenta de selecție.

• NS_LOG_UNCOND - Înregistrare necondiționată a mesajului asociat (fără nivel de înregistrare asociat).

Fiecare nivel poate fi interogat individual sau cumulativ. Înregistrarea poate fi configurată folosind variabila de mediu sh NS_LOG sau prin înregistrarea unui apel de funcție de sistem. După cum sa arătat mai devreme, sistemul de înregistrare are documentație Doxygen și acum este un moment bun să o revizuiți dacă nu ați făcut-o deja.

Acum că ați citit documentația în detaliu, să folosim aceste cunoștințe pentru a obține informații interesante din exemplul de script zgârietură/myfirst.ccpe care le-ați compilat deja.

5.1.2 Activați înregistrarea în jurnal

Să folosim variabila de mediu NS_LOG pentru a rula mai multe jurnale, dar mai întâi, doar pentru a vă orienta, rulați ultimul script așa cum ați făcut mai devreme,

$ ./waf --run scratch/myfirst

Ar trebui să vedeți rezultatul familiar din primul exemplu de program 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

Se pare că mesajele „trimise” și „primite” pe care le vedeți mai sus sunt de fapt mesaje înregistrate de la UdpEchoClientApplication и UdpEchoServerApplication. De exemplu, putem cere aplicației client să imprime informații suplimentare prin setarea nivelului său de înregistrare prin variabila de mediu NS_LOG.

De acum înainte, voi presupune că utilizați un shell asemănător sh care folosește sintaxa „VARIABLE=valoare”. Dacă utilizați un shell asemănător csh, atunci va trebui să convertiți exemplele mele la sintaxa „setenv variable value” cerută de acele shell-uri.

În prezent, aplicația client UDP echo răspunde la următoarea linie de cod în zgârietură/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Activează nivelul de înregistrare LOG_LEVEL_INFO. Când trecem un indicator de nivel de înregistrare, activăm de fapt acel nivel și toate nivelurile inferioare. În acest caz, am activat NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN și NS_LOG_ERROR. Putem crește nivelul de înregistrare și obține mai multe informații, fără modificări de script și recompilare, setând variabila de mediu NS_LOG după cum urmează:

$ export NS_LOG=UdpEchoClientApplication=level_all

Deci, setăm variabila SH shell NS_LOG la următoarea valoare,

UdpEchoClientApplication=level_all

Partea stângă a atribuirii este numele componentei înregistrate pe care vrem să o configuram, iar partea dreaptă este steag-ul pe care vrem să-l aplicăm. În acest caz, vom activa toate nivelurile de depanare în aplicație. Dacă rulați scriptul cu NS_LOG setat în acest fel, sistemul de înregistrare ns-3 va accepta modificările și ar trebui să vedeți următoarea ieșire:

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()

Informațiile suplimentare de depanare furnizate de aplicație sunt acum la nivelul NS_LOG_FUNCTION. Afișează fiecare instanță a unui apel de funcție în timpul execuției scriptului. Ca regulă generală, în funcțiile metodei este de preferat să se utilizeze (cel puțin)NS_LOG_FUNCTION (this)... Utilizare NS_LOG_FUNCTION_NOARGS ()
numai în funcţiile statice. Cu toate acestea, rețineți că sistemul ns-3 nu este necesar să suporte nicio funcționalitate de înregistrare. Decizia cu privire la cantitatea de informații înregistrate este lăsată în seama dezvoltatorului individual de model. În cazul aplicațiilor echo, este disponibilă o cantitate mare de ieșiri de înregistrare.

Acum puteți vizualiza un jurnal al apelurilor de funcții care au fost efectuate de aplicație. Dacă te uiți cu atenție, vei observa două puncte între rânduri UdpEchoClientApplication și numele metodei, unde s-ar putea să vă așteptați să vedeți operatorul domeniului C++ (: :). Acest lucru este intenționat.

Acesta nu este de fapt numele clasei, ci numele componentei de logare. Când există o potrivire între un fișier sursă și o clasă, de obicei este numele clasei, dar ar trebui să vă dați seama că nu este de fapt numele clasei și există un singur două puncte în loc de două două puncte. Aceasta este o modalitate de a vă ajuta să separați conceptual numele bobului de înregistrare de numele clasei într-un mod relativ subtil.

Cu toate acestea, în unele cazuri poate fi dificil să se determine care metodă generează de fapt mesajul de jurnal. Dacă te uiți la textul de mai sus, s-ar putea să te întrebi unde este linia "Received 1024 bytes from 10.1.1.2" Puteți rezolva această problemă setând nivelul prefix_func la variabila de mediu NS_LOG. Încercați următoarele:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Rețineți că ghilimelele sunt necesare deoarece bara verticală pe care o folosim pentru a reprezenta operația SAU este, de asemenea, un conector de conductă Unix. Acum, dacă rulați scriptul, veți vedea că sistemul de înregistrare se asigură că fiecare mesaj dintr-un anumit jurnal este prefixat cu numele componentei.

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()

Acum puteți vedea că toate mesajele care provin din aplicația client UDP echo sunt identificate ca atare. Mesaj "Received 1024 bytes from 10.1.1.2" este acum identificat în mod clar ca provenind din aplicația client echo. Mesajul rămas trebuie să provină de la aplicația UDP echo server. Putem activa această componentă introducând o listă de componente separate prin două puncte în variabila de mediu NS_LOG.

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

Avertisment: În exemplul de text de mai sus, va trebui să eliminați caracterul de nouă linie după două puncte (:), acesta este folosit pentru a formata documentul. Acum, dacă rulați scriptul, veți vedea toate mesajele de jurnal de la aplicațiile echo client și server. Puteți vedea că acest lucru poate fi foarte util la depanare.

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()

De asemenea, uneori este util să puteți vedea ora de simulare la care a fost generat mesajul de jurnal. Puteți face acest lucru adăugând bitul SAU prefix_time:

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

Din nou, va trebui să eliminați caracterul de mai sus. Dacă rulați acum scriptul, ar trebui să vedeți următoarea ieșire:

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()

Vă rugăm să rețineți că constructorul pentru UdpEchoServer a fost apelat în timpul simulării 0 secunde. Acest lucru se întâmplă de fapt înainte de începerea simulării, dar timpul este afișat ca zero secunde. Același lucru este valabil și pentru mesajul constructorului 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()

Amintiți-vă că scenariul zgârietură/primul.cc a pornit aplicația server echo cu o secundă înainte de începerea simulării. Acum puteți vedea că metoda StartApplication serverul este de fapt apelat în prima secundă. De asemenea, puteți observa că clientul echo începe în a doua secundă a simulării, așa cum am cerut în script.

Acum puteți urmări progresul simulării la apel ScheduleTransmit în clientul care apelează HandleRead callback Send în aplicația server echo. Rețineți că timpul scurs pentru a trimite un pachet printr-o legătură punct la punct este de 3,69 milisecunde. Puteți vedea că serverul echo înregistrează un mesaj că a răspuns la pachet și apoi, după o întârziere a canalului, vedeți că clientul echo primește pachetul echo în metoda HandleRead.

În această simulare, multe se întâmplă fără ca tu să observi. Dar puteți urmări întregul proces foarte ușor, activând toate componentele de înregistrare în sistem. Încercați să setați variabila NS_LOG la următoarea valoare,

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

Asteriscul de mai sus este un caracter wildcard pentru componenta de înregistrare. Aceasta va include toate intrările din toate componentele utilizate în simulare. Nu voi reproduce rezultatul aici (la momentul scrierii, acesta produce 1265 de linii de ieșire pentru un singur pachet de eco), dar puteți redirecționa aceste informații către un fișier și le puteți vizualiza în editorul dvs. favorit.

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

Eu personal folosesc această versiune extrem de pronunțată de logare când am o problemă și nu am idee unde au mers prost lucrurile. Pot urmări execuția codului destul de ușor, fără a seta puncte de întrerupere și a parcurge codul în depanator. Pot doar să editez rezultatul în editorul meu preferat și să caut ceea ce mă aștept și să văd că se întâmplă ceva la care nu mă așteptam. Odată ce am o idee generală despre ce nu merge bine, trec în depanator pentru a analiza problema. Acest tip de ieșire poate fi util în special atunci când scriptul face ceva complet neașteptat. Dacă utilizați doar depanatorul, este posibil să pierdeți o răsucire completă. Înregistrarea face astfel de viraje vizibile.

5.1.3 Adăugarea de logare la codul dvs

Puteți adăuga intrări noi la simulările dvs. făcând apeluri la componenta jurnal din mai multe macrocomenzi. Să o facem într-un scenariu myfirst.cc, pe care îl avem în directorul „curat”. Amintiți-vă că am definit o componentă de logare în acest scenariu:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Sunteți conștient că puteți activa înregistrarea tuturor mesajelor din această componentă setând variabila de mediu NS_LOG la diferite niveluri. Să mergem mai departe și să adăugăm câteva intrări la script. Macrocomanda utilizată pentru a adăuga mesaje la nivel de informații în jurnal este NS_LOG_INFO. Să adăugăm un mesaj (chiar înainte de a începe să creăm noduri) care vă spune că scriptul este în faza „Crearea topologiei”. Acest lucru se face în următorul fragment de cod,
Deschide zgârietură/myfirst.cc în editorul tău preferat și adaugă linia,
NS_LOG_INFO ("Creating Topology");
chiar înaintea liniilor,

NodeContainer nodes;
nodes.Create (2);

Acum compilați scriptul folosind WAFși ștergeți variabila NS_LOG pentru a dezactiva fluxul de înregistrare pe care l-am activat mai devreme:

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

Nu veți vedea noul mesaj deoarece componenta de înregistrare asociată (FirstScriptExample) nu a fost activată. Pentru a vedea mesajul dvs. trebuie să activați componenta de logare FirstScriptExample cu un nivel nu mai mic decât NS_LOG_INFO. Dacă doriți doar să vedeți acest nivel specific de înregistrare, îl puteți activa astfel,

$ export NS_LOG=FirstScriptExample=info

Dacă rulați scriptul acum, veți vedea un mesaj nou „Crearea topologiei”,

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 Utilizarea argumentelor liniei de comandă

5.2.1 Suprascrierea valorilor atributelor implicite

O altă modalitate de a schimba comportamentul scripturilor ns-3 fără a edita sau construi este utilizarea argumentelor din linia de comandă. Oferim un mecanism pentru a analiza argumentele liniei de comandă și a seta automat variabilele locale și globale pe baza rezultatelor.

Primul pas în utilizarea sistemului de argumente în linia de comandă este declararea unui parser de linie de comandă. Acest lucru este destul de ușor de făcut (în programul principal), ca în următorul cod,

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

Acest simplu fragment de două rânduri este de fapt foarte util în sine. Acesta deschide ușa către sistemul global de variabile și atribute ns-3. Să adăugăm două linii de cod la începutul funcției de script principal zgârietură/myfirst.cc. Mergând mai departe, compilam scriptul și îl rulăm, când rulăm, facem o cerere de ajutor după cum urmează,

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

Această comandă va cere waf rulați scriptul zgârietură/primul meu și transmiteți-i un argument în linia de comandă — PrintHelp. Ghilimelele sunt necesare pentru a indica programul pentru care este destinat argumentul. Analizorul liniei de comandă va detecta argumentul — PrintHelp și va afișa răspunsul,

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.

Acum să ne uităm la opțiune —PrintAttributes. Am menționat deja sistemul de atribute ns-3 când am studiat primul script.cc. Am văzut următoarele linii de cod,

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

si au spus asta Rata de date este de fapt un atribut PointToPointNetDevice. Să folosim analizatorul de argument din linia de comandă pentru a vedea atributele PointToPointNetDevice. Lista de ajutor spune ce trebuie să oferim TypeId. Acesta este numele clasei căreia îi aparțin atributele de interes. În cazul nostru va fi ns3::PointToPointNetDevice. Haideți să mergem înainte, intrați,

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

Sistemul va imprima toate atributele acestui tip de dispozitiv de rețea. Veți vedea că printre atributele din listă sunt,

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

Aceasta este valoarea implicită care va fi utilizată de sistem la crearea obiectului PointToPointNetDevice. Vom suprascrie această valoare implicită utilizând parametrul Atribut в PointToPointHelper superior. Să folosim valorile implicite pentru dispozitive și canale punct la punct. Pentru a face acest lucru, vom șterge apelurile SetDeviceAttribute и SetChannelAttribute de myfirst.cc, pe care îl avem într-un director curat.

Scriptul dvs. ar trebui să declare acum pur și simplu PointToPointHelper și nu efectuați nicio operațiune de instalare așa cum se arată în exemplul de mai jos,

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

Continuați și creați un nou script cu waf (./waff) și să ne întoarcem și să includem o intrare din aplicația UDP echo server și să includem prefixul de timp.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Dacă rulați scriptul, ar trebui să vedeți următoarea ieșire:

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()

Amintiți-vă că ultima dată când ne-am uitat la timpul de simulare, în momentul în care pachetul a fost primit de serverul echo, a fost de 2,00369 secunde.

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

Acum primește pachetul în 2.25732 secunde. Acest lucru se datorează faptului că pur și simplu resetam rata de date PointToPointNetDevice de la cinci megabiți pe secundă la valoarea implicită, care este 32768 biți pe secundă. Dacă ar fi să înlocuim un nou DataRate folosind linia de comandă, am putea accelera din nou simularea. Vom face acest lucru după cum urmează, conform formulei implicate de elementul de ajutor:

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

Acest lucru va returna atributul DataRate la valoarea implicită de cinci megabiți pe secundă. Esti surprins de rezultat? Se pare că, pentru a reveni la comportamentul inițial al scriptului, trebuie să setăm și întârzierea canalului pentru a se potrivi cu viteza luminii. Putem cere sistemului de linie de comandă să imprime atributele canalului, la fel cum am făcut pentru dispozitivul de rețea:

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

Vom descoperi că atributul de întârziere a canalului este setat după cum urmează:

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

Putem apoi, prin sistemul de linie de comandă, să setăm ambele aceste valori implicite.

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

în acest caz, restabilim timpul pe care îl aveam când am setat în mod explicit DataRate și Delay în script:

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()

Rețineți că pachetul este primit din nou de către server după 2,00369 secunde. De fapt, am putea seta oricare dintre atributele utilizate în script în acest fel. În special, am putea seta atributele MaxPackets la valori non-one UdpEchoClient.

Cum l-ai folosi? Incearca. Amintiți-vă că trebuie să comentați locul în care înlocuim valoarea implicită a atributului și setăm în mod explicit MaxPackets în scenariu. Apoi trebuie să reconstruiți scriptul. De asemenea, puteți utiliza linia de comandă pentru a obține ajutor pentru sintaxă pentru setarea unei noi valori implicite de atribut. Odată ce înțelegeți acest lucru, puteți controla numărul de pachete afișate pe linia de comandă. Deoarece suntem oameni studioși, linia noastră de comandă ar trebui să arate cam așa:

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

Întrebarea firească care se ridică în acest moment este cum să știm despre existența tuturor acestor atribute. Din nou, sistemul de linie de comandă are o funcție de ajutor pentru această problemă. Dacă cerem ajutor liniei de comandă, ar trebui să vedem:

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

Dacă selectați argumentul „PrintGroups”, ar trebui să vedeți o listă cu toate grupurile înregistrate TypeId. Numele grupurilor sunt în concordanță cu numele modulelor din directorul sursă (deși cu majuscule). Imprimarea tuturor informațiilor deodată ar fi prea voluminoasă, așa că este disponibil un filtru suplimentar pentru a imprima informațiile pe grupe. Deci, concentrându-ne din nou pe modulul punct la punct:

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

Aici puteți găsi nume de TypeId disponibile pentru căutări de atribute, de exemplu în
--PrintAttributes = ns3 :: PointToPointChannelașa cum se arată mai sus.

O altă modalitate de a afla despre atribute este prin intermediul Doxygen ns-3. Există o pagină care listează toate atributele înregistrate în simulator.

5.2.2 Capturarea propriilor comenzi

De asemenea, puteți adăuga propriile cârlige prin sistemul de linie de comandă. Acest lucru se face destul de simplu folosind metoda parser-ului din linia de comandă Adaugă valoare.
Să folosim această caracteristică pentru a specifica numărul de pachete care urmează să fie afișate într-un mod complet diferit. Să adăugăm o variabilă locală numită nPachete într-o funcție principal. Îl vom seta la unul pentru a se potrivi cu comportamentul nostru implicit anterior. Pentru a permite parserului liniei de comandă să modifice această valoare, trebuie să captăm această valoare în parser. Facem acest lucru adăugând un apel Adaugă valoare. Du-te și schimbă scenariul zgârietură/myfirst.cc deci pentru a începe cu următorul cod,

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

Derulați în jos până la punctul din script în care setăm atributul MaxPackets și îl schimbăm astfel încât să fie setat la variabila nPackets în loc de constanta 1, așa cum se arată mai jos.

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

Acum, dacă rulați scriptul și furnizați argumentul -PrintHelp, ar trebui să vedeți noul argument de utilizator. listate pe ecranul de ajutor. Introduce,

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

Dacă doriți să modificați numărul de pachete transmise, puteți face acest lucru setând argumentul liniei de comandă - -nPackets.

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

Acum ar trebui să vezi

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()

Acum ați trimis două pachete. Destul de simplu, nu-i așa?
Puteți vedea că, în calitate de utilizator ns-3, puteți utiliza sistemul de argumente din linia de comandă pentru a manipula valorile și atributele globale. Dacă sunteți autorul modelului, puteți adăuga noi atribute la obiectele dvs. și acestea vor fi automat disponibile pentru configurare de către utilizatori prin sistemul de linie de comandă. Dacă sunteți un autor de scripturi, puteți adăuga noi variabile la script-urile dvs. și le puteți conecta fără probleme în sistemul dumneavoastră de linie de comandă.

5.3 Utilizarea sistemului de urmărire

Scopul modelării este de a genera rezultate pentru studii ulterioare, iar sistemul de urmărire ns-3 este mecanismul principal pentru aceasta. Deoarece ns-3 este un program C++, pot fi utilizate mijloace standard de generare a rezultatelor dintr-un program C++:

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

Puteți chiar să utilizați un modul de înregistrare pentru a adăuga o mică structură soluției dvs. Există multe probleme cunoscute cauzate de această abordare și, prin urmare, am furnizat un subsistem general de urmărire a evenimentelor pentru a rezolva aceste probleme.

Obiectivele principale ale sistemului de urmărire ns-3 sunt:

• Pentru sarcinile de bază, sistemul de urmărire ar trebui să permită utilizatorului să genereze o urmă standard pentru sursele populare și să selecteze obiectele care generează urma;

• Utilizatorii intermediari ar trebui să poată extinde sistemul de urmărire pentru a modifica formatul de ieșire generat sau pentru a insera noi surse de urmărire, fără a modifica nucleul simulatorului;

• Utilizatorii avansați pot modifica nucleul simulatorului pentru a adăuga noi surse de urmărire și chiuvete. Sistemul de urmărire ns-3 este construit pe principiile surselor și receptorilor de urmărire independente, precum și pe un mecanism unificat pentru conectarea surselor la consumatori.

Sistemul de urmărire ns-3 este construit pe principiile surselor și receptorilor de urmărire independente, precum și pe un mecanism unificat pentru conectarea surselor la receptori. Sursele de urmărire sunt obiecte care pot semnala evenimente care au loc în simulare și oferă acces la datele de interes de bază. De exemplu, o sursă de urmărire poate indica când un dispozitiv de rețea a primit un pachet și poate face conținutul pachetului disponibil pentru receptorii de urmărire interesați.

Sursele de urmărire sunt inutile, cu excepția cazului în care sunt „cuplate” cu alte părți ale codului care fac de fapt ceva util cu informațiile furnizate de chiuvetă. Următoarele sunt consumatori de evenimente și date furnizate de sursele de urmărire. De exemplu, puteți crea un canal de urmărire care (atunci când este conectat la sursa de urmărire din exemplul anterior) va tipări părțile de interes din pachetul primit.

Motivul pentru această separare explicită este de a permite utilizatorilor să conecteze noi tipuri de chiuvete la sursele de urmărire existente fără a fi nevoie să editeze și să recompileze miezul simulatorului. Deci, în exemplul de mai sus, utilizatorul poate defini un trasor nou în scriptul său și îl poate conecta la o sursă de urmărire existentă definită în nucleul de simulare doar prin editarea scriptului utilizatorului.

În acest tutorial, vom parcurge unele dintre sursele și chiuvetele predefinite și vom arăta cum pot fi configurate cu cel mai mic efort din partea utilizatorului. Consultați manualul ns-3 sau secțiunile de instrucțiuni pentru informații despre configurația avansată de urmărire, inclusiv extinderea spațiului de nume de urmărire și crearea de noi surse de urmărire.

5.3.1 Urmărirea ASCII

ns-3 oferă funcționalitate de ajutor care oferă un sistem de urmărire de nivel scăzut pentru a vă ajuta cu detaliile atunci când configurați urme simple de pachete. Dacă activați această funcție, veți vedea rezultatul în fișiere ASCII. Pentru cei familiarizați cu ieșirea ns-2, acest tip de urmărire este similar cu afară.tr, care este generat de multe scripturi.

Să trecem la treabă și să adăugăm câteva rezultate de urmărire ASCII la scriptul nostru scratch/myfirst.cc. Chiar înainte de apel Simulator :: Run (), adăugați următoarele rânduri de cod:
AsciiTraceHelper ascii;

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

La fel ca multe alte expresii ns-3, acest cod folosește un obiect helper pentru a crea urme ASCII. A doua linie conține două apeluri de metodă imbricate. Metoda „în interior”. CreateFileStream() folosește limbajul de obiect anonim pentru a crea un obiect flux de fișiere pe stivă (fără un nume de obiect) și îl transmite metodei apelate. Vom aprofunda acest lucru în viitor, dar tot ce trebuie să știți în acest moment este că creați un obiect care reprezintă un fișier numit myfirst.tr și transferați-l în ns-3. Îi încredințăm lui ns-3 să aibă grijă de obiectul creat pentru întreaga sa viață, timp în care rezolvă problemele cauzate de o limitare (intenționată) puțin cunoscută asociată cu constructorii de copiere a obiectelor de flux C++.

Apel extern EnableAsciiAll() îi spune asistentului că doriți să includeți urmărirea ASCII în simulare pentru toate conexiunile dispozitivelor punct la punct și că doriți ca receptorii de urmărire (specificați) să înregistreze informații despre mișcarea pachetelor în format ASCII.

Pentru cei familiarizați cu ns-2, evenimentele urmărite sunt echivalente cu punctele de urmărire cunoscute care înregistrează evenimentele „+”, „-”, „d” și „r”.
Acum puteți construi scriptul și îl puteți rula din linia de comandă:

$ ./waf --run scratch/myfirst

Ca de multe ori înainte, veți vedea mai multe mesaje de la Waf și apoi „‘build’ finished with success” cu câteva mesaje din programul care rulează.

Când rulează, programul va crea un fișier numit myfirst.tr. Datorită naturii lucrării waf, în mod implicit fișierul este creat nu în directorul local, ci în directorul de nivel superior al depozitului. Dacă doriți să schimbați calea în care sunt salvate urmele, puteți utiliza parametrul Waf pentru a-l specifica --cwd. Nu am făcut acest lucru, așa că pentru a vedea fișierul de urmărire ASCII myfirst.tr în editorul tău preferat, va trebui să navigăm la directorul de nivel superior al depozitului nostru.

Analizarea urmelor ASCII

Există o mulțime de informații acolo într-o formă destul de densă, dar primul lucru pe care trebuie să îl observați este că fișierul constă din linii individuale. Acest lucru va deveni clar vizibil dacă extindeți fereastra de vizualizare mai larg.

Fiecare linie din fișier corespunde unui eveniment de urmărire. În acest caz, urmărim evenimentele din coada de transmisie prezentă în fiecare dispozitiv de rețea punct la punct din simulare. Coada de transmisie este coada prin care trebuie să treacă fiecare pachet pentru o legătură punct la punct. Rețineți că fiecare linie din fișierul de urmărire începe cu un singur caracter (și are un spațiu după el). Acest simbol va avea următoarea semnificație:

+: a avut loc o operație de așteptare în coada dispozitivului;
-: a avut loc o operație de recuperare a elementului în coada dispozitivului;
d: pachetul a fost abandonat, de obicei pentru că coada era plină;
r: Pachetul a fost primit de dispozitivul de rețea.

Să aruncăm o privire mai atentă la prima linie din fișierul de urmărire. Îl voi împărți în părți (cu indentări pentru claritate) și numărul rândului din stânga:

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)

Prima secțiune a acestui eveniment de urmărire extins (linia 0) este operația. Avem aici un simbol +, care corespunde operațiunii de așteptare pentru transmisie. A doua secțiune (linia 1) este timpul de simulare, exprimat în secunde. Poate vă amintiți ce am întrebat UdpEchoClientApplication începeți să trimiteți pachete în două secunde. Aici vedem confirmarea că acest lucru se întâmplă într-adevăr.

Următoarea secțiune a exemplului de urmărire (din linia 2) arată care sursă de urmărire a generat acest eveniment (indicând următorul spațiului de nume). Vă puteți gândi la spațiul de nume de urmărire la fel ca la un spațiu de nume de sistem de fișiere. Rădăcina spațiului de nume este NodeList. Acesta corespunde containerului gestionat în codul principal ns-3. Conține toate nodurile care sunt create în script. Așa cum un sistem de fișiere poate avea directoare la rădăcină, NodeList putem avea multe noduri. Deci, linia /NodeList/0 se referă la nodul nul din NodeList, despre care de obicei îl considerăm „nodul 0”. Fiecare nod are o listă de dispozitive care au fost instalate. Această listă se află în continuare în spațiul de nume. Puteți vedea că acest eveniment de urmărire provine DeviceList/0, care este dispozitivul nul instalat în nod.

Următorul subșir, $ ns3 :: PointToPointNetDevice, spune ce dispozitiv se află în poziţia zero: lista de dispozitive a nodului zero. Amintiți-vă că operația + găsită în linia 0 a însemnat că un element a fost adăugat la coada de transmisie a dispozitivului. Acest lucru se reflectă în ultimele segmente ale „calei de urmărire”: TxQueue/Enqueue.

Secțiunile rămase din urmă ar trebui să fie destul de intuitive. Liniile 3-4 indică faptul că pachetul este încapsulat într-un protocol punct la punct. Rândurile 5-7 arată că pachetul are un antet de versiune IP4 și provine din adresa IP 10.1.1.1 și destinată 10.1.1.2. Liniile 8-9 arată că acest pachet are un antet UDP și în cele din urmă linia 10 arată că sarcina utilă este de 1024 de octeți așteptați.

Următoarea linie din fișierul de urmărire arată că același pachet a fost scos din coada de transmisie de pe același nod.

A treia linie din fișierul de urmărire arată că pachetul a fost primit de un dispozitiv de rețea pe gazda serverului echo. Am reprodus evenimentul mai jos.

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)

Rețineți că operația de urmărire este acum r și timpul de simulare a fost mărit la 2,25732 secunde. Dacă ați urmat cu atenție tutorialul, înseamnă că ați lăsat DataRate și Link Delay ale dispozitivelor din rețea la valorile implicite. Acest timp ar trebui să fie familiar, așa cum ați văzut în secțiunea anterioară.

Intrarea spațiului de nume sursă de urmărire (linia 2) a fost modificată pentru a reflecta faptul că acest eveniment provine din nodul 1 (/NodeList/1) iar pachetul este primit de sursa de urmărire (/MacRx). Ar trebui să vă fie destul de ușor să urmăriți mișcarea pachetului prin topologie, uitându-vă la urmele rămase din fișier.

5.3.2 Urmărire PCAP

Ns-3 Device Helpers poate fi folosit și pentru a crea fișiere de urmărire în format .pcap. Acronim pcap (scris de obicei cu litere mici) înseamnă captura de pachete și este de fapt un API care include definirea formatului de fișier .pcap. Cel mai popular program care poate citi și afișa acest format este Wireshark (numit anterior Eteric). Cu toate acestea, există multe analizoare de urmărire a traficului care utilizează acest format de pachet. Încurajăm utilizatorii să folosească numeroasele instrumente disponibile pentru a analiza urmele pcap. În acest tutorial ne vom concentra pe vizualizarea urmelor pcap folosind tcpdump.

Activarea urmăririi pcap se face cu o singură linie de cod.

pointToPoint.EnablePcapAll ("myfirst");

Lipiți această linie de cod după codul de urmărire ASCII pe care tocmai l-am adăugat zgârietură/myfirst.cc. Rețineți că am trecut doar șirul „myfirst”, nu „myfirst.pcap” sau ceva similar. Acest lucru se datorează faptului că parametrul este un prefix, nu un nume de fișier complet. În timpul simulării, asistentul va crea de fapt un fișier de urmărire pentru fiecare dispozitiv punct la punct. Numele fișierelor vor fi construite folosind prefixul, numărul nodului, numărul dispozitivului și sufixul ".pcap".

Pentru exemplul nostru de script, vom ajunge să vedem fișiere numite „myfirst-0-0.pcap"Și"myfirst-1-0.pcap", care sunt urme pcap pentru nodul 0-dispozitiv 0 și, respectiv, nodul 1-dispozitiv 0. După ce ați adăugat linia de cod pentru a activa urmărirea pcap, puteți rula scriptul în modul obișnuit:

$ ./waf --run scratch/myfirst

Dacă vă uitați în directorul de nivel superior al distribuției dvs., ar trebui să vedeți trei fișiere: un fișier de urmărire ASCII myfirst.tr, pe care le-am studiat anterior, dosare myfirst-0-0.pcap и myfirst-1-0.pcap - noi fișiere pcap pe care tocmai le-am generat.

Citirea ieșirii cu tcpdump

Deocamdată, cel mai simplu mod de a vizualiza fișierele pcap este să folosești 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

În groapă myfirst-0-0.pcap (dispozitiv client) puteți vedea că pachetul de eco este trimis după 2 secunde de simulare. Dacă te uiți la a doua groapă (myfirst-1-0.pcap), veți vedea că pachetul este primit la 2,257324 secunde. Veți vedea în al doilea dump că pachetul este returnat la 2.257324 secunde și, în final, că pachetul a fost primit înapoi de către client în primul dump la 2.514648 secunde.

Citirea ieșirii cu Wireshark

Dacă nu sunteți familiarizat cu Wireshark, există un site web de pe care puteți descărca programe și documentație: http://www.wireshark.org/. Wireshark este o interfață grafică care poate fi utilizată pentru a afișa aceste fișiere de urmărire. Dacă aveți Wireshark, puteți deschide oricare dintre fișierele de urmărire și puteți afișa conținutul ca și cum ați fi capturat pachetele folosind un sniffer de pachete.

Sursa: www.habr.com