ProHoster > Blog > Stjórnsýsla > ns-3 nethermir kennsla. 5. kafli

ns-3 nethermir kennsla. 5. kafli

ns-3 nethermir kennsla. 5. kafli
kafli 1,2
kafli 3
kafli 4

5 Stilling
5.1 Notkun skráningareiningarinnar
5.1.1 Yfirlit yfir skógarhögg
5.1.2 Virkja skráningu
5.1.3 Að bæta skráningu við kóðann þinn
5.2 Notkun skipanalínurök
5.2.1 Hnekkja sjálfgefna eigindagildi
5.2.2 Handtaka eigin skipanir
5.3 Notkun rakningarkerfisins
5.3.1 ASCII rakning
Að greina ASCII ummerki
5.3.2 PCAP rakning

5 kafli

aðlögun

5.1 Notkun skráningareiningarinnar

Við skoðuðum nú þegar stuttlega ns-3 skráningareininguna með því að skoða handritið fyrst.cc. Í þessum kafla munum við skoða nánar mögulega notkun fyrir skráningarundirkerfið.

5.1.1 Yfirlit yfir skógarhögg

Mörg stór kerfi styðja einhvers konar skilaboðaskráningaraðstöðu og ns-3 er engin undantekning. Í sumum tilfellum eru aðeins villuboð skrifuð á "stjórnborðið" (sem er venjulega stderr á Unix-byggðum kerfum). Í öðrum kerfum geta viðvörunarskilaboð birst auk ítarlegri upplýsinga. Í sumum tilfellum eru skógarhöggverkfæri notuð til að gefa út villuleitarskilaboð sem geta fljótt gert úttakið óskýrt.

SubHRD sem notað er í ns-3 gerir ráð fyrir að öll þessi stig upplýsinga innihalds séu gagnleg og við bjóðum upp á sértæka, lagskiptu nálgun við skilaboðaskráningu. Hægt er að slökkva á skráningu algjörlega, virkja fyrir hverja íhluta eða á heimsvísu. Í þessu skyni er stillanlegt magn upplýsingaefnis notað. ns-3 skráningareiningin veitir tiltölulega einfalda leið til að fá gagnlegar upplýsingar úr uppgerðinni þinni.

Þú ættir að skilja að við bjóðum upp á almennan tilgang - rekja - til að draga gögn úr líkönunum þínum, sem ætti að vera ákjósanlegur framleiðsla fyrir uppgerð (fyrir frekari upplýsingar um rakningarkerfið okkar, sjá kennslukafla 5.3). Skráning ætti að vera ákjósanlegasta aðferðin til að afla villuleitarupplýsinga, viðvarana, villuboða eða til að senda fljótt út skilaboð úr skriftum þínum eða gerðum hvenær sem er.

Eins og er, skilgreinir kerfið sjö stig (gerðir) annálaskilaboða í vaxandi röð upplýsinga.

  • LOG_ERROR - villuboð við skráningu (tengd fjölvi: NS_LOG_ERROR);
  • LOG_WARN - Skrá viðvörunarskilaboð (tengd fjölvi: NS_LOG_WARN);
  • LOG_DEBUG - Skráðu tiltölulega sjaldgæf sérstök kembiforrit (tengd fjölvi: NS_LOG_DEBUG);
  • LOG_INFO - skráning upplýsingaskilaboða um framvindu forritsins (tengd fjölvi: NS_LOG_INFO);
  • LOG_FUNCTION - Skráir skilaboð sem lýsa hverri aðgerð sem kallast (tvö tengd fjölvi: NS_LOG_FUNCTION, notað fyrir meðlimaaðgerðir, og NS_LOG_FUNCTION_NOARGS, notað fyrir truflanir aðgerðir);
  • LOG_LOGIC - skráningarskilaboð sem lýsa rökréttu flæði innan falls (tengd fjölvi: NS_LOG_LOGIC);
  • LOG_ALL - Skráir allt sem nefnt er hér að ofan (engin tengd fjölvi).
    Fyrir hverja tegund (LOG_TYPE) er einnig LOG_LEVEL_TYPE sem, ef það er notað, gerir kleift að skrá öll stig fyrir ofan hana til viðbótar við sitt eigið stig. (Þar af leiðandi eru LOG_ERROR og LOG_LEVEL_ERROR, og LOG_ALL og LOG_LEVEL_ALL virkni jafngild.) Til dæmis, ef virkjað LOG_INFO leyfir aðeins skilaboð frá NS_LOG_INFO fjölva, en að virkja LOG_LEVEL_INFO mun einnig innihalda skeyti sem eru veitt af fjölvunum LOG_DE_LOGRN_LOGRNS, LOG_DE_LOGRN_LOGRNS, og

Við bjóðum einnig upp á skilyrðislaust skráningarmagni sem er alltaf birt, óháð skráningarstigi eða valhluta.

  • NS_LOG_UNCOND - Skilyrðislaus skráning á tengdum skilaboðum (ekkert tengt skráningarstig).

