ProHoster > Блог > Administrado > ns-3 retsimulilo lernilo. Ĉapitro 5

ns-3 retsimulilo lernilo. Ĉapitro 5

ns-3 retsimulilo lernilo. Ĉapitro 5
Ĉapitro 1,2
Ĉapitro 3
Ĉapitro 4

5 Agordoj
5.1 Uzante la registran modulon
5.1.1 Ensaluta superrigardo
5.1.2 Ebligu ensalutadon
5.1.3 Aldono de ensalutu al via kodo
5.2 Uzado de komandliniaj argumentoj
5.2.1 Anstataŭi defaŭltajn atributajn valorojn
5.2.2 Kapti viajn proprajn komandojn
5.3 Uzado de la spursistemo
5.3.1 ASCII-Spurado
Analizante ASCII-spurojn
5.3.2 PCAP-Spuro

Ĉapitro 5

alĝustigo

5.1 Uzante la registran modulon

Ni jam mallonge rigardis la ns-3-logan modulon rigardante la skripton unue.cc. En ĉi tiu ĉapitro, ni rigardos pli detale eblajn uzadojn por la protokolo-subsistemo.

5.1.1 Ensaluta superrigardo

Multaj grandaj sistemoj subtenas iun specon de mesaĝregistrado, kaj ns-3 ne estas escepto. En kelkaj kazoj, nur erarmesaĝoj estas skribitaj al la "funkciigisto-konzolo" (kiu kutime estas stderr sur Unikso-bazitaj sistemoj). En aliaj sistemoj, avertaj mesaĝoj povas esti montritaj same kiel pli detalaj informoj. En iuj kazoj, registradaj iloj estas uzataj por eligi sencimigajn mesaĝojn, kiuj povas rapide malklarigi la eligon.

La subHRD uzata en ns-3 supozas, ke ĉiuj ĉi tiuj niveloj de informenhavo estas utilaj, kaj ni provizas selekteman, tavoligitan aliron al mesaĝa registrado. Registrado povas esti tute malŝaltita, ebligita laŭ-komponenta bazo, aŭ tutmonde. Tiucele oni uzas alĝustigeblajn nivelojn de informenhavo. La ns-3 registra modulo provizas relative simplan manieron akiri utilajn informojn de via simulado.

Vi devus kompreni, ke ni provizas ĝeneraluzeblan mekanismon - spuradon - por ĉerpi datumojn de viaj modeloj, kiu devus esti la preferata eligo por simuladoj (por pliaj informoj pri nia spursistemo, vidu lernilon sekcion 5.3). Registrado devus esti la preferata metodo por akiri sencimigajn informojn, avertojn, erarmesaĝojn aŭ por rapide eligi mesaĝojn el viaj skriptoj aŭ modeloj iam ajn.

Nuntempe, la sistemo difinas sep nivelojn (tipoj) de protokolaj mesaĝoj en kreskanta ordo de informenhavo.

  • LOG_ERROR - registri erarmesaĝojn (rilata makroo: NS_LOG_ERROR);
  • LOG_WARN - Ensalutu avertajn mesaĝojn (rilata makroo: NS_LOG_WARN);
  • LOG_DEBUG - Ensalutu relative maloftajn specialajn sencimigajn mesaĝojn (rilata makroo: NS_LOG_DEBUG);
  • LOG_INFO - registriĝo de informaj mesaĝoj pri la progreso de la programo (rilata makroo: NS_LOG_INFO);
  • LOG_FUNCTION - Registras mesaĝojn priskribantaj ĉiun nomitan funkcion (du rilataj makrooj: NS_LOG_FUNCTION, uzata por membrofunkcioj, kaj NS_LOG_FUNCTION_NOARGS, uzata por senmovaj funkcioj);
  • LOG_LOGIC - registri mesaĝojn priskribantaj la logikan fluon ene de funkcio (rilata makroo: NS_LOG_LOGIC);
  • LOG_ALL - Registras ĉion supre menciitan (neniu rilata makroo).
    Por ĉiu tipo (LOG_TYPE) ekzistas ankaŭ LOG_LEVEL_TYPE kiu, se uzata, permesas ĉiujn nivelojn super ĝi esti registritaj krom sia propra nivelo. (Sekve, LOG_ERROR kaj LOG_LEVEL_ERROR, kaj LOG_ALL kaj LOG_LEVEL_ALL estas funkcie ekvivalentaj.) Ekzemple, ebligi LOG_INFO nur permesos mesaĝojn provizitajn de la makroo NS_LOG_INFO, dum ebligo de LOG_LEVEL_INFO ankaŭ inkluzivos mesaĝojn provizitajn de la makrooj NS_LOGNS_DE_W_GARN kaj ERROR_DE_W_GARN.

Ni ankaŭ provizas senkondiĉan registran makroon, kiu ĉiam montriĝas, sendepende de la registra nivelo aŭ la elekta komponanto.

  • NS_LOG_UNCOND - Senkondiĉa protokolado de la rilata mesaĝo (neniu rilata ensaluta nivelo).

