Handbok för nätverkssimulatorn ns-3. Kapitel 4

kapitel 1,2
kapitel 3

4 Översikt av konceptet
4.1 Nyckelabstraktioner
4.1.1 Nod
4.1.2 Applikation
4.1.3 Kanal
4.1.4 Nätverksenhet
4.1.5 Topologiska hjälpmedel
4.2 Första ns-3 skriptet
4.2.1 Grundkod
4.2.2 Tilläggsmoduler
4.2.3 Namnutrymme ns3
4.2.4 Loggning
4.2.5 Huvudfunktion
4.2.6 Användning av topologiska hjälpmedel
4.2.7 Användning av Applikation
4.2.8 Simulator
4.2.9 Bygga ditt scenario
4.3 ns-3 Källkod

Kapitel 4

Översikt av konceptet

Det första vi måste göra innan vi börjar studera eller skriva ns-3 kod är att förklara några grundläggande begrepp och abstraktioner i systemet. Mycket av detta kan för vissa verka uppenbart, men vi rekommenderar att du tar dig tid att läsa detta avsnitt för att säkerställa att du börjar på en stabil grund.

4.1 Nyckelabstraktioner

I detta avsnitt kommer vi att titta på vissa termer som vanligtvis används i nätverksmiljöer, men som har en specifik betydelse i ns-3.

4.1.1 Nod

I internet-jargong kallas en dator som är ansluten till nätverket för en värd eller ibland en slutlig system. Eftersom ns-3 är en nätverkssimulator och inte en internet-simulator, använder vi medvetet inte termen värd, då det är nära kopplat till internet och dess protokoll. Istället använder vi en mer generell term, som även används av andra simulatorer, som härstammar från grafteori - nod (node).

I ns-3 är den grundläggande abstraktionen av en dator en nod. Denna abstraktion representeras i C++ av klassen Node. Klassen NodeNode (nod) ger metoder för att hantera representationerna av datorer i simulationerna.

Du måste förstå Node hur en dator fungerar, som du kan lägga till funktionalitet till. Du kommer att lägga till komponenter som applikationer, protokollstackar och gränssnittskort med drivrutiner som gör det möjligt för datorn att utföra nyttig verksamhet. Vi använder samma grundläggande modell i ns-3.

4.1.2 Applikation

I allmänhet delas datorprogramvara in i två breda klasser. Systemprogramvaran organiserar olika datorresurser som minne, processorcykler, disk, nätverk och så vidare i enlighet med en viss beräkningsmodell. Systemprogramvara används vanligtvis inte för att hantera resurser för att utföra uppgifter som ger direkt nytta för användaren. För att uppnå ett visst mål startar användaren vanligtvis en applikation som får och använder resurser som kontrolleras av systemprogramvaran.

Ofta dras gränsen mellan systemprogramvara och programvaruapplikationer vid förändringen av privilegienivåer, vilket inträffar i operativsystemets avbrott. I ns-3 finns ingen verklig koncept av operativsystem och därmed inga begrepp för privilegienivåer eller systemanrop. Vi har dock en idé om applikationer. Precis som i "den verkliga världen" arbetar programvaruapplikationer på datorer för att utföra uppgifter, arbetar ns-3-applikationer på ns-3-noder för att hantera simulationer i den simulerade världen.

I ns-3 är den grundläggande abstraktionen för användarprogram som genererar viss aktivitet för modellering en applikation. Denna abstraktion representeras i C++ av klassen Application. Klassen Application tillhandahåller metoder för att hantera representationerna av vår version av användarnivåapplikationer i simulationerna. Det förväntas av utvecklarna att de ska specialisera klassen Application för att skapa nya applikationer i enlighet med objektorienterad programmering. I den här guiden kommer vi att använda specialiseringar av klassen Application som kallas UdpEchoClientApplication och UdpEchoServerApplication. Som förväntat utgör dessa applikationer en uppsättning klient/server-applikationer som används för att generera och echo-simulera nätverkspaket.

4.1.3 Kanal

I den verkliga världen kan en dator kopplas till ett nätverk. Ofta kallas de miljöer där data överförs i dessa nätverk för kanaler. När du kopplar en Ethernet-kabel till ett vägguttag kopplar du datorn till en Ethernet-kommunikationskanal. I den simulerade världen ns-3 kopplas en nod till ett objekt som representerar en kommunikationskanal. Här kallas den huvudsakliga abstraktionen av kommunikationsundersystemet för kanal och representeras i C++ av klassen Channel (kanal).

Klassen ChannelChannel tillhandahåller metoder för att hantera interaktionen mellan objekt i undersystemet och kopplingen till noder. Kanaler kan också specialiseras av utvecklare i termer av objektorienterad programmering. Specialiseringen av en kanal kan modellera något så enkelt som en sladd. En specialiserad kanal kan också modellera komplexa saker som en stor Ethernet-switch eller ett tre-dimensionellt utrymme fyllt med hinder i fallet med trådlösa nätverk.

I den här guiden kommer vi att använda specialiserade versioner av kanalen som kallas CsmaChannelCsmaChannel, PointToPointChannelPointToPointChannel och WifiChannelWifiChannel. CsmaChannel, till exempel, modellerar en version av kommunikationsundersystemet som implementerar en kommunikationsmiljö för fleranvändartillgång med bärarkontroll. Detta ger oss Ethernet-liknande funktionalitet.