Hægt er að spyrjast fyrir um hvert stig fyrir sig eða uppsafnað. Hægt er að stilla skráningu með því að nota sh umhverfisbreytuna NS_LOG eða með því að skrá kerfisaðgerðakall. Eins og áður hefur komið fram hefur skógarhöggskerfið Doxygen skjöl og nú er góður tími til að fara yfir það ef þú hefur ekki gert það nú þegar.

Nú þegar þú hefur lesið skjölin í smáatriðum skulum við nota þá þekkingu til að fá áhugaverðar upplýsingar úr dæminu scratch/myfirst.ccsem þú hefur þegar tekið saman.

5.1.2 Virkja skráningu

Við skulum nota NS_LOG umhverfisbreytuna til að keyra fleiri logs, en fyrst, bara til að ná áttum, keyrðu síðasta skriftuna eins og þú gerðir áðan,

$ ./waf --run scratch/myfirst

Þú ættir að sjá kunnuglega úttakið frá fyrsta ns-3 dæmi forritinu

$ 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

Það kemur í ljós að „sendu“ og „mótteknu“ skilaboðin sem þú sérð hér að ofan eru í raun skráð skilaboð frá UdpEchoClientApplication и UdpEchoServerApplication. Til dæmis getum við beðið biðlaraforritið að prenta viðbótarupplýsingar með því að stilla skráningarstig þess í gegnum NS_LOG umhverfisbreytuna.

Héðan í frá ætla ég að gera ráð fyrir að þú sért að nota sh-líka skel sem notar "VARIABLE=value" setningafræðina. Ef þú ert að nota csh-líka skel, þá verður þú að breyta dæmunum mínum í "setenv breytugildi" setningafræði sem krafist er af þessum skeljum.

Eins og er, bregst UDP echo biðlaraforritið við eftirfarandi línu kóða í scratch/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Það gerir skráningarstigið LOG_LEVEL_INFO virkt. Þegar við förum framhjá skráningarstigi fána, virkum við í raun það stig og öll lægri stig. Í þessu tilviki höfum við virkjað NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN og NS_LOG_ERROR. Við getum aukið skráningarstigið og fengið frekari upplýsingar, án breytinga á skriftu og endursamsetningu, með því að stilla NS_LOG umhverfisbreytuna sem hér segir:

$ export NS_LOG=UdpEchoClientApplication=level_all

Svo við setjum sh skel breytuna NS_LOG á eftirfarandi gildi,

UdpEchoClientApplication=level_all

Vinstri hlið verkefnisins er nafn skráða hlutans sem við viljum stilla og hægra megin er fáninn sem við viljum sækja um. Í þessu tilfelli ætlum við að virkja öll stig villuleitar í forritinu. Ef þú keyrir skriftuna með NS_LOG stillt á þennan hátt mun ns-3 skráningarkerfið samþykkja breytingarnar og þú ættir að sjá eftirfarandi úttak:

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

Viðbótarupplýsingar um villuleit sem forritið veitir eru nú á NS_LOG_FUNCTION stigi. Það sýnir hvert tilvik af aðgerðakalli við framkvæmd handrits. Að jafnaði er æskilegt í aðferðaaðgerðum að nota (að minnsta kosti)NS_LOG_FUNCTION (this)... Notaðu NS_LOG_FUNCTION_NOARGS ()
aðeins í kyrrstæðum föllum. Athugaðu samt að ns-3 kerfið þarf ekki að styðja neina skráningarvirkni. Ákvörðun um hversu miklar upplýsingar eru skráðar er eftir einstökum gerðum líkansins. Þegar um bergmálsforrit er að ræða er mikið magn af skráningarúttak tiltækt.

Þú getur nú skoðað skrá yfir aðgerðarsímtöl sem voru gerðar af forritinu. Ef þú skoðar vel muntu taka eftir ristli á milli línunnar UdpEchoClientApplication og nafnið á aðferðinni, þar sem þú gætir búist við að sjá C++ scope operator (: :). Þetta er viljandi.

Þetta er í raun ekki nafn flokksins, heldur nafn skógarhöggsþáttarins. Þegar það er samsvörun á milli frumskrár og flokks er það venjulega nafnið á bekknum, en þú ættir að gera þér grein fyrir því að það er í rauninni ekki nafnið á bekknum og það er einn tvípunktur í stað tvípunkts. Þetta er leið til að hjálpa þér að aðskilja skógarhöggsbaunanafnið frá flokksheitinu á tiltölulega lúmskan hátt.

Hins vegar getur í sumum tilfellum verið erfitt að ákvarða hvaða aðferð er í raun að búa til logskilaboðin. Ef þú skoðar textann hér að ofan gætirðu verið að velta fyrir þér hvar línan "Received 1024 bytes from 10.1.1.2" Þú getur leyst þetta vandamál með því að stilla stigið forskeyti_func í NS_LOG umhverfisbreytuna. Prófaðu eftirfarandi:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Athugaðu að gæsalappirnar eru nauðsynlegar vegna þess að lóðrétta stikan sem við notum til að tákna OR-aðgerðina er einnig Unix píputengi. Nú ef þú keyrir handritið muntu sjá að skógarhöggskerfið tryggir að öll skilaboð í tilteknum annáli séu forskeyti með nafni íhluta.

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