Ĉiu nivelo povas esti demandita individue aŭ akumule. Registrado povas esti agordita uzante la sh-medivariablon NS_LOG aŭ registrante sisteman funkciovokon. Kiel montrite antaŭe, la registra sistemo havas Doxygen-dokumentadon kaj nun estas bona tempo por revizii ĝin, se vi ne jam faris.

Nun, kiam vi legis la dokumentaron tre detale, ni uzu tiun scion por akiri iujn interesajn informojn el la ekzempla skripto. scratch/myfirst.cckiun vi jam kompilis.

5.1.2 Ebligu ensalutadon

Ni uzu la mediovariablon NS_LOG por ruli pliajn protokolojn, sed unue, nur por ekorientiĝi, rulu la lastan skripton kiel vi faris antaŭe,

$ ./waf --run scratch/myfirst

Vi devus vidi la konatan eliron de la unua ekzempla programo ns-3

$ Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' 'build'
finished successfully (0.413s)
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2

Montriĝas, ke la "senditaj" kaj "ricevitaj" mesaĝoj, kiujn vi vidas supre, estas fakte registritaj mesaĝoj de UdpEchoClientApplication и UdpEchoServerApplication. Ekzemple, ni povas peti al la klienta aplikaĵo presi pliajn informojn fiksante ĝian registran nivelon per la mediovariablo NS_LOG.

De nun mi supozos, ke vi uzas ŝ-similan ŝelon, kiu uzas la sintakson "VARIABLE=valoro". Se vi uzas csh-similan ŝelon, tiam vi devos konverti miajn ekzemplojn al la sintakso "setenv-varia valoro" postulata de tiuj ŝeloj.

Nuntempe, la UDP-eĥa klienta aplikaĵo respondas al la sekva linio de kodo en scratch/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Ĝi ebligas la registran nivelon LOG_LEVEL_INFO. Kiam ni pasas flagon de registra nivelo, ni efektive ebligas tiun nivelon kaj ĉiujn pli malaltajn nivelojn. En ĉi tiu kazo, ni ebligis NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN kaj NS_LOG_ERROR. Ni povas pliigi la registran nivelon kaj akiri pli da informoj, sen skriptoŝanĝoj kaj rekompilo, per agordo de la mediovariablo NS_LOG jene:

$ export NS_LOG=UdpEchoClientApplication=level_all

Do ni fiksas la sh-ŝelan variablon NS_LOG al la sekva valoro,

UdpEchoClientApplication=level_all

La maldekstra flanko de la tasko estas la nomo de la registrita komponanto, kiun ni volas agordi, kaj la dekstra flanko estas la flago, kiun ni volas apliki por ĝi. En ĉi tiu kazo, ni ebligos ĉiujn nivelojn de elpurigado en la aplikaĵo. Se vi rulas la skripton kun NS_LOG agordita ĉi tiel, la ns-3-registra sistemo akceptos la ŝanĝojn kaj vi devus vidi la sekvan eligon:

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

Pliaj sencimigaj informoj provizitaj de la aplikaĵo nun estas ĉe la NS_LOG_FUNCTION-nivelo. Ĝi montras ĉiun okazon de funkciovoko dum skripto-ekzekuto. Kiel ĝenerala regulo, en metodofunkcioj estas preferinde uzi (minimume)NS_LOG_FUNCTION (this)... Uzu NS_LOG_FUNCTION_NOARGS ()
nur en senmovaj funkcioj. Tamen, notu, ke la ns-3-sistemo ne estas postulata por subteni ajnan registradan funkcion. La decido pri kiom da informoj estas registritaj estas lasita al la individua modelprogramisto. En la kazo de eĥaj aplikoj, granda kvanto da eligo de protokolo disponeblas.

Vi nun povas vidi protokolon de funkciovokoj faritaj de la aplikaĵo. Se vi rigardas atente, vi rimarkos dupunkton inter la linio UdpEchoClientApplication kaj la nomo de la metodo, kie vi eble atendas vidi la C++-ampleksan operatoron (: :). Ĉi tio estas intencita.

Ĉi tio fakte ne estas la nomo de la klaso, sed la nomo de la protokolo-komponento. Kiam estas kongruo inter fontdosiero kaj klaso, ĝi kutime estas la nomo de la klaso, sed vi devus rimarki, ke ĝi ne estas fakte la nomo de la klaso, kaj ekzistas unu dupunkto anstataŭ duobla dupunkto. Ĉi tio estas maniero helpi vin koncipe apartigi la registran fabnomon de la klasnomo en relative subtila maniero.

