ns-3 netwurk simulator tutorial. Haadstik 5

haadstik 1,2
haadstik 3
haadstik 4

5 Ynstelling
5.1 It brûken fan de logmodule
5.1.1 Logging oersjoch
5.1.2 Logging ynskeakelje
5.1.3 Logging tafoegje oan jo koade
5.2 It brûken fan kommandorigelarguminten
5.2.1 Oerskriuwe standert attribút wearden
5.2.2 It fêstlizzen fan jo eigen kommando's
5.3 It tracingsysteem brûke
5.3.1 ASCII Tracing
ASCII-spoaren analysearje
5.3.2 PCAP Trace

Haadstik 5

oanpassing

5.1 It brûken fan de logmodule

Wy hawwe al koart sjoen nei de ns-3 logging module troch te sjen nei it skript earst.cc. Yn dit haadstik sille wy in tichterby besjen op mooglike gebrûk foar it logging subsysteem.

5.1.1 Logging oersjoch

In protte grutte systemen stypje in soarte fan berjocht logging foarsjenning, en ns-3 is gjin útsûndering. Yn guon gefallen wurde allinnich flater berjochten skreaun nei de "operator console" (dat is meastal stderr op Unix-basearre systemen). Op oare systemen kinne warskôgingsberjochten werjûn wurde en ek mear detaillearre ynformaasje. Yn guon gefallen wurde logging-ark brûkt om debug-berjochten út te fieren dy't de útfier fluch kinne ferwiderje.

De subHRD brûkt yn ns-3 giet derfan út dat al dizze nivo's fan ynformaasje ynhâld nuttich binne, en wy jouwe in selektive, layered oanpak foar berjocht logging. Logging kin folslein útskeakele wurde, ynskeakele op in per-komponint basis, of globaal. Foar dit doel wurde ferstelbere nivo's fan ynformaasjeynhâld brûkt. De ns-3-loggingmodule biedt in relatyf ienfâldige manier om nuttige ynformaasje te krijen fan jo simulaasje.

Jo moatte begripe dat wy in meganisme foar algemien doel leverje - tracing - foar it ekstrahearjen fan gegevens fan jo modellen, wat de foarkommende útfier moat wêze foar simulaasjes (foar mear ynformaasje oer ús tracingsysteem, sjoch tutorial seksje 5.3). Logging moat de foarkommende metoade wêze foar it krijen fan debuggenynformaasje, warskôgingen, flaterberjochten, of foar it fluch útfieren fan berjochten fan jo skripts of modellen op elk momint.

Op it stuit definiearret it systeem sân nivo's (soarten) logberjochten yn tanimmende folchoarder fan ynformaasjeynhâld.

• LOG_ERROR - logging flater berjochten (relatearre makro: NS_LOG_ERROR);
• LOG_WARN - Log warskôgingsberjochten (relatearre makro: NS_LOG_WARN);
• LOG_DEBUG - Log relatyf seldsume spesjale debug-berjochten (relatearre makro: NS_LOG_DEBUG);
• LOG_INFO - registraasje fan ynformaasjeberjochten oer de fuortgong fan it programma (relatearre makro: NS_LOG_INFO);
• LOG_FUNCTION - Logs berjochten beskriuwe elke funksje neamd (twa relatearre makros: NS_LOG_FUNCTION, brûkt foar lidfunksjes, en NS_LOG_FUNCTION_NOARGS, brûkt foar statyske funksjes);
• LOG_LOGIC - logging berjochten beskriuwe de logyske stream binnen in funksje (relatearre makro: NS_LOG_LOGIC);
• LOG_ALL - Logt alles hjirboppe neamd (gjin assosjearre makro).
  Foar elk type (LOG_TYPE) is d'r ek in LOG_LEVEL_TYPE wêrmei't, as brûkt, alle nivo's dêrboppe njonken syn eigen nivo kinne wurde oanmeld. (As konsekwinsje binne LOG_ERROR en LOG_LEVEL_ERROR, en LOG_ALL en LOG_LEVEL_ALL funksjoneel lykweardich.) Bygelyks, it ynskeakeljen fan LOG_INFO sil allinich berjochten tastean dy't troch de NS_LOG_INFO makro levere wurde, wylst it ynskeakeljen fan LOG_LEVEL_INFO ek berjochten befetsje dy't troch de makro's LOG_DE_LOGRNS, LOG_DE_LOGRNS_, LOGR_DE_ NS_ en

Wy jouwe ek in betingstleaze logging makro dy't altyd werjûn wurdt, nettsjinsteande it logging nivo of de seleksje komponint.

• NS_LOG_UNCOND - Betingstleaze logging fan it assosjearre berjocht (gjin assosjearre loggingnivo).

Elk nivo kin yndividueel as kumulatyf oanfrege wurde. Logging kin wurde konfigurearre mei help fan de sh omjouwingsfariabele NS_LOG of troch te loggen in systeem funksje oprop. Lykas earder toand, hat it logsysteem Doxygen-dokumintaasje en no is it in goede tiid om it te besjen as jo dat net al hawwe.

