Handbok för nätverksimulatorn ns-3. Kapitel 5

kapitel 1,2
kapitel 3
kapitel 4

5 Konfiguration
5.1 Användning av loggmodulen
5.1.1 Översikt av loggning
5.1.2 Tillåtelse av loggning
5.1.3 Lägga till loggning i din kod
5.2 Användning av kommandoradsargument
5.2.1 Överskrivning av standardattributvärden
5.2.2 Fånga dina egna kommandon
5.3 Användning av spårningssystemet
5.3.1 ASCII Spårning
Parsing av ASCII spårning
5.3.2 PCAP Spårning

Kapitel 5

Inställning

5.1 Användning av loggmodulen

Vi har redan kort gått igenom loggmodulen ns-3 när vi granskade skriptet first.cc. I detta kapitel ska vi titta närmare på användningsalternativen för loggningsunder-systemet.

5.1.1 Översikt av loggning

Många stora system har någon form av meddelandeloggning, och ns-3 är inget undantag. I vissa fall skrivs endast felmeddelanden till "operatörens konsol" (som vanligen är stderr i Unix-baserade system). I andra system kan varningsmeddelanden och mer detaljerad information också visas. I vissa fall används loggverktyg för att skriva ut felsökningsmeddelanden som kan snabbt "sudda" ut utskriften.

Tillvägagångssättet som används i ns-3 förutsätter att alla dessa informationsnivåer är användbara, och vi erbjuder ett selektivt, flernivåansats till meddelandeloggning. Loggning kan vara helt avstängd, slås på för enskilda komponenter eller på global nivå. Detta åstadkoms med anpassningsbara informationsnivåer. Loggmodulen ns-3 tillhandahåller ett relativt enkelt sätt att få ut användbar information från din simulation.

Du bör förstå att vi tillhandahåller en generell mekanism — spårning — för att extrahera data från dina modeller, som bör vara föredragen för utdata vid modellering (för mer detaljerad information om vårt spårningssystem se avsnitt 5.3 i handledningen). Loggning bör vara den föredragna metoden för att erhålla felsökningsinformation, varningar, felmeddelanden eller för att snabbt utdata meddelanden från dina skript eller modeller när som helst.

För närvarande har systemet definierat sju nivåer (typer) av loggmeddelanden i stigande ordning av informationsinnehåll.

• LOG_ERROR — registrera felmeddelanden (relaterad makro: NS_LOG_ERROR);
• LOG_WARN – registrering av varningsmeddelanden (relaterad makro: NS_LOG_WARN);
• LOG_DEBUG – registrering av relativt sällsynta speciella debugmeddelanden (relaterad makro: NS_LOG_DEBUG);
• LOG_INFO – registrering av informationsmeddelanden om programmets körning (relaterad makro: NS_LOG_INFO);
• LOG_FUNCTION – registrering av meddelanden som beskriver varje anropad funktion (två relaterade makron: NS_LOG_FUNCTION, som används för medlemsfunktioner, och NS_LOG_FUNCTION_NOARGS, som används för statiska funktioner);
• LOG_LOGIC – registrering av meddelanden som beskriver logikflödet inom en funktion (relaterad makro: NS_LOG_LOGIC);
• LOG_ALL – registrering av allt ovanstående (ingen relaterad makro).
  För varje typ (LOG_TYPE) finns även en typ LOG_LEVEL_TYPE, som, om den används, tillåter registrering av alla nivåer ovanför dess egen. (Som ett resultat är LOG_ERROR och LOG_LEVEL_ERROR samt LOG_ALL och LOG_LEVEL_ALL funktionellt ekvivalenta.) Till exempel, om LOG_INFO är aktiverat kommer endast meddelanden som tillhandahålls av makrot NS_LOG_INFO att tillåtas, och om LOG_LEVEL_INFO är aktiverat inkluderas även meddelanden som tillhandahålls av makrona NS_LOG_DEBUG, NS_LOG_WARN och NS_LOG_ERROR.

Vi tillhandahåller också ett makro för oavbruten registrering, som alltid visas oavsett loggnivå eller komponentval.

• NS_LOG_UNCOND – oavbruten registrering av relaterat meddelande (utan relaterad loggnivå).

Varje nivå kan begäras separat eller kumulativt. Loggning kan konfigureras med hjälp av miljövariabeln NS_LOG eller genom att registrera ett anrop till systemfunktionen. Som tidigare visat har loggsystemet Doxygen-dokumentation, och det är nu dags att titta på den om du inte har gjort det än.

Nu när du har läst dokumentationen mycket noggrant, låt oss använda denna kunskap för att dra ut lite intressant information från exempelmanus scratch/myfirst.cc, som du redan har kompilerat.

5.1.2 Tillåtelse av loggning

Låt oss använda miljövariabeln NS_LOG för att köra några fler loggar, men först, bara för att orientera dig, kör den senaste skriptet som du gjorde tidigare,

$ ./waf --run scratch/myfirst

Du bör se den redan bekanta utdata från det första exempelprogrammet ns-3.