Tamen, en kelkaj kazoj povas esti malfacile determini kiu metodo efektive generas la protokolmesaĝon. Se vi rigardas la supran tekston, vi eble demandas, kie la linio "Received 1024 bytes from 10.1.1.2" Vi povas solvi ĉi tiun problemon fiksante la nivelon prefikso_func al la mediovariablo NS_LOG. Provu la jenon:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Notu, ke la citiloj estas necesaj ĉar la vertikala stango, kiun ni uzas por reprezenti la OR-operacion, estas ankaŭ Unikso-pipo-konektilo. Nun se vi rulas la skripton, vi vidos, ke la registra sistemo certigas, ke ĉiu mesaĝo en antaŭfiksita protokolo estas prefiksita kun la komponantonomo.

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

Nun vi povas vidi, ke ĉiuj mesaĝoj venantaj de la UDP-eĥa klienta aplikaĵo estas identigitaj kiel tiaj. Mesaĝo "Received 1024 bytes from 10.1.1.2" nun estas klare identigita kiel venanta de la eĥa klienta aplikaĵo. La restanta mesaĝo devas veni de la aplikaĵo de UDP-eĥa servilo. Ni povas ebligi ĉi tiun komponanton per enigo de dupunkto-disigita listo de komponantoj en la mediovariablo NS_LOG.

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

Averto: En la ekzempla teksto supre, vi devos forigi la novlinian signon post la dupunkto (:), ĝi estas uzata por formati la dokumenton. Nun se vi rulas la skripton, vi vidos ĉiujn protokolojn de la kliento kaj servilo eĥaplikoj. Vi povas vidi, ke ĉi tio povas esti tre utila dum senararigado.

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

Ankaŭ estas foje utile povi vidi la simuladtempon, kiam la protokolo-mesaĝo estis generita. Vi povas fari tion aldonante la OR-biton prefikso_tempo:

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

Denove, vi devos forigi la supran novlinian signon. Se vi nun rulas la skripton, vi devus vidi la sekvan eligon:

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

Bonvolu noti, ke la konstrukciisto por UdpEchoServer estis vokita dum simulado 0 sekundoj. Ĉi tio efektive okazas antaŭ ol la simulado komenciĝas, sed la tempo estas montrita kiel nul sekundoj. La sama estas vera por la konstruaĵa mesaĝo 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()

Memoru ke la skripto grati/unua.cc komencis la eĥservilan aplikaĵon unu sekundon antaŭ la komenco de la simulado. Nun vi povas vidi ke la metodo Komencu Aplikon la servilo estas fakte vokita en la unua sekundo. Vi ankaŭ povas rimarki, ke la eĥo-kliento komenciĝas en la dua sekundo de la simulado, kiel ni demandis en la skripto.

Vi nun povas sekvi la simulan progreson alvoke ScheduleTransmit en la kliento, kiu vokas la HandleRead-revokon Sendi en la eĥservila aplikaĵo. Notu, ke la pasinta tempo por sendi pakaĵeton tra punkto-al-punkta ligo estas 3,69 milisekundoj. Vi povas vidi, ke la eĥservilo registras mesaĝon, ke ĝi respondis al la pakaĵeto, kaj tiam, post kanala prokrasto, vi vidas, ke la eĥa kliento ricevas la eĥan pakon en sia HandleRead-metodo.

En ĉi tiu simulado, multe okazas sen vi rimarki. Sed vi povas spuri la tutan procezon tre facile ebligante ĉiujn registradajn komponantojn en la sistemo. Provu agordi la variablon NS_LOG al la sekva valoro,

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

La steleto supre estas ĵokera signo por la registradkomponento. Ĉi tio inkluzivos ĉiujn enskribojn en ĉiuj komponantoj uzataj en la simulado. Mi ne reproduktos la eligon ĉi tie (je la skribado ĝi produktas 1265 liniojn de eligo por ununura eĥa pako), sed vi povas redirekti ĉi tiun informon al dosiero kaj vidi ĝin en via plej ŝatata redaktilo.

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

Mi persone uzas ĉi tiun ege multvortan version de protokolado kiam mi havas problemon kaj ne havas ideon, kie aferoj misfunkciis. Mi povas sekvi la kodon ekzekuton sufiĉe facile sen fiksi rompopunktojn kaj paŝi tra la kodo en la erarserĉilo. Mi povas simple redakti la eliron en mia plej ŝatata redaktilo kaj serĉi tion, kion mi atendas kaj vidi io okazi, kion mi ne atendis. Post kiam mi havas ĝeneralan ideon pri tio, kio misfunkcias, mi saltas en la erarserĉilon por esplori la problemon. Ĉi tiu tipo de eligo povas esti speciale utila kiam via skripto faras ion tute neatenditan. Se vi nur uzas la erarserĉilon, vi eble tute maltrafos turnon. Registrado rimarkas tiajn turnojn.

5.1.3 Aldono de ensalutu al via kodo