Nú geturðu séð að öll skilaboð sem koma frá UDP echo biðlaraforritinu eru auðkennd sem slík. Skilaboð "Received 1024 bytes from 10.1.1.2" er nú greinilega auðkennt að það komi frá echo biðlaraforritinu. Skilaboðin sem eftir eru verða að koma frá UDP echo server forritinu. Við getum virkjað þennan þátt með því að slá inn lista yfir íhluti aðskilinn með ristli í NS_LOG umhverfisbreytunni.

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

Viðvörun: Í dæminu hér að ofan þarftu að fjarlægja nýlínustafinn á eftir tvípunktinum (:), hann er notaður til að forsníða skjalið. Nú ef þú keyrir handritið muntu sjá öll annálaskilaboðin frá echo forritunum fyrir biðlara og netþjón. Þú getur séð að þetta getur verið mjög gagnlegt þegar kembiforrit eru.

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

Það er líka stundum gagnlegt að geta séð uppgerðartímann þegar logskilaboðin voru mynduð. Þú getur gert þetta með því að bæta við OR bitanum forskeyti_tími:

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

Aftur, þú verður að fjarlægja ofangreindan nýlínustaf. Ef þú keyrir nú handritið ættirðu að sjá eftirfarandi úttak:

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

Vinsamlegast athugaðu að smiðurinn fyrir UdpEchoServer var hringt í uppgerð 0 sekúndur. Þetta gerist í raun áður en uppgerðin byrjar, en tíminn er sýndur sem núll sekúndur. Sama á við um smiðjuboðin 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()

Mundu að handritið scratch/first.cc byrjaði echo server forritið einni sekúndu áður en uppgerðin hófst. Nú geturðu séð að aðferðin Byrjaðu umsókn þjónninn er í raun kallaður á fyrstu sekúndu. Þú gætir líka tekið eftir því að echo viðskiptavinurinn byrjar á annarri sekúndu af uppgerðinni, eins og við spurðum í handritinu.

Þú getur nú fylgst með framvindu uppgerðarinnar á símtali Dagskrá Sending í biðlaranum sem kallar á HandleRead svarhringingu Senda í echo server forritinu. Athugaðu að tíminn sem líður til að senda pakka yfir punkt-til-punkt tengil er 3,69 millisekúndur. Þú getur séð að bergmálsþjónninn skráir skilaboð um að hann hafi svarað pakkanum og síðan, eftir seinkun á rásinni, sérðu að bergmálsþjónninn fær bergmálspakkann í HandleRead aðferð sinni.

Í þessari uppgerð gerist margt án þess að þú takir eftir því. En þú getur fylgst með öllu ferlinu mjög auðveldlega með því að virkja alla skráningarhluta í kerfinu. Prófaðu að stilla NS_LOG breytuna á eftirfarandi gildi,

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

Stjarnan hér að ofan er algildisstafur fyrir skógarhöggshlutann. Þetta mun innihalda allar færslur í öllum hlutum sem notaðir eru í uppgerðinni. Ég mun ekki endurskapa úttakið hér (þegar þetta er skrifað framleiðir það 1265 línur af úttak fyrir einn bergmálspakka), en þú getur beint þessum upplýsingum í skrá og skoðað þær í uppáhalds ritlinum þínum.

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

Ég persónulega nota þessa ákaflega margorðu útgáfu af skráningu þegar ég á í vandræðum og hef ekki hugmynd um hvar hlutirnir fóru úrskeiðis. Ég get fylgst með keyrslu kóða nokkuð auðveldlega án þess að setja brotpunkta og stíga í gegnum kóðann í villuleitarforritinu. Ég get bara breytt úttakinu í uppáhalds ritlinum mínum og leitað að því sem ég býst við og sé eitthvað gerast sem ég bjóst ekki við. Þegar ég hef almenna hugmynd um hvað er að fara úrskeiðis hoppa ég inn í villuleitina til að kafa ofan í vandamálið. Þessi tegund af framleiðsla getur verið sérstaklega gagnleg þegar handritið þitt gerir eitthvað algjörlega óvænt. Ef þú notar aðeins kembiforritið gætirðu misst af snúningi algjörlega. Skráning gerir slíkar beygjur áberandi.

5.1.3 Að bæta skráningu við kóðann þinn

