Tutorial sa ns-3 network simulator. Kabanata 5

kabanata 1,2
kabanata 3
kabanata 4

5 Mga Setting
5.1 Gamit ang logging module
5.1.1 Pangkalahatang-ideya sa pag-log
5.1.2 Paganahin ang pag-log
5.1.3 Pagdaragdag ng pag-log sa iyong code
5.2 Paggamit ng mga argumento ng command line
5.2.1 Ino-override ang mga default na value ng attribute
5.2.2 Pagkuha ng sarili mong mga utos
5.3 Gamit ang sistema ng pagsubaybay
5.3.1 Pagsubaybay sa ASCII
Pag-parse ng mga bakas ng ASCII
5.3.2 Trace ng PCAP

Kabanata 5

pag-aayos

5.1 Gamit ang logging module

Sa madaling sabi, tiningnan namin ang ns-3 logging module sa pamamagitan ng pagtingin sa script una.cc. Sa kabanatang ito, titingnan natin ang mga posibleng gamit para sa subsystem ng pag-log.

5.1.1 Pangkalahatang-ideya sa pag-log

Maraming malalaking sistema ang sumusuporta sa ilang uri ng pasilidad ng pag-log ng mensahe, at ang ns-3 ay walang pagbubukod. Sa ilang mga kaso, ang mga mensahe ng error lamang ang isinulat sa "operator console" (na karaniwang stderr sa mga sistemang nakabatay sa Unix). Sa ibang mga system, maaaring ipakita ang mga mensahe ng babala gayundin ang mas detalyadong impormasyon. Sa ilang mga kaso, ginagamit ang mga tool sa pag-log upang mag-output ng mga mensahe sa pag-debug na maaaring mabilis na lumabo ang output.

Ipinapalagay ng subHRD na ginamit sa ns-3 na ang lahat ng antas ng nilalaman ng impormasyon na ito ay kapaki-pakinabang, at nagbibigay kami ng isang pili, layered na diskarte sa pag-log ng mensahe. Maaaring ganap na hindi paganahin ang pag-log, paganahin sa bawat bahagi, o sa buong mundo. Para sa layuning ito, ginagamit ang mga adjustable na antas ng nilalaman ng impormasyon. Ang ns-3 logging module ay nagbibigay ng medyo simpleng paraan para makakuha ng kapaki-pakinabang na impormasyon mula sa iyong simulation.

Dapat mong maunawaan na nagbibigay kami ng mekanismo ng pangkalahatang layunin - pagsubaybay - para sa pagkuha ng data mula sa iyong mga modelo, na dapat ang ginustong output para sa mga simulation (para sa higit pang impormasyon sa aming sistema ng pagsubaybay, tingnan ang seksyon ng tutorial 5.3). Ang pag-log ay dapat ang gustong paraan para sa pagkuha ng impormasyon sa pag-debug, mga babala, mga mensahe ng error, o para sa mabilis na pag-output ng mga mensahe mula sa iyong mga script o modelo anumang oras.

Sa kasalukuyan, tinutukoy ng system ang pitong antas (mga uri) ng mga mensahe ng log sa pagtaas ng pagkakasunud-sunod ng nilalaman ng impormasyon.

• LOG_ERROR - pag-log ng mga mensahe ng error (kaugnay na macro: NS_LOG_ERROR);
• LOG_WARN - Mag-log ng mga mensahe ng babala (kaugnay na macro: NS_LOG_WARN);
• LOG_DEBUG - Mag-log ng medyo bihirang mga espesyal na debug na mensahe (kaugnay na macro: NS_LOG_DEBUG);
• LOG_INFO - pagpaparehistro ng mga mensahe ng impormasyon tungkol sa pag-unlad ng programa (kaugnay na macro: NS_LOG_INFO);
• LOG_FUNCTION - Nagla-log ng mga mensaheng naglalarawan sa bawat function na tinatawag (dalawang nauugnay na macro: NS_LOG_FUNCTION, ginagamit para sa mga function ng miyembro, at NS_LOG_FUNCTION_NOARGS, na ginagamit para sa mga static na function);
• LOG_LOGIC - pag-log ng mga mensahe na naglalarawan sa lohikal na daloy sa loob ng isang function (kaugnay na macro: NS_LOG_LOGIC);
• LOG_ALL - Nila-log ang lahat ng nabanggit sa itaas (walang nauugnay na macro).
  Para sa bawat uri (LOG_TYPE) mayroon ding LOG_LEVEL_TYPE na, kung gagamitin, pinapayagan ang lahat ng antas sa itaas nito na mai-log bilang karagdagan sa sarili nitong antas. (Bilang kinahinatnan, LOG_ERROR at LOG_LEVEL_ERROR, at LOG_ALL at LOG_LEVEL_ALL ay functionally equivalent.) Halimbawa, ang pagpapagana ng LOG_INFO ay magbibigay-daan lamang sa mga mensaheng ibinigay ng NS_LOG_INFO macro, habang ang pag-enable sa LOG_LEVEL_INFO ay magsasama rin ng mga mensaheng ibinigay ng macros ,WARSLOGER_DEBUGNS.

Nagbibigay din kami ng unconditional logging macro na palaging ipinapakita, anuman ang antas ng pag-log o ang bahagi ng pagpili.

