ns-3 netwerksimulator-tutorial. Hoofdstuk 5

Hoofdstuk 1,2
hoofdstuk 3
hoofdstuk 4

5 Instellingen
5.1 Gebruik van de logmodule
5.1.1 Logboekoverzicht
5.1.2 Logboekregistratie inschakelen
5.1.3 Logboekregistratie toevoegen aan uw code
5.2 Opdrachtregelargumenten gebruiken
5.2.1 Standaard attribuutwaarden overschrijven
5.2.2 Uw eigen opdrachten vastleggen
5.3 Gebruik van het traceersysteem
5.3.1 ASCII-tracering
ASCII-sporen parseren
5.3.2 PCAP-trace

Hoofdstuk 5

afstelling

5.1 Gebruik van de logmodule

We hebben de ns-3-logmodule al kort bekeken door naar het script te kijken eerste.cc. In dit hoofdstuk gaan we dieper in op de mogelijke toepassingen van het logsubsysteem.

5.1.1 Logboekoverzicht

Veel grote systemen ondersteunen een of andere vorm van berichtenregistratie, en ns-3 is daarop geen uitzondering. In sommige gevallen worden alleen foutmeldingen naar de "operatorconsole" geschreven (die meestal stderr is op Unix-gebaseerde systemen). Op andere systemen kunnen waarschuwingsberichten worden weergegeven, evenals meer gedetailleerde informatie. In sommige gevallen worden logboektools gebruikt om foutopsporingsberichten uit te voeren, waardoor de uitvoer snel onscherp kan worden.

De subHRD die in ns-3 wordt gebruikt, gaat ervan uit dat al deze niveaus van informatie-inhoud nuttig zijn, en we bieden een selectieve, gelaagde benadering voor het loggen van berichten. Logboekregistratie kan volledig worden uitgeschakeld, per component of globaal worden ingeschakeld. Voor dit doel worden instelbare niveaus van informatie-inhoud gebruikt. De ns-3-logmodule biedt een relatief eenvoudige manier om nuttige informatie uit uw simulatie te verkrijgen.

U moet begrijpen dat we een mechanisme voor algemene doeleinden bieden – tracering – voor het extraheren van gegevens uit uw modellen, wat de voorkeursuitvoer voor simulaties zou moeten zijn (voor meer informatie over ons traceringssysteem, zie tutorial sectie 5.3). Logboekregistratie zou de voorkeursmethode moeten zijn voor het verkrijgen van foutopsporingsinformatie, waarschuwingen en foutmeldingen, of voor het snel uitvoeren van berichten uit uw scripts of modellen op elk gewenst moment.

Momenteel definieert het systeem zeven niveaus (typen) logberichten in oplopende volgorde van informatie-inhoud.

• LOG_ERROR - loggen van foutmeldingen (gerelateerde macro: NS_LOG_ERROR);
• LOG_WARN - Waarschuwingsberichten loggen (gerelateerde macro: NS_LOG_WARN);
• LOG_DEBUG - Registreer relatief zeldzame speciale debug-berichten (gerelateerde macro: NS_LOG_DEBUG);
• LOG_INFO - registratie van informatieberichten over de voortgang van het programma (gerelateerde macro: NS_LOG_INFO);
• LOG_FUNCTION - Registreert 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 - logberichten die de logische stroom binnen een functie beschrijven (gerelateerde macro: NS_LOG_LOGIC);
• LOG_ALL - Registreert alles hierboven vermeld (geen bijbehorende macro).
  Voor elk type (LOG_TYPE) is er ook een LOG_LEVEL_TYPE die, indien gebruikt, het mogelijk maakt om naast zijn eigen niveau ook alle niveaus daarboven te loggen. (Als gevolg hiervan zijn LOG_ERROR en LOG_LEVEL_ERROR, en LOG_ALL en LOG_LEVEL_ALL functioneel equivalent.) Als u bijvoorbeeld LOG_INFO inschakelt, worden alleen berichten toegestaan ​​die door de macro NS_LOG_INFO worden geleverd, terwijl het inschakelen van LOG_LEVEL_INFO ook berichten omvat die worden geleverd door de macro's NS_LOG_DEBUG, NS_LOG_WARN en NS_LOG_ERROR.

We bieden ook een onvoorwaardelijke logmacro die altijd wordt weergegeven, ongeacht het logniveau of de selectiecomponent.

• NS_LOG_UNCOND - Onvoorwaardelijke registratie van het bijbehorende bericht (geen bijbehorend registratieniveau).

Elk niveau kan afzonderlijk of cumulatief worden opgevraagd. Logging kan worden geconfigureerd met behulp van de sh-omgevingsvariabele NS_LOG of door een systeemfunctieaanroep te loggen. Zoals eerder getoond beschikt het logsysteem over Doxygen-documentatie en dit is een goed moment om deze te herzien als u dat nog niet heeft gedaan.