Þú getur bætt nýjum færslum við uppgerðina þína með því að hringja í annálshlutann úr mörgum fjölvi. Gerum það í handriti myfirst.cc, sem við höfum í „hreinu“ möppunni. Mundu að við skilgreindum skógarhöggshluta í þessari atburðarás:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Þú ert meðvituð um að þú getur virkjað skráningu á öllum skilaboðum frá þessum íhlut með því að stilla NS_LOG umhverfisbreytuna á mismunandi stigum. Við skulum halda áfram og bæta nokkrum færslum við handritið. Fjölvi sem notaður er til að bæta upplýsingaskilaboðum við skrána er NS_LOG_INFO. Við skulum bæta við skilaboðum (rétt áður en við byrjum að búa til hnúta) sem segir þér að handritið sé í „Creating Topology“ áfanganum. Þetta er gert í eftirfarandi kóðabút,
Opnaðu scratch/myfirst.cc í uppáhalds ritlinum þínum og bættu við línunni,
NS_LOG_INFO ("Creating Topology");
rétt fyrir línurnar,

NodeContainer nodes;
nodes.Create (2);

Settu nú saman handritið með því að nota vaf, og hreinsaðu NS_LOG breytuna til að slökkva á skráningarstraumnum sem við kveiktum á áður:

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

Þú munt ekki sjá nýju skilaboðin vegna þess að tengdur skráningarhlutur (FirstScriptExample) hefur ekki verið virkjaður. Til að sjá skilaboðin þín þarftu að virkja skráningarhlutann FirstScriptExample með stigi ekki lægra en NS_LOG_INFO. Ef þú vilt bara sjá þetta tiltekna skráningarstig geturðu virkjað það svona,

$ export NS_LOG=FirstScriptExample=info

Ef þú keyrir handritið núna muntu sjá ný skilaboð "Creating 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 Notkun skipanalínurök

5.2.1 Hnekkja sjálfgefna eigindagildi

Önnur leið til að breyta hegðun ns-3 forskrifta án þess að breyta eða byggja upp er að nota skipanalínurök. Við bjóðum upp á kerfi til að flokka skipanalínurök og stilla sjálfkrafa staðbundnar og alþjóðlegar breytur byggðar á niðurstöðunum.

Fyrsta skrefið í notkun skipanalínu rifrildiskerfisins er að lýsa yfir skipanalínuþjálfara. Þetta er frekar auðvelt að gera (í aðalforritinu þínu), eins og í eftirfarandi kóða,

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

Þetta einfalda tveggja lína brot er í raun mjög gagnlegt í sjálfu sér. Það opnar dyrnar að ns-3 alþjóðlegu breytu- og eigindakerfinu. Við skulum bæta tveimur línum af kóða við upphaf aðalskriftaraðgerðarinnar scratch/myfirst.cc. Áfram tökum við saman handritið og keyrum það, þegar við keyrum sendum við beiðni um hjálp sem hér segir,

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

Þessi skipun mun spyrja Waf keyra handrit klóra/myfirst og sendu því skipanalínurök —PrintHelp. gæsalappirnar eru nauðsynlegar til að gefa til kynna í hvaða forriti röksemdafærslan er ætluð. Skipanalínuþáttarinn mun greina rökin —PrintHelp og mun birta svarið,

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.

Nú skulum við líta á valkostinn —PrintEiginleikar. Við höfum þegar nefnt ns-3 eigindakerfið þegar við skoðum first.cc forskriftina. Við höfum séð eftirfarandi kóðalínur,

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

ok sögðu þat Gagnahraði er í raun eiginleiki PointToPointNetDevice. Við skulum nota skipanalínugreiningarþáttinn til að skoða eiginleikana PointToPointNetDevice. Hjálparlistinn segir hvað við verðum að veita TypeId. Þetta er nafnið á þeim flokki sem eiginleikar áhuga tilheyra. Í okkar tilviki mun það vera ns3::PointToPointNetDevice. Við skulum halda áfram, slá inn,

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

Kerfið mun prenta alla eiginleika þessarar nettækjagerðar. Þú munt sjá að meðal eiginleikanna á listanum eru,

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

Þetta er sjálfgefið gildi sem verður notað af kerfinu þegar hluturinn er búinn til PointToPointNetDevice. Við munum hnekkja þessu sjálfgefna gildi með því að nota færibreytuna Eigindi в PointToPointHelper hærri. Við skulum nota sjálfgefna gildin fyrir punkt-til-punkt tæki og rásir. Til að gera þetta munum við eyða símtölum SetDeviceAttribute и SetChannelAttribute á myfirst.cc, sem við höfum í hreinni möppu.

Handritið þitt ætti nú einfaldlega að lýsa yfir PointToPointHelper og ekki framkvæma neinar uppsetningaraðgerðir eins og sýnt er í dæminu hér að neðan,

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

Farðu á undan og búðu til nýtt handrit með Waf (./vaf) og við skulum fara til baka og setja inn einhverja færslu frá UDP echo server forritinu og láta tímaforskeytið fylgja með.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Ef þú keyrir handritið ættirðu að sjá eftirfarandi úttak:

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

Mundu að síðast þegar við skoðuðum eftirlíkingartímann, um leið og pakkinn var móttekinn af bergmálsþjóninum, var hann 2,00369 sekúndur.

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