• NS_LOG_UNCOND - Walang kondisyong pag-log ng nauugnay na mensahe (walang nauugnay na antas ng pag-log).

Ang bawat antas ay maaaring i-query nang paisa-isa o pinagsama-sama. Maaaring i-configure ang pag-log gamit ang sh environment variable na NS_LOG o sa pamamagitan ng pag-log ng system function call. Tulad ng ipinakita kanina, ang sistema ng pag-log ay may dokumentasyon ng Doxygen at ngayon ay isang magandang panahon upang suriin ito kung hindi mo pa nagagawa.

Ngayong nabasa mo na ang dokumentasyon nang detalyado, gamitin natin ang kaalamang iyon para makakuha ng ilang kawili-wiling impormasyon mula sa halimbawang script scratch/myfirst.ccna naipon mo na.

5.1.2 Paganahin ang pag-log

Gamitin natin ang NS_LOG environment variable para magpatakbo ng ilan pang log, ngunit una, para lang makuha ang iyong bearings, patakbuhin ang huling script gaya ng ginawa mo kanina,

$ ./waf --run scratch/myfirst

Dapat mong makita ang pamilyar na output mula sa unang ns-3 na halimbawang programa

$ 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

Lumalabas na ang mga "ipinadala" at "natanggap" na mga mensahe na nakikita mo sa itaas ay talagang mga naka-log na mensahe mula sa UdpEchoClientApplication и UdpEchoServerApplication. Halimbawa, maaari naming hilingin sa application ng kliyente na mag-print ng karagdagang impormasyon sa pamamagitan ng pagtatakda ng antas ng pag-log nito sa pamamagitan ng variable na kapaligiran ng NS_LOG.

Mula ngayon, ipagpalagay ko na gumagamit ka ng sh-like na shell na gumagamit ng "VARIABLE=value" syntax. Kung gumagamit ka ng tulad-csh na shell, kakailanganin mong i-convert ang aking mga halimbawa sa syntax na "setenv variable value" na kinakailangan ng mga shell na iyon.

Sa kasalukuyan, ang UDP echo client application ay tumutugon sa sumusunod na linya ng code sa scratch/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Pinapagana nito ang antas ng pag-log LOG_LEVEL_INFO. Kapag nagpasa kami ng flag sa antas ng pag-log, talagang pinapagana namin ang antas na iyon at ang lahat ng mas mababang antas. Sa kasong ito, pinagana namin ang NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN at NS_LOG_ERROR. Maaari naming taasan ang antas ng pag-log at makakuha ng higit pang impormasyon, nang walang mga pagbabago sa script at recompilation, sa pamamagitan ng pagtatakda ng NS_LOG environment variable bilang sumusunod:

$ export NS_LOG=UdpEchoClientApplication=level_all

Kaya itinakda namin ang sh shell variable na NS_LOG sa sumusunod na halaga,

UdpEchoClientApplication=level_all

Ang kaliwang bahagi ng pagtatalaga ay ang pangalan ng naka-log na bahagi na gusto naming i-configure, at ang kanang bahagi ay ang bandila na gusto naming ilapat para dito. Sa kasong ito, paganahin namin ang lahat ng antas ng pag-debug sa application. Kung patakbuhin mo ang script na may set ng NS_LOG sa ganitong paraan, tatanggapin ng ns-3 logging system ang mga pagbabago at dapat mong makita ang sumusunod na output:

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

Ang karagdagang impormasyon sa pag-debug na ibinigay ng application ay nasa antas na ng NS_LOG_FUNCTION. Ipinapakita nito ang bawat pagkakataon ng isang function na tawag sa panahon ng pagpapatupad ng script. Bilang isang pangkalahatang tuntunin, sa mga function ng pamamaraan ay mas mainam na gamitin (sa pinakamababa)NS_LOG_FUNCTION (this)... Gamitin NS_LOG_FUNCTION_NOARGS ()
lamang sa mga static na function. Gayunpaman, tandaan na ang ns-3 system ay hindi kinakailangan upang suportahan ang anumang pag-andar sa pag-log. Ang desisyon tungkol sa kung gaano karaming impormasyon ang naitala ay naiwan sa indibidwal na developer ng modelo. Sa kaso ng mga echo application, isang malaking halaga ng pag-log output ang magagamit.

Maaari mo na ngayong tingnan ang isang log ng mga function na tawag na ginawa ng application. Kung titingnan mong mabuti, mapapansin mo ang isang colon sa pagitan ng linya UdpEchoClientApplication at ang pangalan ng pamamaraan, kung saan maaari mong asahan na makita ang operator ng saklaw ng C++ (: :). Ito ay sinadya.

Hindi talaga ito ang pangalan ng klase, ngunit ang pangalan ng bahagi ng pag-log. Kapag may tugma sa pagitan ng isang source file at isang klase, kadalasan ito ang pangalan ng klase, ngunit dapat mong mapagtanto na hindi talaga ito ang pangalan ng klase, at mayroong isang colon sa halip na isang double colon. Ito ay isang paraan upang matulungan kang maisip na paghiwalayin ang pangalan ng logging bean mula sa pangalan ng klase sa medyo banayad na paraan.