No't jo de dokumintaasje yn grutte detail hawwe lêzen, litte wy dy kennis brûke om wat nijsgjirrige ynformaasje te krijen fan it foarbyldskript scratch/myfirst.ccdy't jo al gearstald hawwe.

5.1.2 Logging ynskeakelje

Litte wy de NS_LOG omjouwingsfariabele brûke om wat mear logs út te fieren, mar earst, gewoan om jo lagers te krijen, útfiere it lêste skript lykas jo earder dien hawwe,

$ ./waf --run scratch/myfirst

Jo moatte de bekende útfier sjen fan it earste ns-3 foarbyldprogramma

$ 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

It docht bliken dat de "ferstjoerde" en "ûntfongen" berjochten dy't jo hjirboppe sjogge, feitlik ynlogde berjochten binne fan UdpEchoClientApplication и UdpEchoServerApplication. Wy kinne bygelyks de kliïntapplikaasje freegje om oanfoljende ynformaasje te printsjen troch it oanmeldnivo yn te stellen fia de omjouwingsfariabele NS_LOG.

Fan no ôf gean ik der fan út dat jo in sh-like shell brûke dy't de syntaksis "VARIABLE = wearde" brûkt. As jo ​​​​in csh-like shell brûke, dan moatte jo myn foarbylden konvertearje nei de "setenv fariabele wearde" syntaksis dy't nedich is troch dy shells.

Op it stuit reageart de UDP echo-kliïntapplikaasje op de folgjende rigel fan koade yn scratch/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

It makket it lognivo LOG_LEVEL_INFO mooglik. As wy in flagge foar loggingnivo passe, skeakelje wy dat nivo en alle legere nivo's eins yn. Yn dit gefal hawwe wy NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN en NS_LOG_ERROR ynskeakele. Wy kinne it lognivo ferheegje en mear ynformaasje krije, sûnder skriptwizigingen en opnij kompilaasje, troch de NS_LOG omjouwingsfariabele as folget yn te stellen:

$ export NS_LOG=UdpEchoClientApplication=level_all

Sa sette wy de sh shell fariabele NS_LOG op de folgjende wearde,

UdpEchoClientApplication=level_all

De linkerkant fan 'e opdracht is de namme fan' e oanmelde komponint dy't wy wolle konfigurearje, en de rjochterkant is de flagge dy't wy dêrfoar tapasse wolle. Yn dit gefal sille wy alle nivo's fan debuggen yn 'e applikaasje ynskeakelje. As jo ​​​​it skript útfiere mei NS_LOG ynsteld op dizze manier, sil it ns-3-loggingsysteem de wizigingen akseptearje en jo moatte de folgjende útfier sjen:

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

Oanfoljende debuggen ynformaasje levere troch de applikaasje is no op it NS_LOG_FUNCTION nivo. It toant elke eksimplaar fan in funksje-oanrop by it útfieren fan skript. As algemiene regel, yn metoadefunksjes is it de foarkar te brûken (op syn minst)NS_LOG_FUNCTION (this)... Brûke NS_LOG_FUNCTION_NOARGS ()
allinnich yn statyske funksjes. Tink derom dat it ns-3-systeem net fereaske is om loggingfunksjonaliteit te stypjen. It beslút oer hoefolle ynformaasje wurdt opnommen wurdt oerlitten oan de yndividuele modelûntwikkelder. Yn it gefal fan echo-applikaasjes is in grutte hoemannichte loggingútfier beskikber.

Jo kinne no in log sjen fan funksje-oanroppen dy't makke binne troch de applikaasje. As jo ​​goed sjogge, sille jo in kolon tusken de line fernimme UdpEchoClientApplication en de namme fan 'e metoade, wêr't jo kinne ferwachtsje om de C ++ scope-operator te sjen (: :). Dit is opsetlik.

Dit is eins net de namme fan 'e klasse, mar de namme fan 'e logging-komponint. As der in wedstriid tusken in boarne triem en in klasse, it is meastal de namme fan 'e klasse, mar jo moatte realisearje dat it is net eins de namme fan 'e klasse, en der is in inkele kolon ynstee fan in dûbele kolon. Dit is in manier om jo te helpen de logging beannamme konseptueel te skieden fan 'e klassenamme op in relatyf subtile manier.

Yn guon gefallen kin it lykwols lestich wêze om te bepalen hokker metoade it logberjocht eins genereart. As jo ​​​​nei de tekst hjirboppe sjogge, freegje jo jo miskien ôf wêr't de line "Received 1024 bytes from 10.1.1.2" Jo kinne dit probleem oplosse troch it nivo yn te stellen prefix_func nei de NS_LOG omjouwingsfariabele. Besykje it folgjende:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Tink derom dat de oanhalingstekens nedich binne om't de fertikale balke dy't wy brûke om de OR-operaasje te fertsjintwurdigjen ek in Unix-pipe-ferbining is. As jo ​​​​no it skript útfiere, sille jo sjen dat it logsysteem derfoar soarget dat elk berjocht yn in opjûne log foarôfgeand is mei de komponintnamme.

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

