Manual de utilizare pentru simulatorul de rețea ns-3. Capitolul 5

capitolele 1,2
capitol 3
capitol 4

5 Configurare
5.1 Utilizarea modulului de jurnalizare
5.1.1 Prezentare generală a jurnalizării
5.1.2 Activarea jurnalizării
5.1.3 Adăugarea jurnalizării în codul dvs.
5.2 Utilizarea argumentelor din linia de comandă
5.2.1 Suprascrierea valorilor atributelor implicite
5.2.2 Capturarea propriilor comenzi
5.3 Utilizarea sistemului de trasare
5.3.1 Trasare ASCII
Analiza trasării ASCII
5.3.2 Trasare PCAP

Capitolul 5

Configurare

5.1 Utilizarea modulului de jurnalizare

Am discutat deja pe scurt despre modulul de jurnalizare ns-3, analizând scriptul first.cc. În acest capitol, ne vom uita mai atent la opțiunile de utilizare a subsistemului de jurnalizare.

5.1.1 Prezentare generală a jurnalizării

Multe sisteme mari susțin un fel de instrument de înregistrare a mesajelor, iar ns-3 nu face excepție. În unele cazuri, în « consola operatorului » (care este de obicei stderr în sistemele bazate pe Unix) sunt înregistrate doar mesajele de eroare. În alte sisteme, pot fi afișate mesaje de avertizare, precum și informații mai detaliate. În unele cazuri, instrumentele de jurnalizare sunt utilizate pentru a afișa mesaje de depanare, care pot „estompa” rapid ieșirea.

Abordarea utilizată în ns-3 presupune că toate aceste niveluri de informativitate sunt utile, iar noi oferim o abordare selectivă, multilevel pentru înregistrarea mesajelor. Jurnalizarea poate fi complet dezactivată, activată pentru componente individuale sau la scară globală. Acest lucru este realizat prin niveluri de informativitate configurabile. Modulul de jurnalizare ns-3 oferă o modalitate relativ simplă de a obține informații utile din simularea dvs.

Trebuie să înțelegeți că oferim un mecanism general — trasare — pentru extragerea de date din modelele dvs., care ar trebui să fie preferat pentru ieșirea în timpul modelării (pentru informații mai detaliate despre sistemul nostru de trasare, consultați secțiunea tutorialului 5.3). Jurnalizarea ar trebui să fie metoda preferată pentru obținerea informațiilor de depanare, avertizărilor, mesajelor de eroare sau pentru a obține rapid mesaje din scenariile sau modelele dvs. în orice moment.

În prezent, în sistem sunt definite șapte niveluri (tipuri) de mesaje de jurnal, în ordine crescătoare a informativității.

• LOG_ERROR — înregistrarea mesajelor de eroare (macro asociat: NS_LOG_ERROR);
• LOG_WARN — înregistrarea mesajelor de avertizare (macro asociat: NS_LOG_WARN);
• LOG_DEBUG — înregistrarea mesajelor de debug relativ rare (macro asociat: NS_LOG_DEBUG);
• LOG_INFO — înregistrarea mesajelor informative despre progresul programului (macro asociat: NS_LOG_INFO);
• LOG_FUNCTION — înregistrarea mesajelor care descriu fiecare funcție apelată (două macro-uri asociate: NS_LOG_FUNCTION, utilizat pentru funcții membre, și NS_LOG_FUNCTION_NOARGS, utilizat pentru funcții statice);
• LOG_LOGIC — înregistrarea mesajelor care descriu fluxul logic din cadrul funcției (macro asociat: NS_LOG_LOGIC);
• LOG_ALL — înregistrarea tuturor celor menționate mai sus (nu există macro asociat).
  Pentru fiecare tip (LOG_TYPE) există, de asemenea, un tip LOG_LEVEL_TYPE, care, dacă este utilizat, permite înregistrarea, pe lângă nivelul său propriu, a tuturor nivelurilor deasupra acestuia. (Ca urmare, LOG_ERROR și LOG_LEVEL_ERROR, precum și LOG_ALL și LOG_LEVEL_ALL sunt funcțional echivalente.) De exemplu, activarea LOG_INFO va permite doar mesaje furnizate de macro-ul NS_LOG_INFO, iar activarea LOG_LEVEL_INFO va include, de asemenea, mesaje furnizate de macro-urile NS_LOG_DEBUG, NS_LOG_WARN și NS_LOG_ERROR.

De asemenea, oferim un macro de înregistrare incondiționată, care se afișează întotdeauna, indiferent de nivelul de jurnalizare sau de componenta selectată.

• NS_LOG_UNCOND — înregistrarea incondiționată a mesajului asociat (fără nivel de jurnalizare asociat).

Fiecare nivel poate fi solicitat individual sau cumulativ. Jurnalizarea poate fi configurată prin variabila de mediu sh NS_LOG sau prin înregistrarea unui apel la funcția de sistem. Așa cum s-a arătat anterior, sistemul de înregistrare are documentație Doxygen și acum este momentul să o consultați, dacă nu ați făcut-o deja.