Nu u de documentatie tot in detail heeft gelezen, gaan we die kennis gebruiken om interessante informatie uit het voorbeeldscript te halen scratch/mijneerste.ccdie je al hebt samengesteld.

5.1.2 Logboekregistratie inschakelen

Laten we de omgevingsvariabele NS_LOG gebruiken om nog wat logbestanden uit te voeren, maar voer eerst, gewoon om je te oriënteren, het laatste script uit zoals je eerder deed,

$ ./waf --run scratch/myfirst

U zou de bekende uitvoer van het eerste ns-3-voorbeeldprogramma moeten zien

$ 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

Het blijkt dat de "verzonden" en "ontvangen" berichten die u hierboven ziet, feitelijk geregistreerde berichten zijn UdpEchoClientApplicatie и UdpEchoServerApplicatie. We kunnen de clienttoepassing bijvoorbeeld vragen om aanvullende informatie af te drukken door het logniveau in te stellen via de omgevingsvariabele NS_LOG.

Vanaf nu ga ik ervan uit dat je een sh-achtige shell gebruikt die de syntaxis "VARIABLE=waarde" gebruikt. Als je een csh-achtige shell gebruikt, dan zul je mijn voorbeelden moeten converteren naar de syntaxis "setenv variabele waarde" die vereist is voor die shells.

Momenteel reageert de UDP-echo-clienttoepassing op de volgende coderegel in scratch/mijneerste.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Het maakt het logniveau LOG_LEVEL_INFO mogelijk. Wanneer we een vlag voor logniveau passeren, schakelen we feitelijk 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 verkrijgen, zonder scriptwijzigingen en hercompilatie, door de omgevingsvariabele NS_LOG als volgt in te stellen:

$ export NS_LOG=UdpEchoClientApplication=level_all

Dus stellen we de sh shell-variabele NS_LOG in op de volgende waarde:

UdpEchoClientApplication=level_all

De linkerkant van de toewijzing is de naam van het gelogde onderdeel dat we willen configureren, en de rechterkant is de vlag die we ervoor willen toepassen. In dit geval gaan we alle niveaus van foutopsporing in de applicatie inschakelen. Als u het script uitvoert terwijl NS_LOG op deze manier is ingesteld, accepteert het ns-3-logsysteem de wijzigingen en ziet u de volgende uitvoer:

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

Aanvullende foutopsporingsinformatie die door de applicatie wordt verstrekt, bevindt zich nu op het niveau NS_LOG_FUNCTION. Het toont elk exemplaar van een functieaanroep tijdens de uitvoering van het script. Als algemene regel geldt dat het bij methodefuncties de voorkeur verdient om (minimaal)NS_LOG_FUNCTION (this)... Gebruik maken van NS_LOG_FUNCTION_NOARGS ()
alleen in statische functies. Houd er echter rekening mee dat het ns-3-systeem geen enkele logfunctionaliteit hoeft te ondersteunen. De beslissing over hoeveel informatie wordt vastgelegd, wordt overgelaten aan de individuele modelontwikkelaar. In het geval van echotoepassingen is er een grote hoeveelheid logoutput beschikbaar.

U kunt nu een logboek bekijken van functieaanroepen die door de toepassing zijn gedaan. Als je goed kijkt, zie je een dubbele punt tussen de lijn UdpEchoClientApplicatie en de naam van de methode, waarbij u de C++ scope-operator zou verwachten (: :). Dit is opzettelijk.

Dit is eigenlijk niet de naam van de klasse, maar de naam van de logcomponent. Als er een overeenkomst is tussen een bronbestand en een klasse, is dit meestal de naam van de klasse, maar u moet zich realiseren dat dit niet daadwerkelijk de naam van de klasse is, en dat er een enkele dubbele punt is in plaats van een dubbele dubbele punt. Dit is een manier om u te helpen de naam van de logbean op een relatief subtiele manier conceptueel te scheiden van de naam van de klasse.

In sommige gevallen kan het echter moeilijk zijn om te bepalen welke methode het logbericht daadwerkelijk genereert. Als je naar de bovenstaande tekst kijkt, vraag je je misschien af ​​waar de regel "Received 1024 bytes from 10.1.1.2" U kunt dit probleem oplossen door het niveau in te stellen voorvoegsel_func aan de omgevingsvariabele NS_LOG. Probeer het volgende:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Merk op dat de aanhalingstekens nodig zijn omdat de verticale balk die we gebruiken om de OR-bewerking weer te geven ook een Unix-pipe-connector is. Als u nu het script uitvoert, zult u zien dat het logsysteem ervoor zorgt dat elk bericht in een bepaald log wordt voorafgegaan door de componentnaam.

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