Gayunpaman, sa ilang mga kaso maaaring mahirap matukoy kung aling paraan ang aktwal na bumubuo ng mensahe ng log. Kung titingnan mo ang teksto sa itaas, maaaring nagtataka ka kung saan ang linya "Received 1024 bytes from 10.1.1.2" Maaari mong lutasin ang problemang ito sa pamamagitan ng pagtatakda ng antas prefix_func sa NS_LOG environment variable. Subukan ang sumusunod:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Tandaan na ang mga panipi ay kinakailangan dahil ang vertical bar na ginagamit namin upang kumatawan sa operasyon ng OR ay isa ring Unix pipe connector. Ngayon kung patakbuhin mo ang script, makikita mo na tinitiyak ng sistema ng pag-log na ang bawat mensahe sa isang naibigay na log ay may prefix na pangalan ng bahagi.

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

Ngayon ay makikita mo na ang lahat ng mga mensahe na nagmumula sa UDP echo client application ay natukoy bilang ganoon. Mensahe"Received 1024 bytes from 10.1.1.2" ay malinaw na natukoy ngayon bilang nagmumula sa echo client application. Ang natitirang mensahe ay dapat magmula sa UDP echo server application. Maaari naming paganahin ang bahaging ito sa pamamagitan ng paglalagay ng listahan ng mga bahagi na pinaghihiwalay ng tutuldok sa NS_LOG environment variable.

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

Babala: Sa halimbawang teksto sa itaas, kakailanganin mong alisin ang bagong linya na character pagkatapos ng colon (:), ito ay ginagamit upang i-format ang dokumento. Ngayon kung patakbuhin mo ang script, makikita mo ang lahat ng mga mensahe ng log mula sa client at server echo application. Maaari mong makita na ito ay maaaring maging lubhang kapaki-pakinabang kapag nagde-debug.

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

Minsan kapaki-pakinabang din na makita ang simulation time kung kailan nabuo ang log message. Magagawa mo ito sa pamamagitan ng pagdaragdag ng OR bit prefix_time:

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

Muli, kakailanganin mong alisin ang bagong linyang karakter sa itaas. Kung pinapatakbo mo na ngayon ang script dapat mong makita ang sumusunod na output:

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

Mangyaring tandaan na ang constructor para sa UdpEchoServer ay tinawag sa simulation na 0 segundo. Ito ay aktwal na nangyayari bago magsimula ang simulation, ngunit ang oras ay ipinapakita bilang zero segundo. Ang parehong ay totoo para sa constructor mensahe 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()

Tandaan na ang script scratch/first.cc sinimulan ang echo server application isang segundo bago magsimula ang simulation. Ngayon ay makikita mo na ang pamamaraan StartApplication ang server ay talagang tinatawag sa unang segundo. Maaari mo ring mapansin na ang echo client ay magsisimula sa ikalawang segundo ng simulation, gaya ng hiniling namin sa script.

Maaari mo na ngayong sundin ang simulation progress on call ScheduleTransmit sa client na tumatawag sa HandleRead callback Ipadala sa echo server application. Tandaan na ang lumipas na oras upang magpadala ng packet sa isang point-to-point na link ay 3,69 milliseconds. Makikita mo na ang echo server ay nag-log ng isang mensahe na tumugon ito sa packet, at pagkatapos, pagkatapos ng pagkaantala ng channel, makikita mo na natatanggap ng echo client ang echo packet sa pamamaraang HandleRead nito.

Sa simulation na ito, maraming nangyayari nang hindi mo napapansin. Ngunit masusubaybayan mo ang buong proseso nang napakadali sa pamamagitan ng pagpapagana sa lahat ng bahagi ng pag-log sa system. Subukang itakda ang NS_LOG variable sa sumusunod na halaga,

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

Ang asterisk sa itaas ay isang wildcard na character para sa bahagi ng pag-log. Isasama nito ang lahat ng mga entry sa lahat ng sangkap na ginamit sa simulation. Hindi ko muling gagawin ang output dito (sa oras ng pagsulat ay gumagawa ito ng 1265 na linya ng output para sa isang solong echo packet), ngunit maaari mong i-redirect ang impormasyong ito sa isang file at tingnan ito sa iyong paboritong editor.

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

Personal kong ginagamit ang sobrang verbose na bersyon ng pag-log kapag mayroon akong problema at walang ideya kung saan nagkamali. Madali kong masusunod ang code execution nang hindi nagtatakda ng mga breakpoint at hakbang sa code sa debugger. Maaari ko lamang i-edit ang output sa aking paboritong editor at hanapin kung ano ang inaasahan ko at makita ang isang bagay na mangyayari na hindi ko inaasahan. Sa sandaling mayroon akong pangkalahatang ideya kung ano ang nangyayaring mali, tumalon ako sa debugger upang mag-drill down sa problema. Ang ganitong uri ng output ay maaaring maging kapaki-pakinabang lalo na kapag ang iyong script ay gumawa ng isang bagay na ganap na hindi inaasahan. Kung gagamitin mo lang ang debugger, maaari kang makaligtaan nang buo. Ang pagpaparehistro ay ginagawang kapansin-pansin ang gayong mga pagliko.

5.1.3 Pagdaragdag ng pag-log sa iyong code