No kinne jo sjen dat alle berjochten dy't komme fan 'e UDP echo client applikaasje wurde identifisearre as sadanich. Berjocht "Received 1024 bytes from 10.1.1.2" is no dúdlik identifisearre as komt fan 'e echo-kliïntapplikaasje. It oerbleaune berjocht moat komme fan 'e UDP-echo-tsjinnerapplikaasje. Wy kinne ynskeakelje dizze komponint troch it ynfieren fan in kolon-skieden list fan komponinten yn de NS_LOG omjouwingsfariabele.

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

Warskôging: Yn it foarbyldtekst hjirboppe moatte jo it nijeline-karakter fuortsmite nei de kolon (:), it wurdt brûkt om it dokumint op te meitsjen. No as jo it skript útfiere, sille jo alle logberjochten sjen fan 'e client- en server-echo-applikaasjes. Jo kinne sjen dat dit heul nuttich kin wêze by it debuggen.

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

It is ek soms nuttich om de simulaasjetiid te sjen wêrop it logberjocht is oanmakke. Jo kinne dit dwaan troch it tafoegjen fan it OR-bit prefix_time:

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

Nochris moatte jo it boppesteande nije line-karakter fuortsmite. As jo ​​​​no it skript útfiere, moatte jo de folgjende útfier sjen:

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

Tink derom dat de constructor foar UdpEchoServer waard neamd tidens simulaasje 0 sekonden. Dit bart eins foardat de simulaasje begjint, mar de tiid wurdt werjûn as nul sekonden. Itselde jildt foar it konstruktorberjocht 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()

Unthâld dat it skript scratch/first.cc begon de echo-serverapplikaasje ien sekonde foar it begjin fan 'e simulaasje. No kinne jo sjen dat de metoade StartApplikaasje de tsjinner wurdt eins neamd yn de earste sekonde. Jo kinne ek merke dat de echo-kliïnt yn 'e twadde sekonde fan' e simulaasje begjint, lykas wy yn it skript fregen.

Jo kinne no de simulaasje foarútgong folgje op oprop ScheduleTransmit yn 'e kliïnt dy't de HandleRead-oprop ropt Stjoer yn 'e echo-tsjinnerapplikaasje. Tink derom dat de ferrine tiid om in pakket oer in punt-nei-punt-keppeling te ferstjoeren 3,69 millisekonden is. Jo kinne sjen dat de echo-tsjinner in berjocht oanmelde dat it hat reagearre op it pakket, en dan, nei in kanaalfertraging, sjogge jo dat de echo-kliïnt it echo-pakket ûntfangt yn syn HandleRead-metoade.

Yn dizze simulaasje bart der in protte sûnder dat jo it merken. Mar jo kinne it heule proses heul maklik folgje troch alle loggingkomponinten yn it systeem yn te skeakeljen. Besykje de NS_LOG fariabele yn te stellen op de folgjende wearde,

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

De asterisk hjirboppe is in jokerteken foar de logging-komponint. Dit sil alle yngongen omfetsje yn alle komponinten dy't brûkt wurde yn 'e simulaasje. Ik sil de útfier hjir net reprodusearje (op it stuit fan it skriuwen produsearret it 1265 rigels fan útfier foar ien echopakket), mar jo kinne dizze ynformaasje omliede nei in bestân en it besjen yn jo favorite bewurker.

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

Ik persoanlik brûk dizze ekstreem verbose ferzje fan logging as ik haw in probleem en haw gjin idee wêr't dingen gie mis. Ik kin de koade-útfiering frij maklik folgje sûnder brekpunten yn te stellen en troch de koade yn 'e debugger te stappen. Ik kin de útfier gewoan bewurkje yn myn favorite bewurker en sykje nei wat ik ferwachtsje en sjoch wat barre dat ik net ferwachte. Sadree't ik in algemien idee haw fan wat der mis giet, spring ik yn 'e debugger om yn it probleem te boarjen. Dit soarte fan útfier kin benammen nuttich wêze as jo skript wat folslein ûnferwacht docht. As jo ​​​​allinich de debugger brûke, kinne jo miskien in twist folslein misse. Registraasje makket sokke bochten opfallend.

5.1.3 Logging tafoegje oan jo koade

Jo kinne nije yngongen tafoegje oan jo simulaasjes troch oproppen te meitsjen nei it logkomponint fan meardere makro's. Litte wy it dwaan yn in skript myfirst.cc, dy't wy hawwe yn 'e "skjinne" map. Tink derom dat wy in loggingkomponint definieare yn dit senario:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Jo binne bewust dat jo it loggen fan alle berjochten fan dizze komponint ynskeakelje kinne troch de NS_LOG-omjouwingsfariabele op ferskate nivo's yn te stellen. Litte wy fierder gean en wat ynstjoerings tafoegje oan it skript. De makro dy't brûkt wurdt om ynformaasjenivo-berjochten ta te foegjen oan it log is NS_LOG_INFO. Litte wy in berjocht tafoegje (krekt foardat wy begjinne mei it meitsjen fan knopen) dat jo fertelt dat it skript yn 'e faze "Topology oanmeitsje" is. Dit wurdt dien yn it folgjende koadefragment,
Iepenje op scratch/myfirst.cc yn jo favorite bewurker en foegje de rigel ta,
NS_LOG_INFO ("Creating Topology");
rjocht foar de rigels,