Vi povas aldoni novajn enskribojn al viaj simulaĵoj per vokoj al la protokolo el pluraj makrooj. Ni faru ĝin en skripto miaunua.cc, kiun ni havas en la "pura" dosierujo. Memoru, ke ni difinis registradan komponenton en ĉi tiu scenaro:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Vi konscias, ke vi povas ebligi protokolon de ĉiuj mesaĝoj de ĉi tiu ero per agordo de la mediovariablo NS_LOG je malsamaj niveloj. Ni iru antaŭen kaj aldonu kelkajn enskribojn al la skripto. La makroo uzata por aldoni informnivelajn mesaĝojn al la protokolo estas NS_LOG_INFO. Ni aldonu mesaĝon (ĝuste antaŭ ol ni komencas krei nodojn), kiu diras al vi, ke la skripto estas en la fazo "Kreado de Topologio". Ĉi tio estas farita en la sekva kodpeceto,
Malfermu scratch/myfirst.cc en via plej ŝatata redaktilo kaj aldonu la linion,
NS_LOG_INFO ("Creating Topology");
tuj antaŭ la linioj,

NodeContainer nodes;
nodes.Create (2);

Nun kompilu la skripton uzante waf, kaj forigu la variablon NS_LOG por malŝalti la registran fluon, kiun ni ebligis pli frue:

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

Vi ne vidos la novan mesaĝon ĉar la rilata registradkomponento (FirstScriptExample) ne estis ebligita. Por vidi vian mesaĝon vi devas ebligi la protokolon UnuaSkriptoEkzemplo kun nivelo ne pli malalta ol NS_LOG_INFO. Se vi nur volas vidi ĉi tiun specifan registran nivelon, vi povas ebligi ĝin tiel,

$ export NS_LOG=FirstScriptExample=info

Se vi rulas la skripton nun, vi vidos novan mesaĝon "Kreante Topologion",

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 Uzado de komandliniaj argumentoj

5.2.1 Anstataŭi defaŭltajn atributajn valorojn

Alia maniero ŝanĝi la konduton de ns-3-skriptoj sen redaktado aŭ konstruado estas uzi komandliniajn argumentojn. Ni provizas mekanismon por analizi komandliniajn argumentojn kaj aŭtomate agordi lokajn kaj tutmondajn variablojn surbaze de la rezultoj.

La unua paŝo en uzado de la komandlinia argumentsistemo estas deklari komandlinian analizilon. Ĉi tio estas sufiĉe facila por fari (en via ĉefa programo), kiel en la sekva kodo,

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

Ĉi tiu simpla dulinia fragmento efektive estas tre utila per si mem. Ĝi malfermas la pordon al la tutmonda variablo kaj atributosistemo ns-3. Ni aldonu du liniojn de kodo al la komenco de la ĉefa skriptofunkcio scratch/myfirst.cc. Pluirante, ni kompilas la skripton kaj rulas ĝin, kiam ni faras helpopeton jene,

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

Ĉi tiu komando demandos Waf ruli skripton grati/miaunue kaj pasigu al ĝi komandlinian argumenton —PresiHelpon. La citiloj estas postulataj por indiki al kiu programo estas celita la argumento. La komandlinia analizilo detektos la argumenton —PresiHelpon kaj montros la respondon,

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.

Nun ni rigardu la opcion —PresiAtributojn. Ni jam menciis la ns-3-atributan sistemon dum studado de la unua.cc-skripto. Ni vidis la sekvajn liniojn de kodo,

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

kaj ili diris tion DataRate estas fakte atributo PointToPointNetDevice. Ni uzu la komandlinian argumentan analizilon por vidi la atributojn PointToPointNetDevice. La helplisto diras, kion ni devas provizi TypeId. Ĉi tio estas la nomo de la klaso al kiu apartenas la interesaj atributoj. En nia kazo estos ns3::PointToPointNetDevice. Ni daŭre antaŭeniru, eniru,

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

La sistemo presos ĉiujn atributojn de ĉi tiu ret-aparato. Vi vidos, ke inter la atributoj en la listo estas,

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

Ĉi tiu estas la defaŭlta valoro, kiu estos uzata de la sistemo dum kreado de la objekto PointToPointNetDevice. Ni anstataŭigos ĉi tiun defaŭltan valoron uzante la parametron atributo в PointToPointHelper pli alta. Ni uzu la defaŭltajn valorojn por punkto-al-punktaj aparatoj kaj kanaloj. Por fari tion, ni forigos vokojn AgorduDeviceAtribute и SetChannelAttribute el miaunua.cc, kiun ni havas en pura dosierujo.

Via skripto nun devus simple deklari PointToPointHelper kaj ne faru iujn ajn instalajn operaciojn kiel montrite en la ekzemplo sube,

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

Antaŭen kaj kreu novan skripton kun Waf (./waff) kaj ni reiru kaj inkluzivu iun eniron de la aplikaĵo pri eĥo-servilo de UDP kaj inkludu la tempprefikson.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Se vi rulas la skripton, vi devus vidi la sekvan eligon:

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

Memoru, ke la lastan fojon ni rigardis la simulan tempon, la momenton, kiam la pako estis ricevita de la eĥservilo, ĝi estis 2,00369 sekundoj.

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