Maaari kang magdagdag ng mga bagong entry sa iyong mga simulation sa pamamagitan ng pagtawag sa bahagi ng log mula sa maraming macro. Gawin natin ito sa isang script myfirst.cc, na mayroon kami sa "malinis" na direktoryo. Tandaan na tinukoy namin ang isang bahagi ng pag-log sa sitwasyong ito:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Alam mo na maaari mong paganahin ang pag-log ng lahat ng mga mensahe mula sa bahaging ito sa pamamagitan ng pagtatakda ng variable ng kapaligiran ng NS_LOG sa iba't ibang antas. Sige at magdagdag tayo ng ilang mga entry sa script. Ang macro na ginamit upang magdagdag ng mga mensahe sa antas ng impormasyon sa log ay NS_LOG_INFO. Magdagdag tayo ng mensahe (bago lang tayo magsimulang gumawa ng mga node) na nagsasabi sa iyo na ang script ay nasa yugto ng "Paglikha ng Topology." Ginagawa ito sa sumusunod na snippet ng code,
Buksan scratch/myfirst.cc sa iyong paboritong editor at idagdag ang linya,
NS_LOG_INFO ("Creating Topology");
bago ang mga linya,

NodeContainer nodes;
nodes.Create (2);

Ngayon i-compile ang script gamit ang waf, at i-clear ang NS_LOG variable upang hindi paganahin ang pag-log stream na pinagana namin kanina:

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

Hindi mo makikita ang bagong mensahe dahil hindi pinagana ang nauugnay na bahagi ng pag-log (FirstScriptExample). Upang makita ang iyong mensahe kailangan mong paganahin ang bahagi ng pag-log FirstScriptExample na may antas na hindi mas mababa sa NS_LOG_INFO. Kung gusto mo lang makita itong partikular na antas ng pag-log, maaari mo itong paganahin tulad nito,

$ export NS_LOG=FirstScriptExample=info

Kung patakbuhin mo ang script ngayon, makakakita ka ng bagong mensahe na "Paglikha ng Topology",

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 Paggamit ng mga argumento ng command line

5.2.1 Ino-override ang mga default na value ng attribute

Ang isa pang paraan upang baguhin ang pag-uugali ng mga script ng ns-3 nang walang pag-edit o pagbuo ay ang paggamit ng mga argumento ng command line. Nagbibigay kami ng mekanismo para i-parse ang mga argumento ng command line at awtomatikong magtakda ng mga lokal at pandaigdigang variable batay sa mga resulta.

Ang unang hakbang sa paggamit ng command line argument system ay ang magdeklara ng command line parser. Ito ay medyo madaling gawin (sa iyong pangunahing programa), tulad ng sa sumusunod na code,

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

Ang simpleng two-line snippet na ito ay talagang lubhang kapaki-pakinabang sa sarili nitong karapatan. Binubuksan nito ang pinto sa ns-3 global variable at attribute system. Magdagdag tayo ng dalawang linya ng code sa simula ng pangunahing function ng script scratch/myfirst.cc. Sa pagpapatuloy, kino-compile namin ang script at pinapatakbo ito, kapag tumatakbo kami ay humihiling ng tulong tulad ng sumusunod,

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

Itatanong ng utos na ito Waf patakbuhin ang script scratch/myfirst at ipasa ito ng argumento ng command line —PrintHelp. Ang mga panipi ay kinakailangan upang ipahiwatig kung aling programa ang inilaan para sa argumento. Makikita ng command line parser ang argumento —PrintHelp at ipapakita ang sagot,

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.

Ngayon tingnan natin ang opsyon —PrintAttributes. Nabanggit na namin ang ns-3 attribute system kapag pinag-aaralan ang first.cc script. Nakita namin ang mga sumusunod na linya ng code,

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

at sinabi nila iyon DataRate ay talagang isang katangian PointToPointNetDevice. Gamitin natin ang command line argument parser para tingnan ang mga katangian PointToPointNetDevice. Ang listahan ng tulong ay nagsasabi kung ano ang dapat naming ibigay TypeId. Ito ang pangalan ng klase kung saan nabibilang ang mga katangian ng interes. Sa aming kaso ito ay magiging ns3::PointToPointNetDevice. Patuloy tayong sumulong, pumasok,

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

Ipi-print ng system ang lahat ng katangian ng ganitong uri ng network device. Makikita mo na kabilang sa mga katangian sa listahan ay,

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

Ito ang default na halaga na gagamitin ng system kapag lumilikha ng object PointToPointNetDevice. I-override namin ang default na value na ito gamit ang parameter katangian в PointToPointHelper mas mataas. Gamitin natin ang mga default na halaga para sa mga point-to-point na device at channel. Para magawa ito, tatanggalin namin ang mga tawag SetDeviceAttribute и SetChannelAttribute ng myfirst.cc, na mayroon kami sa isang malinis na direktoryo.

Ang iyong script ay dapat na ngayong ipahayag PointToPointHelper at huwag magsagawa ng anumang mga operasyon sa pag-install tulad ng ipinapakita sa halimbawa sa ibaba,

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

Sige at gumawa ng bagong script gamit ang Waf (./waff) at bumalik tayo at isama ang ilang entry mula sa UDP echo server application at isama ang prefix ng oras.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Kung pinapatakbo mo ang script dapat mong makita ang sumusunod na output:

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

Alalahanin na sa huling pagkakataon na tiningnan namin ang simulation time, sa sandaling natanggap ang packet ng echo server, ito ay 2,00369 segundo.

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