4.1.4 Nätverksenhet

Tidigare var det så att om du ville koppla en dator till ett nätverk, behövde du köpa en specifik nätverkskabel och en hårdvaruenhet som kallas (i PC-terminologi) ett expansionskort, som behövde installeras i datorn. Om vissa nätverksfunktioner var implementerade på expansionskortet kallades de nätverksgränssnittskort eller nätverkskort. Idag levereras de flesta datorer med integrerad nätverksutrustning och användare ser dem inte som separata enheter.

Ett nätverkskort fungerar inte utan en programdrivrutin som styr dess hårdvara. I Unix (eller Linux) klassificeras en del of perifera enheter som en device. Enheter styrs med hjälp av enhetsdrivrutiner (device drivers), och nätverksenheter (NIC) styrs med hjälp av nätverksenhetsdrivrutiner (network device drivers) och har den samlande termen nätverksenheter (net devices). I Unix och Linux refererar du till nätverksenheter med namn som till exempel eth0.

I ns-3 omfattar abstraktionen av nätverksenheter både en programdrivrutin och den simulerade hårdvaran. Vid simulering "installeras" nätverksenheten i en nod för att möjliggöra kommunikation med andra noder via kanaler. Precis som i en verklig dator kan en nod vara ansluten till flera kanaler genom flera enheter. NetDevices.

Nätverksabstraktionen av en enhet representeras i C++ genom klassen NetDevice. Klassen NetDevice tillhandahåller metoder för att hantera anslutningar till objekt av typen Node och Channel; och kan specialanpassas av utvecklare inom objektorienterad programmering. I denna guide kommer vi att använda flera specialanpassade versioner av NetDevice med namnen CsmaNetDevice, PointToPointNetDevice och WifiNetDevice. Precis som en Ethernet-nätverksadapter är avsedd att fungera med nätverket, är Ethernet, CsmaNetDevice avsedd att fungera med CsmaChannel, PointToPointNetDevice avsedd att fungera med PointToPointChannel, och WifiNetDevice — är avsedd att fungera med WifiChannel.

4.1.5 Topologiska hjälpmedel

I ett verkligt nätverk hittar du värddatorer med tillagda (eller inbyggda) nätverkskort. I ns-3 skulle vi säga att du ser noder med anslutna NetDevices. I ett stort simulerat nätverk behöver du organisera anslutningar mellan många objekt. Node, NetDevice och Channel.

Eftersom anslutningen av NetDevices till noder, NetDevices till kanaler, tilldelning av IP-adresser osv. i ns-3 är en gemensam uppgift, så för att göra detta så enkelt som möjligt erbjuder vi så kallade topologiska hjälpmedel. Till exempel, för att skapa en NetDevice måste du utföra många grundläggande operationer i ns-3, lägga till en MAC-adress, installera denna nätverksenhet i Node, konfigurera protokollstacken för noden och sedan koppla NetDevice till Channel. Ännu fler operationer krävs för att koppla flera enheter till multipointkanaler och sedan ansluta separata nätverk till ett gemensamt nätverk (Internetworks). Vi erbjuder hjälpapparater för topologi som, för din bekvämlighet, kombinerar dessa många operationer i en lättanvänd modell.

4.2 Första ns-3 skriptet

Om du har installerat systemet enligt ovan, kommer du att ha ns-3-versionen i en katalog med namnet repos i din hemkatalog. Gå till katalogen. release

Om du inte har en sådan katalog har du inte angivit utmatningskatalogen vid kompileringen av releaseversionen av ns-3. Kör kompileringen så här:
$ ./waf configure —build-profile=release —out=build/release,
$ ./waf build

där bör du se en katalogstruktur som liknar följande:

AUTHORS       examples      scratch       utils       waf.bat*
bindings      LICENSE       src           utils.py    waf-tools
build         ns3           test.py*      utils.pyc   wscript
CHANGES.html  README        testpy-output VERSION     wutils.py
doc           RELEASE_NOTES testpy.supp   waf*        wutils.pyc

Gå till mappen examples/tutorial. Du bör se en fil där som heter first.cc. Detta är ett skript som kommer att skapa en enkel punkt-till-punkt-anslutning mellan två noder och överföra ett paket mellan noderna. Låt oss titta på detta skript rad för rad genom att öppna first.cc i din favoriteditor.

4.2.1 Grundkod
Den första raden i filen är redigerarens lägenrad emacs. Den informerar emacs om formateringskonventionerna (kodningsstil) som vi ska använda i vår källkod.

/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */

Detta är alltid en ganska kontroversiell fråga, så vi måste klargöra detta för att omedelbart få det ur vägen. Projektet ns-3, precis som de flesta större projekt, har antagit en kodningsstil som all kod som tillhandahålls måste följa. Om du vill bidra med din kod till projektet måste du så småningom följa ns-3:s kodningsstandard, som beskrivs i filen doc/codingstd.txt eller som visas på projektets webbplats: https://www.nsnam.org/develop/contributing-code/coding-style/.