$ Waf: Går in i katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Lämnar katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 'build'
avslutat framgångsrikt (0.413s)
Skickade 1024 byte till 10.1.1.2
Mottog 1024 byte från 10.1.1.1
Mottog 1024 byte från 10.1.1.2

Det visar sig att "skickade" och "mottagna" meddelanden, som ni ser ovan, faktiskt är registrerade meddelanden från UdpEchoClientApplication och UdpEchoServerApplication. Till exempel kan vi be klientapplikationen att skriva ut mer information genom att ställa in loggnivån via miljövariabeln NS_LOG.

Från och med nu kommer jag att anta att du använder en sh-liknande skal som använder syntaksen "VARIABLE = value". Om du använder en csh-liknande skal, då måste du konvertera mina exempel till syntaksen "setenv variabel värde" som krävs av dessa skal.

För närvarande reagerar UDP eko-klientapplikationen på följande kodrad i scratch/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Det aktiverar loggnivån LOG_LEVEL_INFO. När vi skickar loggnivåflaggor, aktiverar vi faktiskt denna nivå och alla lägre nivåer. I detta fall har vi aktiverat NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN och NS_LOG_ERROR. Vi kan höja loggnivån och få mer information, utan att ändra skriptet eller recompilera, genom att ställa in miljövariabeln NS_LOG på följande sätt:

$ export NS_LOG=UdpEchoClientApplication=level_all

På så sätt ställer vi in följande värde på NS_LOG miljövariabeln för sh-skalet,

UdpEchoClientApplication=level_all

Den vänstra sidan av tilldelningen är namnet på den loggade komponenten som vi vill konfigurera, och den högra sidan är flaggan som vi vill tillämpa för detta. I detta fall kommer vi att inkludera alla felsökningsnivåer i applikationen. Om du kör skriptet med NS_LOG inställt på detta sätt, kommer ns-3:s loggningssystem att acceptera ändringarna och du bör se följande utdata:

Waf: Går in i katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Lämnar katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' avslutat framgångsrikt (0.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Skickade 1024 byte till 10.1.1.2
Mottog 1024 byte från 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Mottog 1024 byte från 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Den extra felsökningsinformationen som tillhandahålls av applikationen motsvarar nu nivån NS_LOG_FUNCTION. Den visar varje fall av funktionsanrop under skriptets körning. Som regel är det att föredra att använda (åtminstone)NS_LOG_FUNCTION (this). Använd NS_LOG_FUNCTION_NOARGS ()
endast i statiska funktioner. Observera dock att det i ns-3-systemet inte finns några krav på att stödja någon loggning. Beslutet om hur mycket information som loggas ligger helt och hållet i modellutvecklarens händer. För ekapplikationer finns det mycket utdata för loggning.

Nu kan du granska loggen över funktionsanrop som har gjorts av applikationen. Om du tittar noga kommer du att märka ett kolon mellan raden UdpEchoClientApplication och metodens namn, på det ställe där du kanske förväntade dig att se C++-områdesoperatören (: :). Detta har gjorts avsiktligt.

Det är faktiskt inte klassnamnet, utan loggkomponentens namn. När det finns en överensstämmelse mellan källfiler och klasser är det vanligtvis klassens namn, men du måste förstå att det faktiskt inte är klassens namn och att det finns ett kolon istället för en dubbelkolon. Det här är ett sätt att på ett relativt subtilt sätt konceptuellt separera loggkomponentens namn från klassens namn.

Det kan dock vara svårt att avgöra vilken metod som genererar loggmeddelandet. Om du ser på texten ovan kan du fråga dig var strängen "Received 1024 bytes from 10.1.1.2" kom ifrån. Du kan lösa detta problem genom att ställa in nivån prefix_func i miljövariabeln NS_LOG. Försök att göra följande,

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Notera att citattecken är nödvändiga, eftersom vertikala strecket som vi använder för att ange OCH-operationen också är en Unix-rörledare. Nu, om du kör skriptet, kommer du att se att loggsystemet säkerställer att varje meddelande från denna logg har ett prefix med loggkomponentens namn.