Ngayon natatanggap niya ang packet sa loob ng 2.25732 segundo. Iyon ay dahil ni-reset lang namin ang PointToPointNetDevice data rate mula sa limang megabit bawat segundo patungo sa default na halaga, na 32768 bit bawat segundo. Kung papalitan namin ang isang bagong DataRate gamit ang command line, maaari naming pabilisin muli ang aming simulation. Gagawin namin ito bilang mga sumusunod, ayon sa formula na ipinahiwatig ng elemento ng tulong:

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

Ibabalik nito ang katangian ng DataRate sa default na halaga nito na limang megabit bawat segundo. Nagulat ka ba sa resulta? Lumalabas na upang maibalik ang orihinal na gawi ng script, kailangan din nating itakda ang pagkaantala ng channel upang tumugma sa bilis ng liwanag. Maaari naming hilingin sa command line system na i-print ang mga katangian ng channel, tulad ng ginawa namin para sa network device:

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

Malalaman namin na ang katangian ng pagkaantala ng channel ay nakatakda tulad ng sumusunod:

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

Maaari naming pagkatapos, sa pamamagitan ng command line system, itakda ang parehong mga default na halaga.

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

sa kasong ito, ibinabalik namin ang oras na mayroon kami noong tahasang itinakda namin ang DataRate at Delay sa 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()

Tandaan na ang packet ay natanggap muli ng server pagkatapos ng 2,00369 segundo. Maaari naming aktwal na itakda ang alinman sa mga katangian na ginamit sa script sa ganitong paraan. Sa partikular, maaari naming itakda ang mga katangian ng MaxPackets sa mga hindi isang halaga UdpEchoClient.

Paano mo ito gagamitin? Subukan. Tandaan na dapat kang magkomento sa lugar kung saan na-override namin ang default na value ng attribute at tahasang itinakda MaxPackets sa script. Pagkatapos ay kailangan mong muling buuin ang script. Maaari mo ring gamitin ang command line upang makakuha ng tulong sa syntax para sa pagtatakda ng bagong default na value ng attribute. Kapag naintindihan mo na ito, makokontrol mo ang bilang ng mga package na ipinapakita sa command line. Dahil kami ay mga taong masipag mag-aral, ang aming command line ay dapat magmukhang ganito:

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

Ang natural na tanong na lumitaw sa puntong ito ay kung paano malalaman ang tungkol sa pagkakaroon ng lahat ng mga katangiang ito. Muli, ang command line system ay may function ng tulong para sa bagay na ito. Kung humingi tayo ng tulong sa command line, dapat nating makita:

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

Kung pipiliin mo ang argumentong "PrintGroups" dapat mong makita ang isang listahan ng lahat ng nakarehistrong grupo TypeId. Ang mga pangalan ng grupo ay pare-pareho sa mga pangalan ng mga module sa pinagmulang direktoryo (kahit na naka-capitalize). Ang pagpi-print ng lahat ng impormasyon nang sabay-sabay ay magiging masyadong malaki, kaya ang isang karagdagang filter ay magagamit upang mag-print ng impormasyon ayon sa pangkat. Kaya, muling tumuon sa point-to-point na module:

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

Dito mahahanap mo ang mga available na pangalan ng TypeId para sa mga paghahanap ng katangian, halimbawa sa
--PrintAttributes = ns3 :: PointToPointChanneltulad ng ipinapakita sa itaas.

Ang isa pang paraan upang malaman ang tungkol sa mga katangian ay sa pamamagitan ng Doxygen ns‑3. Mayroong isang pahina na naglilista ng lahat ng mga katangiang nakarehistro sa simulator.

5.2.2 Pagkuha ng sarili mong mga utos

Maaari ka ring magdagdag ng iyong sariling mga kawit sa pamamagitan ng command line system. Ginagawa ito nang simple gamit ang command line parser method Magdagdag ng Halaga.
Gamitin natin ang feature na ito para tukuyin ang bilang ng mga package na ipapakita sa ibang paraan. Magdagdag tayo ng lokal na variable na tinatawag nPackets sa isang function pangunahin. Itatakda namin ito sa isa upang tumugma sa aming nakaraang default na gawi. Upang payagan ang command line parser na baguhin ang value na ito, kailangan nating makuha ang value na ito sa parser. Ginagawa namin ito sa pamamagitan ng pagdaragdag ng isang tawag Magdagdag ng Halaga. Pumunta at baguhin ang script scratch/myfirst.cc kaya para magsimula sa sumusunod na code,

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

Mag-scroll pababa sa punto sa script kung saan itinakda namin ang katangian ng MaxPackets at baguhin ito upang maitakda ito sa variable ng nPackets sa halip na ang pare-parehong 1, tulad ng ipinapakita sa ibaba.

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

Ngayon kung patakbuhin mo ang script at ibigay ang -PrintHelp argument, dapat mong makita ang bagong argumento ng user. nakalista sa display ng tulong. Pumasok,

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

Kung gusto mong baguhin ang bilang ng mga packet na ipinadala, magagawa mo ito sa pamamagitan ng pagtatakda ng command line argument - -nPackets.

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

Ngayon dapat mo na ngayong makita

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