Vi rekommenderar att du vänjer dig vid utseendet på kod i ns-3 och tillämpar denna standard varje gång du arbetar med vår kod. Hela utvecklingsteamet och bidragsgivare har kommit överens om detta efter en del gnäll. Emacs-läget som nämns ovan underlättar korrekt formatering om du använder editorn emacs.

Simulatorn ns-3 licensieras under GNU General Public License. Du kommer att se den relevanta juridiska rubriken för GNU i varje fil i ns-3:s distribution. Ofta kan du se en upplysning om upphovsrätt för en av de deltagande institutionerna i ns-3-projektet ovanför texten GPL och författaren som visas nedan.

/* 
* This program is free software; you can redistribute it and/or modify 
* it under the terms of the GNU General Public License version 2 as 
* published by the Free Software Foundation; 
*
* This program is distributed in the hope that it will be useful, 
* but WITHOUT ANY WARRANTY; without even the implied warranty of 
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 
* GNU General Public License for more details. 
* 
* You should have received a copy of the GNU General Public License 
* along with this program; if not, write to the Free Software 
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 
*/

4.2.2 Tilläggsmoduler

Den faktiska koden börjar med en rad include-direktiv (include).

#include "ns3/core-module.h"
#include "ns3/network-module.h"
#include "ns3/internet-module.h"
#include "ns3/point-to-point-module.h"
#include "ns3/applications-module.h"

För att hjälpa våra användare av hög nivå-skript att hantera det stora antalet header-filer som finns i systemet grupperar vi dem efter deras användning i stora moduler. Vi tillhandahåller en header-fil som rekursivt kommer att ladda alla header-filer som används i den aktuella modulen. Istället för att söka efter vilken header du behöver och kanske få rätt lista över beroenden ger vi dig möjlighet att ladda en grupp filer med hög detaljnivå. Det är kanske inte det mest effektiva tillvägagångssättet, men det gör definitivt skriptskrivning mycket enklare.

Varje inkluderad fil i ns‑3 placeras i en katalog med namnet ns3 (underkatalog för byggnation), för att undvika namnkonflikter under byggprocessen. Filen ns3/core-module.h motsvarar ns‑3-modulen som du kommer att hitta i katalogen src/core i den version du har installerat. I listningen av denna katalog hittar du ett stort antal header-filer. När du gör byggnation Waf placeras de offentliga header-filerna i katalogen ns3 i underkatalogen build/debug

Om du inte har en sådan katalog har du inte angivit utmatningskatalogen vid kompileringen av releaseversionen av ns-3. Kör kompileringen så här:
$ ./waf configure --build-profile=debug --out=build/debug
$ ./waf build
eller
$ ./waf configure --build-profile=optimized --out=build/optimized
$ ./waf build

eller build/optimized, beroende på din konfiguration. Waf kommer också automatiskt att generera en inkluderingsfil för modulen för att ladda alla offentliga header-filer. Eftersom du självklart strikt följer denna guide har du redan utfört

$ ./waf -d debug --enable-examples --enable-tests configure

för att konfigurera projektet för att köra debug-byggnader som inkluderar exempel och tester. Du har också utfört

$ .\/waf

för att bygga projektet. Så nu, när du tittar i katalogen ../..../build/debug/ns3, så kommer du där, bland annat, att hitta header-filerna från de fyra modulerna som nämns ovan. Du kan ta en titt på innehållet i dessa filer och upptäcka att de inkluderar alla offentliga filer som används av de berörda modulerna.

4.2.3 Namnutrymme ns3

Den nästa raden i skriptet first.cc är deklarationen av namnutrymmet.

using namespace ns3;

Projektet ns‑3 är implementerat i ett C++-namnrymde som kallas ns3. Detta grupperar alla ns‑3-relaterade deklarationer inom en synlighet utanför det globala namnrymden, vilket vi hoppas kommer att underlätta integrationen med annan kod. Användningen av C++-operatören införlivar namnrymden ns‑3 i det aktuella (globala) deklarativa området. Detta är ett snobbigt sätt att säga att efter denna deklaration behöver du inte ange operatören ns3:: scope före all ns‑3-kod för att använda den. Om du inte är bekant med namnrymder, kolla på nästan vilken C++-lärobok som helst och jämför namnrymden ns3 med användningen av namnrymden std och deklarationer. using namespace std; i exempel med utmatningsoperatören cout och strömmarna.

4.2.4 Loggning

Nästa rad i skriptet är så här:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Vi kommer att använda detta påstående som en bekväm plats för att diskutera vårt dokumentationssystem. DoxygenOm du tittar på ns‑3-projektets webbplats hittar du en länk till "Dokumentation" i navigeringspanelen. Om du väljer denna länk hamnar du på vår dokumentationssida. Det finns en länk till "Senaste utgåvan", som tar dig till dokumentationen för den senaste stabila versionen av ns‑3. Om du väljer länken "API Documentation" kommer du till ns‑3:s API-dokumentationssida.

Till vänster på sidan finner du en grafisk representation av dokumentationsstrukturen. En bra plats att börja är "boken" Modules ns‑3 i ns‑3:s navigeringsträd. Om du expanderar Moduler, kommer du att se en lista över dokumentationen för ns‑3-moduler. Som diskuterats ovan är begreppet modul här direkt kopplat till filerna som inkluderas i modulen ovan. Ns‑3:s loggningssystem diskuteras i avsnittet Användning av loggningsmodulen, därför kommer vi att återkomma till den senare i denna guide, men du kan lära dig mer om det ovanstående uttalandet genom att titta på modulen Core, och sedan öppna boken Debugging tools, och sedan välja sidan Logging. Klicka på Logging.