Acum, când ați citit documentația foarte detaliat, haideți să folosim aceste cunoștințe pentru a obține informații interesante dintr-un exemplu de script scratch/myfirst.cc, pe care l-ați compilat deja.

5.1.2 Activarea jurnalizării

Să folosim variabila de mediu NS_LOG pentru a rula și alte câteva jurnale, dar mai întâi, doar pentru a ne orienta, rulați ultimul script, așa cum ați făcut anterior,

$ ./waf --run scratch/myfirst

Ar trebui să vedeți deja ieșirea familiară a primului program exemplu ns-3

$ Waf: Intrând în directorul `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Părăsind directorul `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 'build'
finalizat cu succes (0.413s)
Trimis 1024 bytes către 10.1.1.2
Recepționat 1024 bytes de la 10.1.1.1
Recepționat 1024 bytes de la 10.1.1.2

Se pare că mesajele «trimise» și «recepute» pe care le vedeți mai sus sunt, de fapt, mesaje înregistrate de la UdpEchoClientApplication și UdpEchoServerApplication. De exemplu, putem cere aplicației client să imprimate informații suplimentare, setând nivelul de jurnalizare prin variabila de mediu NS_LOG.

În acest moment, voi presupune că folosiți un shell de tip sh care utilizează sintaxa „VARIABLE = value”. Dacă utilizați un shell de tip csh, va trebui să transformați exemplele mele în sintaxa „setenv VARIABLE value” necesară acelor shell-uri.

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

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Aceasta activează nivelul de jurnalizare LOG_LEVEL_INFO. Atunci când transmitem un flag de nivel de jurnalizare, de fapt activăm 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 jurnalizare și obține mai multe informații, fără a modifica scriptul și recompilarea, setând variabila de mediu NS_LOG astfel:

$ export NS_LOG=UdpEchoClientApplication=level_all

Astfel, stabilim următoarea valoare pentru variabila de shell NS_LOG:

UdpEchoClientApplication=level_all

Partea stângă a atribuirii este numele componentei de jurnalizare pe care dorim să o configurăm, iar partea dreaptă este flag-ul pe care dorim să-l aplicăm. În acest caz, ne propunem să activăm toate nivelurile de depanare în aplicație. Dacă rulați scriptul cu NS_LOG setat astfel, sistemul de jurnalizare ns-3 va accepta modificările și ar trebui să vedeți următoarea ieșire:

Waf: Intrând în directorul `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Părăsind directorul `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' finalizat cu succes (0.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Trimis 1024 bytes către 10.1.1.2
Recepționat 1024 bytes de la 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Recepționat 1024 bytes de la 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Informațiile suplimentare de depanare oferite de aplicație corespund acum nivelului NS_LOG_FUNCTION. Aceasta arată fiecare caz de apelare a funcțiilor în timpul execuției scriptului. În general, în funcțiile metodă, este preferabil să folosiți (cel puțin)NS_LOG_FUNCTION (this). Utilizați NS_LOG_FUNCTION_NOARGS ()
doar în funcțiile statice. Cu toate acestea, rețineți că în sistemul ns-3 nu există cerințe pentru a menține vreo funcționalitate de jurnalizare. Decizia privind cantitatea de informație care este înregistrată rămâne la latitudinea dezvoltatorului modelului. În cazul aplicațiilor echo, sunt disponibile multe date pentru jurnalizare.

Acum puteți vizualiza jurnalul apelurilor de funcții care au fost efectuate de aplicație. Dacă priviți cu atenție, veți observa un două puncte între linia UdpEchoClientApplication și numele metodei, în locul în care ați putea aștepta să vedeți operatorul de domeniu C++ (::). Aceasta a fost făcută intenționat.

De fapt, acesta nu este numele clasei, ci numele componentului de jurnalizare. Când există o corespondență între fișierul sursă și clasă, de obicei acesta este numele clasei, dar trebuie să înțelegeți că, de fapt, acesta nu este numele clasei și acolo este un două puncte în loc de două puncte duble. Aceasta este o modalitate de a vă ajuta într-un mod mai subtil să conceptualizați separarea numelui componentului de jurnalizare de numele clasei.

Cu toate acestea, în unele cazuri, poate fi dificil să determinați ce metodă generează de fapt mesajul de jurnal. Dacă priviți textul de mai sus, veți avea întrebarea de unde a apărut linia„Received 1024 bytes from 10.1.1.2». Puteți rezolva această problemă prin stabilirea nivelului prefix_func în 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 indica operația OR, este, de asemenea, un separator de conducte Unix. Acum, dacă rulați scriptul, veți vedea că sistemul de jurnalizare garantează că fiecare mesaj din acest jurnal are un prefix cu numele componentului.

Waf: Intrând în directorul `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Ieșind din directorul `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' s-a încheiat cu succes (0.417s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): A trimis 1024 bytes către 10.1.1.2
A primit 1024 bytes de la 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
UdpEchoClientApplication:HandleRead(): A primit 1024 bytes de la 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Acum poți vedea că toate mesajele primite de la aplicația UDP echo-client sunt identificate ca atare. Mesajul „Received 1024 bytes from 10.1.1.2“ este acum definit clar ca provenind de la aplicația echo-client. Mesajul rămas ar trebui să provină din aplicația UDP echo-server. Putem activa acest 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'