Nu kunt u zien dat alle berichten die afkomstig zijn van de UDP-echo-clienttoepassing als zodanig worden geïdentificeerd. Bericht "Received 1024 bytes from 10.1.1.2" is nu duidelijk geïdentificeerd als afkomstig van de echo-clienttoepassing. Het resterende bericht moet afkomstig zijn van de UDP-echoservertoepassing. We kunnen deze component inschakelen door een door dubbele punten gescheiden lijst met componenten in te voeren in de omgevingsvariabele NS_LOG.

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

Waarschuwing: In de bovenstaande voorbeeldtekst moet u het teken voor de nieuwe regel na de dubbele punt (:) verwijderen. Deze wordt gebruikt om het document op te maken. Als u nu het script uitvoert, ziet u alle logberichten van de client- en server-echotoepassingen. Je kunt zien dat dit erg handig kan zijn bij het debuggen.

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.406s)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoServerApplication:StartApplication()
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
UdpEchoServerApplication:HandleRead(): Echoing packet
UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
UdpEchoServerApplication:StopApplication()
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Soms is het ook handig om het simulatietijdstip te kunnen zien waarop het logbericht is gegenereerd. U kunt dit doen door het OR-bit toe te voegen voorvoegsel_tijd:

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

Nogmaals, je zult het bovenstaande newline-teken moeten verwijderen. Als u het script nu uitvoert, zou u de volgende uitvoer moeten zien:

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

Houd er rekening mee dat de constructor voor UdpEchoServer werd opgeroepen tijdens simulatie 0 seconden. Dit gebeurt feitelijk voordat de simulatie start, maar de tijd wordt weergegeven als nul seconden. Hetzelfde geldt voor het constructorbericht 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()

Bedenk dat het script kras/eerste.cc startte de echoserverapplicatie één seconde vóór de start van de simulatie. Nu kun je zien dat de methode Startapplicatie de server wordt feitelijk in de eerste seconde gebeld. Het zal je misschien ook opvallen dat de echoclient in de tweede seconde van de simulatie start, zoals we in het script vroegen.

U kunt nu op afroep de voortgang van de simulatie volgen SchemaVerzenden in de client die de HandleRead callback Send aanroept in de echoservertoepassing. Houd er rekening mee dat de verstreken tijd voor het verzenden van een pakket via een point-to-point-verbinding 3,69 milliseconden bedraagt. U kunt zien dat de echoserver een bericht registreert dat deze op het pakket heeft gereageerd, en vervolgens, na een kanaalvertraging, ziet u dat de echoclient het echopakket ontvangt in de HandleRead-methode.

In deze simulatie gebeurt er veel zonder dat je het merkt. Maar u kunt het hele proces heel eenvoudig volgen door alle logboekcomponenten in het systeem in te schakelen. Probeer de NS_LOG-variabele in te stellen op de volgende waarde:

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

Het sterretje hierboven is een jokerteken voor de logboekcomponent. Dit omvat alle vermeldingen in alle componenten die in de simulatie worden gebruikt. Ik zal de uitvoer hier niet reproduceren (op het moment dat ik dit schrijf levert het 1265 regels uitvoer op voor een enkel echopakket), maar u kunt deze informatie omleiden naar een bestand en deze bekijken in uw favoriete editor.

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

Persoonlijk gebruik ik deze extreem uitgebreide versie van loggen als ik een probleem heb en geen idee heb waar het mis is gegaan. Ik kan de uitvoering van de code vrij eenvoudig volgen zonder breekpunten in te stellen en door de code in de debugger te stappen. Ik kan de uitvoer gewoon in mijn favoriete editor bewerken en zoeken naar wat ik verwacht en iets zien gebeuren dat ik niet had verwacht. Zodra ik een algemeen idee heb van wat er misgaat, spring ik in de debugger om dieper op het probleem in te gaan. Dit type uitvoer kan vooral handig zijn als uw script iets totaal onverwachts doet. Als u alleen de debugger gebruikt, mist u mogelijk een twist helemaal. Registratie maakt dergelijke bochten merkbaar.

5.1.3 Logboekregistratie toevoegen aan uw code

U kunt nieuwe vermeldingen aan uw simulaties toevoegen door vanuit meerdere macro's de logcomponent aan te roepen. Laten we het in een script doen mijneerste.cc, die we in de map "schone" hebben. Bedenk dat we in dit scenario een logcomponent hebben gedefinieerd:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

U bent zich ervan bewust dat u het loggen van alle berichten van dit onderdeel kunt inschakelen door de omgevingsvariabele NS_LOG op verschillende niveaus in te stellen. Laten we doorgaan en enkele vermeldingen aan het script toevoegen. De macro die wordt gebruikt om berichten op informatieniveau aan het logboek toe te voegen is NS_LOG_INFO. Laten we een bericht toevoegen (vlak voordat we beginnen met het maken van knooppunten) waarin wordt aangegeven dat het script zich in de fase "Topologie maken" bevindt. Dit gebeurt in het volgende codefragment,
Doe open scratch/mijneerste.cc in je favoriete editor en voeg de regel toe,
NS_LOG_INFO ("Creating Topology");
vlak voor de lijnen,