NodeContainer nodes;
nodes.Create (2);

No kompilearje it skript mei waf, en wiskje de NS_LOG fariabele om de loggingstream út te skeakeljen dy't wy earder ynskeakele hawwe:

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

Jo sille it nije berjocht net sjen, om't de byhearrende logging-komponint (FirstScriptExample) net ynskeakele is. Om jo berjocht te sjen moatte jo de loggingkomponint ynskeakelje Foarbyld fan FirstScript mei in nivo net leger as NS_LOG_INFO. As jo ​​​​gewoan dit spesifike loggingnivo wolle sjen, kinne jo it sa ynskeakelje,

$ export NS_LOG=FirstScriptExample=info

As jo ​​​​it skript no útfiere, sille jo in nij berjocht sjen "Topology oanmeitsje",

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 It brûken fan kommandorigelarguminten

5.2.1 Oerskriuwe standert attribút wearden

In oare manier om it gedrach fan ns-3-skripts te feroarjen sûnder te bewurkjen of te bouwen is it brûken fan kommandorigelarguminten. Wy jouwe in meganisme foar it parsearjen fan kommandorigelarguminten en automatysk lokale en globale fariabelen yn te stellen op basis fan de resultaten.

De earste stap yn it brûken fan it kommando-rigel-argumintsysteem is om in kommandorigelparser te ferklearjen. Dit is frij maklik te dwaan (yn jo haadprogramma), lykas yn 'e folgjende koade,

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

Dit ienfâldige twa-line snippet is eins heul nuttich op himsels. It iepenet de doar nei it ns-3 globale fariabele en attribútsysteem. Litte wy twa rigels koade tafoegje oan it begjin fan 'e haadskriptfunksje scratch/myfirst.cc. Trochgean, kompilearje wy it skript en rinne it út, by it útfieren meitsje wy in helpfersyk as folget,

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

Dit kommando sil freegje Waf run skript scratch / myn earste en jou it in kommandorigelargumint troch - PrintHelp. De oanhalingstekens binne nedich om oan te jaan foar hokker programma it argumint bedoeld is. De kommandorigelparser sil it argumint ûntdekke - PrintHelp en sil it antwurd sjen litte,

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.

Litte wy no nei de opsje sjen - PrintAttributes. Wy hawwe it ns-3 attribútsysteem al neamd by it bestudearjen fan it first.cc-skript. Wy hawwe de folgjende rigels koade sjoen,

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

en dat seine se DataRate is eins in attribút PointToPointNetDevice. Litte wy de kommandorigelargumintparser brûke om de attributen te besjen PointToPointNetDevice. De helplist seit wat wy moatte leverje TypeId. Dit is de namme fan 'e klasse dêr't de attributen fan belang by hearre. Yn ús gefal sil it wêze ns3 :: PointToPointNetDevice. Lit ús trochgean foarút, gean yn,

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

It systeem sil alle attributen fan dit type netwurkapparaat printsje. Jo sille sjen dat ûnder de attributen yn 'e list binne,

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

Dit is de standertwearde dy't brûkt wurdt troch it systeem by it meitsjen fan it objekt PointToPointNetDevice. Wy sille dizze standertwearde oerskriuwe mei de parameter attributen в PointToPointHelper heger. Litte wy de standertwearden brûke foar punt-tot-punt-apparaten en kanalen. Om dit te dwaan, sille wy oproppen wiskje SetDeviceAttribute и SetChannelAttribute fan myfirst.cc, dy't wy hawwe yn in skjinne map.

Jo skript moat no gewoan ferklearje PointToPointHelper en net útfiere gjin ynstallaasje operaasjes lykas werjûn yn it foarbyld hjirûnder,

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

Gean fierder en meitsje in nij skript mei Waf (./waff) en litte wy weromgean en wat yngong opnimme fan 'e UDP-echo-serverapplikaasje en it tiidfoarheaksel opnimme.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

As jo ​​​​it skript útfiere, moatte jo de folgjende útfier sjen:

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

Tink derom dat de lêste kear dat wy nei de simulaasjetiid seagen, it momint dat it pakket waard ûntfongen troch de echo-tsjinner, wie it 2,00369 sekonden.

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

No krijt hy it pakket yn 2.25732 sekonden. Dit is om't wy de PointToPointNetDevice-gegevensrate gewoan weromsette fan fiif megabits per sekonde nei de standertwearde, dy't 32768 bits per sekonde is. As wy in nije DataRate soene ferfange mei de kommandorigel, koene wy ​​ús simulaasje wer fersnelle. Wy sille dit dwaan as folget, neffens de formule ymplisearre troch it help-elemint:

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