Atenție: în exemplul de text de mai sus, va trebui să ștergi caracterul de sfârșit de linie după două puncte (:), acesta este utilizat pentru formatarea documentului. Acum, dacă vei rula scriptul, vei vedea toate mesajele de jurnal din aplicațiile de echo client și server. Poate fi foarte util în procesul de depanare.

Waf: Intrând în directorul `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Ieșind din directorul `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' s-a încheiat cu succes (0.406s)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoServerApplication:StartApplication()
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): A trimis 1024 bytes către 10.1.1.2
UdpEchoServerApplication:HandleRead(): A primit 1024 bytes de la 10.1.1.1
UdpEchoServerApplication:HandleRead(): Echiparea pachetului
UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
UdpEchoClientApplication:HandleRead(): A primit 1024 bytes de la 10.1.1.2
UdpEchoServerApplication:StopApplication()
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

De asemenea, este uneori util să ai posibilitatea de a vedea timpul de simulare în care a fost generat mesajul de jurnal. Poți face acest lucru prin adăugarea unui bit de tip OR prefix_time:

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

Din nou, va trebui să ștergi caracterul de sfârșit de linie de mai sus. Dacă acum vei rula scriptul, ar trebui să vezi următoarea ieșire:

Waf: Intrând în directorul `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 
Waf: Ieșind din directorul `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 
'build' finalizat cu succes (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(): A trimis 1024 bytes către 10.1.1.2 
2.00369s UdpEchoServerApplication:HandleRead(): A primit 1024 bytes de la 10.1.1.1 
2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet 
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0) 
2.00737s UdpEchoClientApplication:HandleRead(): A primit 1024 bytes de la 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 de 0 secunde. Acest lucru se întâmplă, de fapt, înainte de începerea simulării, dar acest timp este afișat ca zero secunde. Același lucru este adevărat pentru mesajul constructorului UdpEchoClient.

Waf: Intrând în directorul `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 
Waf: Ieșind din directorul `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 
'build' finalizat cu succes (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(): A trimis 1024 bytes către 10.1.1.2 
2.00369s UdpEchoServerApplication:HandleRead(): A primit 1024 bytes de la 10.1.1.1 
2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet 
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0) 
2.00737s UdpEchoClientApplication:HandleRead(): A primit 1024 bytes de la 10.1.1.2 
10s UdpEchoServerApplication:StopApplication() 
10s UdpEchoClientApplication:StopApplication() 
UdpEchoClientApplication:DoDispose() 
UdpEchoServerApplication:DoDispose() 
UdpEchoClientApplication:~UdpEchoClient() 
UdpEchoServerApplication:~UdpEchoServer()

Amintim că scriptul scratch/first.cc a pornit aplicația serverului echo cu un secundă înainte de începerea simulării. Acum puteți vedea că metoda StartApplication serverului este, de fapt, apelată în prima secundă. De asemenea, puteți observa că clientul echo pornește în a doua secundă a simulării, așa cum am solicitat în script.

Acum puteți urmări progresul simulării prin apelul ScheduleTransmit în client, care apelează callback-ul HandleRead în aplicația serverului echo. Rețineți că timpul necesar pentru a trimite un pachet printr-un link cu două puncte este de 3,69 milisecunde. Este evident că serverul echo înregistrează un mesaj conform căruia a răspuns la pachet, iar apoi, după o întârziere a canalului, vedeți că clientul echo primește pachetul echo în metoda sa HandleRead.

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

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

Asteriscul de mai sus este un caracter wildcard pentru componenta de jurnalizare. Acesta va activa toate înregistrările din toate componentele utilizate în simulare. Nu voi reproduse ieșirea aici (la momentul scrierii articolului produce 1265 linii de ieșire pentru un singur pachet echo), dar puteți redirecționa această informație într-un fișier și să o vizualizați în editorul preferat.

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

Personalmente, folosesc această versiune extrem de detaliată a jurnalizării atunci când întâmpin o problemă și nu am idee unde lucrurile au mers prost. Pot urmări destul de ușor execuția codului, fără a seta puncte de oprire și a debuga codul pas cu pas. Pot modifica pur și simplu ieșirea în editorul meu preferat și pot căuta ceea ce mă aștept și pot vedea ce se întâmplă ceea ce nu m-am așteptat. Când am o idee generală despre ceea ce nu merge bine, trec la debugger pentru a investiga problema în detaliu. Acest tip de ieșire poate fi deosebit de util atunci când scriptul tău face ceva complet neașteptat. Dacă folosești doar debuggerul, ai putea să ratezi complet o întorsătură neașteptată. Jurnalizarea face ca astfel de întorsături să fie vizibile.

5.1.3 Adăugarea jurnalizării în codul dvs.