NodeContainer nodes;
nodes.Create (2);

Compileer nu het script met behulp van wafen wis de NS_LOG variabele om de logboekstroom uit te schakelen die we eerder hebben ingeschakeld:

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

U ziet het nieuwe bericht niet omdat de bijbehorende logboekregistratiecomponent (FirstScriptExample) niet is ingeschakeld. Om uw bericht te kunnen zien, moet u de logcomponent inschakelen FirstScriptVoorbeeld met een niveau niet lager dan NS_LOG_INFO. Als u alleen dit specifieke logniveau wilt zien, kunt u dit als volgt inschakelen:

$ export NS_LOG=FirstScriptExample=info

Als u het script nu uitvoert, ziet u een nieuw bericht “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 Opdrachtregelargumenten gebruiken

5.2.1 Standaard attribuutwaarden overschrijven

Een andere manier om het gedrag van ns-3-scripts te veranderen zonder ze te bewerken of te bouwen, is door opdrachtregelargumenten te gebruiken. We bieden een mechanisme om opdrachtregelargumenten te ontleden en automatisch lokale en globale variabelen in te stellen op basis van de resultaten.

De eerste stap bij het gebruik van het opdrachtregelargumentsysteem is het declareren van een opdrachtregelparser. Dit is vrij eenvoudig te doen (in uw hoofdprogramma), zoals in de volgende code:

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

Dit eenvoudige fragment van twee regels is op zichzelf al heel nuttig. Het opent de deur naar het ns-3 globale variabelen- en attribuutsysteem. Laten we twee regels code toevoegen aan het begin van de hoofdscriptfunctie scratch/mijneerste.cc. Verderop compileren we het script en voeren het uit. Tijdens het uitvoeren doen we als volgt een hulpverzoek:

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

Dit commando zal vragen Waf script uitvoeren scratch/mijneerste en geef het een opdrachtregelargument door —Afdrukhulp. De aanhalingstekens zijn nodig om aan te geven voor welk programma het argument bedoeld is. De opdrachtregelparser detecteert het argument —Afdrukhulp en zal het antwoord weergeven,

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.

Laten we nu naar de optie kijken —Afdrukkenmerken. We hebben het ns-3-attributensysteem al genoemd bij het bestuderen van het first.cc-script. We hebben de volgende regels code gezien,

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

en dat zeiden ze Datasnelheid is eigenlijk een attribuut PointToPointNetDevice. Laten we de argumentparser op de opdrachtregel gebruiken om de attributen te bekijken PointToPointNetDevice. Op de hulplijst staat wat we moeten bieden TypeId. Dit is de naam van de klasse waartoe de relevante attributen behoren. In ons geval zal dat zo zijn ns3::PointToPointNetDevice. Laten we vooruit blijven gaan, binnenkomen,

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

Het systeem drukt alle kenmerken van dit netwerkapparaattype af. U zult zien dat onder de attributen in de lijst zijn:

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

Dit is de standaardwaarde die door het systeem wordt gebruikt bij het maken van het object PointToPointNetDevice. We zullen deze standaardwaarde overschrijven met behulp van de parameter Kenmerk в PuntToPuntHelper hoger. Laten we de standaardwaarden gebruiken voor point-to-point-apparaten en kanalen. Om dit te doen, zullen we oproepen verwijderen SetDeviceAttribute и Kanaalkenmerk instellen van mijneerste.cc, die we in een schone map hebben.

Uw script zou nu eenvoudigweg moeten declareren PuntToPuntHelper en voer geen installatiehandelingen uit zoals weergegeven in het onderstaande voorbeeld,

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

Ga je gang en maak een nieuw script met Waf (./waff) en laten we teruggaan en wat invoer van de UDP-echoservertoepassing toevoegen en het tijdvoorvoegsel toevoegen.

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

Bedenk dat de laatste keer dat we naar de simulatietijd keken, het moment waarop het pakket werd ontvangen door de echoserver, deze 2,00369 seconden bedroeg.

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

Nu ontvangt hij het pakketje in 2.25732 seconden. Dit komt omdat we eenvoudigweg de gegevenssnelheid van PointToPointNetDevice opnieuw instellen van vijf megabits per seconde naar de standaardwaarde, namelijk 32768 bits per seconde. Als we een nieuwe DataRate zouden vervangen via de opdrachtregel, zouden we onze simulatie opnieuw kunnen versnellen. We zullen dit als volgt doen, volgens de formule die wordt geïmpliceerd door het help-element:

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