Dit sil it DataRate-attribút werombringe nei syn standertwearde fan fiif megabits per sekonde. Binne jo ferrast troch it resultaat? It docht bliken dat om it orizjinele gedrach fan it skript werom te jaan, moatte wy ek de kanaalfertraging ynstelle om de snelheid fan ljocht te passen. Wy kinne it kommandorigelsysteem freegje om de kanaalattributen te printsjen, krekt lykas wy diene foar it netwurkapparaat:

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

Wy sille fine dat it kanaal fertraging attribút is ynsteld as folget:

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

Wy kinne dan, fia it kommandorigelsysteem, beide standertwearden ynstelle.

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

yn dit gefal restaurearje wy de tiid dy't wy hiene doe't wy de DataRate en Delay eksplisyt yn it skript ynstelle:

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

Tink derom dat it pakket nei 2,00369 sekonden opnij wurdt ûntfongen troch de tsjinner. Wy koene eins ien fan 'e attributen yn it skript op dizze manier ynstelle. Yn it bysûnder kinne wy ​​​​de MaxPackets-attributen ynstelle op net-ien wearden UdpEchoClient.

Hoe soene jo it brûke? Besykje it. Unthâld dat jo moatte kommentaar út it plak dêr't wy oerskriuwe de standert attribút wearde en eksplisyt ynsteld MaxPackets yn it skript. Dan moatte jo it skript opnij opbouwe. Jo kinne ek de kommandorigel brûke om syntaksishelp te krijen foar it ynstellen fan in nije standert attribútwearde. Sadree't jo dit begripe, kinne jo it oantal pakketten kontrolearje op 'e kommandorigel. Om't wy learsume minsken binne, soe ús kommandorigel der sa útsjen moatte:

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

De natuerlike fraach dy't op dit punt ûntstiet is hoe te witten oer it bestean fan al dizze attributen. Nochris hat it kommandorigelsysteem in helpfunksje foar dizze saak. As wy de kommandorigel om help freegje, moatte wy sjen:

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

As jo ​​it argumint "PrintGroups" selektearje moatte jo in list sjen fan alle registrearre groepen TypeId. De groepsnammen binne konsistint mei de nammen fan 'e modules yn' e boarnemap (al is it mei haadletter). It printsjen fan alle ynformaasje yn ien kear soe te voluminous wêze, dus in ekstra filter is beskikber om ynformaasje per groep te printsjen. Dat, wer rjochte op de punt-tot-punt module:

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

Hjir kinne jo beskikbere TypeId-nammen fine foar attribútsykjen, bygelyks yn
--PrintAttributes = ns3 :: PointToPointChannellykas hjirboppe werjûn.

In oare manier om te learen oer attributen is fia Doxygen ns-3. D'r is in side dy't alle attributen listet registrearre yn 'e simulator.

5.2.2 It fêstlizzen fan jo eigen kommando's

Jo kinne ek jo eigen heakjes tafoegje fia it kommandorigelsysteem. Dit wurdt gewoan dien mei de kommandorigelparsermetoade AddWearde.
Litte wy dizze funksje brûke om it oantal pakketten op in folslein oare manier te werjaan. Lit ús tafoegje in lokale fariabele neamd nPackets yn in funksje main. Wy sille it op ien ynstelle om oerien te kommen mei ús foarige standertgedrach. Om de kommandorigelparser dizze wearde te feroarjen, moatte wy dizze wearde yn 'e parser fêstlizze. Wy dogge dit troch in oprop ta te foegjen AddWearde. Gean en feroarje it skript scratch/myfirst.cc dus om te begjinnen mei de folgjende koade,

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

Rôlje omleech nei it punt yn it skript wêr't wy it MaxPackets-attribút ynstelle en it feroarje sadat it ynsteld is op 'e nPackets-fariabele ynstee fan 'e konstante 1, lykas hjirûnder werjûn.

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

As jo ​​​​no it skript útfiere en it argumint -PrintHelp leverje, moatte jo it nije brûkersargumint sjen. fermeld op de help werjefte. Yngean,

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

As jo ​​​​it oantal ferstjoerde pakketten wizigje wolle, kinne jo dat dwaan troch it kommandorigelargumint yn te stellen - -nPackets.

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

No moatte jo no sjen

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

Jo hawwe no twa pakketten stjoerd. Hiel ienfâldich, is it net?
Jo kinne sjen dat jo as ns-3-brûker it argumintsysteem foar kommandorigel kinne brûke om globale wearden en attributen te manipulearjen. As jo ​​​​de modelskriuwer binne, kinne jo nije attributen tafoegje oan jo objekten en se sille automatysk beskikber wêze foar konfiguraasje troch jo brûkers fia it kommandorigelsysteem. As jo ​​​​in skriptskriuwer binne, kinne jo nije fariabelen tafoegje oan jo skripts en se naadloos yn jo kommandorigelsysteem plugje.