Poți adăuga noi înregistrări în simulările tale, apelând componenta log din mai multe macro-uri. Să facem acest lucru în scenariul myfirst.cc, pe care îl avem în directorul „curat”. Să ne amintim că am definit în acest scenariu componenta de jurnalizare:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Știți că puteți activa jurnalizarea tuturor mesajelor acestui component, setând variabila de mediu NS_LOG la diferite niveluri. Să continuăm și să adăugăm câteva înregistrări în script. Macro-ul folosit pentru a adăuga la jurnal mesajele de nivel informativ este NS_LOG_INFO. Să adăugăm un mesaj (chiar înainte de a începe crearea nodurilor) care să vă spună că scriptul este în etapa de creare a topologiei ("Creating Topology"). Acest lucru se face în următorul fragment de cod,
Deschideți scratch/myfirst.cc în editorul vostru preferat și adăugați linia,
NS_LOG_INFO ("Creating Topology");
imediat înainte de liniile,

NodeContainer nodes;
nodes.Create (2);

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

$ ./waf
$ export NS_LOG=
Acum, dacă rulați scriptul,
$ ./waf --run scratch/myfirst

nu veți vedea noul mesaj, deoarece componenta de jurnalizare asociată (FirstScriptExample) nu a fost activată. Pentru a vedea mesajul dvs., trebuie să activați componenta de jurnalizare FirstScriptExample cu un nivel de cel puțin NS_LOG_INFO. Dacă doriți să vedeți doar acest nivel specific de jurnalizare, îl puteți activa astfel,

$ export NS_LOG=FirstScriptExample=info

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

Waf: Intrând în director `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf: Părăsind directorul `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'build' finalizat cu succes (0.404s)\nCrearea topologiei\nTrimis 1024 de octeți către 10.1.1.2\nRecepționat 1024 de octeți de la 10.1.1.1\nRecepționat 1024 de octeți de la 10.1.1.2

5.2 Utilizarea argumentelor din linia de comandă

5.2.1 Suprascrierea valorilor atributelor implicite

O altă modalitate de a modifica comportamentul scripturilor ns‑3 fără a edita și construi este utilizarea argumentelor din linia de comandă. Oferim un mecanism pentru analizarea argumentelor din linia de comandă și setarea automată a variabilelor locale și globale pe baza rezultatelor.

Primul pas în utilizarea sistemului de argumente din linia de comandă este declararea parserului de linie de comandă. Acest lucru se face destul de simplu (în programul dumneavoastră principal), ca în următorul cod,

int\nmain (int argc, char *argv[])\n{\n...\nCommandLine cmd;\ncmd.Parse (argc, argv);\n...\n}

Acest simplu fragment de două linii este, de fapt, foarte util de la sine. El deschide ușa pentru variabila globală ns‑3 și sistemul de atribute. Să adăugăm două linii de cod la începutul funcției principale a scriptului. scratch/myfirst.cc. Continuând, compilăm scriptul și îl rulăm, solicitând ajutorul în acest fel,

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

Această comandă va solicita Waf să ruleze scriptul scratch\/myfirst și să-i transmită un argument din linia de comandă —PrintHelp. Ghidul este necesar pentru a arăta pentru ce program este destinat argumentul. Parserul de linie de comandă va detecta argumentul —PrintHelp și va afișa răspunsul,

Waf: Intrând în director `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf: Părăsind directorul `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'build' finalizat cu succes (0.413s)\nTcpL4Protocol:TcpStateMachine()\nCommandLine:HandleArgument(): Handle arg name=PrintHelp value=\n--PrintHelp: Afișați acest mesaj de ajutor.\n--PrintGroups: Afișați lista grupurilor.\n--PrintTypeIds: Afișați toate TypeIds.\n--PrintGroup=[group]: Afișați toate TypeIds de grup.\n--PrintAttributes=[typeid]: Afișați toate atributele de typeid.\n--PrintGlobals: Afișați lista globalelor.

Acum să examinăm opțiunea —PrintAttributes. Am menționat deja sistemul de atribute ns‑3, când am analizat scriptul first.cc. Am văzut următoarele linii de cod,

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

și am spus că DataRate este de fapt un atribut PointToPointNetDevice. Să aplicăm parserul de argumente din linia de comandă pentru a vizualiza atributele PointToPointNetDevice. Lista de ajutor spune că trebuie să furnizăm TypeId. Acesta este numele clasei la care aparțin atributele de interes. În cazul nostru, aceasta va fi ns3::PointToPointNetDevice. Să continuăm, introduceți

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

Sistemul va imprima toate atributele acestui tip de dispozitiv de rețea. Veți observa că printre atributele din listă se află

--ns3::PointToPointNetDevice::DataRate=[32768bps]:
Rata de transfer implicită pentru conexiunile punct la punct

Aceasta este valoarea implicită care va fi utilizată în sistem la crearea obiectului PointToPointNetDevice. Vom suprascrie această valoare implicită cu ajutorul parametrului Atribut în PointToPointHelper de mai sus. Să folosim valorile implicite pentru dispozitivele și canalele punct la punct. Pentru aceasta, vom elimina apelurile SetDeviceAttribute și SetChannelAttribute din myfirst.cc, pe care le avem în directorul curat.