Waf: Entrér in katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Lämnar katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'bygget' avslutades framgångsrikt (0,417s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Skickade 1024 byte till 10.1.1.2
Mottog 1024 byte från 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
UdpEchoClientApplication:HandleRead(): Mottog 1024 byte från 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Nu kan du se att alla meddelanden som kommer från UDP-eko-klientapplikationen identifieras som sådana. Meddelandet "Received 1024 bytes from 10.1.1.2“ är nu tydligt definierat som kommande från eko-klientapplikationen. Det kvarvarande meddelandet bör komma från UDP-eko-serverapplikationen. Vi kan aktivera denna komponent genom att skriva en lista med komponenter, separerade med kolon, i miljövariabeln NS_LOG.

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

Varning: I exemplet ovan måste du ta bort radbrytningen efter kolon (:), den används för dokumentformattering. Nu, om du kör skriptet, kommer du att se alla loggmeddelanden från klientens och serverns eko-applikationer. Du kanske ser att detta kan vara mycket användbart vid felsökning.

Waf: Entrér in katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Lämnar katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'bygget' avslutades framgångsrikt (0,406s)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoServerApplication:StartApplication()
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Skickade 1024 byte till 10.1.1.2
UdpEchoServerApplication:HandleRead(): Mottog 1024 byte från 10.1.1.1
UdpEchoServerApplication:HandleRead(): Återsänder paket
UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
UdpEchoClientApplication:HandleRead(): Mottog 1024 byte från 10.1.1.2
UdpEchoServerApplication:StopApplication()
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Det är också ibland nyttigt att kunna se simuleringstiden då loggmeddelandet skapades. Du kan göra detta genom att lägga till antingen biten prefix_time:

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

Återigen måste du ta bort radbrytningen ovan. Om du nu kör skriptet ska du se följande utdata:

Waf: Går in i katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Lämnar katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' avslutades framgångsrikt (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(): Skickade 1024 byte till 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Mottagen 1024 byte från 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Återkopplar paket
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Mottagen 1024 byte från 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Observera att konstruktorn för UdpEchoServer kallades under simuleringen vid 0 sekunder. Detta händer faktiskt före simuleringens början, men tiden visas som noll sekunder. Samma sak gäller för meddelandet från konstruktorn UdpEchoClient.

Waf: Går in i katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Lämnar katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' avslutades framgångsrikt (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(): Skickade 1024 byte till 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Mottagen 1024 byte från 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Återkopplar paket
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Mottagen 1024 byte från 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Kom ihåg att skriptet scratch/first.cc startade echoserverapplikationen en sekund före simuleringens början. Nu kan du se att metoden StartApplication för servern faktiskt anropas vid den första sekunden. Du kan också märka att ekoch klienten startar vid den andra sekunden av simuleringen, precis som vi bad i skriptet.

Nu kan du följa simuleringens gång genom att anropa ScheduleTransmit i klienten, som anropar Send-back callback HandleRead i echoserverapplikationen. Observera att den förflutna tiden för att skicka paketet över den tvåpunktslänken är 3,69 millisekunder. Det är tydligt att echoservern registrerar ett meddelande om att den har svarat på paketet, och sedan, efter en kanalens fördröjning, ser du att ekoch klienten tar emot eko-paketet i sin metod HandleRead.

I denna simulering sker mycket utan att du märker det. Men du kan väldigt lätt spåra hela processen genom att aktivera alla loggkomponenter i systemet. Försök att ställa in värdet i variabeln NS_LOG till följande:

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

Stjärnan ovan är en wildcard för loggkomponenten. Detta kommer att aktivera alla loggar i alla komponenter som används i simuleringen. Jag kommer inte att återskapa utskriften här (vid tidpunkten för skrivandet genererar den 1265 rader utskrift för ett eko-paket), men du kan omdirigera denna information till en fil och granska den i din favorittextredigerare.

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

Jag använder personligen denna extremt detaljerade loggversion när jag har ett problem och ingen aning om var det gick fel. Jag kan ganska enkelt följa kodens körning utan att sätta brytpunkter och stega genom koden i debuggern. Jag kan bara redigera utdata i min favoritredigerare och leta efter det jag förväntar mig och se saker som jag inte förväntade mig. När jag får en allmän känsla av vad som går fel, går jag över till debuggern för en närmare granskning av problemet. Denna typ av utdata kan vara särskilt användbar när ditt skript gör något helt oväntat. Om du bara använder debuggern kan du missa oväntade svängar helt. Loggning gör sådana svängar tydliga.

5.1.3 Lägga till loggning i din kod

Du kan lägga till nya poster i dina simuleringar genom att göra anrop till loggkomponenten från flera makron. Låt oss göra detta i skriptet myfirst.cc, som vi har i den "rena" katalogen. Låt oss påminna oss om att vi definierade loggkomponenten i detta skript:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Du vet att du kan aktivera loggning av alla meddelanden från denna komponent genom att ställa in miljövariabeln NS_LOG på olika nivåer. Låt oss fortsätta och lägga till några poster i skriptet. Makrot som används för att logga meddelanden på informationsnivå är NS_LOG_INFO. Låt oss lägga till ett meddelande (precis innan vi börjar skapa noder) som säger till dig att skriptet är i processen att skapa topologi ("Creating Topology"). Detta görs i följande kodavsnitt,
Öppna scratch/myfirst.cc i din favoritredigerare och lägg till raden,
NS_LOG_INFO ("Creating Topology");
precis innan raderna,

NodeContainer nodes;
nodes.Create (2);

Nu kompilera skriptet med waf, och rensa NS_LOG-variabeln för att stänga av loggströmmen som vi aktiverade tidigare:

$ ./waf
$ export NS_LOG=
Nu, om du kör skriptet,
$ ./waf --run scratch/myfirst

kommer du inte att se det nya meddelandet, eftersom den relaterade loggkomponenten (FirstScriptExample) inte har aktiverats. För att se ditt meddelande måste du aktivera loggkomponenten FirstScriptExample med en nivå som är minst NS_LOG_INFO. Om du bara vill se denna specifika loggnivå kan du aktivera den så,

$ export NS_LOG=FirstScriptExample=info

Om du kör skriptet nu kommer du att se det nya meddelandet "Creating Topology".

Waf: Går in i mappen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Lämnar mappen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'bygget' slutfört framgångsrikt (0.404s)
Skapar Topologi
Skickade 1024 byte till 10.1.1.2
Mottog 1024 byte från 10.1.1.1
Mottog 1024 byte från 10.1.1.2

5.2 Användning av kommandoradsargument

5.2.1 Överskrivning av standardattributvärden

Ett annat sätt att ändra ns-3-skriptens beteende utan att redigera och kompilera är att använda kommandoradsargument. Vi tillhandahåller en mekanism för att analysera kommandoradsargument och automatiskt ställa in lokala och globala variabler baserat på resultaten.

Det första steget i att använda kommandoradssystemet är att deklarera kommandoradsanalysatorn. Detta är ganska enkelt att göra (i ditt huvudprogram), som i följande kod:

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

Detta enkla två-raders stycke är faktiskt mycket användbart i sig. Det öppnar dörren till den globala ns-3 variabeln och attributsystemet. Låt oss lägga till två rader kod i början av huvudfunktionen i skriptet. scratch/myfirst.cc. När vi går vidare, kompilera skriptet och kör det, vid körning gör vi en hjälpförfrågan på följande sätt:

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

Detta kommando ber Waf att köra skriptet scratch/myfirst och skicka det ett kommandoradsargument --PrintHelp. Citat tecknen är nödvändiga för att visa vilket program argumentet är avsett för. Kommandoradsanalysatorn kommer att upptäcka argumentet --PrintHelp och ge ett svar,

Waf: Går in i mappen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Lämnar mappen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'bygget' slutfört framgångsrikt (0.413s)
TcpL4Protocol:TcpStateMachine()
CommandLine:HandleArgument(): Hanterar arg namn=PrintHelp värde=
--PrintHelp: Skriv ut detta hjälpbussmeddelande.
--PrintGroups: Skriv ut listan över grupper.
--PrintTypeIds: Skriv ut alla TypeIds.
--PrintGroup=[grupp]: Skriv ut alla TypeIds i gruppen.
--PrintAttributes=[typid]: Skriv ut alla attribut av typid.
--PrintGlobals: Skriv ut listan över globala variabler.

Låt oss nu se på alternativet --PrintAttributes. Vi har redan nämnt ns-3:s attributsystem, när vi studerade skriptet first.cc. Vi såg följande rader kod,

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

och sa att DataRate är ett attribut PointToPointNetDevice. Låt oss använda kommandoradsanalysatorn för att visa attributen PointToPointNetDevice. Hjälplistan säger att vi måste ange TypeId. Detta är namnet på klassen som de intressanta attributen tillhör. I vårt fall kommer det att vara ns3::PointToPointNetDevice. Låt oss fortsätta framåt, ange,

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

Systemet kommer att skriva ut alla attribut för denna typ av nätverksenhet. Du kommer att se att bland attributen i listan finns,

--ns3::PointToPointNetDevice::DataRate=[32768bps]:
Den standard datahastighet för punkt-till-punkt-länkar

Detta är standardvärdet som kommer att användas i systemet när ett objekt skapas. PointToPointNetDevice. Vi kommer att åsidosätta detta standardvärde med hjälp av parametern Attribut på PointToPointHelper ovan. Låt oss använda standardvärdena för punkt-till-punkt-enheter och kanaler. För att göra detta tar vi bort anropen SetDeviceAttribute och SetChannelAttribute från myfirst.cc, som vi har i den rena katalogen.

Ditt skript ska nu bara deklarera PointToPointHelper och inte utföra några installationsoperationer, som visas i exemplet nedan,

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

Fortsätt och skapa ett nytt skript med Waf (.\/waf) och låt oss gå tillbaka och inkludera lite loggning från UDP echo-applikationen på servern och inkludera tidsprefix.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Om du kör skriptet, bör du se följande utdata:

Waf: Går in i katalogen `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Lämnar katalogen `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'bygg' slutfördes framgångsrikt (0.405s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Skickade 1024 byte till 10.1.1.2
2.25732s Mottog 1024 byte från 10.1.1.1
2.25732s Återkopplar paket
Mottog 1024 byte från 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Låt oss komma ihåg att förra gången vi tittade på simuleringstidpunkten för mottagandet av paketet av echoservern var det vid 2,00369 sekunder.

2.00369s UdpEchoServerApplication:HandleRead(): Mottog 1024 byte från 10.1.1.1

Nu får den paketet vid 2.25732 sekunder. Detta beror på att vi helt enkelt sänkte överföringshastigheten för PointToPointNetDevice från fem megabit per sekund till standardvärdet som är 32768 bitar per sekund. Om vi hade angivit den nya DataRate med hjälp av kommandoraden kunde vi ha ökat hastigheten på vår simulering igen. Vi gör det på följande sätt, enligt formeln som föreslås av hjälpelementet:

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

Som ett resultat kommer standardvärdet för DataRate-attributet att återgå till fem megabit per sekund. Är du förvånad över resultatet? Tydligen behöver vi för att återställa det ursprungliga beteendet i skriptet också ställa in kanalens fördröjning i enlighet med ljusets hastighet. Vi kan be kommandoraden att skriva ut kanalens attribut, precis som vi gjorde för nätverksenheten:

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

Vi kommer att upptäcka att kanalens fördröjningsattribut är inställt på följande sätt:

--ns3::PointToPointChannel::Delay=[0ns]:
Överföringsfördröjning genom kanalen

Därefter kan vi via kommandoraden ställa in båda dessa standardvärden,

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

i detta fall återställer vi tiden vi hade när vi tydligt ställde in DataRate och Delay i skriptet:

Waf: Går in i katalogen `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Lämnar katalogen `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' avslutades framgångsrikt (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Skickat 1024 byte till 10.1.1.2
2.00369s Mottaget 1024 byte från 10.1.1.1
2.00369s Ekkopaket
Mottaget 1024 byte från 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Notera att paketet mottogs igen av servern efter 2,00369 sekunder. Vi skulle faktiskt kunna ställa in vilket av de attribut som används i skriptet som helst på det här sättet. Specifikt skulle vi kunna ställa in värden som är olika från ett för attributen MaxPackets UdpEchoClient.

Hur skulle du använda detta? Prova. Kom ihåg att du måste kommentera platsen där vi åsidosätter värdet av standardattributet och ställa in det tydligt MaxPackets i skriptet. Du måste också bygga om skriptet. Du kan också få hjälp via kommandoraden för syntaxen för att ställa in ett nytt värde för standardattributet. När du förstått detta kan du styra antalet paket som visas i kommandoraden. Eftersom vi är noggranna ska vår kommandorad se ut ungefär så här:

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

En naturlig fråga som uppstår här är hur man får veta om alla dessa attributs existens. Återigen har kommandoraden en hjälpfunktion för detta. Om vi begär hjälp från kommandoraden bör vi se:

$ ./waf --run "scratch/myfirst --PrintHelp"
myfirst [Program Arguments] [General Arguments]
General Arguments:
--PrintGlobals: Skriv ut listan med globala variabler.
--PrintGroups: Skriv ut listan med grupper.
--PrintGroup=[group]: Skriv ut alla TypeIds av gruppen.
--PrintTypeIds: Skriv ut alla TypeIds.
--PrintAttributes=[typeid]: Skriv ut alla attribut för typeid.
--PrintHelp: Skriv ut detta hjälpmeddelande.

Om du väljer argumentet "PrintGroups" bör du se en lista över alla registrerade grupper. TypeId. Gruppnamnen överensstämmer med modulnamnen i källkatalogen (dock med versaler). Att skriva ut all information på en gång skulle bli för omfattande, så en ytterligare filter för utskrift av information efter grupper är tillgängligt. Så, med fokus på modulen "punkt-till-punkt":

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

Här kan du hitta tillgängliga TypeId-namn för att söka efter attribut, till exempel i
--PrintAttributes = ns3::PointToPointChannel, som visas ovan.

Ett annat sätt att lära sig om attribut är via Doxygen ns-3. Det finns en sida som listar alla registrerade attribut i simulatorn.

5.2.2 Fånga dina egna kommandon

Du kan också lägga till egna hooks via kommandoradesystemet. Detta görs ganska enkelt med metod för kommandoradsparser. AddValue.
Låt oss använda denna möjlighet för att ange antalet paket som ska visas på ett helt annat sätt. Låt oss lägga till en lokal variabel med namnet nPackets i funktionen main. Vi sätter den till en för att matcha vårt tidigare beteende som standard. För att låta kommandoradsparseren ändra detta värde behöver vi fånga detta värde i parsern. Vi gör detta genom att lägga till anropet AddValue. Gå och ändra skriptet scratch/myfirst.cc så att det börjar med följande kod,

int
main (int argc, char *argv[])
{
uint32_t nPackets = 1;
CommandLine cmd;
cmd.AddValue("nPackets", "Antal paket som ska ekas", nPackets);
cmd.Parse (argc, argv);
...

Rulla ner till den punkt i skriptet där vi sätter attributet MaxPackets och ändra det så att det är inställt på variabeln nPackets istället för konstanten 1, som visas nedan.

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

Nu, om du kör skriptet och anger argumentet --PrintHelp, borde du se det nya användarargumentet. listat på hjälpskärmen. Skriv in,

$ .\/waf --run "scratch\/myfirst --PrintHelp"
Waf: Går in i katalogen `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Lämnar katalogen `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' avslutades framgångsrikt (0.403s)
--PrintHelp: Skriv ut detta hjälpbok.
--PrintGroups: Skriv ut listan över grupper.
--PrintTypeIds: Skriv ut alla TypeIds.
--PrintGroup=[group]: Skriv ut alla TypeIds för gruppen.
--PrintAttributes=[typeid]: Skriv ut alla attribut för typeid.
--PrintGlobals: Skriv ut listan över globala värden.
Användarargument:
--nPackets: Antal paket att echoure

Om du vill ändra antalet överförda paket kan du göra det genom att ställa in argumentet - -nPackets i kommandoraden.

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

Nu bör du se

Waf: Går in i katalogen `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Lämnar katalogen `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' avslutades framgångsrikt (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Skickade 1024 bytes till 10.1.1.2
2.25732s Mottog 1024 bytes från 10.1.1.1
2.25732s Echouerande paket
Mottog 1024 bytes från 10.1.1.2
Skickade 1024 bytes till 10.1.1.2
3.25732s Mottog 1024 bytes från 10.1.1.1
3.25732s Echouerande paket
Mottog 1024 bytes från 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Du har nu skickat två paket. Ganska enkelt, eller hur?
Du kan se att som en användare av ns‑3 kan du använda kommandoradssystemet för att styra globala värden och attribut. Om du är modellförfattare kan du lägga till nya attribut till dina objekt, och de kommer automatiskt att vara tillgängliga för konfiguration av dina användare via kommandoradssystemet. Om du är skriptförfattare kan du lägga till nya variabler i dina skript och smidigt koppla dem till kommandoradssystemet.

5.3 Användning av spårningssystemet

Syftet med simulering är att skapa utdata för vidare undersökning, och ns‑3:s spårningssystem är den primära mekanismen för detta. Eftersom ns‑3 är ett program i C++ kan man använda standardmetoder för att generera utdata i program skrivna i C++:

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

Du kan till och med använda loggningsmodulen för att lägga till lite struktur i din lösning. Många problem kan uppstå med denna metod, och för att lösa dessa problem har vi tillhandahållit ett gemensamt system för händelsetransaktioner.

De huvudsakliga målen med ns‑3:s spårningssystem:

• För grundläggande uppgifter ska spårningssystemet möjliggöra för användaren att generera standardspårning för populära källor och välja objekt som genererar spårning.

• Mellanliggande användare bör kunna utvidga spårningssystemet för att ändra det genererade utdataformatet eller för att infoga nya spårningskällor utan att modifiera simulatorns kärna;

• Erfarna användare kan modifiera simulatorns kärna för att lägga till nya källor och mottagare av spårning. Ns-3:s spårningssystem bygger på principerna för oberoende spårningskällor och mottagare samt ett enhetligt mekanism för att koppla källor till konsumenter.

Ns-3:s spårningssystem bygger på principerna för oberoende spårningskällor och mottagare samt ett enhetligt mekanism för att koppla källor till mottagare. Spårningskällor är objekt som kan signalera om händelser som inträffar i simuleringen och ge tillgång till intressanta grundläggande uppgifter. Till exempel kan en spårningskälla indikera när en nätverksenhet har mottagit ett paket och ge tillgång till paketets innehåll för intresserade spårningsmottagare.

Spårningskällor är i sig själva värdelösa om de inte "ansluts" till andra delar av koden som faktiskt gör något användbart med informationen som tillhandahålls av mottagaren. Spårare är konsumenter av händelser och data som tillhandahålls av spårningskällor. Till exempel kan man skapa en spårningsmottagare som (vid anslutning till spårningskällan från det tidigare exemplet) skriver ut intressanta delar av det mottagna paketet.

En rimlig grund för en sådan tydlig separation är att tillåta användare att koppla nya typer av mottagare till befintliga spårningskällor utan att behöva redigera och rekonstruera simulatorns kärna. Därför kan användaren i det ovanstående exemplet definiera en ny spårare i sitt skript och koppla den till en befintlig spårningskälla som definieras i simuleringskärnan, endast genom att redigera användarskriptet.

I den här guiden går vi igenom vissa fördefinierade källor och mottagare och visar hur de kan konfigureras med minimal ansträngning från användarens sida. Se ns-3-guiden eller avsnitt med instruktioner för information om avancerad spårningskonfiguration, inklusive utvidgning av spårningsnamnutrymmet och skapande av nya spårningskällor.

5.3.1 ASCII Spårning

ns-3 tillhandahåller hjälpfunktionalitet som erbjuder ett lågnivå spårningssystem för att hjälpa dig med detaljerna när du ställer in enkla paketspårningar. Om du aktiverar denna funktion kommer du att se output i ASCII-filer. För dem som är bekanta med ns-2:s output, är denna typ av spårning liknande out.tr, som genereras av en mängd skript.

Låt oss komma till saken och lägga till lite ASCII-spårningsresultat i vårt skript scratch/myfirst.cc. Precis före anropet till Simulator::Run(), lägg till följande kodrader:
AsciiTraceHelper ascii;

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

Som i många andra idiomer i ns-3, använder denna kod ett hjälpbject för att skapa ASCII-spårningar. Den andra raden innehåller två inbäddade metodanrop. Metoden 'inuti' CreateFileStream() använder en anonym objektidiom för att skapa ett filströmobjekt på stacken (utan objektnamn) och skickar det till den anropade metoden. I framtiden kommer vi att fördjupa oss i detta ämne, men allt du behöver veta för tillfället är att du skapar ett objekt som representerar en fil med namnet myfirst.tr och överför det till ns-3. Vi överlåter ns-3 ansvaret för det skapade objektet under hela dess livslängd, under vilken problem som orsakas av det okända (avsiktliga) begränsningen relaterat till kopierande konstruktörer av C++ strömobjekt hanteras.

Det externa anropet EnableAsciiAll() informerar hjälparen att du vill aktivera ASCII-spårning för alla punkt-till-punkt-enhetsanslutningar i din simulering och att du vill att de (specificerade) spårningsmottagarna ska registrera information om paketens rörelse i ASCII-format.

För dem som är bekanta med ns-2 är de spårade händelserna ekvivalenta med de kända spårningspunkterna som loggar händelserna '+', '-', 'd' och 'r'.
Nu kan du kompilera skriptet och köra det från kommandoraden:

$ ./waf --run scratch/myfirst

Så många gånger tidigare har du sett flera meddelanden från Waf, och sedan "‘build’ finished successfully" (bygget slutfördes framgångsrikt) med ett antal meddelanden från programmet som körs.

När programmet körs, kommer det att skapa en fil med namnet myfirst.tr. På grund av programmets egenskaper Waf, skapas filen som standard inte i den lokala katalogen, utan i den översta katalogen av repositoryt. Om du vill ändra sökvägen där spåren sparas, kan du ange den för Waf-parametern --cwd. Vi gjorde inte det, så för att titta på ASCII-spårfilen myfirst.tr i din favoritredigerare, måste vi gå till den översta katalogen i vårt repository.

Parsing av ASCII spårning

Det finns mycket information i en ganska kompakt form, men det första att notera är att filen består av separata rader. Detta kommer att bli tydligt om du breddar visningsfönstret.

Varje rad i filen motsvarar en spårningshändelse. I det här fallet spårar vi händelser i överföringskön som finns i varje punkt-till-punkt-nätverksenhet i simuleringen. Överföringskön är den kö genom vilken varje paket måste passera för punkt-till-punkt-kanalen. Observera att varje rad i spårningsfilen inleds med en ensam symbol (och har ett mellanrum efter sig). Denna symbol kommer att ha följande betydelse:

+: en operation för att sätta i kö skedde i enhetens kö;
-: en operation för att ta bort ett element skedde i enhetens kö;
d: paketet avvisades, vanligtvis eftersom kön var full;
r: paketet mottogs av nätverksenheten.

Låt oss titta mer detaljerat på den första raden i spårningsfilen. Jag kommer att dela upp den i delar (med indrag för tydlighet) och radnumret till vänster:

0 +
1 2
2 \/NodeList\/0\/DeviceList\/0\/$ns3::PointToPointNetDevice\/TxQueue\/Enqueue
3 ns3::PppHeader (
4   Punkt-till-Punkt-protokoll: IP (0x0021))
6   ns3::Ipv4Header (
7     tos 0x0 ttl 64 id 0 protokoll 17 offset 0 flaggor [inga]
8     längd: 1052 10.1.1.1 > 10.1.1.2)
9     ns3::UdpHeader (
10      längd: 1032 49153 > 9)
11      Payload (storlek=1024)

Den första sektionen av detta utökade spårningshändelse (rad 0) är operationen. Här har vi symbolen +, som motsvarar en operation för att sätta i kö för överföring. Den andra sektionen (rad 1) är simuleringstiden, uttryckt i sekunder. Du kanske kommer ihåg att vi bad om UdpEchoClientApplication starta paketöverföringen om två sekunder. Här ser vi en bekräftelse på att detta faktiskt sker.

I nästa avsnitt av tracerouten (från rad 2) visas vilken källa som genererat denna händelse (namnrymden anges). Du kan tänka på namnrymden i tracerouten ungefär som en filsystemnamnrymd. Roten av namnrymden är NodeList. Detta motsvarar en behållare som hanteras i huvudsak av ns-3-koden. Den innehåller alla noder som skapas i skriptet. Liksom ett filsystem kan ha flera kataloger i roten, kan vi i NodeList ha många noder. Således refererar raden /NodeList/0 till nod noll i NodeList, som vi vanligtvis förstår som 'nod 0'. I varje nod finns en lista över enheter som har installerats. Denna lista ligger i nästa namnrymd. Du kan se att denna traceroute-händelse kommer från DeviceList/0, som är den nollställda enheten installerad på noden.

Den följande understrängen, $ ns3::PointToPointNetDevice, anger vilken enhet som befinner sig i nollposition: enhetslistan för nod noll. Det bör noteras att operationen + som finns på rad 0 innebar att ett element lades till i enhetens överföringskö. Detta återspeglas i de senaste segmenten av "tracern": TxQueue/Enqueue.

De återstående sektionerna i tracerouten bör vara ganska intuitiva. Raderna 3-4 visar att paketet är inkapslat i punkt-till-punkt-protokollet. Raderna 5-7 visar att paketet har en IP4-versionens rubrik och har sin ursprung från IP-adressen 10.1.1.1 och är avsett för 10.1.1.2. Raderna 8-9 visar att detta paket har en UDP-rubrik och slutligen visar rad 10 att nyttolasten är förväntade 1024 byte.

Den följande raden i traceroute-filen visar att samma paket har tagits bort från överföringskön på samma nod.

Den tredje raden i traceroute-filen visar att paketet har tagits emot av nätverksenheten på noden med echoservern. Jag återges denna händelse nedan.

0 r
1 2.25732
2 /NodeList/1/DeviceList/0/$ns3::PointToPointNetDevice/MacRx
3   ns3::Ipv4Header (
4     tos 0x0 ttl 64 id 0 protokoll 17 offset 0 flaggor [inga]
5     längd: 1052 10.1.1.1 > 10.1.1.2)
6     ns3::UdpHeader (
7       längd: 1032 49153 > 9)
8       Nyttolast (storlek=1024)

Observera att spårningsoperationen nu är r, och simuleringstiden har ökat till 2,25732 sekunder. Om du noggrant följde instruktionerna i handledningen betyder detta att du lämnade DataRate för nätverksenheter och kanalens fördröjning på sina standardvärden. Denna tid borde vara bekant, som du redan har sett i föregående avsnitt.

Namnrymden för spårningskällan (rad 2) har ändrats för att återspegla att denna händelse kommer från nod 1 (\/NodeList/1) и пакет принят источником трассировки (/MacRx). Det bör vara ganska enkelt att följa paketets rörelse genom topologin genom att titta på de kvarvarande stigen i spårningsfilen.

5.3.2 PCAP Spårning

ns-3-enhetens hjälpare kan också användas för att skapa spårningsfiler i .pcap-format. Akronymen pcap (vanligtvis skrivet med små bokstäver) står för paketfångst och är i själva verket ett API som inkluderar definitionen av .pcap filformatet. Det mest populära programmet som kan läsa och visa detta format är Wireshark (tidigare kallad Ethereal). Det finns dock många paketanalysatorer som använder detta paketformat. Vi rekommenderar användare att använda en mängd olika verktyg som är tillgängliga för analys av pcap-spår. I denna handledning kommer vi att fokusera på att visa pcap-spår med hjälp av Fungerar libdns korrekt? => Kör.

Aktiveringen av pcap-spårning görs med en kodrad.

pointToPoint.EnablePcapAll ("myfirst");

Sätt denna kodrad efter ASCII-spårningskoden som vi just har lagt till i scratch/myfirst.cc. Observera att vi endast har skickat strängen "myfirst", inte "myfirst.pcap" eller något liknande. Detta beror på att parametern är ett prefix, inte ett fullständigt filnamn. Under simuleringen kommer hjälpen faktiskt att skapa en spårningsfil för varje punkt-till-punkt-enhet. Filnamnen kommer att byggas med hjälp av prefixet, nodnumret, enhetsnumret och suffixet “.pcap».

För vårt exempel på skript kommer vi slutligen att se filer med namnen “myfirst-0-0.pcap" och "myfirst-1-0.pcap,” som är pcap-spår för nod 0-enhet 0 och nod 1-enhet 0 respektive. När du har lagt till kodraden för att aktivera pcap-spårning, kan du köra skriptet på vanligt sätt:

$ ./waf --run scratch/myfirst

Om du kollar i rotkatalogen för din distribution bör du se tre filer: en ASCII-spårningsfil, myfirst.trsom vi studerade tidigare, filer myfirst-0-0.pcap och myfirst-1-0.pcap — nya pcap-filer som vi precis har genererat.

Läser utdata med tcpdump

För närvarande är det enklast att använda tcpdump för att visa pcap-filer.

$ tcpdump -nn -tt -r myfirst-0-0.pcap
läser från filen myfirst-0-0.pcap, länktyp PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, längd 1024
2.514648 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, längd 1024
tcpdump -nn -tt -r myfirst-1-0.pcap
läser från filen myfirst-1-0.pcap, länktyp PPP (PPP)
2.257324 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, längd 1024
2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, längd 1024

I dumpen myfirst-0-0.pcap (klientapparat) kan du se att ekopaketet skickas efter 2 sekunder av simulering. Om du tittar på den andra dumpen (myfirst-1-0.pcap), kommer du att se att paketet tas emot vid 2,257324 sekunder. Du kommer att se i den andra dumpen att paketet återkommer vid 2,257324 sekunder och slutligen att paketet har mottagits av klienten tillbaka i den första dumpen vid 2,514648 sekunder.

Läser utdata med Wireshark

Om du inte är bekant med Wireshark, finns det en webbplats där du kan ladda ner program och dokumentation: http://www.wireshark.org/. Wireshark — det är ett grafiskt användargränssnitt som kan användas för att visa dessa spårningsfiler. Om du har Wireshark kan du öppna valfri av spårningsfilerna och visa innehållet som om du hade fångat paket med en paketanalysator.

Källa: habr.com