🥇Handleiding voor de netwerksimulator ns-3. Hoofdstuk 5

hoofdstukken 1,2
hoofdstuk 3
hoofdstuk 4

5 Configuratie
5.1 Gebruik van de loggingmodule
5.1.1 Overzicht van logging
5.1.2 Logging inschakelen
5.1.3 Logging aan uw code toevoegen
5.2 Gebruik van commando-argumenten
5.2.1 Vervangen van standaardattributwaarden
5.2.2 Uw eigen commando's vastleggen
5.3 Gebruik van het tracing-systeem
5.3.1 ASCII Traceren
Parseren van ASCII-tracering
5.3.2 PCAP Tracering

Hoofdstuk 5

Instellingen

5.1 Gebruik van de loggingmodule

We hebben al kort gekeken naar de loggingmodule van ns-3, terwijl we het script first.cc. In dit hoofdstuk zullen we dieper ingaan op de mogelijkheden van de logging subsystem.

5.1.1 Overzicht van logging

Veel grote systemen ondersteunen een of andere vorm van logboekregistratie, en ns-3 is daarop geen uitzondering. In sommige gevallen worden alleen foutmeldingen geschreven naar de 'operatorconsole' (die doorgaans stderr is in op Unix gebaseerde systemen). In andere systemen kunnen waarschuwingsberichten en meer gedetailleerde informatie worden weergegeven. In sommige gevallen worden logging-systemen gebruikt om debug-informatie weer te geven, die de uitvoer snel kan ‘vervagen’.

De benadering die in ns-3 wordt gebruikt, impliceert dat al deze niveaus van informatie nuttig zijn, en we bieden een selectieve, gelaagde aanpak voor logboekregistratie. Logging kan volledig worden uitgeschakeld, ingeschakeld voor specifieke componenten of globaal. Dit wordt gedaan met configureerbare informatieniveaus. De loggingmodule van ns-3 biedt een relatief eenvoudige manier om nuttige informatie uit uw simulatie te halen.

U moet begrijpen dat we een algemeen mechanisme bieden — tracing — om gegevens uit uw modellen te extraheren, dat de voorkeur moet hebben voor uitvoer tijdens modellering (voor meer gedetailleerde informatie over ons tracing-systeem, zie sectie 5.3 van de handleiding). Logging moet de voorkeur genieten voor het verkrijgen van debug-informatie, waarschuwingen, foutmeldingen, of om snel berichten uit uw scripts of modellen op elk moment weer te geven.

Momenteel zijn er zeven niveaus (typen) van logberichten gedefinieerd in het systeem, gerangschikt op oplopende informativiteit.