Scriptingul tău ar trebui acum să declare doar PointToPointHelper și să nu execute nicio operațiune de configurare, așa cum este arătat î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 (.\/waf) și să ne întoarcem la includerea unor înregistrări din aplicația server UDP Echo și să adăugăm 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: Intrați în director `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Ieșind din director `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' finalizat cu succes (0.405s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Trimis 1024 de octeți către 10.1.1.2
2.25732s Am primit 1024 de octeți de la 10.1.1.1
2.25732s Răspunzând pachetului
Am primit 1024 de octeți de la 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Amintim că data trecută, când ne-am uitat la timpul de simulare, momentul în care pachetul a fost primit de serverul de echo a fost la 2.00369 secunde.

2.00369s UdpEchoServerApplication:HandleRead(): Am primit 1024 de octeți de la 10.1.1.1

Acum primește pachetul la 2.25732 secunde. Acest lucru se datorează faptului că am redus viteza de transfer a PointToPointNetDevice de la cinci megabiți pe secundă la valoarea implicită de 32768 biți pe secundă. Dacă am fi introdus noul DataRate prin linia de comandă, am putea accelera din nou simularea noastră. O vom face astfel, conform formulei sugerate de elementul de ajutor:

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

Ca urmare, valoarea atributului DataRate va reveni la cinci megabiți pe secundă. Sunteți surprins de rezultat? Se pare că, pentru a restabili comportamentul inițial al scriptului, trebuie de asemenea să setăm întârzierea canalului corespunzătoare vitezei luminii. Putem cere sistemului de linie de comandă să imprime atributele canalului, așa cum am făcut pentru dispozitivul de rețea:

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

Vom observa că atributul întârzierei canalului este setat astfel:

--ns3::PointToPointChannel::Delay=[0ns]:
Întârzierea de transmisie prin canal

Apoi putem, prin sistemul de linie de comandă, să setăm ambele aceste valori implicit,

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

în acest caz, restaurăm timpul pe care l-am avut când am setat explicit DataRate și Delay în script:

Waf: Intrând în directorul `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Ieșind din directorul `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' finalizat cu succes (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Trimis 1024 de octeți către 10.1.1.2
2.00369s A primit 1024 de octeți de la 10.1.1.1
2.00369s Repetând pachetul
A primit 1024 de octeți de la 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Observați că pachetul este primit din nou de server după 2.00369 secunde. Am putea de fapt să setăm astfel orice dintre atributele folosite în script. În special, am putea să setăm valori diferite de unu pentru atributele MaxPackets UdpEchoClient.

Cum ați folosi asta? Încercați. Amintiți-vă că trebuie să comentați locul unde suprascriem valoarea atributului implicit și să setăm explicit MaxPackets în script. Apoi trebuie să recompilați scriptul. De asemenea, puteți obține ajutor pentru sintaxa de setare a unei noi valori a atributului implicit din linia de comandă. Odată ce ați înțeles acest lucru, veți putea gestiona numărul de pachete afișate în linia de comandă. Deoarece suntem oameni harnici, linia noastră de comandă ar trebui să arate aproximativ așa:

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

O întrebare naturală care apare în acest loc este cum să aflăm despre existența tuturor acestor atribute. Din nou, sistemul de linie de comandă are o funcție de ajutor în această privință. Dacă solicităm ajutor din linia de comandă, atunci ar trebui să vedem:

$ ./waf --run "scratch/myfirst --PrintHelp"
myfirst [Program Arguments] [General Arguments]
General Arguments:
--PrintGlobals: Afișează lista de globale.
--PrintGroups: Afișează lista de grupuri.
--PrintGroup=[group]: Afișează toate TypeIds din grup.
--PrintTypeIds: Afișează toate TypeIds.
--PrintAttributes=[typeid]: Afișează toate atributele pentru typeid.
--PrintHelp: Afișează acest mesaj de ajutor.

Dacă alegeți argumentul „PrintGroups”, ar trebui să vedeți lista tuturor grupurilor înregistrate. TypeId. Numele grupurilor se aliniază cu numele modulelor din directorul sursă (deși cu literă mare). Afișarea tuturor informațiilor simultan ar fi prea voluminoasă, așa că este disponibil un filtru suplimentar pentru a afișa informațiile pe grupuri. Astfel, concentrându-ne din nou pe modulul „punct-la-punct”:

./waf --run "scratch/myfirst --PrintGroup=PointToPoint"
TypeIds în grupul PointToPoint:
ns3::PointToPointChannel
ns3::PointToPointNetDevice
ns3::PointToPointRemoteChannel
ns3::PppHeader

Aici puteți găsi numele disponibile TypeId pentru a căuta atribute, de exemplu, în
--PrintAttributes = ns3::PointToPointChannel, așa cum este prezentat mai sus.

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

5.2.2 Capturarea propriilor comenzi