Nu bör du granska dokumentationen Doxygen för modulen Logging. I listan över makron högst upp på sidan ser du en post för NS_LOG_COMPONENT_DEFINE. Innan du följer länken, se till att kolla på "Detaljerad beskrivning" av loggmodulen för att förstå dess funktioner. För att göra detta kan du scrolla ner eller välja "More…" under diagrammet.

När du har en allmän förståelse av vad som pågår, gå vidare och se dokumentationen för specifika NS_LOG_COMPONENT_DEFINE. Jag kommer inte att duplicera dokumentationen här, men för att sammanfatta kan jag säga att denna rad deklarerar en loggkomponent med namnet FirstScriptExample, som gör det möjligt att aktivera och deaktivira konsol-loggning av meddelanden via länken till namnet.

4.2.5 Huvudfunktion

I de följande raderna av skriptet ser du,

int 
main (int argc, char *argv[])
{ 

Detta är bara en deklaration av huvudfunktionen i ditt program (skript). Precis som i varje C++-program måste du definiera huvudfunktionen, som körs först. Här är det inget speciellt. Ditt ns-3-skript är helt enkelt ett C++-program. Nästa rad ställer in tidupplösningen på 1 nanosekund, vilket är standardvärdet:

Time::SetResolution (Time::NS);

Tidupplösning eller helt enkelt upplösning är det minsta tidsvärdet som kan användas (den minsta tänkbara skillnaden mellan två tidsvärden). Du kan ändra upplösningen exakt en gång. Mekanismen som möjliggör denna flexibilitet förbrukar minne, så när upplösningen har ställts in explicit frigör vi minnet för att förhindra ytterligare uppdateringar. (Om du inte ställer in upplösningen explicit kommer den som standard att vara en nanosekund, och minnet kommer att frigöras vid simuleringens början.)

De följande två raderna av skriptet används för att aktivera två loggkomponenter som är inbyggda i applikationerna EchoClient och EchoServer:

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO); LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO);

Om du har läst dokumentationen för komponenten Logging, har du sett att det finns flera nivåer av loggning/detaljeringsgrad som du kan aktivera på varje komponent. Dessa två rader kod inkluderar felsökning på INFO-nivå för echo-klienter och servrar. På denna nivå kommer applikationen att skriva ut meddelanden vid sändning och mottagning av paket under simuleringen.

Nu går vi direkt till att skapa topologin och starta simuleringen. Vi kommer att använda topologiska hjälpare för att göra detta så enkelt som möjligt.

4.2.6 Användning av topologiska hjälpmedel

De följande två raderna kod i vårt skript kommer faktiskt att skapa Node ns‑3-objekt som representerar datorer i simuleringen.

NodeContainer nodes;
nodes.Create (2);

Innan vi fortsätter, låt oss hitta dokumentationen för klassen NodeContainer. Ett annat sätt att komma åt dokumentationen för denna klass är genom fliken Classes på sidorna Doxygen. Om du redan har Doxygen öppet, bläddra bara upp till toppen av sidan och välj fliken Classes. Du bör se en ny uppsättning flikar, en av vilka är klasslistan. Under denna flik kommer du att se en lista över alla klasser ns‑3. Bläddra ner till ns3 :: NodeContainer. När du hittar klassen, välj den för att gå till dokumentationen för klassen.

Som vi minns, är en av våra centrala abstraktioner en nod. Den representerar datorn som vi kommer att lägga till saker som protokollstackar, applikationer och gränssnittskort till. Den topologiska hjälpen NodeContainer ger ett bekvämt sätt att skapa, hantera och komma åt alla objekt Node, som vi skapar för att köra simuleringen. Den första raden ovan deklarerar NodeContainer, som vi kallar nodes. Den andra raden anropar metoden Create för objektet nodes och ber containern att skapa två noder. Som beskrivet i Doxygen, ber containern systemet ns‑3 att skapa två objekt Node och lagrar pekare på dessa objekt inuti sig.

De noder som skapades i skriptet gör fortfarande inget. Nästa steg i att bygga topologin är att koppla våra noder till nätverket. Den enklaste formen av nätverk som vi stöder är en punkt-till-punkt-anslutning mellan två noder. Vi kommer nu att skapa en sådan koppling.

PointToPointHelper

Vi skapar en tvåpunktsanslutning genom att använda en bekant mall och en topologisk hjälpare för att utföra det lågnivåarbete som krävs för anslutningen. Vi påminner om att våra två nyckelabstraktioner NetDevice och Channel. I den verkliga världen motsvarar dessa termer ungefär perifera kort och nätverkskablar. Som regel är dessa två saker nära kopplade till varandra, och ingen kan förlita sig på att byta, till exempel, enheter Ethernet via en trådlös kanal. Våra topologiska hjälpare följer denna nära koppling och därför kommer du i detta scenario att använda ett objekt PointToPointHelper för att konfigurera och ansluta ns-3 objekt PointToPointNetDevice och PointToPointChannel. De följande tre raderna i scenariot:

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

Den första raden,