Nun li ricevas la pakaĵon en 2.25732 sekundoj. Ĉi tio estas ĉar ni simple restarigas la datumrapidecon de PointToPointNetDevice de kvin megabitoj sekundo al la defaŭlta valoro, kiu estas 32768 bitoj sekundo. Se ni anstataŭigus novan DataRate uzante la komandlinion, ni povus denove akceli nian simuladon. Ni faros tion jene, laŭ la formulo implicita de la helpelemento:

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

Ĉi tio redonos la atributon DataRate al ĝia defaŭlta valoro de kvin megabitoj sekundo. Ĉu vi surprizas la rezulton? Rezultas, ke por redoni la originalan konduton de la skripto, ni ankaŭ devas agordi la kanalan prokraston por kongrui kun la lumrapido. Ni povas peti la komandlinian sistemon presi la kanalajn atributojn, same kiel ni faris por la reta aparato:

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

Ni trovos, ke la kanala prokrasta atributo estas agordita jene:

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

Ni povas tiam, per la komandlinia sistemo, agordi ambaŭ ĉi tiujn defaŭltajn valorojn.

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

en ĉi tiu kazo ni restarigas la tempon, kiun ni havis, kiam ni eksplicite fiksis la DataRate kaj Prokraston en la skripto:

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

Notu, ke la pako estas ricevita de la servilo denove post 2,00369 sekundoj. Ni povus efektive agordi iun ajn el la atributoj uzataj en la skripto tiamaniere. Aparte, ni povus agordi la MaxPackets-atributojn al ne-unu valoroj UdpEchoClient.

Kiel vi uzus ĝin? Provu ĝin. Memoru, ke vi devas komenti la lokon, kie ni anstataŭas la defaŭltan atributan valoron kaj eksplicite agordi Maksimumaj Pakoj en la skripto. Tiam vi devas rekonstrui la skripton. Vi ankaŭ povas uzi la komandlinion por ricevi sintaksan helpon por agordi novan defaŭltan atributan valoron. Post kiam vi komprenas ĉi tion, vi povas kontroli la nombron da pakaĵoj montrataj sur la komandlinio. Ĉar ni estas studemaj homoj, nia komandlinio devus aspekti kiel ĉi tio:

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

La natura demando, kiu ekestas ĉe ĉi tiu punkto, estas kiel scii pri la ekzisto de ĉiuj ĉi tiuj atributoj. Denove, la komandlinia sistemo havas helpan funkcion por ĉi tiu afero. Se ni petas la komandlinion helpon, ni devus vidi:

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

Se vi elektas la argumenton "PrintGroups", vi devus vidi liston de ĉiuj registritaj grupoj TypeId. La grupnomoj kongruas kun la nomoj de la moduloj en la fonta dosierujo (kvankam majuskle). Presi ĉiujn informojn samtempe estus tro volumena, do plia filtrilo disponeblas por presi informojn laŭgrupo. Do, denove koncentriĝante sur la punkto-al-punkta modulo:

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

Ĉi tie vi povas trovi disponeblajn TypeId-nomojn por atributaj serĉoj, ekzemple en
--PrintAttributes = ns3 :: PointToPointChannelkiel montrite supre.

Alia maniero lerni pri atributoj estas per Doxygen ns‑3. Estas paĝo, kiu listigas ĉiujn atributojn registritajn en la simulilo.

5.2.2 Kapti viajn proprajn komandojn

Vi ankaŭ povas aldoni viajn proprajn hokojn per la komandlinia sistemo. Ĉi tio estas farita tute simple uzante la komandlinian analizan metodon Aldoni Valoron.
Ni uzu ĉi tiun funkcion por specifi la nombron da pakaĵoj montrotaj en tute malsama maniero. Ni aldonu lokan variablon nomitan nPakoj en funkcion ĉefa. Ni agordos ĝin al unu por kongrui kun nia antaŭa defaŭlta konduto. Por permesi al la komandlinia analizilo ŝanĝi ĉi tiun valoron, ni devas kapti ĉi tiun valoron en la analizilo. Ni faras tion aldonante vokon Aldoni Valoron. Iru kaj ŝanĝu la skripton scratch/myfirst.cc do komenci per la sekva kodo,

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

Rulumu malsupren al la punkto en la skripto, kie ni starigas la atributon MaxPackets kaj ŝanĝu ĝin tiel ke ĝi estu agordita al la variablo nPackets anstataŭ la konstanta 1, kiel montrite sube.

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

Nun se vi rulas la skripton kaj provizas la -PrintHelp-argumenton, vi devus vidi la novan uzantan argumenton. listigita sur la helpa ekrano. Enigu,

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

Se vi volas ŝanĝi la nombron da elsenditaj pakaĵoj, vi povas fari tion per agordo de la komandlinia argumento - -nPackets.

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

Nun vi nun devus vidi

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