Puteți adăuga și propriile hook-uri prin sistemul de linie de comandă. Acest lucru se face destul de simplu cu ajutorul metodei parserului de linie de comandă. AddValue.
Să folosim această oportunitate pentru a specifica numărul de pachete care ar trebui să fie afișate, într-un mod complet diferit. Să adăugăm o variabilă locală numită nPackets în funcția main. O vom seta la unu pentru a corespunde comportamentului nostru implicit anterior. Pentru a permite parserului de linie de comandă să schimbe această valoare, trebuie să captam această valoare în parser. Facem acest lucru adăugând un apel AddValue. Mergeți și modificați scriptul scratch/myfirst.cc în așa fel încât să înceapă cu următorul cod:

int
main (int argc, char *argv[])
{
uint32_t nPackets = 1;
CommandLine cmd;
cmd.AddValue("nPackets", "Numărul de pachete de echo", nPackets);
cmd.Parse (argc, argv);
...

Derulați în jos până la punctul din script unde setăm atributul MaxPackets și modificați-l astfel încât să fie configurat la variabila nPackets în loc de constanta 1, așa cum este arătat mai jos.

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

Acum, dacă rulați scriptul și introduceți argumentul —PrintHelp, ar trebui să vedeți un nou argument de utilizator listat pe ecranul de ajutor. Introduceți,

$ . /waf --run "scratch/myfirst --PrintHelp"
Waf: Intrăm în directorul ` /home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Părăsim directorul ` /home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' a fost finalizat cu succes (0.403s)
--PrintHelp: Afișează acest mesaj de ajutor.
--PrintGroups: Afișează lista grupurilor.
--PrintTypeIds: Afișează toate TypeIds.
--PrintGroup=[group]: Afișează toate TypeIds ale grupului.
--PrintAttributes=[typeid]: Afișează toate atributele typeid.
--PrintGlobals: Afișează lista de variabile globale.
Argumente utilizator:
--nPackets: Numărul de pachete de trimis

Dacă doriți să modificați numărul de pachete trimise, puteți face acest lucru stabilind argumentul - -nPackets în linia de comandă.

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

Acum ar trebui să vedeți

Waf: Intrăm în directorul ` /home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Părăsim directorul ` /home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' a fost finalizat cu succes (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Trimis 1024 bytes către 10.1.1.2
2.25732s Am primit 1024 bytes de la 10.1.1.1
2.25732s Aștept pachet
Am primit 1024 bytes de la 10.1.1.2
Trimis 1024 bytes către 10.1.1.2
3.25732s Am primit 1024 bytes de la 10.1.1.1
3.25732s Aștept pachet
Am primit 1024 bytes de la 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Ați trimis acum două pachete. Destul de simplu, nu-i așa?
Puteți observa că, ca utilizator ns‑3, puteți utiliza sistemul de argumente din linia de comandă pentru a gestiona valorile globale și atributele. Dacă sunteți creatorul modelului, puteți adăuga noi atribute obiectelor dumneavoastră, iar acestea vor fi disponibile automat pentru configurarea utilizatorilor dvs. prin sistemul din linia de comandă. Dacă sunteți autorul scriptului, puteți adăuga noi variabile în scripturile dvs. și le puteți integra fără probleme în sistemul din linia de comandă.

5.3 Utilizarea sistemului de trasare

Întregul scop al modelării este de a genera rezultate pentru studii ulterioare, iar sistemul de trasare ns‑3 reprezintă mecanismul principal pentru acest lucru. Deoarece ns‑3 este un program în C++, se pot utiliza metodele standard de generare a rezultatelor din programările C++:

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

Puteți folosi chiar și modulul de jurnalizare pentru a adăuga o oarecare structură soluției dumneavoastră. Există multe probleme cauzate de această abordare și, prin urmare, pentru a le rezolva, am furnizat o subsistemă comună pentru trasarea evenimentelor.

Obiectivele principale ale sistemului de trasare ns‑3 sunt:

• Pentru sarcinile de bază, sistemul de trasare ar trebui să permită utilizatorului să genereze o trasare standard pentru surse populare și să selecteze obiectele care generează trasări;

• Utilizatorii intermediari ar trebui să aibă posibilitatea de a extinde sistemul de trasare pentru a modifica formatul de ieșire generat sau pentru a adăuga noi surse de trasare, fără a modifica nucleul simulatorului;

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

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

Sursele de trasare sunt inutile în sine, dacă nu sunt „conectate” la alte părți ale codului, care fac ceva util cu informația furnizată de receptor, ceea ce este semnificativ. Trasatorii sunt consumatori ai evenimentelor și datelor oferite de sursele de trasare. De exemplu, se poate crea un receptor de trasare care să (când este conectat la sursa de trasare din exemplul anterior) imprime părțile de interes ale pachetului primit.

O rațiune solidă pentru o asemenea separare explicită este de a permite utilizatorilor să conecteze noi tipuri de receptori la sursele existente de trasare fără a fi necesară editarea și recompilarea nucleului simulatorului. Astfel, în exemplul de mai sus, utilizatorul poate defini un nou trasator în scriptul său și îl poate conecta la o sursă existentă de trasare definită în nucleul simulării, editând doar scriptul personalizat.

În acest ghid, vom trece în revistă câteva surse și receptoare predeterminate și vă vom arăta cum le puteți configura cu eforturi minime din partea utilizatorului. Consultați Ghidul ns‑3 sau secțiunile cu instrucțiuni pentru informații despre configurarea avansată a trasărilor, inclusiv extensia spațiului de nume de trasare și crearea de noi surse de trasare.

5.3.1 Trasare ASCII

ns‑3 oferă funcționalitate auxiliară care furnizează un sistem de trasare de nivel inferior pentru a vă ajuta cu detaliile, atunci când configurați trase simple ale pachetelor. Dacă activați această funcție, veți vedea ieșirea în fișiere ASCII. Pentru cei familiarizați cu ieșirea ns-2, acest tip de trasare este similar out.tr, care a fost generat de mai multe scripturi.

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

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

Ca în multe alte idiomuri ns‑3, acest cod folosește un obiect auxiliar pentru a crea trasări ASCII. A doua linie conține două apeluri înlănțuite de metodă. Metoda "interna" CreateFileStream () utilizează idiomul obiectului anonim pentru a crea un obiect de flux de fișiere în stivă (fără nume de obiect) și îl transmite metodei apelante. În viitor, ne vom aprofunda în acest subiect, dar tot ce trebuie să știți în acest stadiu este că creați un obiect care reprezintă un fișier cu numele myfirst.tr și îl transmiteți în ns‑3. Ne bazăm pe ns‑3 să se ocupe de obiectul creat pe toată durata vieții sale, perioadă în care se rezolvă problemele generate de o restricție puțin cunoscută (intenționată) legată de constructorii de copiere ai obiectelor de flux C++.

Apelul extern EnableAsciiAll() informează asistentul că doriți să activați trasarea ASCII pentru toate conexiunile dispozitivului punct-la-punct în simularea dumneavoastră și că doriți ca (receptorii specificați) ai trasării să înregistreze informații despre mișcarea pachetelor în format ASCII.

Pentru cei familiarizați cu ns-2, evenimentele urmărite sunt echivalente cu cunoscutele puncte de trasare care înregistrează evenimentele "+", "-", "d" și "r".
Acum puteți să compilați scriptul și să-l rulați din linia de comandă:

$ ./waf --run scratch/myfirst

De câte ori înainte, veți vedea câteva mesaje de la Waf și apoi „build finished successfully” (construcția s-a finalizat cu succes) cu un anumit număr de mesaje de la programul care funcționează.

În timpul funcționării, programul va crea un fișier cu numele myfirst.tr. Din cauza specificului funcționării Waf, prin intermediul default, fișierul nu este creat în directorul local, ci în directorul de nivel superior al repository-ului. Dacă doriți să schimbați calea unde sunt salvate traseele, pentru a specifica acest lucru, puteți folosi pentru Waf parametrul --cwd. Nu am făcut acest lucru, așa că pentru a vizualiza fișierul ASCII de trasare myfirst.tr în editorul vostru preferat, va trebui să navigăm în directorul de nivel superior al repository-ului nostru.

Analiza trasării ASCII

Există multe informații într-o formă destul de compactă, dar primul lucru la care trebuie să ne concentrăm este că fișierul constă din linii separate. Acest lucru va deveni evident dacă extindeți fereastra de vizualizare.

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

+: a avut loc o operațiune de coadă a dispozitivului;
-: a avut loc o operațiune de extragere a unui element din coada dispozitivului;
d: pachetul a fost respins, de obicei, deoarece coada era plină;
r: pachetul a fost primit de dispozitivul rețea.

Să examinăm mai în detaliu prima linie din fișierul de trasare. O voi descompune în părți (cu indentare pentru claritate) și cu numărul liniei în stânga:

0 +
1 2
2 /NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue
3 ns3::PppHeader (
4   Protocol Point-to-Point: IP (0x0021))
6   ns3::Ipv4Header (
7     tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
8     lungime: 1052 10.1.1.1 > 10.1.1.2)
9     ns3::UdpHeader (
10      lungime: 1032 49153 > 9)
11      Payload (size=1024)

Prima secțiune a acestui eveniment extins de trasare (linia 0) este operațiunea. Avem aici simbolul +, care corespunde unei operațiuni de coadă pentru transmitere. A doua secțiune (linia 1) este timpul de simulare, exprimat în secunde. Puteți aminti că am solicitat UdpEchoClientApplication începerea trimiterii pachetelor în două secunde. Aici vedem confirmarea faptului că acest lucru se întâmplă cu adevărat.

În următoarea secțiune a exemplelor de urmărire (din linia 2) se arată care sursă de urmărire a generat acest eveniment (se specifică spațiul de nume al urmării). Puteți reprezenta spațiul de nume al urmării aproximativ la fel ca un sistem de fișiere. Rădăcina spațiului de nume este NodeList. Aceasta corespunde unui container gestionat în principal de codul ns-3. În el se află toate nodurile create în script. La fel cum un sistem de fișiere poate avea directoare în rădăcină, în NodeList putem avea mai multe noduri. Astfel, linia /NodeList/0 se referă la nodul zero din NodeList, pe care îl înțelegem de obicei ca 'nodul 0'. Fiecare nod are o listă de dispozitive care au fost instalate. Această listă se află următoarea în spațiul de nume. Puteți vedea că acest eveniment de urmărire provine din DeviceList/0, care este dispozitivul zero instalat în nod.

Următoarea subliniere, $ ns3::PointToPointNetDevice, indică ce dispozitiv se află în poziția zero: lista dispozitivelor nodului zero. Să ne amintim că operația +, aflată în linia 0, a însemnat că s-a adăugat un element în coada de transmisie a dispozitivului. Aceasta este reflectată în ultimele segmente 'calea urmării': TxQueue/Enqueue.

Celelalte secțiuni din urmărire ar trebui să fie destul de intuitive. Liniile 3-4 indică că pachetul este encapsulat în protocolul punct-punct. Liniile 5-7 arată că pachetul are un antet de versiune IP4 și a apărut la adresa IP 10.1.1.1 și este 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 așteptat să fie de 1024 byte.

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

A treia linie din fișierul de urmărire arată că pachetul a fost primit de dispozitivul de rețea pe nodul cu serverul de ecou. Am reprodus acest eveniment 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)