5.3 It tracingsysteem brûke

It hiele punt fan modellering is om útfier te generearjen foar fierdere stúdzje, en it ns-3-tracesysteem is it haadmeganisme foar dit. Sûnt ns-3 in C++-programma is, kinne standertmiddels foar it generearjen fan útfier fan in C++-programma brûkt wurde:

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

Jo kinne sels in logmodule brûke om in bytsje struktuer ta te foegjen oan jo oplossing. D'r binne in protte bekende problemen feroarsake troch dizze oanpak, en dêrom hawwe wy in algemien subsysteem foar tracing fan eveneminten levere om dizze problemen op te lossen.

De haaddoelen fan it ns-3 tracingsysteem binne:

• Foar basistaken moat it tracingsysteem de brûker in standert trace generearje foar populêre boarnen en objekten selektearje dy't it trace generearje;

• Intermediate brûkers moatte it tracingsysteem kinne útwreidzje om it generearre útfierformaat te feroarjen of nije spoarboarnen yn te foegjen, sûnder de simulatorkearn te feroarjen;

• Avansearre brûkers kinne de simulatorkearn wizigje om nije spoarboarnen en sinken ta te foegjen. It ns-3-tracingsysteem is boud op 'e prinsipes fan ûnôfhinklike trackingboarnen en ûntfangers, lykas ek in ferienige meganisme foar it ferbinen fan boarnen oan konsuminten.

It ns-3-tracingsysteem is boud op 'e prinsipes fan ûnôfhinklike tracingboarnen en ûntfangers, lykas ek in ferienige meganisme foar it ferbinen fan boarnen oan ûntfangers. Spoarboarnen binne objekten dy't eveneminten kinne sinjalearje dy't foarkomme yn 'e simulaasje en tagong jouwe ta de ûnderlizzende gegevens fan belang. Bygelyks, in spoarboarne kin oanjaan wannear't in netwurkapparaat in pakket krige en de ynhâld fan it pakket beskikber stelle foar ynteressearre trace-ûntfangers.

Spoarboarnen op har eigen binne nutteloos, útsein as se "keppele" binne mei oare dielen fan 'e koade dy't eins wat nuttich dogge mei de ynformaasje dy't troch de sink wurdt levere. Tracers binne konsuminten fan eveneminten en gegevens levere troch spoarboarnen. Jo kinne bygelyks in trace sink meitsje dy't (as ferbûn mei de spoarboarne fan it foarige foarbyld) de dielen fan belang yn it ûntfongen pakket ôfdrukke sil.

De reden foar dizze eksplisite skieding is om brûkers nije sinktypen te ferbinen mei besteande spoarboarnen sûnder de simulatorkearn te bewurkjen en opnij te kompilearjen. Dat yn it foarbyld hjirboppe kin de brûker in nije tracer yn har skript definiearje en it ferbine mei in besteande spoarboarne definieare yn 'e simulaasjekearn allinich troch it brûkersskript te bewurkjen.

Yn dizze tutorial sille wy troch guon fan 'e foarôf definieare boarnen en sinken gean en sjen litte hoe't se kinne wurde konfigureare mei de minste ynspanning fan 'e brûker. Sjoch de ns-3 Hânlieding of hoe-to seksjes foar ynformaasje oer avansearre trace konfiguraasje, ynklusyf it útwreidzjen fan de trace nammeromte en it meitsjen fan nije trace boarnen.

5.3.1 ASCII Tracing

ns-3 biedt helperfunksjonaliteit dy't in tracingsysteem op leech nivo leveret om jo te helpen mei de details by it opsetten fan ienfâldige pakketsporen. As jo ​​dizze funksje ynskeakelje, sille jo de útfier sjen yn ASCII-bestannen. Foar dyjingen dy't bekend binne mei ns-2-útfier, is dit soarte spoar gelyk oan út.tr, dat wurdt oanmakke troch in protte skripts.

Litte wy nei saken gean en wat ASCII-tracing-resultaten tafoegje oan ús scratch/myfirst.cc-skript. Rjocht foar de oprop Simulator :: Run (), foegje de folgjende rigels koade ta:
AsciiTraceHelper ascii;

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

Lykas in protte oare ns-3-idioom, brûkt dizze koade in helpobjekt foar it meitsjen fan ASCII-spoaren. De twadde rigel befettet twa nested metoade calls. "Binnen" metoade CreateFileStream() brûkt it anonime objektidioom om in triemstreamobjekt op 'e stapel te meitsjen (sûnder in objektnamme) en jout it troch nei de neamde metoade. Wy sille dit yn 'e takomst djipper yngean, mar alles wat jo op dit punt witte moatte is dat jo in objekt meitsje dat in bestân fertsjintwurdiget mei de namme myfirst.tr en oermeitsje it nei ns-3. Wy jouwe ns-3 ta in soarch foar it oanmakke foarwerp foar syn hiele libben, wêrby't it oplost problemen feroarsake troch in bytsje bekend (opsetlike) beheining ferbûn mei C ++ stream foarwerp kopiearje konstruktors.