Hierdoor wordt het DataRate-attribuut teruggezet naar de standaardwaarde van vijf megabits per seconde. Ben je verrast door het resultaat? Het blijkt dat we, om het oorspronkelijke gedrag van het script terug te geven, ook de kanaalvertraging moeten instellen zodat deze overeenkomt met de snelheid van het licht. We kunnen het opdrachtregelsysteem vragen om de kanaalkenmerken af ​​te drukken, net zoals we deden voor het netwerkapparaat:

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

We zullen zien dat het kanaalvertragingsattribuut als volgt is ingesteld:

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

We kunnen dan, via het opdrachtregelsysteem, beide standaardwaarden instellen.

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

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

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

Merk op dat het pakket na 2,00369 seconden opnieuw door de server wordt ontvangen. We zouden eigenlijk alle attributen die in het script worden gebruikt op deze manier kunnen instellen. In het bijzonder zouden we de MaxPackets-attributen kunnen instellen op niet-één waarden UdpEchoClient.

Hoe zou je het gebruiken? Probeer het eens. Houd er rekening mee dat u commentaar moet geven op de plaats waar we de standaard attribuutwaarde overschrijven en expliciet instellen MaxPakketten in het script. Vervolgens moet u het script opnieuw opbouwen. U kunt ook de opdrachtregel gebruiken om hulp bij de syntaxis te krijgen voor het instellen van een nieuwe standaardkenmerkwaarde. Zodra u dit begrijpt, kunt u het aantal pakketten beheren dat op de opdrachtregel wordt weergegeven. Omdat we leergierige mensen zijn, zou onze opdrachtregel er ongeveer zo uit moeten zien:

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

De natuurlijke vraag die op dit punt opkomt is hoe je het bestaan ​​van al deze attributen kunt weten. Nogmaals, het opdrachtregelsysteem heeft hiervoor een helpfunctie. Als we de opdrachtregel om hulp vragen, zouden we het volgende moeten zien:

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

Als u het argument "PrintGroups" selecteert, zou u een lijst met alle geregistreerde groepen moeten zien TypeId. De groepsnamen komen overeen met de namen van de modules in de bronmap (zij het met een hoofdletter). Alle informatie in één keer afdrukken zou te omvangrijk zijn. Daarom is er een extra filter beschikbaar om informatie per groep af te drukken. Dus nogmaals gericht op de point-to-point-module:

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

Hier vindt u beschikbare TypeId-namen voor het opzoeken van attributen, bijvoorbeeld in
--PrintAttributes = ns3 :: PointToPointChannelzoals hierboven getoond.

Een andere manier om over attributen te leren is via Doxygen ns-3. Er is een pagina met alle attributen die in de simulator zijn geregistreerd.

5.2.2 Uw eigen opdrachten vastleggen

Je kunt ook je eigen hooks toevoegen via het opdrachtregelsysteem. Dit gebeurt heel eenvoudig met behulp van de opdrachtregelparsermethode Waarde toevoegen.
Laten we deze functie gebruiken om het aantal pakketten dat op een geheel andere manier moet worden weergegeven, te specificeren. Laten we een lokale variabele toevoegen met de naam nPakketten in een functie hoofd-. We stellen het in op één die overeenkomt met ons eerdere standaardgedrag. Om ervoor te zorgen dat de opdrachtregelparser deze waarde kan wijzigen, moeten we deze waarde in de parser vastleggen. Dit doen wij door een oproep toe te voegen Waarde toevoegen. Ga en verander het script scratch/mijneerste.cc dus om te beginnen met de volgende code,