PointToPointHelper pointToPoint;

skapar en instans av objektet i stacken. PointToPointHelperSett ur ett högre perspektiv säger nästa rad,

pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));

att objektet PointToPointHelper ska använda värdet "5 Mbps" (fem megabit per sekund) som "DataRate».

Sett ur ett mer specifikt perspektiv motsvarar raden "DataRate" det som vi kallar en attribut. PointToPointNetDevice. Om du ser på Doxygen för klassen ns3::PointToPointNetDevice och i dokumentationen för metoden GetTypeId kommer du att hitta en lista med attribut som definieras för enheten. Bland dessa kommer det att finnas attributet "DataRate". De flesta användarobjekt i ns-3 har liknande listor av attribut. Vi använder denna mekanism för enkel konfiguration av simuleringen utan omkompilering, som du kommer att se i nästa avsnitt.

På liknande sätt som "DataRate" i PointToPointNetDevice, hittar du attributet "Delay" kopplat till PointToPointChannel. Den slutliga raden,

pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));

säger PointToPointHelper använder värdet "2 ms" (två millisekunder) som värde för fördröjningen av signalen genom den punkt-till-punktkanalen som den senare skapar.

NetDeviceContainer

Hittills har vi i scenariot NodeContainer, som innehåller två noder. Vi har PointToPointHelper, som är redo att skapa objekt PointToPointNetDevices och ansluta dem med hjälp av objektet PointToPointChannel. På samma sätt som vi använde en topologisk hjälpare NodeContainer för att skapa noder, kommer vi att be PointToPointHelper att utföra det arbete som rör skapandet, konfigurationen och installationen av våra enheter. Vi kommer att behöva en lista över alla skapade objekt. NetDevice, därför använder vi NetDeviceContainer för deras lagring precis som vi använde NodeContainer för att lagra de noder vi har skapat. De följande två kodraderna,

NetDeviceContainer devices;
devices = pointToPoint.Install (nodes);

slutför inställningen av enheter och kanalen. Den första raden deklarerar enhetens behållare, nämnd ovan, och den andra gör det huvudsakliga arbetet. Metoden Installera anläggningen. PointToPointHelper accepterar NodeContainer som parameter. Inuti NetDeviceContainer för varje nod som finns i NodeContainer skapas (för punkt-till-punkt-kopplingar måste det finnas exakt två) PointToPointNetDevice skapas och lagras i enhetsbehållaren. PointToPointChannel skapas, och två PointToPointNetDevices. Efter skapandet av objekten används attributen som lagrades i PointToPointHelper, för att initiera motsvarande attribut i de skapade objekten.

Efter anropet av pointToPoint.Install (nodes) kommer vi att ha två noder, var och en med en installerad "punkt-till-punkt" nätverksenhet och en "punkt-till-punkt" kanal mellan dem. Båda enheterna kommer att konfigureras för att överföra data med en hastighet av fem megabit per sekund med en överföringsfördröjning på två millisekunder.

InternetStackHelper

Nu har vi konfigurerat noder och enheter, men våra noder saknar protokollstackar. De följande två kodraderna kommer att ta hand om detta.

InternetStackHelper stack;
stack.Install (nodes);

InternetStackHelper är en topologihjälpare för internetstackar, liknande PointToPointHelper för punkt-till-punkt nätverksenheter. Metoden Installera tar en NodeContainer som parameter. När den körs kommer den att installera internetstacken (TCP, UDP, IP etc.) på varje nod i behållaren.

Ipv4AddressHelper

Sedan behöver vi koppla våra enheter till IP-adresser. Vi tillhandahåller en topologihjälpare för hantering av distributionen av IP-adresser. Den enda användarbar API:n synlig för användaren är att ställa in en grundläggande IP-adress och nätmask för användning vid utförandet av den faktiska adresstilldelningen (detta görs på en lägre nivå inuti hjälparen). De följande två kodraderna i vårt exempel skript first.cc,

Ipv4AddressHelper address;
address.SetBase ("10.1.1.0", "255.255.255.0");

deklarerar ett hjälpbjekt för adresser och berättar för det att det ska börja tilldela IP-adresser från nätverket 10.1.1.0, med hjälp av en nätmask på 255.255.255.0 för att avgöra detta. Som standard kommer tilldelade adresser att börja med ett och öka monotoniskt, så den första adressen som tilldelas från denna bas blir 10.1.1.1, följt av 10.1.1.2 och så vidare. I verkligheten håller systemet ns-3 vid lågnivå koll på alla tilldelade IP-adresser och genererar ett fatalt fel om du av misstag skapar en situation där samma adress genereras två gånger (för övrigt är detta fel svårt att debugga).

Följande kodrad,

Ipv4InterfaceContainer interfaces = address.Assign (devices);

utför den faktiska adressallokeringen. I ns-3 upprättar vi en koppling mellan IP-adressen och enheten genom att använda objektet Ipv4Interface. Precis som vi ibland behöver en lista över nätverksenheter skapade av hjälparen för senare användning, behöver vi ibland en lista över objekt. Ipv4Interface. Ipv4InterfaceContainer erbjuder denna funktionalitet.

Vi har byggt ett punkt-till-punkt-nätverk, med installerade stackar och tilldelade IP-adresser. Nu behöver vi tillämpningar i varje nod för att generera trafik.