LOG_ERROR — registratie van foutmeldingen (gerelateerde macro: NS_LOG_ERROR);
LOG_WARN — registratie van waarschuwingen (gerelateerde macro: NS_LOG_WARN);
LOG_DEBUG — registratie van relatief zeldzame speciale debugberichten (gerelateerde macro: NS_LOG_DEBUG);
LOG_INFO — registratie van informatieve berichten over de voortgang van het programma (gerelateerde macro: NS_LOG_INFO);
LOG_FUNCTION — registratie van berichten die elke aangeroepen functie beschrijven (twee gerelateerde macro's: NS_LOG_FUNCTION, gebruikt voor lidfuncties, en NS_LOG_FUNCTION_NOARGS, gebruikt voor statische functies);
LOG_LOGIC — registratie van berichten die de logische stroom binnen een functie beschrijven (gerelateerde macro: NS_LOG_LOGIC);
LOG_ALL — registratie van alles wat hierboven is vermeld (er is geen gerelateerde macro).
Voor elk type (LOG_TYPE) is er ook een type LOG_LEVEL_TYPE, dat, wanneer gebruikt, toestaat om naast zijn eigen niveau alle niveaus daarboven te registreren. (Als gevolg hiervan zijn LOG_ERROR en LOG_LEVEL_ERROR, evenals LOG_ALL en LOG_LEVEL_ALL functioneel equivalent.) Bijvoorbeeld, het inschakelen van LOG_INFO staat alleen berichten toe die worden verstrekt door de macro NS_LOG_INFO, terwijl met het inschakelen van LOG_LEVEL_INFO ook berichten die zijn verstrekt door de macro's NS_LOG_DEBUG, NS_LOG_WARN en NS_LOG_ERROR worden opgenomen.

We bieden ook een macro voor onvoorwaardelijke logging, die altijd wordt weergegeven, ongeacht het loggingniveau of de geselecteerde component.

NS_LOG_UNCOND — onvoorwaardelijke registratie van het gerelateerde bericht (zonder gerelateerd loggingniveau).

Elk niveau kan afzonderlijk of cumulatief worden opgevraagd. Logging kan worden ingesteld met behulp van de omgevingsvariabele NS_LOG of door middel van het registreren van een aanroep naar een systeemfunctie. Zoals eerder werd aangetoond, heeft het logging systeem Doxygen-documentatie en is het nu de tijd om dit te bekijken, als je dat nog niet hebt gedaan.

Nu je de documentatie zeer grondig hebt gelezen, laten we deze kennis gebruiken om interessante informatie uit een voorbeeldscript te halen. scratch/myfirst.cc, dat je al hebt gecompileerd.

5.1.2 Logging inschakelen

Laten we de omgevingsvariabele NS_LOG gebruiken om nog wat logboeken te starten, maar eerst, gewoon om weer op de hoogte te zijn, voer het laatste script uit zoals je eerder deed,

$ ./waf --run scratch/myfirst

Je zou de al bekende output van het eerste voorbeeldprogramma ns-3 moeten zien.

$ Waf: Voer directory `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build' binnen
Waf: Verlaat directory `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build' 'build'
met succes voltooid (0.413s)
Verzonden 1024 bytes naar 10.1.1.2
Ontvangen 1024 bytes van 10.1.1.1
Ontvangen 1024 bytes van 10.1.1.2

Het blijkt dat de "verzonden" en "ontvangen" berichten die je hierboven ziet in feite geregistreerde berichten zijn van UdpEchoClientApplication en UdpEchoServerApplication. Bijvoorbeeld, we kunnen het clientapplicatie vragen om extra informatie af te drukken door het logniveau in te stellen via de omgevingsvariabele NS_LOG.

Vanaf dit moment ga ik ervan uit dat je een sh-achtige shell gebruikt die de syntaxis "VARIABLE = value" gebruikt. Als je een csh-achtige shell gebruikt, moet je mijn voorbeelden omzetten naar de syntaxis "setenv variabele waarde" die door die shells vereist wordt.

Momenteel reageert de UDP echo-client op de volgende regel code in scratch/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Dit activeert het logniveau LOG_LEVEL_INFO. Wanneer we een logniveau-vlag doorgeven, schakelen we daadwerkelijk dat niveau en alle lagere niveaus in. In dit geval hebben we NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN en NS_LOG_ERROR ingeschakeld. We kunnen het logniveau verhogen en meer informatie krijgen zonder de script te wijzigen of opnieuw te compileren, door de omgevingsvariabele NS_LOG als volgt in te stellen:

$ export NS_LOG=UdpEchoClientApplication=level_all

Zo stellen we de volgende waarde voor de NS_LOG-variabele in de sh-shell in,

UdpEchoClientApplication=level_all

De linkerkant van de toewijzing is de naam van de gelogde component die we willen configureren, en de rechterkant is de vlag die we daarvoor willen toepassen. In dit geval gaan we alle debugniveaus in de applicatie inschakelen. Als je het script uitvoert met de zo ingestelde NS_LOG, zal het ns-3 loggingsysteem de wijzigingen accepteren en je zou de volgende uitvoer moeten zien:

Waf: Voer directory `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build' binnen
Waf: Verlaat directory `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' met succes voltooid (0.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Verzonden 1024 bytes naar 10.1.1.2
Ontvangen 1024 bytes van 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Ontvangen 1024 bytes van 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

De aanvullende foutopsporingsinformatie die door de applicatie wordt geleverd, komt nu overeen met het niveau NS_LOG_FUNCTION. Het toont elke aanroep van functies tijdens het uitvoeren van het script. Over het algemeen is het in methoden van functies het beste om (minimaal) te gebruikenNS_LOG_FUNCTION (this). Gebruik NS_LOG_FUNCTION_NOARGS ()
alleen in statische functies. Houd er echter rekening mee dat er in het ns-3-systeem geen vereisten zijn om enige loggingfunctionaliteit te ondersteunen. De beslissing over hoeveel informatie wordt gelogd, ligt volledig bij de modelontwikkelaar. In het geval van echo-applicaties is er een grote hoeveelheid uitvoer beschikbaar voor logging.

Nu kunt u het logboek bekijken van de functieaanroepen die door de applicatie zijn gedaan. Als u goed kijkt, zult u een dubbele punt zien tussen de regel UdpEchoClientApplication en de naam van de methode, op de plek waar u misschien de C++ scope operator (: :) had verwacht. Dit is opzettelijk gedaan.

Het is eigenlijk niet de naam van de klasse, maar de naam van de loggingcomponent. Wanneer er een overeenkomst is tussen het bronbestand en de klasse, is dit meestal de naam van de klasse, maar u moet begrijpen dat dit in feite niet de naam van de klasse is en dat er één dubbele punt staat in plaats van een dubbele dubbele punt. Dit is een manier om u op een subtiele manier te helpen het conceptueel te scheiden van de naam van de component van de naam van de klasse.

Toch kan het in sommige gevallen moeilijk zijn om te bepalen welke methode daadwerkelijk het logbericht genereert. Als u kijkt naar de bovenstaande tekst, zult u zich afvragen waar de regel "Ontvangen 1024 bytes van 10.1.1.2" vandaan komt. U kunt dit probleem oplossen door het niveau prefix_func in de omgevingsvariabele NS_LOG in te stellen. Probeer het volgende:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Houd er rekening mee dat de aanhalingstekens nodig zijn, omdat de verticale lijn die we gebruiken om de OF-operatie aan te geven ook een Unix-pijpunieter is. Nu, als u het script uitvoert, zult u zien dat het loggingsysteem ervoor zorgt dat elk bericht uit dit log een prefix heeft met de naam van de component.

Waf: Binnenkomend in map `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Verlaten uit map `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' is succesvol voltooid (0.417s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): 1024 bytes verzonden naar 10.1.1.2
Ontvangen 1024 bytes van 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
UdpEchoClientApplication:HandleRead(): Ontvangen 1024 bytes van 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Nu kun je zien dat alle berichten die van de UDP echo-client applicatie komen, als zodanig zijn geïdentificeerd. Het bericht 'Ontvangen 1024 bytes van 10.1.1.2' is nu duidelijk gedefinieerd als afkomstig van de echo-client applicatie. Het resterende bericht moet van de UDP echo-server applicatie komen. We kunnen deze component inschakelen door een lijst van componenten, gescheiden door dubbele punten, in de omgevingsvariabele NS_LOG in te voeren.

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

Waarschuwing: in het bovenstaande voorbeeld moet je de nieuwe regel na de dubbele punt (:) verwijderen; deze is gebruikt voor documentopmaak. Nu, als je het script uitvoert, zie je alle logberichten van de client- en server-echosystemen. Je zult merken dat dit erg nuttig kan zijn bij het debuggen.

Waf: Binnenkomend in map `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Verlaten uit map `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' is succesvol voltooid (0.406s)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoServerApplication:StartApplication()
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): 1024 bytes verzonden naar 10.1.1.2
UdpEchoServerApplication:HandleRead(): 1024 bytes ontvangen van 10.1.1.1
UdpEchoServerApplication:HandleRead(): Echo van pakket
UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
UdpEchoClientApplication:HandleRead(): Ontvangen 1024 bytes van 10.1.1.2
UdpEchoServerApplication:StopApplication()
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Het kan ook nuttig zijn om het simulatie tijdstip waarop het logbericht is gemaakt te zien. Je kunt dit doen door de IER bit toe te voegen prefix_time:

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