int
main (int argc, char *argv[])
{
uint32_t nPackets = 1;
CommandLine cmd;
cmd.AddValue("nPackets", "Number of packets to echo", nPackets);
cmd.Parse (argc, argv);
...

Blader omlaag naar het punt in het script waar we het MaxPackets-attribuut instellen en wijzig het zodat het wordt ingesteld op de nPackets-variabele in plaats van de constante 1, zoals hieronder weergegeven.

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

Als u nu het script uitvoert en het argument -PrintHelp opgeeft, zou u het nieuwe gebruikersargument moeten zien. vermeld op het helpscherm. Binnenkomen,

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

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

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

Nu zou je het nu moeten zien

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

Je hebt nu twee pakketten verzonden. Vrij eenvoudig, nietwaar?
Je kunt zien dat je als ns-3-gebruiker het opdrachtregelargumentsysteem kunt gebruiken om globale waarden en attributen te manipuleren. Als u de auteur van het model bent, kunt u nieuwe attributen aan uw objecten toevoegen. Deze zijn dan automatisch beschikbaar voor configuratie door uw gebruikers via het opdrachtregelsysteem. Als u een scriptauteur bent, kunt u nieuwe variabelen aan uw scripts toevoegen en deze naadloos in uw opdrachtregelsysteem aansluiten.

5.3 Gebruik van het traceersysteem

Het hele punt van modellering is het genereren van output voor verder onderzoek, en het ns-3-traceersysteem is hiervoor het belangrijkste mechanisme. Omdat ns-3 een C++-programma is, kunnen standaardmethoden voor het genereren van uitvoer uit een C++-programma worden gebruikt:

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

U kunt zelfs een 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 algemeen subsysteem voor het traceren van gebeurtenissen ter beschikking gesteld om deze problemen op te lossen.

De belangrijkste doelstellingen van het ns-3-traceersysteem zijn:

• Voor basistaken moet het traceringssysteem de gebruiker in staat stellen een standaardtracering voor populaire bronnen te genereren en objecten te selecteren die de tracering genereren;

• Gemiddelde gebruikers moeten het traceringssysteem kunnen uitbreiden om het gegenereerde uitvoerformaat te wijzigen of nieuwe traceringsbronnen in te voegen, zonder de simulatorkern te wijzigen;

• Gevorderde gebruikers kunnen de kern van de simulator aanpassen om nieuwe traceerbronnen en putten toe te voegen. Het ns-3-traceersysteem is gebouwd op de principes van onafhankelijke trackingbronnen en -ontvangers, evenals op een uniform mechanisme om bronnen met consumenten te verbinden.

Het ns-3-traceersysteem is gebouwd op de principes van onafhankelijke traceringsbronnen en -ontvangers, evenals op een uniform mechanisme voor het verbinden van bronnen met ontvangers. Traceerbronnen zijn objecten die gebeurtenissen kunnen signaleren die zich in de simulatie voordoen en die toegang bieden tot de onderliggende relevante gegevens. Een traceerbron kan bijvoorbeeld aangeven wanneer een netwerkapparaat een pakket heeft ontvangen en de inhoud van het pakket beschikbaar maken voor geïnteresseerde traceerontvangers.

Traceerbronnen op zichzelf zijn nutteloos, tenzij ze worden "gekoppeld" aan andere delen van de code die daadwerkelijk iets nuttigs doen met de informatie die door de sink wordt verstrekt. Tracers zijn consumenten van gebeurtenissen en gegevens afkomstig van traceerbronnen. U kunt bijvoorbeeld een trace-sink maken die (wanneer verbonden met de trace-bron uit het vorige voorbeeld) de interessante delen in het ontvangen pakket afdrukt.

De reden voor deze expliciete scheiding is om gebruikers in staat te stellen nieuwe sink-typen te verbinden met bestaande traceringsbronnen zonder de simulatorkern te hoeven bewerken en opnieuw te compileren. In het bovenstaande voorbeeld kan de gebruiker dus een nieuwe tracer in zijn script definiëren en deze verbinden met een bestaande tracerbron die in de simulatiekern is gedefinieerd, alleen door het gebruikersscript te bewerken.

In deze zelfstudie bespreken we enkele van de vooraf gedefinieerde bronnen en sinks en laten we zien hoe deze kunnen worden geconfigureerd met de minste inspanning van de gebruiker. Zie de ns-3-handleiding of de how-to-secties voor informatie over geavanceerde traceringsconfiguratie, inclusief het uitbreiden van de traceringsnaamruimte en het maken van nieuwe traceringsbronnen.

5.3.1 ASCII-tracering

ns-3 biedt helperfunctionaliteit die een traceringssysteem op laag niveau biedt om u te helpen met de details bij het instellen van eenvoudige pakkettraceringen. Als u deze functie inschakelt, ziet u de uitvoer in ASCII-bestanden. Voor degenen die bekend zijn met ns-2-uitvoer: dit type trace is vergelijkbaar met uit.tr, die door veel scripts wordt gegenereerd.

Laten we aan de slag gaan en enkele ASCII-traceerresultaten toevoegen aan ons scratch/myfirst.cc-script. Vlak voor het telefoontje Simulator :: Run (), voeg de volgende regels code toe:
AsciiTraceHelper ascii;

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

Net als veel andere ns-3-idiomen gebruikt deze code een helperobject om ASCII-sporen te creëren. De tweede regel bevat twee geneste methodeaanroepen. "Binnen"-methode MaakBestandStream() gebruikt het anonieme objectidioom om een ​​bestandsstroomobject op de stapel te maken (zonder objectnaam) en geeft dit door aan de aangeroepen methode. We zullen hier in de toekomst dieper op ingaan, maar het enige wat je op dit moment moet weten is dat je een object aan het maken bent dat een bestand vertegenwoordigt met de naam mijneerste.tr en breng het over naar ns-3. We vertrouwen ns-3 toe om gedurende zijn gehele levensduur voor het gemaakte object te zorgen, gedurende welke het problemen oplost die worden veroorzaakt door een weinig bekende (opzettelijke) beperking die verband houdt met C++-stroomobjectkopieconstructors.

Externe oproep AsciiAll() inschakelen vertelt de assistent dat u ASCII-tracering in uw simulatie wilt opnemen voor alle point-to-point-apparaatverbindingen en dat u wilt dat (gespecificeerde) traceerontvangers informatie over pakketbewegingen registreren in ASCII-indeling.

Voor degenen die bekend zijn met ns-2: de gevolgde gebeurtenissen zijn gelijkwaardig aan de bekende tracepoints die gebeurtenissen "+", "-", "d" en "r" registreren.
Nu kunt u het script bouwen en uitvoeren vanaf de opdrachtregel:

$ ./waf --run scratch/myfirst

Zoals zo vaak eerder zul je verschillende berichten van Waf zien, en dan “'build' is succesvol voltooid” met enkele berichten van het actieve programma.

Tijdens het uitvoeren maakt het programma een bestand met de naam mijneerste.tr. Vanwege de aard van het werk Waf, wordt het bestand standaard niet in de lokale map gemaakt, maar in de map op het hoogste niveau van de repository. Als u het pad wilt wijzigen waar traceringen worden opgeslagen, kunt u de parameter Waf gebruiken om dit op te geven --cwd. We hebben dit niet gedaan, dus om het ASCII-tracebestand myfirst.tr in je favoriete editor te bekijken, moeten we naar de map op het hoogste niveau van onze repository navigeren.

ASCII-sporen parseren

Er staat veel informatie in een vrij compacte vorm, maar het eerste dat u moet opmerken is dat het bestand uit afzonderlijke regels bestaat. Dit wordt duidelijk zichtbaar als je het kijkvenster breder maakt.

Elke regel in het bestand komt overeen met een traceergebeurtenis. In dit geval traceren we gebeurtenissen in de transmissiewachtrij die aanwezig is in elk point-to-point netwerkapparaat in de simulatie. De transmissiewachtrij is de wachtrij waar elk pakket doorheen moet voor een point-to-point-verbinding. Houd er rekening mee dat elke regel in het traceringsbestand begint met een enkel teken (en daarachter een spatie staat). Dit symbool heeft de volgende betekenis:

+: er heeft een wachtrijbewerking plaatsgevonden in de apparaatwachtrij;
-: er heeft een elementophaalbewerking plaatsgevonden in de apparaatwachtrij;
d: het pakket is verwijderd, meestal omdat de wachtrij vol was;
r: Het pakket is ontvangen door een netwerkapparaat.

Laten we de eerste regel in het traceringsbestand eens nader bekijken. Ik zal het opsplitsen in delen (met inkepingen voor de duidelijkheid) en het regelnummer aan de linkerkant:

0 +
1 2
2 /NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue
3 ns3::PppHeader (
4   Point-to-Point Protocol: IP (0x0021))
6   ns3::Ipv4Header (
7     tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
8     length: 1052 10.1.1.1 > 10.1.1.2)
9     ns3::UdpHeader (
10      length: 1032 49153 > 9)
11      Payload (size=1024)

Het eerste deel van deze uitgebreide traceergebeurtenis (regel 0) is de bewerking. We hebben hier een +-symbool, dat overeenkomt met de werking van het in de wachtrij plaatsen voor verzending. Het tweede deel (regel 1) is de simulatietijd, uitgedrukt in seconden. Misschien herinnert u zich nog wat we vroegen UdpEchoClientApplicatie begin binnen twee seconden met het verzenden van pakketten. Hier zien we de bevestiging dat dit inderdaad gebeurt.

In het volgende gedeelte van het traceringsvoorbeeld (uit regel 2) wordt weergegeven welke traceringsbron deze gebeurtenis heeft gegenereerd (waarmee de naamruimtetracering wordt aangegeven). U kunt de traceernaamruimte op dezelfde manier beschouwen als een bestandssysteemnaamruimte. De root van de naamruimte is KnooppuntenLijst. Dit komt overeen met de container die wordt beheerd in de hoofdcode van ns-3. Het bevat alle knooppunten die in het script zijn gemaakt. Net zoals een bestandssysteem mappen in de root kan hebben, KnooppuntenLijst we kunnen veel knooppunten hebben. Dus de regel /NodeList/0 verwijst naar het nulknooppunt in de NodeList, dat we gewoonlijk als "knooppunt 0" beschouwen. Elk knooppunt heeft een lijst met apparaten die zijn geïnstalleerd. Deze lijst bevindt zich vervolgens in de naamruimte. U kunt zien waar deze traceergebeurtenis vandaan komt Apparaatlijst/0, het nulapparaat dat in het knooppunt is geïnstalleerd.

Volgende subtekenreeks, $ ns3 :: PointToPointNetDevice, vertelt welk apparaat zich op positie nul bevindt: de apparatenlijst van knooppunt nul. Bedenk dat de +-bewerking in regel 0 betekende dat een element werd toegevoegd aan de verzendwachtrij van het apparaat. Dit komt tot uiting in de laatste segmenten van het “trackpad”: TxQueue/Enqueue.

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

De volgende regel in het traceringsbestand laat zien dat hetzelfde pakket uit de transmissiewachtrij op hetzelfde knooppunt is gehaald.

De derde regel in het traceringsbestand laat zien dat het pakket is ontvangen door een netwerkapparaat op de echoserverhost. Hieronder heb ik de gebeurtenis weergegeven.

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)