4.2.7 Användning av Applikation

En annan av de grundläggande abstraktionerna i systemet ns-3 är Application (applikation). I detta scenario använder vi två specialiseringar av basklassen Application ns-3 som heter UdpEchoServerApplication och UdpEchoClientApplication. Som i de tidigare fallen använder vi hjälpbjekt för att konfigurera och hantera basobjekten. Här använder vi UdpEchoServerHelper och UdpEchoClientHelperobjekt för att göra vårt liv enklare.

UdpEchoServerHelper

Följande kodrader i vårt exempel skript first.cc används för att konfigurera en UDP-eko serverapplikation på en av noderna som vi skapade tidigare.

UdpEchoServerHelper echoServer (9);

ApplicationContainer serverApps = echoServer.Install (nodes.Get (1));
serverApps.Start (Seconds (1.0));
serverApps.Stop (Seconds (10.0));

Den första kodraden i den angivna koden skapar UdpEchoServerHelper. Precis som vanligt är detta inte en applikation i sig, utan ett objekt som hjälper oss att skapa verkliga applikationer. En av våra överenskommelser är att överlämna nödvändiga attribut till konstruktorn för hjälpobjektet. I det här fallet kan hjälpen inte göra något användbart om den inte får portnumret som servern kommer att vänta på paket, detta nummer måste också vara känt för klienten. I detta fall överlämnar vi portnumret till konstruktorn för hjälpen. Konstruktorn utför i sin tur bara SetAttribute med det överlämnade värdet. Senare, om så önskas, kan du med hjälp av SetAttribute ställa in ett annat värde för attributet "Port".

Liksom många andra hjälpapparater har objektet UdpEchoServerHelper en metod Installera. Att utföra denna metod leder faktiskt till att en grundläggande echo-serverapplikation skapas och kopplas till noden. Intressant nog har metoden Installera accepterar NodeContainter ett parameterliknande andra Installera metoder som vi har sett.

Den implicita omvandlingen i C++, som fungerar här, tar resultatet från metoden node.Get (1) (som returnerar en smart pekare på nodobjektet — Ptr) och använder den i konstruktorn för det anonyma objektet NodeContainer, som sedan överlämnas till metoden Installera. Om du inte kan identifiera i C++-koden vilken metod med vilken signatur som kompileras och körs, bör du titta bland de implicita omvandlingarna.

Nu ser vi att echoServer.Install planerar att installera applikationen UdpEchoServerApplication på den som hittades i NodeContainer, som vi använder för att hantera våra noder, noden med index 1. Metoden Installera återkommer med en behållare som innehåller pekare till alla applikationer (i detta fall en, eftersom vi överlämnade en anonym NodeContainer, som innehåller en nod) skapad av hjälpen.

Applikationerna måste ange när trafikgenereringen ska starta "start" och kan behöva ytterligare ange tiden då den ska stoppas "stop". Vi tillhandahåller båda parametrarna. Dessa tider ställs in med hjälp av metoderna ApplicationContainer Start och Stoppa. Dessa metoder tar parameter av typen Tid. I detta fall använder vi explicita C++-omvandlingar för att ta en C++ double 1.0 och konvertera det till objektet tns‑3 Time, som använder objektet Seconds för att konvertera till sekunder. Kom ihåg att omvandlingsreglerna kan kontrolleras av modellens skapare, och C++ har sina egna regler, så du kan inte alltid lita på att parametrarna omvandlas som du förväntade dig. Två rader,

serverApps.Start (Seconds (1.0));
serverApps.Stop (Seconds (10.0));

kommer att leda till att echoserverapplikationen startar (aktiveras automatiskt) efter en sekund från simuleringens början och stoppar (avaktiveras) efter tio sekunder av simuleringen. Eftersom vi har deklarerat en simuleringshändelse (applikationsstoppande händelse) som kommer att genomföras efter tio sekunder, så kommer nätverksdriften att simuleras under minst tio sekunder.

UdpEchoClientHelper

Klientapplikationen echo konfigureras på ett sätt som praktiskt taget liknar servern. Det finns ett grundläggande objekt UdpEchoClientApplication, som hanteras av
UdpEchoClientHelper.

UdpEchoClientHelper echoClient (interfaces.GetAddress (1), 9);
echoClient.SetAttribute ("MaxPackets", UintegerValue (1));
echoClient.SetAttribute ("Interval", TimeValue (Seconds (1.0)));
echoClient.SetAttribute ("PacketSize", UintegerValue (1024));

ApplicationContainer clientApps = echoClient.Install (nodes.Get (0));
clientApps.Start (Seconds (2.0));
clientApps.Stop (Seconds (10.0));;

Men för echoklienten behöver vi ställa in fem olika attribut. De första två attributen ställs in vid skapandet UdpEchoClientHelper. Vi överför parametrarna som används (inuti hjälparen) för att ställa in attributen "RemoteAddress" och "RemotePort" i enlighet med vår överenskommelse om att överföra de nödvändiga parametrarna till hjälparens konstruktor.