Nú fær hann pakkann á 2.25732 sekúndum. Þetta er vegna þess að við endurstillum einfaldlega PointToPointNetDevice gagnahraðann úr fimm megabitum á sekúndu í sjálfgefið gildi, sem er 32768 bitar á sekúndu. Ef við myndum skipta út nýjum DataRate með því að nota skipanalínuna gætum við hraðað uppgerðinni okkar aftur. Við munum gera þetta sem hér segir, samkvæmt formúlunni sem hjálparþátturinn gefur til kynna:

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

Þetta mun skila DataRate eigindinni í sjálfgefið gildi sem er fimm megabitar á sekúndu. Ertu hissa á niðurstöðunni? Það kemur í ljós að til þess að skila upprunalegu hegðun handritsins þurfum við líka að stilla rástöfina til að passa við ljóshraðann. Við getum beðið skipanalínukerfið að prenta rásareiginleikana, alveg eins og við gerðum fyrir nettækið:

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

Við munum komast að því að eigindurinn fyrir rás seinkun er stilltur sem hér segir:

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

Við getum síðan, í gegnum skipanalínukerfið, stillt bæði þessi sjálfgefna gildi.

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

í þessu tilfelli endurheimtum við þann tíma sem við höfðum þegar við stilltum gagngert DataRate og Delay í handritinu:

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

Athugaðu að pakkinn er móttekin af þjóninum aftur eftir 2,00369 sekúndur. Við gætum í raun stillt hvaða eiginleika sem er notað í handritinu á þennan hátt. Sérstaklega gætum við stillt MaxPackets eiginleikana á ekki eitt gildi UdpEchoClient.

Hvernig myndir þú nota það? Reyndu. Mundu að þú verður að gera athugasemdir við staðinn þar sem við hnekum sjálfgefna eigindargildinu og beinlínis stillt MaxPackets í handritinu. Þá verður þú að endurbyggja handritið. Þú getur líka notað skipanalínuna til að fá setningafræðihjálp til að stilla nýtt sjálfgefið eigindargildi. Þegar þú hefur skilið þetta geturðu stjórnað fjölda pakka sem birtast á skipanalínunni. Þar sem við erum vandvirkt fólk ætti skipanalínan okkar að líta einhvern veginn svona út:

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

Eðlilega spurningin sem vaknar á þessum tímapunkti er hvernig á að vita um tilvist allra þessara eiginleika. Aftur, skipanalínukerfið hefur hjálparaðgerð fyrir þetta mál. Ef við biðjum skipanalínuna um hjálp ættum við að sjá:

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

Ef þú velur "PrintGroups" rökin ættir þú að sjá lista yfir alla skráða hópa TypeId. Hópnöfnin eru í samræmi við nöfn eininga í upprunaskránni (að vísu með hástöfum). Það væri of umfangsmikið að prenta allar upplýsingarnar í einu, þannig að aukasía er tiltæk til að prenta upplýsingar eftir hópum. Svo, aftur með áherslu á punkt-til-punkt eininguna:

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

Hér getur þú fundið tiltæk TypeId nöfn fyrir eigindauppflettingar, til dæmis í
--PrintAttributes = ns3 :: PointToPointChanneleins og sýnt er hér að ofan.

Önnur leið til að læra um eiginleika er í gegnum Doxygen ns-3. Það er síða sem sýnir alla eiginleika sem skráðir eru í herminum.

5.2.2 Handtaka eigin skipanir

Þú getur líka bætt við þínum eigin krókum í gegnum skipanalínukerfið. Þetta er einfaldlega gert með því að nota skipanalínuþáttunaraðferðina AddValue.
Við skulum nota þennan eiginleika til að tilgreina fjölda pakka sem á að sýna á allt annan hátt. Bætum við staðbundinni breytu sem heitir nPakkar í fall helstu. Við munum stilla það á einn til að passa við fyrri sjálfgefna hegðun okkar. Til að leyfa skipanalínuþáttaranum að breyta þessu gildi þurfum við að fanga þetta gildi í þáttaranum. Þetta gerum við með því að bæta við símtali AddValue. Farðu og breyttu handritinu scratch/myfirst.cc svo til að byrja með eftirfarandi kóða,

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

Skrunaðu niður að þeim stað í handritinu þar sem við stillum MaxPackets eigindina og breytum því þannig að það sé stillt á nPackets breytuna í stað fastans 1, eins og sýnt er hér að neðan.

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

Nú ef þú keyrir handritið og gefur upp -PrintHelp rökin, þá ættir þú að sjá nýju notandarökin. skráð á hjálparskjánum. Koma inn,

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

Ef þú vilt breyta fjölda sendra pakka geturðu gert það með því að stilla skipanalínurökin - -nPackets.

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

Nú ættirðu nú að sjá

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