Eksterne oprop EnableAsciiAll() fertelt de assistint dat jo ASCII-tracing wolle opnimme yn jo simulaasje foar alle punt-to-punt apparaatferbiningen en dat jo wolle dat (oantsjutte) trace-ûntfangers pakketbewegingynformaasje opnimme yn ASCII-formaat.

Foar dyjingen dy't bekend binne mei ns-2, binne tracked events lykweardich oan de bekende tracepoints dy't log barren "+", "-", "d" en "r".
No kinne jo it skript bouwe en it útfiere fanút de kommandorigel:

$ ./waf --run scratch/myfirst

Lykas in protte kearen earder, sille jo ferskate berjochten sjen fan Waf, en dan "'bouwe' mei súkses klear" mei guon berjochten fan it rinnende programma.

By it útfieren sil it programma in triem mei de namme oanmeitsje myfirst.tr. Troch de aard fan it wurk Waf, standert wurdt it bestân net makke yn 'e lokale map, mar yn' e top-level map fan it repository. As jo ​​​​it paad feroarje wolle wêr't spoaren bewarre wurde, dan kinne jo de Waf-parameter brûke om it oan te jaan --cwd. Wy hawwe dit net dien, dus om te sjen nei it ASCII-tracebestân myfirst.tr yn jo favorite bewurker, moatte wy nei de map op topnivo fan ús repository navigearje.

ASCII-spoaren analysearje

D'r is in soad ynformaasje yn in frij dichte foarm, mar it earste ding dat jo moatte opmerke is dat it bestân bestiet út yndividuele rigels. Dit sil dúdlik sichtber wurde as jo it werjeftefinster breder útwreidzje.

Elke rigel yn 'e triem komt oerien mei in trace evenemint. Yn dit gefal trace wy eveneminten yn 'e oerdrachtwachtrige oanwêzich yn elk punt-nei-punt netwurkapparaat yn' e simulaasje. De oerdrachtwachtrige is de wachtrige dêr't elk pakket troch moat foar in punt-nei-punt keppeling. Tink derom dat elke rigel yn 'e spoarbestân begjint mei in inkeld karakter (en hat in spaasje nei it). Dit symboal sil de folgjende betsjutting hawwe:

+: in wachtrige operaasje barde op 'e apparaatwachtrige;
-: in elemint opheljen operaasje barde yn de apparaat wachtrige;
d: it pakket waard dellein, meastentiids omdat de wachtrige fol wie;
r: It pakket waard ûntfongen troch in netwurk apparaat.

Litte wy de earste rigel yn 'e spoarbestân in tichterby besjen. Ik sil it opbrekke yn dielen (mei ynspringingen foar dúdlikens) en it rigelnûmer oan 'e linkerkant:

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)

De earste seksje fan dit útwreide trace evenemint (rigel 0) is de operaasje. Wy hawwe hjir in + symboal, dat oerienkomt mei de wurking fan wachtrige foar oerdracht. De twadde seksje (rigel 1) is de simulaasjetiid, útdrukt yn sekonden. Jo kinne ûnthâlde wat wy fregen UdpEchoClientApplication begjinne pakketten yn twa sekonden te ferstjoeren. Hjir sjogge wy befêstiging dat dit yndie bart.

De folgjende seksje fan it spoarfoarbyld (fan rigel 2) lit sjen hokker spoarboarne dit barren generearre (wat oanjout op de nammeromtespoar). Jo kinne tinke oan 'e trace-nammeromte lykas jo in triemsysteemnammeromte soene. De root fan 'e nammeromte is NodeList. Dit komt oerien mei de kontener beheard yn 'e haad ns-3-koade. It befettet alle knopen dy't makke binne yn it skript. Krekt sa't in bestânsysteem mappen op syn root kin hawwe, NodeList wy kinne in protte knopen hawwe. De line /NodeList/0 ferwiist dus nei it nulknooppunt yn 'e NodeList, dêr't wy normaal oan tinke as "knooppunt 0". Elke knooppunt hat in list mei apparaten dy't binne ynstallearre. Dizze list stiet neist yn de nammeromte. Jo kinne sjen dat dit spoar barren komt út DeviceList/0, dat is it nul-apparaat ynstalleare yn 'e knooppunt.

Folgjende substring, $ ns3 :: PointToPointNetDevice, fertelt hokker apparaat is op posysje nul: de apparaat list fan node nul. Tink derom dat de + operaasje fûn yn rigel 0 betsjutte dat in elemint waard tafoege oan 'e útstjoerwachtrige fan it apparaat. Dit wurdt wjerspegele yn 'e lêste segminten fan it "spoarpaad": TxQueue/Enqueue.

De oerbleaune seksjes yn it spoar moatte frij yntuïtyf wêze. Rigels 3-4 jouwe oan dat it pakket is ynkapsele yn in punt-nei-punt protokol. Rigels 5-7 litte sjen dat it pakket in koptekst fan IP4-ferzje hat en ûntstien is yn it IP-adres 10.1.1.1 en is bedoeld foar 10.1.1.2. Rigels 8-9 litte sjen dat dit pakket in UDP-header hat en op it lêst lit line 10 sjen dat de lading de ferwachte 1024 bytes is.