Vi nun sendis du pakaĵojn. Sufiĉe simple, ĉu ne?
Vi povas vidi, ke kiel uzanto ns-3, vi povas uzi la komandlinian argumentsistemon por manipuli tutmondajn valorojn kaj atributojn. Se vi estas la modelaŭtoro, vi povas aldoni novajn atributojn al viaj objektoj kaj ili estos aŭtomate disponeblaj por agordo de viaj uzantoj per la komandlinia sistemo. Se vi estas skriptaŭtoro, vi povas aldoni novajn variablojn al viaj skriptoj kaj perfekte ŝtopi ilin en vian komandlinian sistemon.

5.3 Uzado de la spursistemo

La tuta punkto de modeligado estas generi produktaĵon por plia studo, kaj la ns-3-spursistemo estas la ĉefa mekanismo por tio. Ĉar ns-3 estas C++-programo, normaj rimedoj de generado de produktaĵo de C++-programo povas esti uzataj:

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

Vi eĉ povas uzi registran modulon por aldoni iom da strukturo al via solvo. Estas multaj konataj problemoj kaŭzitaj de ĉi tiu aliro, kaj tial ni disponigis ĝeneralan okazaĵan spuran subsistemon por solvi ĉi tiujn problemojn.

La ĉefceloj de la ns-3 spursistemo estas:

  • Por bazaj taskoj, la spursistemo devus permesi al la uzanto generi norman spuron por popularaj fontoj kaj elekti objektojn kiuj generas la spuron;

  • Mezaj uzantoj devus povi etendi la spursistemon por ŝanĝi la generitan eligformaton aŭ enmeti novajn spurfontojn, sen modifi la simulilkernon;

  • Altnivelaj uzantoj povas modifi la simulilkernon por aldoni novajn spurfontojn kaj lavujojn. La spursistemo ns-3 estas konstruita sur la principoj de sendependaj spurfontoj kaj riceviloj, same kiel unuigita mekanismo por ligado de fontoj al konsumantoj.

La spursistemo ns-3 estas konstruita sur la principoj de sendependaj spurfontoj kaj riceviloj, same kiel unuigita mekanismo por ligado de fontoj al riceviloj. Spurfontoj estas objektoj kiuj povas signali okazaĵojn okazantajn en la simulado kaj disponigi aliron al la subestaj datenoj de intereso. Ekzemple, spurfonto povas indiki kiam retoaparato ricevis pakaĵeton kaj disponigi la enhavon de la pakaĵeto al interesitaj spurriceviloj.

Spurfontoj memstare estas senutilaj krom se ili estas "kunligitaj" kun aliaj partoj de la kodo, kiuj efektive faras ion utilan kun la informoj provizitaj de la lavujo. Spuriloj estas konsumantoj de eventoj kaj datumoj provizitaj de spurfontoj. Ekzemple, vi povas krei spurlavujon kiu (kiam ligite al la spurfonto de la antaŭa ekzemplo) presis la interesajn partojn en la ricevita pako.

La raciaĵo por tiu eksplicita apartigo estas permesi al uzantoj ligi novajn lavujtipojn al ekzistantaj spurfontoj sen devi redakti kaj rekompili la simulilkernon. Do en la supra ekzemplo, la uzanto povas difini novan spurilon en sia skripto kaj konekti ĝin al ekzistanta spurfonto difinita en la simulada kerno nur per redaktado de la uzantskripto.

En ĉi tiu lernilo, ni trarigardos iujn el la antaŭdifinitaj fontoj kaj lavujoj kaj montros kiel ili povas esti agorditaj kun la plej malgranda peno de la uzanto. Vidu la ns-3 Manlibron aŭ sekciojn pri instruado por informoj pri altnivela agordo de spuro, inkluzive de vastigado de la spura nomspaco kaj kreado de novaj spurfontoj.

5.3.1 ASCII-Spurado

ns-3 provizas helpan funkcion, kiu disponigas malaltnivelan spursistemon por helpi vin pri la detaloj dum agordado de simplaj pakaj spuroj. Se vi ebligas ĉi tiun funkcion, vi vidos la eligon en ASCII-dosieroj. Por tiuj konataj kun ns-2 eligo, ĉi tiu speco de spuro estas simila al eksteren.tr, kiu estas generita de multaj skriptoj.

Ni komencu kaj aldonu kelkajn ASCII-spurajn rezultojn al nia scratch/myfirst.cc-skripto. Tuj antaŭ la voko Simulator :: Run (), aldonu la sekvajn liniojn de kodo:
AsciiTraceHelper ascii;

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

Kiel multaj aliaj ns-3-idiomoj, ĉi tiu kodo uzas helpan objekton por krei ASCII-spurojn. La dua linio enhavas du nestitajn metodovokojn. "Ene" metodo Krei FileStream () uzas la anoniman objekto-idiomon por krei dosierfluan objekton sur la stako (sen objektonomo) kaj pasas ĝin al la nomita metodo. Ni profundigos ĉi tion estonte, sed ĉio, kion vi bezonas scii ĉi-momente, estas, ke vi kreas objekton, kiu reprezentas dosieron nomatan. mia unua.tr kaj translokigu ĝin al ns-3. Ni konfidas al ns-3 prizorgi la kreitan objekton dum ĝia tuta vivdaŭro, dum kiu ĝi solvas problemojn kaŭzitajn de malmulte konata (intencita) limigo asociita kun C++-fluaj objektokopiaj konstrukciistoj.