Þú hefur nú sent tvo pakka. Frekar einfalt, er það ekki?
Þú getur séð að sem ns-3 notandi geturðu notað skipanalínu rifrildiskerfið til að vinna með alþjóðleg gildi og eiginleika. Ef þú ert höfundur líkansins geturðu bætt nýjum eiginleikum við hlutina þína og þeir verða sjálfkrafa aðgengilegir fyrir notendur þína í gegnum skipanalínukerfið. Ef þú ert handritahöfundur geturðu bætt nýjum breytum við forskriftirnar þínar og tengt þær óaðfinnanlega við skipanalínukerfið þitt.

5.3 Notkun rakningarkerfisins

Allur tilgangurinn með líkanagerð er að búa til úttak til frekari rannsókna, og ns-3 snefilkerfið er aðalbúnaðurinn fyrir þetta. Þar sem ns-3 er C++ forrit er hægt að nota staðlaðar leiðir til að búa til úttak úr C++ forriti:

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

Þú getur jafnvel notað skráningareiningu til að bæta smá uppbyggingu við lausnina þína. Það eru mörg þekkt vandamál af völdum þessarar nálgun og því höfum við útvegað almennt atburðarekningarkerfi til að leysa þessi vandamál.

Helstu markmið ns-3 rakningarkerfisins eru:

  • Fyrir grunnverkefni ætti rakningarkerfið að gera notandanum kleift að búa til staðlaða rakningu fyrir vinsælar heimildir og velja hluti sem búa til rakninguna;

  • Meðalnotendur ættu að geta stækkað rakningarkerfið til að breyta mynduðu úttakssniði eða til að setja inn nýjar rakningargjafa, án þess að breyta hermirkjarnanum;

  • Háþróaðir notendur geta breytt hermikjarnanum til að bæta við nýjum rekjagjöfum og vaskum. ns-3 rakningarkerfið er byggt á meginreglum óháðra rakningargjafa og móttakara, auk sameinaðs kerfis til að tengja heimildir við neytendur.

ns-3 rakningarkerfið er byggt á meginreglum óháðra rakningargjafa og móttakara, auk sameinaðs kerfis til að tengja heimildir við viðtæki. Sporgjafar eru hlutir sem geta gefið til kynna atburði sem eiga sér stað í uppgerðinni og veita aðgang að undirliggjandi gögnum sem vekja áhuga. Til dæmis getur rakningargjafi gefið til kynna hvenær nettæki fékk pakka og gert innihald pakkans aðgengilegt fyrir áhugasama rakningarmóttakara.

Sporheimildir einar og sér eru gagnslausar nema þær séu „tengdar“ við aðra hluta kóðans sem raunverulega gera eitthvað gagnlegt við upplýsingarnar sem vaskurinn gefur. Sporefni eru neytendur atburða og gagna sem rekja heimildir. Til dæmis er hægt að búa til rekja vask sem mun (þegar hann er tengdur við rekja uppsprettu fyrra dæmis) prenta út áhugaverða hluta í mótteknum pakka.

Rökin fyrir þessum skýra aðskilnaði eru að leyfa notendum að tengja nýjar vaskagerðir við núverandi rakauppsprettur án þess að þurfa að breyta og setja saman hermirkjarnann aftur. Þannig að í dæminu hér að ofan getur notandinn skilgreint nýjan rakara í handritinu sínu og tengt það við núverandi rakningargjafa sem er skilgreindur í hermikjarnanum aðeins með því að breyta notendahandritinu.

Í þessari kennslu munum við fara í gegnum nokkrar af fyrirfram skilgreindum heimildum og vaskum og sýna hvernig hægt er að stilla þær með minnstu fyrirhöfn af hálfu notandans. Sjáðu ns-3 handbókina eða leiðbeiningarhlutana til að fá upplýsingar um háþróaða rekjastillingar, þar á meðal að stækka nafnasvæðið og búa til nýjar rakningarheimildir.

5.3.1 ASCII rakning

ns-3 veitir hjálparvirkni sem veitir lágstigs rakningarkerfi til að hjálpa þér með smáatriðin þegar þú setur upp einföld pakkaspor. Ef þú virkjar þennan eiginleika muntu sjá úttakið í ASCII skrám. Fyrir þá sem þekkja til ns-2 úttaks er þessi tegund af rekstri svipuð og út.tr, sem er búið til af mörgum skriftum.

Við skulum taka til hendinni og bæta nokkrum ASCII rakningarniðurstöðum við scratch/myfirst.cc handritið okkar. Rétt fyrir símtalið Simulator :: Run (), bætið við eftirfarandi línum af kóða:
AsciiTraceHelper ascii;

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

Eins og mörg önnur ns-3 orðatiltæki notar þessi kóði hjálparhlut til að búa til ASCII spor. Önnur línan inniheldur tvö hreiður aðferðaköll. "Inní" aðferð CreateFileStream() notar orðatiltækið fyrir nafnlausa hluti til að búa til skráarstraumshlut á stafla (án nafns hlutar) og sendir það til aðferðarinnar sem kallað er. Við munum fara dýpra í þetta í framtíðinni, en allt sem þú þarft að vita á þessum tímapunkti er að þú ert að búa til hlut sem táknar skrá sem heitir myfirst.tr og færðu það yfir á ns-3. Við felum ns-3 að sjá um skapaðan hlut allan líftíma hans, á meðan hann leysir vandamál sem stafa af lítt þekktri (viljandi) takmörkun sem tengist C++ straumshluta afritunarframleiðendum.