Vi påminner om att vi använde Ipv4InterfaceContainer för att spåra IP-adresserna som vi har tilldelat våra enheter. Nollgränssnittet i gränssnittskontainern kommer att motsvara IP-adressen för nollnoden i nodkontainern. Första gränssnittet i gränssnittskontainern motsvarar IP-adressen för första noden i nodkontainern. Så, i den första raden av koden (överst) skapar vi hjälparen och informerar den om att klientens fjärradress kommer att vara IP-adressen som tilldelats noden där servern finns. Vi säger också att paket måste skickas till nionde porten.

Attributet „MaxPackets“ informerar klienten om det maximala antalet paket som vi kan skicka under simuleringen. Attributet „Interval“ meddelar klienten hur länge man ska vänta mellan paketen, och attributet „PacketSize“ informerar klienten om hur stora paketets nyttolast ska vara. Med denna kombination av attribut ber vi klienten att skicka ett 1024-byte paket.

Som med echoservern sätter vi också attributen för ekoch klienten Start och Stoppa, men här startar vi klienten en sekund efter servern aktiveras (två sekunder efter att simuleringen har börjat).

4.2.8 Simulator

Vid detta steg behöver vi starta simuleringen. Detta görs med hjälp av den globala funktionen Simulator::Run.

Simulator::Run ();

När vi tidigare anropade metoder,

serverApps.Start (Seconds (1.0));
serverApps.Stop (Seconds (10.0));
... 
clientApps.Start (Seconds (2.0));
clientApps.Stop (Seconds (10.0));

har vi faktiskt schemalagt evenemang i simuleringen på 1,0 sekunder, 2,0 sekunder och två evenemang på 10,0 sekunder. Efter anropet Simulator::Run, kommer systemet att börja gå igenom listan över schemalagda evenemang och utföra dem. Först kommer det att starta evenemanget efter 1,0 sekunder, vilket aktiverar echoserverapplikationen (detta evenemang kan i sin tur schemalägga många andra evenemang). Sedan kommer det att starta evenemanget som är schemalagt för t = 2,0 sekunder, vilket startar ekoch klientapplikationen. Återigen kan detta evenemang schemalägga många andra evenemang. Genomförandet av start-evenemanget i ekoch klienten kommer att påbörja datatransfersteget för simuleringen genom att skicka ett paket till servern.

Skickandet av paketet till servern kommer att aktivera en kedja av evenemang som automatiskt kommer att schemaläggas i bakgrunden och som kommer att implementera mekaniken för att skicka echosignals paket i enlighet med de synkroniseringsparametrar som vi har ställt in i scenariot.

Som en följd av detta, eftersom vi bara skickar ett paket (kom ihåg att attributet MaxPackets var inställt på ett), kommer kedjan av evenemang som initierades av denna enda klient-echo-förfrågan att avslutas, och simuleringen kommer att gå in i vänteläge. När detta sker kommer de återstående schemalagda evenemangen att vara evenemang Stoppa för servern och klienten. När dessa evenemang har genomförts finns det inga evenemang kvar för vidare behandling och Simulator::Run tillbaka kontrollen. Simuleringen är avslutad.

Det är bara att städa upp efter sig. Detta görs genom att anropa den globala funktionen Simulator::DestroyEftersom hjälpfunktioner (eller lågnivåkod för ns-3) anropades, organiserade de sig så att hookar för att förstöra alla skapade objekt skulle sättas in i simulatorn. Du behöver inte spåra något av dessa objekt själv – allt du behövde göra var att anropa Simulator::Destroy och avsluta. Systemet ns-3 kommer att göra det här tunga arbetet åt dig. De återstående raderna i vår första ns-3-skript, first.cc, gör just detta:

Simulator::Destroy ();
return 0;
}

När stoppas simulatorn?

ns-3 är en simulering av diskreta händelser (DE). I en sådan simulator är varje händelse kopplad till tidpunkten för dess utförande, och simuleringen fortsätter genom att bearbeta händelser i den ordning de inträffar under simuleringens gång. Händelser kan leda till att framtida händelser planeras (till exempel kan en timer omplanera sig själv för att avsluta en nedräkning under nästa intervall).

Inledande händelser initieras vanligtvis av ett objekt, till exempel kommer IPv6 att planera upptäckten av tjänster i nätverket, grannförfrågningar etc. Applikationen planerar den första händelsen för paketutsändning etc. När en händelse bearbetas kan den generera noll, en eller flera händelser. Allteftersom simuleringen fortgår inträffar händelser, antingen avslutas de eller generar nya. Simuleringen kommer automatiskt att stoppa om händelsekön är tom eller ett speciellt händelse upptäckts. StoppaEn händelse Stoppa genereras av funktionen Simulator::Stop (stoppa tiden).

Det finns ett typiskt fall där Simulator::Stop är absolut nödvändigt för att stoppa simuleringen: när det finns självupprepande händelser. Självupprepande (eller återkommande) händelser är sådana händelser som alltid omplaneras. Som ett resultat håller de alltid händelsekön inte tom. Det finns många protokoll och moduler som innehåller återkommande händelser, såsom:

• FlowMonitor – periodisk kontroll av förlorade paket;

• RIPng – periodisk sändning av uppdateringar av routingtabeller;

• osv.

I sådana fall Simulator::Stop är nödvändig för att korrekt stoppa simuleringen. Dessutom, när ns-3 är i emuleringsläge, används RealtimeSimulator för att synkronisera simuleringens klocka med maskinens klocka, och Simulator::Stop är nödvändig för att stoppa processen.