Ekstera voko EnableAsciiAll() diras al la asistanto, ke vi volas inkluzivi ASCII-spuradon en via simulado por ĉiuj punkt-al-punktaj aparato-konektoj kaj ke vi volas (specifitaj) spurriceviloj registri pakaĵajn movadajn informojn en ASCII-formato.

Por tiuj konataj kun ns-2, spuritaj eventoj estas ekvivalentaj al la konataj spurpunktoj kiuj registras eventojn "+", "-", "d" kaj "r".
Nun vi povas konstrui la skripton kaj ruli ĝin de la komandlinio:

$ ./waf --run scratch/myfirst

Kiel multajn fojojn antaŭe, vi vidos plurajn mesaĝojn de Waf, kaj poste "'konstruo' finiĝis sukcese" kun kelkaj mesaĝoj de la ruliĝanta programo.

Dum funkciado, la programo kreos dosieron nomitan mia unua.tr. Pro la naturo de la laboro Waf, defaŭlte la dosiero estas kreita ne en la loka dosierujo, sed en la plej alta dosierujo de la deponejo. Se vi volas ŝanĝi la vojon, kie spuroj estas konservitaj, tiam vi povas uzi la parametron Waf por specifi ĝin. --cwd. Ni ne faris tion, do por rigardi la ASCII-spurdosieron myfirst.tr en via plej ŝatata redaktilo, ni devos navigi al la plej alta dosierujo de nia deponejo.

Analizante ASCII-spurojn

Estas multe da informoj tie en sufiĉe densa formo, sed la unua afero, kiun vi devas rimarki, estas, ke la dosiero konsistas el individuaj linioj. Ĉi tio fariĝos klare videbla se vi plilarĝigas la rigardan fenestron.

Ĉiu linio en la dosiero respondas al spurokazaĵo. En ĉi tiu kazo, ni spuras eventojn en la dissendovico ĉeestanta en ĉiu punkto-al-punkta reto-aparato en la simulado. La dissendovico estas la atendovico tra kiu ĉiu pakaĵeto devas pasi por punkt-al-punkta ligo. Notu, ke ĉiu linio en la spurdosiero komenciĝas per ununura signo (kaj havas spacon post ĝi). Ĉi tiu simbolo havos la jenan signifon:

+: vica operacio okazis sur la aparata vico;
-: en la vico de la aparato okazis elemento retrova operacio;
d: la pakaĵo estis faligita, kutime ĉar la atendovico estis plena;
r: La pako estis ricevita de reta aparato.

Ni rigardu pli detale la unuan linion en la spurdosiero. Mi disdividos ĝin en partojn (kun indentaĵoj por klareco) kaj la linionumeron maldekstre:

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)

La unua sekcio de ĉi tiu plilongigita spurokazaĵo (linio 0) estas la operacio. Ni havas +-simbolon ĉi tie, kiu respondas al la operacio de vico por transdono. La dua sekcio (linio 1) estas la simuladtempo, esprimita en sekundoj. Vi eble memoros, kion ni demandis UdpEchoClientApplication komencu sendi pakaĵojn post du sekundoj. Ĉi tie ni vidas konfirmon, ke tio efektive okazas.

La sekva sekcio de la spurekzemplo (de linio 2) montras kiu spurfonto generis ĉi tiun eventon (indikante la nomspacspuron). Vi povas pensi pri la spura nomspaco tre kiel vi farus pri dosiersistema nomspaco. La radiko de la nomspaco estas NodoListo. Ĉi tio respondas al la ujo administrita en la ĉefa ns-3-kodo. Ĝi enhavas ĉiujn nodojn, kiuj estas kreitaj en la skripto. Same kiel dosiersistemo povas havi dosierujojn ĉe sia radiko, NodoListo ni povas havi multajn nodojn. Do la linio /NodeList/0 rilatas al la nula nodo en la NodeList, kiun ni kutime pensas kiel "nodo 0". Ĉiu nodo havas liston de aparatoj instalitaj. Ĉi tiu listo troviĝas poste en la nomspaco. Vi povas vidi, ke ĉi tiu spura evento venas de AparatoListo/0, kiu estas la nula aparato instalita en la nodo.

Sekva subĉeno, $ ns3 :: PointToPointNetDevice, rakontas kiu aparato estas ĉe pozicio nul: la aparatolisto de nodo nul. Memoru, ke la + operacio trovita en linio 0 signifis ke elemento estis aldonita al la elsenda atendovico de la aparato. Tio estas reflektita en la lastaj segmentoj de la "traka vojo": TxQueue/Enqueue.