Ytra símtal Virkja AsciiAll() segir aðstoðarmanninum að þú viljir hafa ASCII rakningu með í uppgerðinni þinni fyrir allar punkt-til-punkt tækjatengingar og að þú viljir að (tilgreindir) rakningarmóttakarar skrái upplýsingar um pakkahreyfingar á ASCII sniði.

Fyrir þá sem þekkja til ns-2 eru raktir atburðir jafngildir þekktum rakningarpunktum sem skrá atburði "+", "-", "d" og "r".
Nú geturðu smíðað handritið og keyrt það frá skipanalínunni:

$ ./waf --run scratch/myfirst

Eins og oft áður muntu sjá nokkur skilaboð frá Waf, og síðan „byggja“ lokið með góðum árangri“ með nokkrum skilaboðum frá forritinu sem er í gangi.

Þegar það er keyrt mun forritið búa til skrá sem heitir myfirst.tr. Vegna eðlis verksins Waf, sjálfgefið er skráin ekki búin til í staðbundinni skrá, heldur í efstu möppu geymslunnar. Ef þú vilt breyta slóðinni þar sem spor eru vistuð, þá geturðu notað Waf færibreytuna til að tilgreina hana --cwd. Við höfum ekki gert þetta, svo til að skoða ASCII rekja skrána myfirst.tr í uppáhalds ritlinum þínum, þurfum við að fara í efstu möppuna í geymslunni okkar.

Að greina ASCII ummerki

Það er mikið af upplýsingum þarna í nokkuð þéttu formi, en það fyrsta sem þú þarft að taka eftir er að skráin samanstendur af einstökum línum. Þetta verður greinilega sýnilegt ef þú stækkar útsýnisgluggann breiðari.

Hver lína í skránni samsvarar rekja atburði. Í þessu tilviki rekjum við atburði í sendingarröðinni sem er til staðar í hverju punkti netkerfi í uppgerðinni. Sendingarröðin er biðröðin sem hver pakki þarf að fara í gegnum fyrir punkt-til-punkt tengil. Athugaðu að hver lína í rekjaskránni byrjar á einum staf (og hefur bil á eftir honum). Þetta tákn mun hafa eftirfarandi merkingu:

+: biðröð aðgerð átti sér stað í biðröð tækisins;
-: aðgerð til að sækja einingar átti sér stað í tækjaröðinni;
d: pakkinn var sleppt, venjulega vegna þess að röðin var full;
r: Pakkinn var móttekinn af nettæki.

Við skulum skoða nánar fyrstu línuna í rekjaskránni. Ég mun skipta því niður í hluta (með inndráttum til skýringar) og línunúmerið til vinstri:

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)

Fyrsti hluti þessa útbreidda rekja atburðar (lína 0) er aðgerðin. Við höfum + tákn hér, sem samsvarar aðgerðinni á biðröð fyrir sendingu. Annar hlutinn (lína 1) er hermitíminn, gefinn upp í sekúndum. Þú manst kannski hvað við spurðum UdpEchoClientApplication byrjaðu að senda pakka eftir tvær sekúndur. Hér sjáum við staðfestingu á því að þetta er sannarlega að gerast.

Næsti hluti af rekja dæminu (frá línu 2) sýnir hvaða rekja uppspretta myndaði þennan atburð (sem gefur til kynna nafnrýmissporið). Þú getur hugsað um rekjanafnsvæðið svipað og nafnrými skráakerfis. Rót nafnrýmisins er NodeList. Þetta samsvarar gámnum sem stjórnað er í aðal ns-3 kóðanum. Það inniheldur alla hnúta sem eru búnir til í handritinu. Rétt eins og skráarkerfi getur haft möppur í rótinni, NodeList við getum haft marga hnúta. Þannig að línan /NodeList/0 vísar til núllhnútsins í NodeList, sem við hugsum venjulega um sem "hnút 0". Hver hnút hefur lista yfir tæki sem hafa verið sett upp. Þessi listi er næst í nafnarýminu. Þú getur séð að þessi rekja atburður kemur frá Tækjalisti/0, sem er núll tækið sem er uppsett í hnútnum.

Næsti undirstrengur, $ ns3 :: PointToPointNetDevice, segir hvaða tæki er í stöðu núll: tækjalisti yfir hnút núll. Mundu að + aðgerðin sem fannst í línu 0 þýddi að einingu var bætt við sendingarröð tækisins. Þetta endurspeglast í síðustu hluta „brautarstígsins“: TxQueue/Enqueue.