Många av simuleringsprogrammen i läroboken anropar inte Simulator::Stop Det är uppenbart, eftersom de avslutas automatiskt när händelserna i kön är slut. Men dessa program kommer också att ta emot anropet Simulator::Stop. Till exempel, följande extra rad i det första programmet schemalägger en uttrycklig stoppning vid sekund 11:

+ Simulator::Stop (Seconds (11.0));
  Simulator::Run ();
  Simulator::Destroy ();
  return 0;
}

Det ovanstående kommer faktiskt inte att ändra programmet, eftersom denna specifika simulering naturligtvis avslutas efter 10 sekunder. Men om du ändrade stopp-tiden i den angivna raden ovan från 11 sekunder till 1 sekund, skulle du märka att simuleringen stoppar innan någon utmatning når skärmen (eftersom utmatningen sker ungefär efter 2 sekunders simuleringstid).

Det är viktigt att anropa Simulator::Stop innan du anropar Simulator::Run; annars kan Simulator::Run aldrig återge kontrollen till huvudprogrammet för att utföra stoppet!

4.2.9 Bygga ditt scenario

Vi har gjort skapandet av dina enkla skript trivialt. Allt du behöver göra är att placera ditt skript i scratch-katalogen, så kommer det att kompileras automatiskt när du kör Waf. Låt oss prova. Gå tillbaka till rotkatalogen och kopiera examples/tutorial/first.cc i katalogen scratch

$ cd ../..
$ cp examples/tutorial/first.cc scratch/myfirst.cc

Nu ska du kompilera ditt första exempel på skript med waf:

$ .\/waf

Du bör se meddelanden om att ditt första exempel har skapats framgångsrikt.

Waf: Går in i katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
[614/708] cxx: scratch/myfirst.cc -> build/debug/scratch/myfirst_3.o
[706/708] cxx_link: build/debug/scratch/myfirst_3.o -> build/debug/scratch/myfirst
Waf: Lämnar katalogen `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' avslutades framgångsrikt (2.357s)

Nu kan du köra exemplet (observera att om du kompilerar ditt program i scratch-katalogen, så måste du också köra det från scratch):

$ ./waf --run scratch/myfirst

Du bör se en liknande utmatning:

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

Här ser du att byggsystemet kontrollerar att filen har byggts och sedan kör den. Du ser att en komponentpost på echo-klienten indikerar att den har skickat en 1024-byte paket till echo-servern 10.1.1.2. Du kan också se komponenten för loggning på echo-servern som visar att den fick 1024 byte från 10.1.1.1. Echo-servern skickar tyst tillbaka paketet, och du ser i loggen på echo-klienten att den fått sitt paket tillbaka från servern.

4.3 ns-3 Källkod

Nu när du har använt några av ns-3:s hjälpverktyg kan du ta en titt på några av källkoderna som implementerar denna funktionalitet. Den senaste koden kan ses på vår webbserver via följande länk: https://gitlab.com/nsnam/ns-3-dev.git. Där kommer du att se en sammanfattande sida i Mercurial för vårt ns-3 utvecklingsträd. I toppen av sidan ser du några länkar:

summary | shortlog | changelog | graph | tags | files

Fortsätt och välj länken till filerna. Så här ser det översta nivån ut i de flesta av våra förråd:

drwxr-xr-x                               [up]
drwxr-xr-x                               bindings python  files
drwxr-xr-x                               doc              files
drwxr-xr-x                               examples         files
drwxr-xr-x                               ns3              files
drwxr-xr-x                               scratch          files
drwxr-xr-x                               src              files
drwxr-xr-x                               utils            files
-rw-r--r-- 2009-07-01 12:47 +0200 560    .hgignore        file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 1886   .hgtags          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 1276   AUTHORS          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 30961  CHANGES.html     file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 17987  LICENSE          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 3742   README           file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 16171  RELEASE_NOTES    file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 6      VERSION          file | revisions | annotate
-rwxr-xr-x 2009-07-01 12:47 +0200 88110  waf              file | revisions | annotate
-rwxr-xr-x 2009-07-01 12:47 +0200 28     waf.bat          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 35395  wscript          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 7673   wutils.py        file | revisions | annotate

Våra exempel på skript finns i katalogen examples. Om du klickar på exempel, kommer du att se en lista över underkataloger. En av filerna i underkatalogen tutorial — first.cc. Om du klickar på first.cc ser du koden som du just har studerat.

Källkoden finns huvudsakligen i katalogen src. Du kan visa koden genom att klicka på katalognamnet eller genom att klicka på länken "filer" till höger om katalognamnet. Om du klickar på katalogen src får du en lista över underkataloger i src. Om du sedan klickar på underkatalogen core hittar du en lista över filer. Den första filen du ser (vid skrivandet av denna guide) — abort.h. Om du klickar på länken abort.h, kommer du att skickas till källfilen för abort.h, som innehåller användbara makron för att avsluta skript om onormala tillstånd upptäcks. Koden för hjälparna som vi använde i detta kapitel finns i katalogen src/Applications/helper. Tveka inte att gräva i katalogträdet för att förstå vad som finns och för att få en känsla för ns‑3:s programmeringsstil.

Källa: habr.com