Nogmaals, je moet de nieuwe regel hierboven verwijderen. Als je nu het script uitvoert, zou je de volgende output moeten zien:

Waf: Ingang van directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' Waf: Verlaat directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' 'build' succesvol afgesloten (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(): Verstuurd 1024 bytes naar 10.1.1.2 2.00369s UdpEchoServerApplication:HandleRead(): Ontvangen 1024 bytes van 10.1.1.1 2.00369s UdpEchoServerApplication:HandleRead(): Echo van pakket 2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0) 2.00737s UdpEchoClientApplication:HandleRead(): Ontvangen 1024 bytes van 10.1.1.2 10s UdpEchoServerApplication:StopApplication() 10s UdpEchoClientApplication:StopApplication() UdpEchoClientApplication:DoDispose() UdpEchoServerApplication:DoDispose() UdpEchoClientApplication:~UdpEchoClient() UdpEchoServerApplication:~UdpEchoServer()

Let op dat de constructeur voor UdpEchoServer werd aangeroepen tijdens simulatie 0 seconden. Dit gebeurt eigenlijk vóór het begin van de simulatie, maar deze tijd wordt weergegeven als nul seconden. Hetzelfde geldt voor het bericht van de constructeur UdpEchoClient.

Waf: Ingang van directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' Waf: Verlaat directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' 'build' succesvol afgesloten (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(): Verstuurd 1024 bytes naar 10.1.1.2 2.00369s UdpEchoServerApplication:HandleRead(): Ontvangen 1024 bytes van 10.1.1.1 2.00369s UdpEchoServerApplication:HandleRead(): Echo van pakket 2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0) 2.00737s UdpEchoClientApplication:HandleRead(): Ontvangen 1024 bytes van 10.1.1.2 10s UdpEchoServerApplication:StopApplication() 10s UdpEchoClientApplication:StopApplication() UdpEchoClientApplication:DoDispose() UdpEchoServerApplication:DoDispose() UdpEchoClientApplication:~UdpEchoClient() UdpEchoServerApplication:~UdpEchoServer()

Vergeet niet dat het script scratch/first.cc de echo-serverapplicatie één seconde vóór het begin van de simulatie heeft opgestart. Nu kunt u zien dat de methode StartApplication van de server feitelijk in de eerste seconde wordt aangeroepen. U kunt ook opmerken dat de echo-client in de tweede seconde van de simulatie wordt opgestart, zoals we in het script hebben gevraagd.

Nu kunt u de voortgang van de simulatie volgen via de aanroep ScheduleTransmit in de client, die de Send callback HandleRead aanroept in de echo-serverapplicatie. Let op dat de verstreken tijd voor het verzenden van een pakket via de point-to-point link 3,69 milliseconden bedraagt. Het is duidelijk dat de echo-server een bericht registreert dat hij op het pakket heeft gereageerd, en vervolgens na de kanaalvertraging ziet u dat de echo-client het echo-pakket ontvangt in zijn HandleRead-methode.

In deze simulatie gebeurt er veel onopgemerkt voor u. Maar u kunt het hele proces heel eenvoudig volgen door alle logcomponenten in het systeem in te schakelen. Probeer de variabele NS_LOG in te stellen als volgt:

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

Het sterretje hierboven is een wildcard voor de logcomponent. Dit zal alle logs inschakelen in alle componenten die in de simulatie worden gebruikt. Ik zal de uitvoer hier niet reproduceren (op het moment van schrijven genereert het 1265 regels uitvoer voor één echo-pakket), maar u kunt deze informatie omleiden naar een bestand en het bekijken in uw favoriete editor.

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

Ik gebruik deze zeer gedetailleerde versie van logging persoonlijk wanneer ik een probleem heb en geen idee heb waar het misgaat. Ik kan de uitvoering van de code vrij gemakkelijk volgen zonder breakpoints en stap-voor-stap coderen in de debugger. Ik kan gewoon de uitvoer in mijn favoriete editor bewerken en zoeken naar wat ik verwacht en zien wat er onverwacht gebeurt. Wanneer ik een algemeen idee heb van wat er misgaat, ga ik naar de debugger voor een grondige analyse van het probleem. Dit soort uitvoer kan bijzonder nuttig zijn wanneer je script iets totaal onverwachts doet. Als je alleen de debugger gebruikt, kun je een onverwachte wending volledig missen. Logging maakt zulke wendingen zichtbaar.

5.1.3 Logging aan uw code toevoegen

Je kunt nieuwe records aan je simulaties toevoegen door de log-component vanuit verschillende macro's aan te roepen. Laten we dit doen in het script myfirst.cc, dat we in de 'schone' directory hebben. Laten we herinneren dat we in dit script de logging-component hebben gedefinieerd:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Je weet dat je logging van alle berichten van deze component kunt inschakelen door de omgevingsvariabele NS_LOG op verschillende niveaus in te stellen. Laten we doorgaan en wat records aan het script toevoegen. De macro die wordt gebruikt om informatieve logberichten toe te voegen, is NS_LOG_INFO. Laten we een bericht toevoegen (direct voordat we de knooppunten beginnen te creëren) dat je vertelt dat het script zich in de fase van het creëren van de topologie bevindt ("Creating Topology"). Dit gebeurt in het volgende codefragment,
Open het scratch/myfirst.cc in je favoriete editor en voeg de regel toe,
NS_LOG_INFO ("Creating Topology");
juist voor de regels,