Vă rugăm să rețineți că operația de urmărire este acum r, iar timpul de simulare a fost crescut la 2,25732 secunde. Dacă ați urmat cu atenție instrucțiunile din manual, acesta înseamnă că ați lăsat DataRate pentru dispozitivele de rețea și latența canalului la valorile lor implicite. Acest timp ar trebui să vă fie familiar, deoarece l-ați văzut deja în secțiunea anterioară.

Înregistrarea spațiului de nume al sursei de urmărire (linia 2) a fost modificată pentru a reflecta că acest eveniment provine de la nodul 1 (/NodeList/1) и пакет принят источником трассировки (/MacRx). Ar trebui să vă fie destul de ușor să urmăriți mișcarea pachetului prin topologie, consultând urma rămasă în fișierul de urmărire.

5.3.2 Trasare PCAP

Asistenții de dispozitive ns-3 pot fi, de asemenea, utilizați pentru a crea fișiere de urmărire în format .pcap. Acronomul pcap (de obicei scris cu litere mici) se referă la captarea pachetelor și este practic un API care include definirea formatului fișierului .pcap. Cea mai populară aplicație care poate citi și afișa acest format este Wireshark (cunoscută anterior sub numele de Ethereal). Cu toate acestea, există multe analizatoare de urmărire a traficului care folosesc acest format de pachet. Recomandăm utilizatorilor să folosească o mulțime de instrumente disponibile pentru analizarea urmărilor pcap. În acest ghid ne vom concentra pe vizualizarea urmărilor pcap folosind tcpdump.

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