Hlutarnir sem eftir eru í rekstrinum ættu að vera nokkuð leiðandi. Línur 3-4 gefa til kynna að pakkinn sé hjúpaður í punkt-til-punkt siðareglur. Línur 5-7 sýna að pakkinn er með IP4 útgáfuhaus og er upprunninn í IP tölunni 10.1.1.1 og er ætlað fyrir 10.1.1.2. Línur 8-9 sýna að þessi pakki er með UDP haus og að lokum sýnir lína 10 að farmurinn er væntanleg 1024 bæti.

Næsta lína í rekjaskránni sýnir að sami pakki var dreginn úr sendingarröðinni á sama hnút.

Þriðja línan í rekjaskránni sýnir að pakkinn var móttekinn af nettæki á echo netþjóninum. Ég hef endurskapað atburðinn hér að neðan.

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)

Athugið að rekja aðgerðin er nú r og hermitíminn hefur verið aukinn í 2,25732 sekúndur. Ef þú fylgdir kennslunni vandlega þýðir þetta að þú skildir eftir DataRate og Link Delay nettækjanna á sjálfgefnum gildum. Þessi tíð ætti að vera kunnugleg eins og þú sást í fyrri hlutanum.

Nafnarýmisfærslunni fyrir rekjauppsprettu (lína 2) hefur verið breytt til að endurspegla að þessi atburður kemur frá hnút 1 (/NodeList/1) og pakkinn er móttekinn af rekjagjafanum (/MacRx). Það ætti að vera frekar auðvelt fyrir þig að fylgjast með hreyfingu pakkans í gegnum svæðisfræðina með því að skoða ummerkin sem eftir eru í skránni.

5.3.2 PCAP rakning

Einnig er hægt að nota ns-3 tækjahjálpina til að búa til rakningarskrár á .pcap sniði. Skammstöfun pcap (venjulega skrifað með lágstöfum) stendur fyrir pakkafanga og er í raun API sem felur í sér að skilgreina .pcap skráarsniðið. Vinsælasta forritið sem getur lesið og sýnt þetta snið er Wireshark (áður kallað Ethereal). Hins vegar eru margir umferðarsporagreiningartæki sem nota þetta pakkasnið. Við hvetjum notendur til að nota þau fjölmörgu verkfæri sem til eru til að greina pcap spor. Í þessari kennslu munum við einbeita okkur að því að skoða pcap spor með því að nota tcpdump.

Að virkja pcap rekja er gert með einni línu af kóða.

pointToPoint.EnablePcapAll ("myfirst");

Límdu þessa kóðalínu á eftir ASCII rekja kóðanum sem við bættum inn í scratch/myfirst.cc. Athugaðu að við sendum bara strenginn "myfirst", ekki "myfirst.pcap" eða eitthvað álíka. Þetta er vegna þess að færibreytan er forskeyti, ekki fullt skráarnafn. Meðan á uppgerðinni stendur mun aðstoðarmaðurinn í raun búa til rakningarskrá fyrir hvert punkt-til-punkt tæki. Skráarnöfn verða smíðuð með forskeyti, hnútnúmeri, tækisnúmeri og viðskeytinu ".pcap'.

Fyrir dæmi skriftu okkar munum við enda með því að sjá skrár sem heita "myfirst-0-0.pcap"Og"myfirst-1-0.pcap", sem eru pcap spor fyrir hnút 0-tæki 0 og hnút 1-tæki 0 í sömu röð. Þegar þú hefur bætt við kóðalínunni til að virkja pcap rakningu geturðu keyrt skriftuna á venjulegan hátt:

$ ./waf --run scratch/myfirst

Ef þú skoðar efstu möppuna í dreifingunni þinni ættirðu að sjá þrjár skrár: ASCII rekja skrá myfirst.tr, sem við höfum áður rannsakað, skrár myfirst-0-0.pcap и myfirst-1-0.pcap - nýjar pcap skrár sem við bjuggum til.

Að lesa úttak með tcpdump

Í bili er auðveldasta leiðin til að skoða pcap skrár að nota 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

Í sorphaugnum myfirst-0-0.pcap (viðskiptavinur tæki) þú getur séð bergmál pakkinn er sendur eftir 2 sekúndur af uppgerð. Ef þú horfir á seinni sorphauginn (myfirst-1-0.pcap), muntu sjá að pakkinn er móttekinn á 2,257324 sekúndum. Þú munt sjá á seinni tappinu að pakkanum er skilað eftir 2.257324 sekúndur og að lokum að pakkinn var móttekinn til baka af viðskiptavininum í fyrsta tappinu á 2.514648 sekúndum.

Lestrarúttak með Wireshark

Ef þú ert ekki kunnugur Wireshark, það er vefsíða þar sem þú getur hlaðið niður forritum og skjölum: http://www.wireshark.org/. Wireshark er GUI sem hægt er að nota til að sýna þessar rakningarskrár. Ef þú ert með Wireshark geturðu opnað hvaða rekjaskrár sem er og birt innihaldið eins og þú hefðir tekið pakkana með því að nota pakkaþefur.

Heimild: www.habr.com

Bæta við athugasemd