Nagpadala ka na ngayon ng dalawang pakete. Medyo simple, hindi ba?
Maaari mong makita na bilang isang ns-3 user, maaari mong gamitin ang command line argument system upang manipulahin ang mga pandaigdigang halaga at katangian. Kung ikaw ang may-akda ng modelo, maaari kang magdagdag ng mga bagong katangian sa iyong mga bagay at awtomatiko silang magiging available para sa pagsasaayos ng iyong mga user sa pamamagitan ng command line system. Kung ikaw ay isang may-akda ng script, maaari kang magdagdag ng mga bagong variable sa iyong mga script at walang putol na isaksak ang mga ito sa iyong command line system.

5.3 Gamit ang sistema ng pagsubaybay

Ang buong punto ng pagmomodelo ay upang makabuo ng output para sa karagdagang pag-aaral, at ang ns-3 trace system ay ang pangunahing mekanismo para dito. Dahil ang ns-3 ay isang C++ program, ang karaniwang paraan ng pagbuo ng output mula sa isang C++ program ay maaaring gamitin:

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

Maaari ka ring gumamit ng module ng pag-log upang magdagdag ng kaunting istraktura sa iyong solusyon. Maraming kilalang problema na dulot ng diskarteng ito, at samakatuwid ay nagbigay kami ng pangkalahatang subsystem sa pagsubaybay sa kaganapan upang malutas ang mga problemang ito.

Ang mga pangunahing layunin ng ns-3 tracing system ay:

• Para sa mga pangunahing gawain, dapat pahintulutan ng sistema ng pagsubaybay ang user na bumuo ng isang karaniwang bakas para sa mga sikat na mapagkukunan at pumili ng mga bagay na bumubuo ng bakas;

• Ang mga intermediate na user ay dapat na ma-extend ang tracing system upang baguhin ang nabuong format ng output o magpasok ng mga bagong trace source, nang hindi binabago ang simulator core;

• Maaaring baguhin ng mga advanced na user ang simulator core upang magdagdag ng mga bagong trace source at sink. Ang sistema ng pagsubaybay sa ns-3 ay binuo sa mga prinsipyo ng mga independiyenteng mapagkukunan ng pagsubaybay at mga receiver, pati na rin ang isang pinag-isang mekanismo para sa pagkonekta ng mga mapagkukunan sa mga mamimili.

Ang ns-3 tracing system ay binuo sa mga prinsipyo ng independiyenteng pagsubaybay sa mga pinagmumulan at mga receiver, pati na rin ang isang pinag-isang mekanismo para sa pagkonekta ng mga mapagkukunan sa mga receiver. Ang mga trace source ay mga bagay na maaaring magpahiwatig ng mga kaganapang nagaganap sa simulation at magbigay ng access sa pinagbabatayan na data ng interes. Halimbawa, maaaring ipahiwatig ng isang trace source kung kailan nakatanggap ang isang network device ng isang packet at gawing available ang mga nilalaman ng packet sa mga interesadong trace receiver.

Ang mga pagsubaybay sa kanilang sarili ay walang silbi maliban kung sila ay "kaisa" sa ibang mga bahagi ng code na aktwal na gumagawa ng isang bagay na kapaki-pakinabang sa impormasyong ibinigay ng lababo. Ang mga tracer ay mga mamimili ng mga kaganapan at data na ibinigay ng mga pinagmumulan ng bakas. Halimbawa, maaari kang lumikha ng trace sink na (kapag nakakonekta sa trace source ng nakaraang halimbawa) i-print ang mga bahagi ng interes sa natanggap na packet.

Ang katwiran para sa tahasang paghihiwalay na ito ay upang payagan ang mga user na ikonekta ang mga bagong uri ng lababo sa mga kasalukuyang pinagmumulan ng bakas nang hindi kinakailangang i-edit at muling i-compile ang simulator core. Kaya sa halimbawa sa itaas, maaaring tukuyin ng user ang isang bagong tracer sa kanilang script at ikonekta ito sa isang umiiral nang trace source na tinukoy sa simulation core lamang sa pamamagitan ng pag-edit sa script ng user.

Sa tutorial na ito, susuriin namin ang ilan sa mga paunang natukoy na source at sink at ipapakita kung paano i-configure ang mga ito nang may pinakamababang pagsisikap sa bahagi ng user. Tingnan ang ns-3 Manual o how-to na mga seksyon para sa impormasyon sa advanced na configuration ng trace, kabilang ang pagpapalawak ng trace namespace at paglikha ng mga bagong trace source.

5.3.1 Pagsubaybay sa ASCII

Nagbibigay ang ns-3 ng helper functionality na nagbibigay ng mababang antas ng tracing system upang matulungan ka sa mga detalye kapag nagse-set up ng mga simpleng packet trace. Kung pinagana mo ang feature na ito, makikita mo ang output sa mga ASCII file. Para sa mga pamilyar sa ns-2 output, ang ganitong uri ng bakas ay katulad ng out.tr, na nabuo ng maraming mga script.

Bumaba tayo sa negosyo at magdagdag ng ilang resulta ng pagsubaybay sa ASCII sa aming script ng scratch/myfirst.cc. Bago ang tawag Simulator :: Run (), idagdag ang mga sumusunod na linya ng code:
AsciiTraceHelper ascii;

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