pointToPoint.EnablePcapAll ("myfirst");

Introduceți această linie de cod după codul de urmărire ASCII pe care l-am adăugat anterior în scratch/myfirst.cc. Rețineți că am transmis doar șirul „myfirst”, nu „myfirst.pcap” sau ceva asemănător. Acesta este deoarece parametrul este un prefix, nu un nume complet de fișier. În timpul simulării, asistentul va crea practic un fișier de urmărire pentru fiecare dispozitiv point-to-point. Numele fișierelor vor fi construite folosind prefixul, numărul nodului, numărul dispozitivului și sufixul „.pcap».

Pentru exemplul nostru de scenariu, în cele din urmă vom vedea fișiere cu numele „myfirst-0-0.pcap” și „myfirst-1-0.pcap”, care sunt urmărilor pcap pentru nodul 0-dispozitiv 0 și nodul 1-dispozitiv 0, respectiv. După ce ați adăugat linia de cod pentru activarea urmăririi pcap, puteți rula scriptul în mod obișnuit:

$ ./waf --run scratch/myfirst

Dacă verificați directorul de nivel superior al distribuției dvs., ar trebui să vedeți trei fișiere: fișierul de urmărire ASCII myfirst.tr, pe care l-am analizat anterior, fișiere myfirst-0-0.pcap și myfirst-1-0.pcap — fișierele pcap noi pe care le-am generat recent.

Citirea ieșirii cu tcpdump

În prezent, cea mai simplă modalitate de a vizualiza fișierele pcap este să folosiț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

În dump myfirst-0-0.pcap (dispozitivul client) puteți vedea că pachetul de echo este trimis după 2 secunde de simulare. Dacă vă uitați la al doilea dump (myfirst-1-0.pcap), veți observa că pachetul este primit în momentul 2,257324 secunde. Veți observa în al doilea dump că pachetul este returnat în momentul 2.257324 secunde și, în final, că pachetul a fost primit de client în primul dump în momentul 2.514648 secunde.

Citirea ieșirii cu Wireshark

Dacă nu sunteți familiarizat cu Wireshark, există un site web de unde puteți descărca programele și documentația: http://www.wireshark.org/. Wireshark — acesta este un interfață grafică de utilizator care poate fi folosită pentru a vizualiza aceste fișiere de trasare. Dacă aveți Wireshark, puteți deschide oricare dintre fișierele de trasare și vizualiza conținutul, ca și cum ați fi capturat pachetele folosind un analizor de pachete.

Sursa: habr.com