NodeContainer nodes;
nodes.Create (2);

Nu compileer je het script met behulp van waf, en maak de NS_LOG-variabele leeg om de loggingstroom die we eerder ingeschakeld hebben, uit te schakelen:

$ ./waf
$ export NS_LOG=
Nu, als je het script uitvoert,
$ ./waf --run scratch/myfirst

zie je het nieuwe bericht niet, omdat de bijbehorende loggingcomponent (FirstScriptExample) niet was ingeschakeld. Om je bericht te zien, moet je de loggingcomponent FirstScriptExample inschakelen met een niveau van tenminste NS_LOG_INFO. Als je alleen dit specifieke loggingniveau wilt zien, kun je het als volgt inschakelen,

$ export NS_LOG=FirstScriptExample=info

Als je het script nu uitvoert, zie je een nieuw bericht 'Topology aanmaken'.

Waf: Betreden van directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Verlaat directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' is succesvol afgerond (0.404s)
Topology aanmaken
Verzonden 1024 bytes naar 10.1.1.2
Ontvangen 1024 bytes van 10.1.1.1
Ontvangen 1024 bytes van 10.1.1.2

5.2 Gebruik van commando-argumenten

5.2.1 Vervangen van standaardattributwaarden

Een andere manier om het gedrag van ns-3-scripts te wijzigen zonder ze te bewerken en opnieuw te bouwen, is door gebruik te maken van commandoregelargumenten. We bieden een mechanisme voor het parseren van commandoregelargumenten en het automatisch instellen van lokale en globale variabelen op basis van de resultaten.

De eerste stap bij het gebruik van het commandoregelargumentensysteem is het declareren van de commandoregelparser. Dit kan vrij eenvoudig worden gedaan (in je hoofdprogramma), zoals in de volgende code.

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

Dit eenvoudige tweeregelige fragment is op zich al zeer nuttig. Het opent de deur naar een globale ns-3 variabele en het systeem van attributen. Laten we twee regels code toevoegen aan het begin van de hoofd functie van het script. scratch/myfirst.cc. Vervolgens compileren we het script en voeren we het uit, waarbij we als volgt naar hulp vragen.

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

Dit commando vraagt Waf het script scratch/myfirst uit te voeren en het commandoregelargument --PrintHelpdoor te geven. De aanhalingstekens zijn nodig om aan te geven voor welk programma het argument bedoeld is. De commandoregelparser zal het argument herkennen --PrintHelp en een antwoord geven.

Waf: Betreden van directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Verlaat directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' is succesvol afgerond (0.413s)
TcpL4Protocol:TcpStateMachine()
CommandLine:HandleArgument(): Verwerk arg naam=PrintHelp waarde=
--PrintHelp: Print dit hulpbericht.
--PrintGroups: Geef de lijst van groepen weer.
--PrintTypeIds: Geef alle TypeIds weer.
--PrintGroup=[group]: Geef alle TypeIds van de groep weer.
--PrintAttributes=[typeid]: Geef alle attributen van typeid weer.
--PrintGlobals: Geef de lijst van globals weer.

Laten we nu de optie overwegen --PrintAttributes. We hebben het systeem van ns-3 attributen al eerder genoemd toen we het script first.cc bestudeerden. We zagen de volgende regels code:

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

en we hebben gezegd dat DataRate in feite een attribuut is van PointToPointNetDevice. Laten we de argumentenparser toepassen om de attributen te bekijken. PointToPointNetDevice. De hulplijst zegt dat we moeten opgeven TypeIdDit is de naam van de klasse waartoe de interessante attributen behoren. In ons geval is dit ns3::PointToPointNetDevice. Laten we verdergaan, voer in,

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

Het systeem drukt alle attributen van dit type netwerkapparaat af. U zult zien dat onder de attributen in de lijst er

--ns3::PointToPointNetDevice::DataRate=[32768bps]:
De standaard data rate voor punt-tot-punt verbindingen

Deze waarde wordt standaard gebruikt door het systeem bij het aanmaken van het object PointToPointNetDevice. We zullen deze standaardwaarde overschrijven met de parameter Attribuut in PointToPointHelper hierboven. Laten we de standaardwaarden gebruiken voor punt-tot-punt apparaten en verbindingen. Hiervoor verwijderen we de aanroepen SetDeviceAttribute en SetChannelAttribute uit myfirst.cc, die we in de schone directory hebben.

Uw script moet nu gewoon verklaren PointToPointHelper en geen installatieoperaties uitvoeren, zoals in het onderstaande voorbeeld wordt getoond,

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

Ga door en maak een nieuw script met Waf (.\/waf) en laten we teruggaan en enkele logboeken inschakelen van de UDP echo-applicatie server en de tijdprefix inschakelen.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Als u het script uitvoert, zou u de volgende uitvoer moeten zien:

Waf: Entering directory `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf: Leaving directory `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'build' finished successfully (0.405s)\n0s UdpEchoServerApplication:UdpEchoServer()\n1s UdpEchoServerApplication:StartApplication()\nSent 1024 bytes to 10.1.1.2\n2.25732s Received 1024 bytes from 10.1.1.1\n2.25732s Echoing packet\nReceived 1024 bytes from 10.1.1.2\n10s UdpEchoServerApplication:StopApplication()\nUdpEchoServerApplication:DoDispose()\nUdpEchoServerApplication:~UdpEchoServer()