Merk op dat de traceerbewerking nu r is en dat de simulatietijd is verhoogd naar 2,25732 seconden. Als u de tutorial zorgvuldig hebt gevolgd, betekent dit dat u de DataRate en Link Delay van de netwerkapparaten op hun standaardwaarden hebt gelaten. Deze tijd zou bekend moeten zijn, zoals je in de vorige sectie hebt gezien.

De naamruimte-invoer van de traceringsbron (regel 2) is gewijzigd om aan te geven dat deze gebeurtenis afkomstig is van knooppunt 1 (/KnooppuntenLijst/1) en het pakket wordt ontvangen door de traceringsbron (/MacRx). Het zou voor u vrij eenvoudig moeten zijn om de beweging van het pakket door de topologie te volgen door naar de resterende sporen in het bestand te kijken.

5.3.2 PCAP-trace

De ns-3 Device Helpers kunnen ook worden gebruikt om traceerbestanden in .pcap-indeling te maken. Acroniem PCAP (meestal in kleine letters geschreven) staat voor packet capture en is eigenlijk een API die het definiëren van het .pcap-bestandsformaat omvat. Het populairste programma dat dit formaat kan lezen en weergeven is Wireshark (vroeger gebeld Etherisch). Er zijn echter veel analyseprogramma's voor verkeerstracering die dit pakketformaat gebruiken. We moedigen gebruikers aan om de vele beschikbare tools te gebruiken om pcap-traceringen te analyseren. In deze tutorial zullen we ons concentreren op het bekijken van pcap-traceringen met behulp van tcpdump.

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