Tulad ng maraming iba pang ns-3 idiom, ang code na ito ay gumagamit ng helper object upang lumikha ng ASCII traces. Ang pangalawang linya ay naglalaman ng dalawang nested method na tawag. "Sa loob" na pamamaraan CreateFileStream() gumagamit ng anonymous na object idiom upang lumikha ng file stream object sa stack (nang walang pangalan ng object) at ipapasa ito sa tinatawag na method. Palalimin pa natin ito sa hinaharap, ngunit ang kailangan mo lang malaman sa puntong ito ay lumilikha ka ng object na kumakatawan sa isang file na tinatawag na myfirst.tr at ilipat ito sa ns-3. Ipinagkatiwala namin ang ns-3 na pangalagaan ang nilikhang bagay sa buong buhay nito, kung saan nalulutas nito ang mga problemang dulot ng hindi gaanong kilalang (sinasadya) na limitasyon na nauugnay sa mga konstruktor ng kopya ng object ng C++ na stream.

Panlabas na tawag EnableAsciiAll() nagsasabi sa assistant na gusto mong isama ang ASCII tracing sa iyong simulation para sa lahat ng point-to-point na koneksyon ng device at gusto mong (tinukoy) trace receiver na mag-record ng impormasyon sa paggalaw ng packet sa ASCII format.

Para sa mga pamilyar sa ns-2, ang mga sinusubaybayang kaganapan ay katumbas ng mga kilalang tracepoint na nagla-log ng mga kaganapang "+", "-", "d" at "r".
Ngayon ay maaari kang bumuo ng script at patakbuhin ito mula sa command line:

$ ./waf --run scratch/myfirst

Tulad ng maraming beses bago, makakakita ka ng ilang mensahe mula kay Waf, at pagkatapos ay "matagumpay na natapos ang 'build'" na may ilang mensahe mula sa tumatakbong programa.

Kapag tumatakbo, ang program ay lilikha ng isang file na pinangalanan myfirst.tr. Dahil sa likas na katangian ng trabaho Waf, bilang default ang file ay nilikha hindi sa lokal na direktoryo, ngunit sa nangungunang antas na direktoryo ng repositoryo. Kung gusto mong baguhin ang landas kung saan naka-save ang mga bakas, maaari mong gamitin ang parameter na Waf para tukuyin ito --cwd. Hindi pa namin ito nagawa, kaya para tingnan ang ASCII trace file myfirst.tr sa iyong paboritong editor, kakailanganin naming mag-navigate sa top-level na direktoryo ng aming repository.

Pag-parse ng mga bakas ng ASCII

Mayroong maraming impormasyon doon sa isang medyo siksik na anyo, ngunit ang unang bagay na kailangan mong mapansin ay ang file ay binubuo ng mga indibidwal na linya. Ito ay magiging malinaw na makikita kung palawakin mo ang window ng pagtingin nang mas malawak.

Ang bawat linya sa file ay tumutugma sa isang trace na kaganapan. Sa kasong ito, sinusubaybayan namin ang mga kaganapan sa transmission queue na nasa bawat point-to-point network device sa simulation. Ang transmission queue ay ang pila kung saan dapat dumaan ang bawat packet para sa isang point-to-point na link. Tandaan na ang bawat linya sa trace file ay nagsisimula sa isang character (at may puwang pagkatapos nito). Ang simbolo na ito ay magkakaroon ng sumusunod na kahulugan:

+: isang queuing operation ang naganap sa device queue;
-: may naganap na operasyon sa pagkuha ng elemento sa queue ng device;
d: nalaglag ang packet, kadalasan dahil puno ang pila;
r: Ang packet ay natanggap ng isang network device.

Tingnan natin ang unang linya sa trace file. Hatiin ko ito sa mga bahagi (na may mga indentasyon para sa kalinawan) at ang numero ng linya sa kaliwa:

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)

Ang unang seksyon ng pinahabang trace event na ito (linya 0) ay ang operasyon. Mayroon kaming simbolo na + dito, na tumutugma sa pagpapatakbo ng pagpila para sa paghahatid. Ang pangalawang seksyon (linya 1) ay ang simulation time, na ipinahayag sa mga segundo. Naaalala mo siguro ang tinanong namin UdpEchoClientApplication simulan ang pagpapadala ng mga packet sa loob ng dalawang segundo. Dito makikita natin ang kumpirmasyon na ito nga ay nangyayari.

Ang susunod na seksyon ng halimbawa ng trace (mula sa linya 2) ay nagpapakita kung aling trace source ang nakabuo ng kaganapang ito (nagsasaad ng namespace trace). Maaari mong isipin ang trace namespace tulad ng gagawin mo sa isang filesystem namespace. Ang ugat ng namespace ay NodeList. Ito ay tumutugma sa container na pinamamahalaan sa pangunahing ns-3 code. Naglalaman ito ng lahat ng mga node na nilikha sa script. Kung paanong ang isang file system ay maaaring magkaroon ng mga direktoryo sa ugat nito, NodeList maaari tayong magkaroon ng maraming node. Kaya ang linyang /NodeList/0 ay tumutukoy sa null node sa NodeList, na kadalasang iniisip natin bilang "node 0". Ang bawat node ay may listahan ng mga device na na-install. Ang listahang ito ay matatagpuan sa tabi ng namespace. Makikita mong nagmula ang trace event na ito DeviceList/0, na kung saan ay ang null device na naka-install sa node.

Susunod na substring, $ ns3 :: PointToPointNetDevice, nagsasabi kung aling device ang nasa posisyong zero: ang listahan ng device ng node zero. Alalahanin na ang + operation na natagpuan sa linya 0 ay nangangahulugan na ang isang elemento ay idinagdag sa transmit queue ng device. Ito ay makikita sa mga huling segment ng "track path": TxQueue/Enqueue.