De folgjende rigel yn it spoarbestân lit sjen dat itselde pakket waard lutsen út 'e oerdrachtwachtrige op deselde knooppunt.

De tredde rigel yn it spoarbestân lit sjen dat it pakket ûntfongen is troch in netwurkapparaat op 'e echo-tsjinnerhost. Ik haw it barren hjirûnder reprodusearre.

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)

Tink derom dat de trace operaasje is no r en de simulaasje tiid is ferhege nei 2,25732 sekonden. As jo ​​​​de tutorial foarsichtich hawwe folge, betsjut dit dat jo de DataRate en Link Delay fan 'e netwurkapparaten op har standertwearden hawwe litten. Dizze tiid moat bekend wêze, lykas jo seagen yn 'e foarige paragraaf.

De nammeromte foar spoarboarne (rigel 2) is wizige om te reflektearjen dat dit barren komt fan node 1 (/NodeList/1) en it pakket wurdt ûntfongen troch de spoarboarne (/MacRx). It soe foar jo frij maklik wêze moatte om de beweging fan it pakket troch de topology te folgjen troch te sjen nei de oerbleaune spoaren yn it bestân.

5.3.2 PCAP Trace

De ns-3 Device Helpers kinne ek brûkt wurde om trace-bestannen yn .pcap-formaat te meitsjen. Acronym pcap (meastentiids skreaun yn lytse letters) stiet foar pakket capture en is eins in API dy't omfettet it definiearjen fan it .pcap bestânsformaat. It populêrste programma dat dit formaat kin lêze en werjaan is Wireshark (earder neamd Ethereal). D'r binne lykwols in protte ferkearsspoaranalyzers dy't dit pakketformaat brûke. Wy stimulearje brûkers om de protte beskikbere ark te brûken om pcap-spoaren te analysearjen. Yn dizze tutorial sille wy rjochtsje op it besjen fan pcap-spoaren mei help fan tcpdump.

It ynskeakeljen fan pcap tracing wurdt dien mei ien rigel koade.

pointToPoint.EnablePcapAll ("myfirst");

Plak dizze rigel koade nei de ASCII-spoarkoade dy't wy krekt tafoege hawwe scratch/myfirst.cc. Tink derom dat wy allinich de tekenrige "myfirst" trochjûn hawwe, net "myfirst.pcap" of wat ferlykber. Dit komt omdat de parameter in foarheaksel is, net in folsleine bestânsnamme. Tidens de simulaasje sil de assistint eins in spoarbestân meitsje foar elk punt-nei-punt-apparaat. Bestânsnammen sille wurde konstruearre mei it foarheaksel, knooppuntnûmer, apparaatnûmer en efterheaksel ".pcap".

Foar ús foarbyldskript sille wy úteinlik bestannen sjen mei de namme "myfirst-0-0.pcap"En"myfirst-1-0.pcap", dy't respektivelik pcap-spoaren binne foar node 0-apparaat 0 en node 1-apparaat 0. Sadree't jo de rigel koade tafoege hawwe om pcap tracing yn te skeakeljen, kinne jo it skript op 'e gewoane manier útfiere:

$ ./waf --run scratch/myfirst

As jo ​​​​yn 'e map op topnivo fan jo distribúsje sjogge, moatte jo trije bestannen sjen: in ASCII-tracebestân myfirst.tr, dy't wy earder studearre, triemmen myfirst-0-0.pcap и myfirst-1-0.pcap - nije pcap-bestannen dy't wy krekt genereare.

Lêze útfier mei tcpdump

Foar no is de maklikste manier om pcap-bestannen te besjen is tcpdump te brûken.

$ 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

Yn 'e dump myfirst-0-0.pcap (kliïntapparaat) kinne jo sjen dat it echopakket wurdt ferstjoerd nei 2 sekonden fan simulaasje. As jo ​​​​nei de twadde dump sjogge (myfirst-1-0.pcap), sille jo sjen dat it pakket wurdt ûntfongen op 2,257324 sekonden. Jo sille sjen yn 'e twadde dump dat it pakket wurdt weromjûn op 2.257324 sekonden, en as lêste dat it pakket waard ûntfongen werom troch de kliïnt yn de earste dump op 2.514648 sekonden.

Lêsútfier mei Wireshark

As jo ​​net bekend mei Wireshark, d'r is in webside wêrfan jo programma's en dokumintaasje kinne downloade: http://www.wireshark.org/. Wireshark is in GUI dy't brûkt wurde kin om dizze trace-bestannen wer te jaan. As jo ​​​​Wireshark hawwe, kinne jo ien fan 'e spoarbestannen iepenje en de ynhâld sjen litte as jo de pakketten hawwe fêstlein mei in pakketsniffer.

Boarne: www.habr.com