pointToPoint.EnablePcapAll ("myfirst");

Plak deze coderegel na de ASCII-traceercode die we zojuist hebben toegevoegd scratch/mijneerste.cc. Merk op dat we alleen de string "myfirst" hebben doorgegeven, en niet "myfirst.pcap" of iets dergelijks. Dit komt omdat de parameter een voorvoegsel is en geen volledige bestandsnaam. Tijdens de simulatie maakt de assistent daadwerkelijk een tracebestand aan voor elk point-to-point-apparaat. Bestandsnamen worden opgebouwd met behulp van het voorvoegsel, knooppuntnummer, apparaatnummer en achtervoegsel ".PCAP.

Voor ons voorbeeldscript zien we uiteindelijk bestanden met de naam "mijneerste-0-0.pcap"En"mijneerste-1-0.pcap", Dit zijn pcap-traceringen voor respectievelijk knooppunt 0-apparaat 0 en knooppunt 1-apparaat 0. Nadat u de coderegel hebt toegevoegd om pcap-tracering in te schakelen, kunt u het script op de gebruikelijke manier uitvoeren:

$ ./waf --run scratch/myfirst

Als u in de map op het hoogste niveau van uw distributie kijkt, ziet u drie bestanden: een ASCII-traceerbestand mijneerste.tr, die we eerder hebben bestudeerd, bestanden mijneerste-0-0.pcap и mijneerste-1-0.pcap - nieuwe pcap-bestanden die we zojuist hebben gegenereerd.

Uitvoer lezen met tcpdump

Voorlopig is de eenvoudigste manier om pcap-bestanden te bekijken het gebruik van 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

In de vuilstort mijneerste-0-0.pcap (clientapparaat) kunt u zien dat het echopakket na 2 seconden simulatie wordt verzonden. Als je naar de tweede dump kijkt (mijneerste-1-0.pcap), zult u zien dat het pakket na 2,257324 seconden wordt ontvangen. U zult in de tweede dump zien dat het pakket na 2.257324 seconden wordt geretourneerd, en ten slotte dat het pakket na 2.514648 seconden door de client in de eerste dump wordt ontvangen.

Uitvoer lezen met Wireshark

Als u er niet bekend mee bent Wireshark, is er een website waar u programma's en documentatie kunt downloaden: http://www.wireshark.org/. Wireshark is een GUI die kan worden gebruikt om deze traceerbestanden weer te geven. Als u Wireshark heeft, kunt u elk van de traceerbestanden openen en de inhoud weergeven alsof u de pakketten hebt vastgelegd met behulp van een pakketsniffer.

Bron: www.habr.com