Ang natitirang mga seksyon sa bakas ay dapat na medyo intuitive. Ang mga linya 3-4 ay nagpapahiwatig na ang packet ay naka-encapsulated sa isang point-to-point na protocol. Ipinapakita ng mga linya 5-7 na ang packet ay may IP4 version header at nagmula sa IP address 10.1.1.1 at inilaan para sa 10.1.1.2. Ipinapakita ng mga linya 8-9 na ang packet na ito ay may header ng UDP at sa wakas ang linya 10 ay nagpapakita na ang payload ay ang inaasahang 1024 byte.

Ang susunod na linya sa trace file ay nagpapakita na ang parehong packet ay nakuha mula sa transmission queue sa parehong node.

Ang ikatlong linya sa trace file ay nagpapakita na ang packet ay natanggap ng isang network device sa echo server host. Ni-reproduce ko ang kaganapan sa ibaba.

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)

Tandaan na ang trace operation ay r na ngayon at ang simulation time ay nadagdagan sa 2,25732 segundo. Kung maingat mong sinunod ang tutorial, nangangahulugan ito na iniwan mo ang DataRate at Link Delay ng mga network device sa kanilang mga default na halaga. Ang panahunan na ito ay dapat na pamilyar, tulad ng nakita mo sa nakaraang seksyon.

Ang bakas na source namespace entry (linya 2) ay binago upang ipakita na ang kaganapang ito ay nagmula sa node 1 (/NodeList/1) at ang packet ay natanggap ng trace source (/MacRx). Dapat ay medyo madali para sa iyo na sundan ang paggalaw ng packet sa topology sa pamamagitan ng pagtingin sa mga natitirang bakas sa file.

5.3.2 Trace ng PCAP

Ang ns-3 Device Helpers ay maaari ding gamitin upang lumikha ng mga trace file sa .pcap na format. Acronym pcap (karaniwang nakasulat sa lowercase) ay kumakatawan sa packet capture at isa talaga itong API na kinabibilangan ng pagtukoy sa .pcap file format. Ang pinakasikat na programa na maaaring basahin at ipakita ang format na ito ay Wireshark (tinatawag dati Ethereal). Gayunpaman, maraming traffic trace analyzer na gumagamit ng packet format na ito. Hinihikayat namin ang mga user na gamitin ang maraming tool na magagamit upang pag-aralan ang mga bakas ng pcap. Sa tutorial na ito kami ay tumutuon sa pagtingin sa pcap traces gamit tcpdump.

Ang pagpapagana ng pcap tracing ay ginagawa gamit ang isang linya ng code.

pointToPoint.EnablePcapAll ("myfirst");

I-paste ang linyang ito ng code pagkatapos ng ASCII trace code na idinagdag namin scratch/myfirst.cc. Tandaan na ipinasa lang namin ang string na "myfirst", hindi "myfirst.pcap" o anumang katulad. Ito ay dahil ang parameter ay isang prefix, hindi isang buong filename. Sa panahon ng simulation, gagawa ang assistant ng isang trace file para sa bawat point-to-point na device. Ang mga pangalan ng file ay gagawin gamit ang prefix, node number, device number, at suffix ".pcap'.

Para sa aming halimbawang script, makikita namin ang mga file na pinangalanang "myfirst-0-0.pcap"At"myfirst-1-0.pcap", na mga pcap trace para sa node 0-device 0 at node 1-device 0 ayon sa pagkakabanggit. Kapag naidagdag mo na ang linya ng code upang paganahin ang pcap tracing, maaari mong patakbuhin ang script sa karaniwang paraan:

$ ./waf --run scratch/myfirst

Kung titingnan mo ang nangungunang antas na direktoryo ng iyong pamamahagi, dapat mong makita ang tatlong file: isang ASCII trace file myfirst.tr, na dati naming pinag-aralan, mga file myfirst-0-0.pcap и myfirst-1-0.pcap - mga bagong pcap file na kakagawa lang namin.

Binabasa ang output gamit ang tcpdump

Sa ngayon, ang pinakamadaling paraan upang tingnan ang mga pcap file ay ang paggamit ng 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

Sa tambakan myfirst-0-0.pcap (client device) makikita mo ang echo packet na ipinadala pagkatapos ng 2 segundo ng simulation. Kung titingnan mo ang pangalawang dump (myfirst-1-0.pcap), makikita mo na ang packet ay natanggap sa 2,257324 segundo. Makikita mo sa pangalawang dump na ang packet ay ibinalik sa 2.257324 segundo, at sa wakas na ang packet ay natanggap muli ng kliyente sa unang dump sa 2.514648 segundo.

Pagbasa ng Output gamit ang Wireshark

Kung hindi ka pamilyar sa Wireshark, mayroong isang website kung saan maaari kang mag-download ng mga programa at dokumentasyon: http://www.wireshark.org/. Wireshark ay isang GUI na maaaring magamit upang ipakita ang mga trace file na ito. Kung mayroon kang Wireshark, maaari mong buksan ang alinman sa mga trace file at ipakita ang mga nilalaman na parang nakuha mo ang mga packet gamit ang isang packet sniffer.

Pinagmulan: www.habr.com