Laten we niet vergeten dat de vorige keer dat we naar de simulatie tijd keken, het moment waarop het echo-server het pakket ontving, was op 2,00369 seconden.

2.00369s UdpEchoServerApplication:HandleRead(): Ontvangen 1024 bytes van 10.1.1.1

Nu ontvangt hij het pakket op 2.25732 seconden. Dit komt omdat we de data rate van de PointToPointNetDevice gewoon hebben teruggebracht van vijf megabit per seconde naar de standaardwaarde van 32768 bits per seconde. Als we de nieuwe DataRate via de opdrachtregel hadden ingesteld, zouden we ons modelleren opnieuw kunnen versnellen. We zullen dit als volgt doen, volgens de formule die door het help-element wordt aangegeven:

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

Als gevolg hiervan wordt de standaardwaarde van de DataRate-attribuut teruggebracht naar vijf megabit per seconde. Bent u verrast door het resultaat? Blijkbaar moeten we ook de kanaalvertraging instellen op de snelheid van het licht om het oorspronkelijke gedrag van het script te herstellen. We kunnen de opdrachtregelinterface vragen om de kanaalattributen af te drukken, net zoals we dat voor het netwerkapparaat deden:

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

We zullen ontdekken dat het kanaalvertraging-attribuut als volgt is ingesteld:

--ns3::PointToPointChannel::Delay=[0ns]:
Verzendvertraging door het kanaal

Vervolgens kunnen we via de opdrachtregel beide deze standaardwaarden instellen,

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

in dit geval herstellen we de waarden die we hadden toen we DataRate en Delay expliciet in het script instelden:

Waf: In directory `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Laat directory `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build' achter
'bouw' is succesvol afgerond (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Verstuurd 1024 bytes naar 10.1.1.2
2.00369s Ontvangen 1024 bytes van 10.1.1.1
2.00369s Echo-pakket
Ontvangen 1024 bytes van 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Let op dat het pakket opnieuw door de server is ontvangen na 2,00369 seconden. We zouden in feite op deze manier elke van de gebruikte attributen in het script kunnen instellen. In het bijzonder zouden we waarden anders dan één voor de MaxPackets-attributen kunnen instellen. UdpEchoClient.

Hoe zou je dit gebruiken? Probeer het eens. Vergeet niet dat je de plek moet comentaire waar we de standaardwaarde van het attribuut overschrijven en deze expliciet instellen. MaxPackets in het script. Vervolgens moet je het script opnieuw bouwen. Je kunt ook via de opdrachtregel hulp krijgen over de syntaxis voor het instellen van een nieuwe standaardwaarde voor het attribuut. Nadat je dit hebt begrepen, kun je het aantal pakketten beheren dat in de opdrachtregel wordt weergegeven. Aangezien we plichtsgetrouwe mensen zijn, moet onze opdrachtregel er ongeveer zo uitzien:

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

De natuurlijke vraag die hier opkomt, is hoe je te weten kunt komen van het bestaan van al deze attributen. Nogmaals, de opdrachtregel heeft een functie voor hulp hierbij. Als we om hulp vragen via de opdrachtregel, zouden we dit moeten zien:

$ .\/waf --run "scratch\/myfirst --PrintHelp"
myfirst [Program Arguments] [General Arguments]
General Arguments:
--PrintGlobals: Print de lijst van globals.
--PrintGroups: Print de lijst van groepen.
--PrintGroup=[group]: Print alle TypeIds van de groep.
--PrintTypeIds: Print alle TypeIds.
--PrintAttributes=[typeid]: Print alle attributen van typeid.
--PrintHelp: Print dit helpbericht.

Als u de 'PrintGroups'-argument kiest, zou u een lijst van alle geregistreerde groepen moeten zien. TypeId. De namen van de groepen komen overeen met de namen van modules in de oorspronkelijke directory (hoewel met een hoofdletter). Het afdrukken van alle informatie tegelijk zal te veel zijn, daarom is er een extra filter beschikbaar voor het afdrukken van informatie per groep. Laten we ons weer richten op de module 'point-to-point':

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

Hier kunt u beschikbare namen van TypeId vinden om attributen te zoeken, bijvoorbeeld in
--PrintAttributes = ns3 :: PointToPointChannel, zoals hierboven getoond.

Een andere manier om meer te weten te komen over de attributen is via Doxygen ns-3. Daar is een pagina die alle geregistreerde attributen in de simulator opsomt.

5.2.2 Uw eigen commando's vastleggen

U kunt ook uw eigen hooks toevoegen via het commandoregel-systeem. Dit is vrij eenvoudig te doen met behulp van de commando parser methode. AddValue.
Laten we deze mogelijkheid gebruiken om het aantal pakketten dat moet worden weergegeven op een heel andere manier aan te geven. Laten we een lokale variabele met de naam nPackets in de functie main. We stellen deze in op één, zodat het overeenkomt met ons eerdere standaardgedrag. Om de waarde te laten veranderen door de parser, moeten we deze waarde vastleggen in de parser. We doen dit door een aanroep toe te voegen van AddValue. Ga en wijzig het script scratch/myfirst.cc zodat het begint met de volgende code,

int
main (int argc, char *argv[])
{
uint32_t nPackets = 1;
CommandLine cmd;
cmd.AddValue("nPackets", "Aantal pakketten om te echoën", nPackets);
cmd.Parse (argc, argv);
...

Scroll naar beneden naar het punt in het script waar we het attribuut MaxPackets instellen en wijzig het zodat het is ingesteld op de variabele nPackets in plaats van de constante 1, zoals hieronder weergegeven.

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

Nu, als u het script uitvoert en het argument --PrintHelp invoert, zou u het nieuwe gebruikersargument op het helpdisplay moeten zien. Voer in,

$ ./waf --run "scratch/myfirst --PrintHelp"
Waf: De directory `home/craigdo/repos/ns-3-allinone/ns-3-dev/build' binnengegaan
Waf: De directory `home/craigdo/repos/ns-3-allinone/ns-3-dev/build' verlaten
'build' succesvol voltooid (0.403s)
--PrintHelp: Toon dit helpbericht.
--PrintGroups: Toon de lijst met groepen.
--PrintTypeIds: Toon alle TypeIds.
--PrintGroup=[group]: Toon alle TypeIds van de groep.
--PrintAttributes=[typeid]: Toon alle attributen van typeid.
--PrintGlobals: Toon de lijst met globals.
Gebruikersargumenten:
--nPackets: Aantal pakketten om te echoën

Als u het aantal verzonden pakketten wilt wijzigen, kunt u dit doen door het argument - -nPackets in de opdrachtregel in te stellen.

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

Nu zou u moeten zien

Waf: De directory `home/craigdo/repos/ns-3-allinone/ns-3-dev/build' binnengegaan
Waf: De directory `home/craigdo/repos/ns-3-allinone/ns-3-dev/build' verlaten
'build' succesvol voltooid (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
1024 bytes verzonden naar 10.1.1.2
2.25732s 1024 bytes ontvangen van 10.1.1.1
2.25732s Pakket echoën
1024 bytes ontvangen van 10.1.1.2
1024 bytes verzonden naar 10.1.1.2
3.25732s 1024 bytes ontvangen van 10.1.1.1
3.25732s Pakket echoën
1024 bytes ontvangen van 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

U heeft nu twee pakketten verzonden. Best simpel, toch?
U kunt zien dat als gebruiker van ns‑3, u het opdrachtregelsysteem kunt gebruiken om globale waarden en attributen te beheren. Als u een model auteur bent, kunt u nieuwe attributen aan uw objecten toevoegen, en deze zullen automatisch beschikbaar zijn voor configuratie door uw gebruikers via het opdrachtenysteem. Als u een script auteur bent, kunt u nieuwe variabelen aan uw scripts toevoegen en ze naadloos aansluiten op het opdrachtenysteem.

5.3 Gebruik van het tracing-systeem

Het doel van modelleren is het genereren van gegevens voor verder onderzoek, en het ns‑3 traceersysteem is de belangrijkste mechanisme hiervoor. Aangezien ns‑3 een programma in C++ is, kunnen de standaardmethoden voor gegevensgeneratie in C++ worden gebruikt:

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

U kunt zelfs de logmodule gebruiken om wat structuur aan uw oplossing toe te voegen. Er zijn veel bekende problemen die door deze aanpak worden veroorzaakt, en daarom hebben we een algemene gebeurtenistracering subsysteem ontwikkeld om deze problemen aan te pakken.

De belangrijkste doelen van het ns‑3 traceersysteem:

Voor basis taken moet het traceersysteem de gebruiker in staat stellen standaard tracing te genereren voor populaire bronnen, en selecteren welke objecten tracing genereren;
Tussenliggende gebruikers moeten in staat zijn om het traceersysteem uit te breiden om het gegenereerde uitvoerformaat te wijzigen of nieuwe traceerbronnen in te voegen, zonder de kern van de simulator aan te passen;
Ervaren gebruikers kunnen de kern van de simulator aanpassen om nieuwe traceerbronnen en -ontvangers toe te voegen. Het ns-3 traceersysteem is gebaseerd op de principes van onafhankelijke traceerbronnen en -ontvangers, evenals een uniforme verbinding tussen bronnen en verbruikers.

Het ns-3 traceersysteem is gebouwd op de principes van onafhankelijke traceerbronnen en -ontvangers, evenals een uniforme mechanismen om bronnen aan ontvangers te koppelen. Traceerbronnen zijn objecten die gebeurtenissen in de simulatie kunnen signaleren en toegang bieden tot relevante basisgegevens. Bijvoorbeeld, een traceerbron kan aangeven wanneer een netwerkapparaat een pakket heeft ontvangen en biedt toegang tot de inhoud van dat pakket voor geïnteresseerde traceerontvangers.

Traceerbronnen zijn op zichzelf nutteloos, tenzij ze 'verbonden' zijn met andere delen van de code die daadwerkelijk iets nuttigs doen met de informatie die door de ontvanger wordt verstrekt. Traceerders zijn consumenten van de evenementen en gegevens die door traceerbronnen worden geleverd. Bijvoorbeeld, je kunt een traceerontvanger maken die (bij verbinding met de traceerbron van het vorige voorbeeld) interessante delen van het ontvangen pakket afdrukt.

Een goede reden voor zo'n duidelijke scheiding is om gebruikers in staat te stellen nieuwe soorten ontvangers aan bestaande traceerbronnen te koppelen zonder dat ze de kern van de simulator hoeven te bewerken en opnieuw te compileren. In het bovenstaande voorbeeld kan de gebruiker een nieuwe traceerder in zijn script definiëren en deze verbinden met een bestaande traceerbron die in de simulatiekern is gedefinieerd, enkel door het gebruikersscript te bewerken.

In deze gids zullen we enkele vooraf gedefinieerde bronnen en ontvangers doornemen en laten zien hoe deze met minimale inspanning van de gebruiker kunnen worden ingesteld. Zie de ns-3 gids of de instructie secties voor informatie over geavanceerde traceerconfiguratie, inclusief het uitbreiden van de naamruimte voor tracering en het creëren van nieuwe traceerbronnen.

5.3.1 ASCII Traceren

ns-3 biedt hulpfunctionaliteit die een laag-niveau traceersysteem biedt om u te helpen met de details bij het instellen van eenvoudige pakkettraceringen. Als u deze functie inschakelt, ziet u uitvoer in ASCII-bestanden. Voor degenen die vertrouwd zijn met de uitvoer van ns-2, is dit type tracering vergelijkbaar met out.tr, dat gegenereerd is door meerdere scripts.

Laten we ter zake komen en enkele ASCII-traceringresultaten aan ons script scratch/myfirst.cc toevoegen. Net vóór de aanroep van Simulator::Run(), voegt u de volgende regels code toe:
AsciiTraceHelper ascii;

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

Zoals in veel andere idiomen in ns-3, gebruikt deze code een hulpobject om ASCII-traceringen te creëren. De tweede regel bevat twee geneste aanroepen van de methode. De methode 'binnenin' CreateFileStream() maakt gebruik van de idiomatische anonieme objecten om een bestandsstroomobject op de stack te creëren (zonder een naam voor het object) en geeft dit door aan de aangeroepen methode. In de toekomst zullen we dieper ingaan op dit onderwerp, maar alles wat u op deze stadium moet weten, is dat u een object maakt dat een bestand vertegenwoordigt met de naam myfirst.tr en dat u dit doorgaat naar ns-3. We vertrouwen ns-3 toe om zorg te dragen voor het gemaakte object gedurende zijn levenscyclus, waarin worden oplossingen voor problemen die voortkomen uit de minder bekende (doelbewuste) beperking met betrekking tot kopieerconstructors van stroomobjecten in C++ worden opgelost.

De externe aanroep EnableAsciiAll() geeft de helper aan dat u ASCII-tracering voor alle punt-tot-punt apparaatverbindingen in uw simulatie wilt inschakelen en dat u wilt dat (de opgegeven) tracering-ontvangers informatie over de pakketbeweging in ASCII-formaat opslaan.

Voor degenen die bekend zijn met ns-2, zijn de getraceerde gebeurtenissen gelijk aan de bekende traceerpunt die de gebeurtenissen ‘+’, ‘-’, ‘d’ en ‘r’ loggen.
Nu kunt u het script samenstellen en het vanuit de opdrachtregel uitvoeren:

$ ./waf --run scratch/myfirst

Hoe vaak je eerder ook berichten van Waf hebt gezien, het zal dan eindigen met “‘build’ finished successfully” (de build is succesvol voltooid) met een aantal berichten van het draaiende programma.

Tijdens de uitvoering zal het programma een bestand aanmaken met de naam myfirst.tr. Vanwege de manier waarop Waf, wordt het bestand standaard niet in de lokale directory aangemaakt, maar in de bovenste directory van de repository. Als je het pad wilt wijzigen waar de traces worden opgeslagen, kun je de parameter --cwdgebruiken. We hebben dat niet gedaan, dus om het ASCII-tracebestand myfirst.tr in je favoriete editor te bekijken, moeten we naar de bovenste directory van onze repository gaan.

Parseren van ASCII-tracering

Er is veel informatie in een vrij compacte vorm, maar het eerste waar je op moet letten is dat het bestand uit afzonderlijke regels bestaat. Dit wordt duidelijker als je het venster wijder opent.

Elke regel in het bestand komt overeen met een traceerbericht. In dit geval traceren we de gebeurtenissen in de transqueue die aanwezig is in elk punt-naar-punt netwerkapparaat in de simulatie. De transqueue is de wachtrij waar elk pakket doorheen moet voordat het het punt-naar-punt kanaal kan gebruiken. Let op dat elke regel in het traceerbestand begint met een enkel teken (en er is een spatie na). Dit teken heeft de volgende betekenis:

+: er vond een enqueue-operatie plaats in de apparaatwachtrij;
-: er vond een dequeue-operatie plaats in de apparaatwachtrij;
d: het pakket werd verworpen, meestal omdat de wachtrij vol was;
r: het pakket werd ontvangen door het netwerkapparaat.

Laten we de eerste regel in het traceerbestand uitgebreider bekijken. Ik zal het opsplitsen in delen (met inspringingen voor duidelijkheid) en het regelnummer aan de linkerkant vermelden:

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)

Het eerste deel van dit uitgebreide traceergebeurtenis (regel 0) is de operatie. We hebben hier het teken +, wat overeenkomt met een enqueue-operatie voor verzending. Het tweede deel (regel 1) is de simulatie tijd, uitgedrukt in seconden. Je kunt je herinneren dat we vroegen om UdpEchoClientApplication De verzending van pakketten begint over twee seconden. Hier zien we de bevestiging dat dit inderdaad gebeurt.

In het volgende segment van de trace (vanaf regel 2) wordt weergegeven welke tracebron dit evenement heeft gegenereerd (de naamsruimte van de trace wordt aangegeven). Je kunt de naamsruimte van de trace vergelijken met die van een bestandssysteem. De wortel van de naamsruimte is NodeList. Dit komt overeen met de container die voornamelijk door de ns-3 code wordt beheerd. Hierin bevinden zich alle knooppunten die in het script worden aangemaakt. Net zoals een bestandssysteem een wortelmap kan hebben, kan NodeList wij meerdere knooppunten hebben. Dus, regel \/NodeList\/0 verwijst naar het nul-knooppunt in NodeList, dat we meestal begrijpen als 'knooppunt 0'. In elk knooppunt is er een lijst van apparaten die zijn geïnstalleerd. Deze lijst bevindt zich vervolgens in de naamsruimte. Je kunt zien dat dit traceerevenement afkomstig is van DeviceList\/0, dat het nul-apparaat is dat in het knooppunt is geïnstalleerd.

De volgende substring, $ ns3 :: PointToPointNetDevice, geeft aan welk apparaat zich op de nulpositie bevindt: de lijst van apparaten van het nul-knooppunt. Ter herinnering: de operatie +, die in regel 0 stond, betekende dat er een element aan de verzendwachtrij van het apparaat was toegevoegd. Dit wordt weerspiegeld in de laatste segmenten van het 'tracepad': TxQueue\/Enqueue.

De overige onderdelen in de trace moeten intuïtief begrijpelijk zijn. Regels 3-4 geven aan dat het pakket is ingekapseld in het point-to-point protocol. Regels 5-7 laten zien dat het pakket een IP4-versie header heeft en afkomstig is van het IP-adres 10.1.1.1 en bedoeld is voor 10.1.1.2. Regels 8-9 tonen aan dat dit pakket een UDP-header heeft en ten slotte geeft regel 10 aan dat de payload - verwachte 1024 bytes - is.

De volgende regel in het traceerbestand geeft aan dat hetzelfde pakket uit de verzendwachtrij op hetzelfde knooppunt is gehaald.

De derde regel in het traceerbestand toont aan dat het pakket is ontvangen door het netwerkapparaat op het knooppunt met de echo-server. Ik heb dit evenement hieronder gereproduceerd.

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)

Let op, de traceringsoperatie is nu r, en de simulatie tijd is verhoogd tot 2,25732 seconden. Als je de instructies uit de handleiding zorgvuldig hebt gevolgd, betekent dit dat je de DataRate van netwerkelementen en de kanaalvertraging in hun standaardinstellingen hebt gelaten. Deze tijd zou je bekend moeten voorkomen, aangezien je deze al in de vorige sectie hebt gezien.

De namespace voor de traceringsbron (regel 2) is gewijzigd om weer te geven dat dit evenement afkomstig is van knooppunt 1 (/NodeList/1) и пакет принят источником трассировки (/MacRx). Het zou vrij gemakkelijk voor je moeten zijn om de voortgang van het pakket door de topologie te volgen door de overgebleven sporen in het traceerbestand te bekijken.

5.3.2 PCAP Tracering

De ns-3 apparaat helpers kunnen ook worden gebruikt om traceerbestanden in .pcap-formaat te genereren. De acroniem pcap (meestal in kleine letters geschreven) staat voor pakketcapture en is feitelijk een API die de definitie van het .pcap-bestandsformaat omvat. De meest populaire software die dit formaat kan lezen en weergeven is Wireshark (voorheen genaamd Ethereal). Er zijn echter veel analysetools voor netwerkverkeer die dit pakketformaat gebruiken. We raden gebruikers aan om verschillende beschikbare tools te gebruiken om pcap-traces te analyseren. In deze handleiding richten we ons op het bekijken van pcap-traces met behulp van tcpdump.

Het inschakelen van pcap-tracering gebeurt met één regel code.

pointToPoint.EnablePcapAll ("myfirst");

Plaats deze regel code na de ASCII-traceringscode die we zojuist hebben toegevoegd aan scratch/myfirst.cc. Let op, we hebben alleen de string 'myfirst' doorgegeven, en niet 'myfirst.pcap' of iets dergelijks. Dit komt omdat de parameter een prefix is, en geen volledige bestandsnaam. Tijdens de simulatie zal de helper feitelijk een traceerbestand voor elk point-to-point apparaat aanmaken. De bestandsnamen worden opgebouwd met behulp van de prefix, het knooppuntnummer, het apparaatnummer en de suffix ‘.pcap».

Voor ons voorbeeldscript zullen we uiteindelijk bestanden zien met de namen ‘myfirst-0-0.pcap» en «myfirst-1-0.pcap’, welke de pcap-traceringen zijn voor knooppunt 0-apparaat 0 en knooppunt 1-apparaat 0 respectievelijk. Nadat je de regel code voor het inschakelen van pcap-tracering hebt toegevoegd, kun je het script op de gebruikelijke manier uitvoeren:

$ ./waf --run scratch/myfirst

Als je in de hoofdmap van je distributie kijkt, zou je drie bestanden moeten zien: het ASCII-traceerbestand myfirst.tr, dat we eerder hebben doorgenomen, bestanden myfirst-0-0.pcap en myfirst-1-0.pcap — nieuwe pcap-bestanden die we zojuist hebben gegenereerd.

Lezen van de uitvoer met tcpdump

Op dit moment is het het eenvoudigste om pcap-bestanden te bekijken met tcpdump.

$ tcpdump -nn -tt -r myfirst-0-0.pcap
lezen van bestand myfirst-0-0.pcap, link-type PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, lengte 1024
2.514648 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, lengte 1024
tcpdump -nn -tt -r myfirst-1-0.pcap
lezen van bestand myfirst-1-0.pcap, link-type PPP (PPP)
2.257324 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, lengte 1024
2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, lengte 1024

In de dump myfirst-0-0.pcap (clientapparaat) zie je dat het echo-pakket wordt verzonden na 2 seconden simulatie. Als je naar de tweede dump kijkt (myfirst-1-0.pcap), zie je dat het pakket wordt ontvangen op moment 2,257324 seconden. Je ziet in de tweede dump dat het pakket wordt teruggestuurd op moment 2,257324 seconden, en uiteindelijk dat het pakket door de client is ontvangen in de eerste dump op moment 2,514648 seconden.

Lezen van de uitvoer met Wireshark

Als je niet bekend bent met Wireshark, is er een website waar je de programma's en documentatie kunt downloaden: http://www.wireshark.org/. Wireshark — dat is een grafische gebruikersinterface die je kunt gebruiken om deze traceerbestanden weer te geven. Als je Wireshark hebt, kun je een van de traceerbestanden openen en de inhoud weergeven alsof je pakketten hebt vastgelegd met een pakketanalysator.

Bron: habr.com