La ceteraj sekcioj en la spuro devus esti sufiĉe intuiciaj. Linioj 3-4 indikas ke la pakaĵeto estas enkapsuligita en punkt-al-punkta protokolo. Linioj 5-7 montras, ke la pakaĵo havas IP4-versian kaplinion kaj originis de la IP-adreso 10.1.1.1 kaj estas celita por 10.1.1.2. Linioj 8-9 montras, ke ĉi tiu pakaĵeto havas UDP-kapon kaj finfine linio 10 montras, ke la utila ŝarĝo estas la atendataj 1024 bajtoj.

La sekva linio en la spurdosiero montras, ke la sama pako estis tirita de la dissenda vico sur la sama nodo.

La tria linio en la spurdosiero montras, ke la pakaĵo estis ricevita de reta aparato sur la eĥservila gastiganto. Mi reproduktis la eventon sube.

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)

Notu, ke la spuroperacio nun estas r kaj la simulada tempo estis pliigita al 2,25732 sekundoj. Se vi zorge sekvis la lernilon, tio signifas, ke vi lasis DataRate kaj Link Delay de la retaj aparatoj ĉe siaj defaŭltaj valoroj. Ĉi tiu tempo devus esti konata, kiel vi vidis en la antaŭa sekcio.

La spurfonta nomspaco eniro (linio 2) estis modifita por reflekti, ke ĉi tiu evento originas de nodo 1 (/NodoListo/1) kaj la pako estas ricevita de la spurfonto (/MacRx). Devus esti sufiĉe facile por vi sekvi la movon de la pakaĵeto tra la topologio rigardante la ceterajn spurojn en la dosiero.

5.3.2 PCAP-Spuro

La ns-3 Device Helpers ankaŭ povas esti uzata por krei spurdosierojn en .pcap formato. Akronimo pkap (kutime skribita en minusklo) signifas pakaĵkapton kaj estas fakte API kiu inkluzivas difini la .pcap dosierformaton. La plej populara programo kiu povas legi kaj montri ĉi tiun formaton estas Wireshark (antaŭe nomita Ethereal). Tamen ekzistas multaj analiziloj pri trafikspuroj, kiuj uzas ĉi tiun pakformaton. Ni instigas uzantojn uzi la multajn disponeblajn ilojn por analizi pcap-spurojn. En ĉi tiu lernilo ni koncentriĝos pri vidi pcap-spurojn uzante tcpdump.

Ebligi pcap-spuradon estas farita per unu linio de kodo.

pointToPoint.EnablePcapAll ("myfirst");

Algluu ĉi tiun linion de kodo post la ASCII-spurkodo, kiun ni ĵus aldonis scratch/myfirst.cc. Notu, ke ni nur pasis la ĉenon "myfirst", ne "myfirst.pcap" aŭ ion similan. Ĉi tio estas ĉar la parametro estas prefikso, ne plena dosiernomo. Dum la simulado, la asistanto efektive kreos spurdosieron por ĉiu punkto-al-punkta aparato. Dosiernomoj estos konstruitaj uzante la prefikson, nodan nombron, aparaton kaj sufikson ".pkap".

Por nia ekzempla skripto, ni finos vidi dosierojn nomitajn "miaunua-0-0.pcap"Kaj"miaunua-1-0.pcap", kiuj estas pcap-spuroj por nodo 0-aparato 0 kaj nodo 1-aparato 0 respektive. Post kiam vi aldonis la linion de kodo por ebligi pcap-spuradon, vi povas ruli la skripton laŭ la kutima maniero:

$ ./waf --run scratch/myfirst

Se vi rigardas en la plej altan dosierujon de via distribuo, vi devus vidi tri dosierojn: ASCII-spurdosiero mia unua.tr, kiujn ni antaŭe studis, dosierojn miaunua-0-0.pcap и miaunua-1-0.pcap - novaj pcap-dosieroj, kiujn ni ĵus generis.

Legante eliron per tcpdump

Nuntempe, la plej facila maniero por vidi pcap-dosierojn estas uzi 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

En la rubejo miaunua-0-0.pcap (klienta aparato) vi povas vidi, ke la eĥa pako estas sendita post 2 sekundoj da simulado. Se vi rigardas la duan rubejon (miaunua-1-0.pcap), vi vidos, ke la pako estas ricevita je 2,257324 sekundoj. Vi vidos en la dua rubejo, ke la pakaĵeto estas resendita je 2.257324 sekundoj, kaj finfine ke la pako estis ricevita reen de la kliento en la unua rubejo je 2.514648 sekundoj.

Legante Eligon per Wireshark

Se vi ne konas Wireshark, ekzistas retejo de kiu vi povas elŝuti programojn kaj dokumentadon: http://www.wireshark.org/. Wireshark estas GUI kiu povas esti uzata por montri ĉi tiujn spurdosierojn. Se vi havas Wireshark, vi povas malfermi iun ajn el la spurdosieroj kaj montri la enhavon kvazaŭ vi kaptis la pakaĵojn per pakaĵeto.

fonto: www.habr.com

Aldoni komenton