🥇 ns-3 hálózati szimulátor bemutatója. 4. fejezet

1,2. fejezet
3. fejezet

4 A koncepció áttekintése
4.1 Kulcsfontosságú absztrakciók
4.1.1 Csomópont
4.1.2 Alkalmazás
4.1.3 Csatorna
4.1.4 Hálózati eszköz
4.1.5 Topológiai asszisztensek
4.2 Első ns-3 szkript
4.2.1 Kazántábla kódja
4.2.2 Beépülő modulok
4.2.3 ns3 névtér
4.2.4 Naplózás
4.2.5 Fő funkció
4.2.6 Topológia asszisztensek használata
4.2.7 Alkalmazás használata
4.2.8 Szimulátor
4.2.9 A forgatókönyv elkészítése
4.3 ns-3 Forráskód

Fejezet 4

Fogalom áttekintése

Az első dolog, amit meg kell tennünk az ns-3 kód tanulásának vagy írásának megkezdése előtt, hogy elmagyarázunk néhány alapvető fogalmat és absztrakciót a rendszerben. Ennek nagy része nyilvánvalónak tűnhet egyesek számára, de javasoljuk, hogy szánjon időt ennek a szakasznak a elolvasására, hogy biztos alapokon induljon.

4.1 Kulcsfontosságú absztrakciók

Ebben a részben megvizsgálunk néhány olyan kifejezést, amelyeket gyakran használnak az interneten, de konkrét jelentésük van az ns-3-ban.

4.1.1 Csomópont

Az internetes zsargonban a hálózathoz csatlakozó számítógépes eszközt gazdagépnek vagy néha végrendszernek nevezik. Mivel az ns-3 hálózati szimulátor és nem internetes szimulátor, szándékosan nem használjuk a host kifejezést, mivel ez szorosan összefügg az Internettel és annak protokolljaival. Ehelyett egy általánosabb, más szimulátorok által is használt kifejezést használunk, amely a gráfelméletből származik: node (csomópont).

Az ns-3-ban egy számítástechnikai eszköz mögöttes absztrakcióját csomópontnak nevezik. Ezt az absztrakciót a C++-ban a Node osztály képviseli. Osztály NodeNode (csomópont) módszereket biztosít a számítástechnikai eszközök szimulációs ábrázolásainak manipulálására.

Meg kell értened Csomópont mint egy számítógép, amelyhez funkcionalitást ad hozzá. Hozzáadhat olyan dolgokat, mint például alkalmazások, protokollveremek és perifériakártyák olyan illesztőprogramokkal, amelyek lehetővé teszik a számítógép számára, hogy hasznos munkát végezzen. Ugyanezt az alapmodellt használjuk az ns-3-ban.

4.1.2 Alkalmazás

A számítógépes szoftvereket általában két nagy csoportra osztják. A rendszerszoftver valamilyen számítási modell szerint rendszerezi a különféle számítógépes erőforrásokat, például memóriát, processzorciklusokat, lemezt, hálózatot stb. A rendszerszoftver általában nem használja fel ezeket az erőforrásokat olyan feladatok végrehajtására, amelyek közvetlenül a felhasználó hasznát veszik. A felhasználó jellemzően egy adott cél elérése érdekében futtat egy alkalmazást, amely a rendszerszoftver által vezérelt erőforrásokat szerez meg és használja.

A rendszer- és az alkalmazásszoftver közötti elválasztási vonalat gyakran az operációs rendszer csapdáiban fellépő jogosultsági szintű változások húzzák meg. Az ns-3-nak nincs valódi fogalma az operációs rendszerről, ezért nincs fogalma a jogosultsági szintekről vagy a rendszerhívásokról. Van azonban egy ötletünk egy alkalmazásra. Csakúgy, mint a „valós világban” számítógépeken futó szoftveralkalmazások feladatok végrehajtására, az ns-3 alkalmazások az ns-3 csomópontokon futnak a szimulációk vezérlésére a szimulált világban.

Az ns-3-ban a modellezéshez valamilyen tevékenységet generáló felhasználói program alapvető absztrakciója egy alkalmazás. Ezt az absztrakciót a C++ nyelvben az Application osztály képviseli. Az Application osztály módszereket biztosít az alkalmazások felhasználói szintű verzióinak nézeteinek manipulálására a szimulációkban. A fejlesztőktől elvárják, hogy az Application osztályt objektum-orientált programozási értelemben specializálják új alkalmazások létrehozásához. Ebben az oktatóanyagban az Alkalmazás osztály szakirányait fogjuk használni UdpEchoClientApplication и UdpEchoServerApplication. Ahogy az várható volt, ezek az alkalmazások a hálózati csomagok generálására és visszhangzására használt kliens/szerver alkalmazásokat alkotják.

4.1.3 Csatorna

A való világban csatlakoztathat számítógépet a hálózathoz. Gyakran csatornáknak nevezik azokat a médiákat, amelyeken keresztül ezekben a hálózatokban az adatokat továbbítják. Ha Ethernet-kábelt csatlakoztat a fali aljzathoz, akkor a számítógépet egy Ethernet-kapcsolathoz csatlakoztatja. A szimulált ns-3 világban egy csomópont egy kommunikációs csatornát képviselő objektumhoz csatlakozik. Itt a kommunikációs alhálózat alapvető absztrakcióját csatornának nevezzük, és a C++-ban a Channel osztály képviseli.

Osztály CsatornaCsatorna módszereket biztosít az alhálózati objektumok interakciójának kezelésére és a csomópontok hozzájuk való csatlakoztatására. A csatornákat a fejlesztők objektum-orientált programozási értelemben is specializálhatják. A csatornaspecializáció olyan egyszerű dolgokat is modellezhet, mint egy vezeték. Egy dedikált csatorna olyan összetett dolgokat is modellezhet, mint például egy nagy Ethernet switch vagy egy akadályokkal teli háromdimenziós tér vezeték nélküli hálózatok esetén.

Ebben az oktatóanyagban a csatorna speciális verzióit fogjuk használni CsmaChannelCsmaChannel, PointToPointChannelPointToPointChannel и WifiChannelWifiChannel. CsmaChannelPéldául egy kommunikációs alhálózat egy olyan verzióját modellezi, amely hordozó-érzékelésű többszörös hozzáférésű kommunikációs környezetet valósít meg. Ez Ethernet-szerű funkcionalitást biztosít számunkra.

4.1.4 Hálózati eszköz

Régebben úgy volt, hogy ha a számítógépet hálózatra akarta kötni, akkor vásárolnia kellett egy adott hálózati kábelt és egy hardvereszközt, amelyet (számítógépes terminológiában) perifériakártyának neveztek, amit a számítógépbe kellett telepíteni. Ha egy perifériakártya megvalósított néhány hálózati funkciót, azokat hálózati interfészkártyáknak vagy hálózati kártyáknak nevezték. Manapság a legtöbb számítógép integrált hálózati interfész hardverrel rendelkezik, és a felhasználók nem tekintik külön eszköznek.

A hálózati kártya nem működik a hardverét vezérlő illesztőprogram nélkül. A Unix (vagy Linux) rendszerben a periféria egy eszköznek minősül. Az eszközöket eszközillesztők, a hálózati eszközöket (NIC) pedig hálózati eszközillesztők (hálózati eszköz-illesztőprogramok) és összefoglaló néven hálózati eszközöknek (netes eszközök). A Unix és a Linux alatt a hálózati eszközöket olyan névvel illeti, mint pl eth0.

Az ns-3-ban a hálózati eszköz absztrakciója lefedi mind a szoftver-illesztőprogramot, mind a modellezett hardvert. A szimuláció során egy hálózati eszközt "telepítenek" egy csomópontba, hogy lehetővé tegye a többi csomóponttal való kommunikációt csatornákon keresztül. Csakúgy, mint egy valódi számítógép, egy csomópont több eszközön keresztül is csatlakoztatható több csatornához NetDevices.

Egy eszköz hálózati absztrakcióját C++-ban az osztály képviseli NetDevice. Osztály NetDevice módszereket biztosít a csomóponti és csatornaobjektumokkal való kapcsolatok kezelésére; és a fejlesztők specializálódhatnak az objektum-orientált programozás értelmében. Ebben az oktatóanyagban a NetDevice több speciális verzióját fogjuk használni CsmaNetDevice, PointToPointNetDevice и WifiNetDevice. Csakúgy, mint az Ethernet hálózati adaptert arra tervezték, hogy hálózattal működjön Ethernet, CsmaNetDevice úgy tervezték, hogy dolgozzon vele CsmaChannel, PointToPointNetDevice úgy tervezték, hogy dolgozzon vele PointToPointChannelÉs WifiNetDevice - használható WifiChannel.

4.1.5 Topológiai asszisztensek

Valódi hálózatban olyan gazdagépeket találhat, amelyekhez hozzáadott (vagy beépített) hálózati kártya van. Az ns-3-ban azt mondanánk, hogy olyan csomópontokat fog látni, amelyekhez NetDevices csatolva van. Egy nagy szimulált hálózatban sok objektum közötti kapcsolatokat kell megszerveznie Csomópont, NetDevice и csatorna.

Mivel a NetDevices csomópontokhoz, a NetDevices a hivatkozásokhoz kapcsolódik, az IP-címek hozzárendelése stb. ns-3-ban gyakori feladat, ennek minél egyszerűbbé tétele érdekében úgynevezett topológia segítőket biztosítunk. Például egy NetDevice létrehozásához sok ns-3 kernelműveletet kell végrehajtania, hozzá kell adnia egy MAC-címet, telepítenie kell a hálózati eszközt a Node-ba, konfigurálnia kell a csomópont protokoll veremét, majd csatlakoztatnia kell a NetDevice-t a csatornához. Még több munkára lesz szükség ahhoz, hogy több eszközt többpontos kapcsolatokhoz csatlakoztasson, majd az egyes hálózatokat egy Internetworks hálózatba csatlakoztassa. Olyan topológia segédobjektumokat kínálunk, amelyek ezt a sok műveletet egy könnyen használható modellben egyesítik az Ön kényelme érdekében.

4.2 Első ns-3 szkript

Ha a fent javasolt módon telepítette a rendszert, akkor az ns-3 kiadás egy repos nevű könyvtárban lesz a saját könyvtárában. Menjen a könyvtárba engedje

Ha nem rendelkezik ilyen könyvtárral, az azt jelenti, hogy nem adta meg a kimeneti könyvtárat az ns-3 kiadási verziójának összeállításakor, építse meg így:
$ ./waf configure —build-profile=release —out=build/release,
$ ./waf build

ott a következőhöz hasonló könyvtárszerkezetet kell látnia:

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

Menjen a könyvtárba példák/oktatóanyag. Látnia kell egy ott található fájlt első.cc. Ez egy olyan szkript, amely egyszerű pont-pont kapcsolatot hoz létre két csomópont között, és egy csomagot továbbít a csomópontok között. Nézzük soronként ezt a szkriptet; ehhez nyissa meg a first.cc fájlt kedvenc szerkesztőjében.

4.2.1 Kazántábla kódja
A fájl első sora a szerkesztő mód sora emacs. Megmondja az emacsnak a formázási konvenciókat (kódolási stílust), amelyeket a forráskódunkban használunk.

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

Ez mindig elég vitatott kérdés, ezért egyenesen fel kell döntenünk a rekordot, hogy azonnal elhárítsuk az útból. Az ns-3 projekt, mint a legtöbb nagy projekt, olyan kódolási stílust alkalmazott, amelyhez az összes beküldött kódnak meg kell felelnie. Ha a kódját hozzá kívánja adni a projekthez, akkor végül meg kell felelnie az ns-3 kódolási szabványnak, a fájlban leírtak szerint. doc/codingstd.txt vagy a projekt weboldalán látható: https://www.nsnam.org/develop/contributing-code/coding-style/.

Javasoljuk, hogy szokja meg az ns-3 kód megjelenését, és alkalmazza ezt a szabványt, amikor a kódunkkal dolgozik. Ebbe némi zúgolódás után beleegyezett az egész fejlesztőcsapat és a közreműködők. A fenti emacs mód sor megkönnyíti a helyes formázást, ha az emacs szerkesztőt használja.

Az ns-3 szimulátor licenccel rendelkezik GNU General Public License. Minden ns-3 terjesztési fájlban látni fogja a megfelelő GNU jogi fejlécet. Gyakran láthat egy szerzői jogi értesítést az ns-3 projektben részt vevő intézmények egyikére vonatkozóan a GPL szövege és szerzője felett, az alábbiakban.

/* 
* 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 Beépülő modulok

Maga a kód egy sor inclusion utasítással kezdődik (tartalmaz).

#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"

Annak érdekében, hogy magas szintű parancsfájl-felhasználóink megbirkózzanak a rendszerben található nagyszámú fejlécfájllal, használatuk szerint nagy modulokba csoportosítjuk őket. Egyetlen fejlécfájlt biztosítunk, amely rekurzív módon betölti az adott modulban használt összes fejlécfájlt. Ahelyett, hogy pontosan azt a fejlécet kellene keresnie, amelyre szüksége van, és esetleg megkapja a függőségek megfelelő listáját, lehetőséget adunk egy fájlcsoport nagy részletességű letöltésére. Nem a leghatékonyabb módszer, de minden bizonnyal sokkal könnyebbé teszi a szkriptek írását.

Az ns-3 include fájlok mindegyike egy nevű könyvtárba kerül ns3 (build alkönyvtár), hogy elkerülje a fájlnév-ütközést a felépítési folyamat során. Fájl ns3/core-module.h megfelel az ns-3 modulnak, amelyet a könyvtárban talál src/core a telepített kiadásban. Ennek a könyvtárnak a listájában nagyszámú fejlécfájlt talál. Amikor elvégzi az összeszerelést, Waf nyilvános fejléc fájlokat helyez el az ns3 könyvtárban egy alkönyvtárban build/debug

Ha nem rendelkezik ilyen könyvtárral, az azt jelenti, hogy nem adta meg a kimeneti könyvtárat az ns-3 kiadási verziójának összeállításakor, építse meg így:
$ ./waf configure --build-profile=debug --out=build/debug
$ ./waf build
vagy
$ ./waf configure --build-profile=optimized --out=build/optimized
$ ./waf build

vagy építeni/optimalizálni, a konfigurációtól függően. Waf automatikusan létrehoz egy modult tartalmazó fájlt az összes nyilvános fejlécfájl betöltéséhez. Mivel természetesen vallásilag követi ezt az útmutatót, már megtette

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

a projekt konfigurálásához példákat és teszteket tartalmazó hibakeresési buildek futtatására. Te is megtetted

$ ./waf

a projekt összeállításához. Tehát most, ha belenézel a könyvtárba ../../build/debug/ns3, akkor ott találod többek között a fent látható négy modul fejléceit. Megnézheti ezeknek a fájloknak a tartalmát, és megállapíthatja, hogy a megfelelő modulok által használt összes nyilvános fájlt tartalmazzák.

4.2.3 ns3 névtér

Következő sor a szkriptben első.cc egy névtér deklaráció.

using namespace ns3;

Az ns-3 projekt egy ns3 nevű C++ névtérben valósul meg. Ez az összes ns-3-mal kapcsolatos deklarációt a globális névtéren kívüli hatókörbe csoportosítja, ami remélhetőleg segít a más kódokkal való integrációban. A C++ operátor használata bevezeti az ns-3 névteret az aktuális (globális) deklaratív régióba. Ez egy divatos módja annak, hogy elmondhassa, hogy e deklaráció után nem kell beírnia az ns3::scope engedély operátort az összes ns-3 kód elé, hogy használni tudja. Ha nem ismeri a névtereket, tekintse meg szinte bármelyik C++ tankönyvet, és hasonlítsa össze az ns3 névteret az std névtér és deklaráció segítségével using namespace std; a kimeneti operátorral végzett munka példáiban cout és patakok.

4.2.4 Naplózás

A szkript következő sora:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Ezt a nyilatkozatot kényelmes helyként fogjuk használni a dokumentációs rendszerünk megvitatásához Doxigen. Ha megnézi az ns-3 projekt weboldalát, a navigációs sávban talál egy Dokumentáció hivatkozást. Ha erre a linkre kattint, a dokumentációs oldalunkra kerül. Van egy „Legújabb kiadás” hivatkozás, amely az ns-3 legújabb stabil verziójának dokumentációjához vezet. Ha az "API dokumentáció" hivatkozást választja, akkor az ns-3 API dokumentációs oldalára kerül.

Az oldal bal oldalán a dokumentációs szerkezet grafikus ábrázolása található. Jó kiindulópont a Modules ns-3 "könyve" az ns-3 navigációs fában. Ha felfedi Modulok, látni fogja az ns-3 modulok dokumentációinak listáját. Ahogy fentebb tárgyaltuk, a modul fogalma itt közvetlenül kapcsolódik a fenti modulban szereplő fájlokhoz. Az ns-3 naplózási alrendszert a fejezet tárgyalja A naplózó modul használata, ezért ebben az oktatóanyagban később visszatérünk rá, de a fenti kijelentést megismerheti, ha megnézi a modult Magmajd kinyitja a könyvet Hibakeresési eszközökmajd válassza ki az oldalt Fakitermelés. Kattintson Fakitermelés.

Most át kell tekintenie a dokumentációt Doxigen modulhoz Fakitermelés. Az oldal tetején található makrók listájában megjelenik az NS_LOG_COMPONENT_DEFINE bejegyzés. Mielőtt rákattint a hivatkozásra, feltétlenül tekintse meg a regisztrációs modul „Részletes leírását”, hogy megértse, hogyan működik általánosságban. Ehhez görgessen lefelé, vagy válassza a "Továbbiak..." lehetőséget a diagram alatt.

Ha általános elképzelése van arról, hogy mi történik, folytassa és tekintse meg az adott NS_LOG_COMPONENT_DEFINE dokumentációját. Nem fogom itt lemásolni a dokumentációt, de összefoglalva, ez a sor deklarál egy regisztrációs komponenst FirstScriptPélda, amely lehetővé teszi az üzenetek konzolos naplózásának engedélyezését vagy letiltását egy névre hivatkozva.

4.2.5 Fő funkció

A szkript következő soraiban látni fogja,

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

Ez egyszerűen a program (script) fő funkciójának deklarációja. Mint minden C++ programnál, itt is meg kell határozni egy fő függvényt, ez kerül végrehajtásra először. Nincs itt semmi különös. Az ns-3 szkripted csak egy C++ program. A következő sor 1 nanoszekundumra állítja az időfelbontást, ami az alapértelmezett:

Time::SetResolution (Time::NS);

Az időfelbontás vagy egyszerűen felbontás a legkisebb használható időérték (két idő közötti legkisebb ábrázolható különbség). Pontosan egyszer módosíthatja a felbontást. Az ezt a rugalmasságot biztosító mechanizmus memóriát fogyaszt, így a felbontás explicit beállítása után felszabadítjuk a memóriát, megakadályozva a további frissítéseket. (Ha nem állítja be kifejezetten a felbontást, az alapértelmezés szerint egy nanoszekundum lesz, és a memória felszabadul, amikor a szimuláció elindul.)

A következő két parancsfájlsor az alkalmazásokba beépített két naplózási összetevő engedélyezésére szolgál EchoClient и EchoServer:

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

Ha elolvassa a Naplózás összetevő dokumentációját, látni fogja, hogy a naplózásnak/részletezettségnek több szintje is engedélyezhető az egyes összetevőknél. Ez a két kódsor lehetővé teszi a hibakeresési naplózást az INFO szintre az echo kliensek és szerverek számára. Ezen a szinten az alkalmazás üzeneteket nyomtat, miközben csomagokat küld és fogad a szimuláció során.

Most rátérünk a topológia létrehozására és a szimuláció futtatására. Topológia segítő objektumokat használunk, hogy ezt a munkát a lehető legegyszerűbbé tegyük.

4.2.6 Topológia asszisztensek használata

A szkriptünk következő két sora létrehozza a Node ns-3 objektumokat, amelyek a szimulációban szereplő számítógépeket képviselik.

NodeContainer nodes;
nodes.Create (2);

Mielőtt folytatnánk, keressük meg az osztály dokumentációját NodeContainer. Egy másik módja annak, hogy egy adott osztály dokumentációjához hozzáférjen a fülön keresztül Osztályok az oldalakon Doxigen. Ha már nyitva van a Doxygen, egyszerűen görgessen fel az oldal tetejére, és válassza az Osztályok lapot. Meg kell jelennie egy új lapkészletnek, amelyek közül az egyik az osztályok listája. Ezen a lapon láthatja az összes ns-3 osztály listáját. Görgessen le a lehetőséghez ns3::NodeContainer. Ha talál egy osztályt, válassza ki azt az osztály dokumentációjának megnyitásához.

Emlékszünk rá, hogy az egyik legfontosabb absztrakciónk a csomópont. Azt a számítógépet jelöli, amelyhez olyan dolgokat fogunk hozzáadni, mint a protokollveremek, alkalmazások és perifériás kártyák. Topológia asszisztens NodeContainer kényelmes módot biztosít bármilyen objektum létrehozására, kezelésére és elérésére Csomópont, amelyet a szimuláció futtatásához hozunk létre. A fenti első sor egyszerűen kijelenti NodeContainer, amit csomópontoknak nevezünk. A második sor meghívja a Create metódust a csomópont objektumon, és felkéri a tárolót, hogy hozzon létre két csomópontot. pontban leírtak szerint Doxigen, a tároló két objektum létrehozását kéri az ns-3 rendszertől Csomópont és belsőleg tárolja a mutatókat ezekre az objektumokra.

A szkriptben létrehozott csomópontok még nem csinálnak semmit. A topológia felépítésének következő lépése a csomópontok összekapcsolása a hálózattal. Az általunk támogatott hálózat legegyszerűbb formája a pont-pont kapcsolat két csomópont között. Most létrehozunk egy ilyen kapcsolatot.

PointToPointHelper

Pont-pont kapcsolatot hozunk létre egy ismerős mintával, egy topológia segítő objektum segítségével végezzük el a kapcsolathoz szükséges alacsony szintű munkát. Emlékezzünk vissza, hogy a két kulcsfontosságú absztrakciónk NetDevice и csatorna. A való világban ezek a kifejezések nagyjából megfelelnek a perifériás kártyáknak és a hálózati kábeleknek. Jellemzően ez a két dolog szorosan összefügg egymással, és senki sem számíthat arra, hogy megosztja például az eszközöket. Ethernet vezeték nélküli csatornán keresztül. Topológia segítőink követik ezt a szoros kapcsolatot, ezért ebben a forgatókönyvben egyetlen objektumot fog használni PointToPointHelper ns-3 objektumok beállításához és csatlakoztatásához PointToPointNetDevice и PointToPointChannel. A következő három sor a forgatókönyvben:

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

Első sor,

PointToPointHelper pointToPoint;

létrehozza egy objektum példányát a veremben PointToPointHelper. Legfelső szintű szemszögből a következő sor:

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

mondja a tárgynak PointToPointHelper használja az "5 Mbit/s" (öt megabit/s) értéket "Adatsebesség".

Konkrétabb szempontból a "DataRate" karakterlánc megfelel annak, amit attribútumnak nevezünk PointToPointNetDevice. Ha megnézed Doxigen az órára ns3::PointToPointNetDevice és a módszer dokumentációjában GetTypeId megtalálja az eszközhöz definiált attribútumok listáját. Köztük lesz a " attribútumAdatsebesség" A legtöbb felhasználó által látható ns-3 objektum hasonló attribútumlistákkal rendelkezik. Ezt a mechanizmust használjuk a szimuláció egyszerű beállítására, újrafordítás nélkül, amint azt a következő részben látni fogjuk.

Hasonló "AdatsebességA PointToPointNetDevice alkalmazásban megtalálja a PointToPointChannelhez társított „Késleltetés” attribútumot. Az utolsó sor

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

beszél PointToPointHelper használja a "2 ms" (két ezredmásodperc) értéket a későbbiekben létrehozott pont-pont kapcsolat terjedési késleltetéseként.

NetDeviceContainer

Jelenleg a forgatókönyvünkben van NodeContainer, amely két csomópontot tartalmaz. Nekünk van PointToPointHelper, amely objektumok létrehozására készült PointToPointNetDevices és összekapcsoljuk őket egy PointToPointChannel objektum segítségével. Ahogy a NodeContainer topológia segédobjektumot használtuk csomópontok létrehozására, úgy fogjuk megkérdezni PointToPointHelper készülékeink létrehozásával, konfigurálásával és telepítésével kapcsolatos munkákat elvégezni számunkra. Szükségünk van egy listára az összes létrehozott objektumról NetDevice, tehát használjuk NetDeviceContainer hogy ugyanúgy tároljuk őket, ahogy mi használtuk NodeContainer az általunk létrehozott csomópontok tárolására. A következő két kódsor,

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

fejezze be az eszköz és a csatorna beállítását. Az első sor deklarálja a fent említett eszköztárolót, a második pedig a fő munkát. Módszer felszerel tárgy PointToPointHelper vesz NodeContainer paraméterként. Belül NetDeviceContainer -ben található minden csomóponthoz NodeContainer létrejön (pont-pont kommunikációhoz pontosan kettőnek kell lennie) PointToPointNetDevice létrejön és az eszköztárolóba menti. PointToPointChannel létrejön, és kettő csatlakozik hozzá PointToPointNetDevices. Az objektumok létrehozása után az attribútumok tárolódnak PointToPointHelper, a megfelelő attribútumok inicializálására szolgál a létrehozott objektumokban.

Hívás kezdeményezése után pointToPoint.Telepítés (csomópontok) két csomópontunk lesz, mindegyikben egy pont-pont hálózati eszköz van telepítve, és egy pont-pont kapcsolat lesz közöttük. Mindkét eszközt úgy konfigurálják, hogy öt megabit/másodperc sebességgel, két ezredmásodperces átviteli késleltetéssel továbbítsák az adatokat a csatornán keresztül.

InternetStackHelper

Most már vannak konfigurálva a csomópontok és az eszközök, de a csomópontjainkra nincs telepítve protokollverem. A következő két kódsor gondoskodik erről.

InternetStackHelper stack;
stack.Install (nodes);

InternetStackHelper - egy topológia segítő az internetes veremekhez, hasonlóan a PointToPointHelperhez a pont-pont hálózati eszközökhöz. Módszer felszerel paraméterként veszi a NodeContainert. Amikor végrehajtja, telepíti az internetes verem (TCP, UDP, IP stb.) minden tároló csomóponton.

IPv4AddressHelper

Ezután az eszközeinket IP-címekkel kell társítanunk. Topológiai asszisztenst biztosítunk az IP-címek kiosztásának kezeléséhez. Az egyetlen API, amelyet a felhasználó láthat, az alap IP-cím és hálózati maszk beállítása, amelyet a tényleges címelosztás során használnak (ez a segítőn belül alacsonyabb szinten történik). A következő két kódsor a példaszkriptünkben első.cc,

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

deklarálja a címsegítő objektumot, és mondja meg neki, hogy el kell kezdenie az IP-címek kiosztását a 10.1.1.0 hálózatról, a 255.255.255.0 bitmaszk segítségével. Alapértelmezés szerint a kiosztott címek egytől kezdődnek, és monoton nőnek, így az ebből az alapból kiosztott első cím a 10.1.1.1, majd a 10.1.1.2 stb. lesz. A valóságban alacsony szinten az ns-3 rendszer megjegyzi az összes kiosztott IP-címet, és végzetes hibát generál, ha véletlenül olyan helyzetet hoz létre, amelyben ugyanaz a cím kétszer generálódik (mellesleg ezt a hibát nehéz hibakeresni).

A következő kódsor,

Ipv4InterfaceContainer interfaces = address.Assign (devices);

végrehajtja a tényleges cím hozzárendelést. Az ns-3-ban kapcsolatot létesítünk egy IP-cím és az objektumot használó eszköz között IPv4 interfész. Ahogy néha szükségünk van egy listára a hálózati eszközökről, amelyeket az asszisztens készített későbbi használatra, olykor szükségünk van az objektumok listájára IPv4 interfész. IPv4InterfaceContainer biztosítja ezt a funkciót.

Pont-pont hálózatot építettünk ki, telepített veremekkel és hozzárendelt IP-címekkel. Most minden csomópontban alkalmazásokra van szükségünk a forgalom generálásához.

4.2.7 Alkalmazás használata

Az ns-3 rendszer másik fő absztrakciója az Alkalmazás (Alkalmazás). Ebben a forgatókönyvben két alaposztály-specializációt használunk Alkalmazás ns-3 hívott UdpEchoServerApplication и UdpEchoClientApplication. A korábbi esetekhez hasonlóan az alapobjektumok konfigurálásához és kezeléséhez segédobjektumokat használunk. Itt használjuk UdpEchoServerHelper и UdpEchoClientHelper tárgyakat, amelyek megkönnyítik életünket.

UdpEchoServerHelper

A first.cc példaszkriptünk következő kódsorai egy UDP echo szerver alkalmazás konfigurálására szolgálnak az egyik korábban létrehozott csomóponton.

UdpEchoServerHelper echoServer (9);

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

A fenti részlet első kódsora létrehozza UdpEchoServerHelper. Szokás szerint ez nem maga az alkalmazás, hanem egy objektum, amely segít valódi alkalmazások létrehozásában. Egyik konvenciónk az, hogy a szükséges attribútumokat átadjuk a segítő objektum konstruktorának. Ebben az esetben a segítő nem tud semmi hasznosat tenni, hacsak nem kapja meg azt a portszámot, amelyen a kiszolgáló a csomagokat figyeli, ezt a számot a kliensnek is ismernie kell. Ebben az esetben a portszámot átadjuk a segítő konstruktornak. A kivitelező viszont egyszerűen ezt teszi SetAttribute az átadott értékkel. Később, ha kívánja, a SetAttribute segítségével beállíthat egy másik értéket a Port attribútumhoz.

Sok más segédtárgyhoz hasonlóan az objektum UdpEchoServerHelper módszere van felszerel. Ennek a módszernek a végrehajtása hatékonyan létrehoz egy alapvető visszhangszerver-alkalmazást, és összekapcsolja azt a gazdagéppel. Érdekes módon a módszer felszerel vesz NodeContainer paraméterként, mint a többi felszerel módszereket láttunk.

Az itt működő C++ implicit konverzió a metódus eredményét veszi fel node.Get(1) (ami egy intelligens mutatót ad vissza a csomópont objektumhoz - Ptr ), és használja a konstruktorban az anonim objektumhoz NodeContaineramelyet aztán átadnak a módszernek felszerel. Ha nem tudja C++ kódban meghatározni, hogy melyik metódusaláírás legyen lefordítva és végrehajtva, akkor nézze meg az implicit konverziókat.

Most ezt látjuk echoServer.Telepítés az alkalmazás telepítése előtt UdpEchoServerApplication -ban található NodeContaineramelyet a csomópontjaink kezelésére használunk, 1. indexű csomópont. Módszer felszerel egy olyan tárolót ad vissza, amely az összes alkalmazásra mutat mutatókat (jelen esetben egyet, mivel egy névtelen NodeContainer, amely egy csomópontot tartalmaz) a segítő által létrehozott.

Az alkalmazásoknak meg kell adniuk, hogy mikor kezdjék el a forgalom generálását "Rajt" és előfordulhat, hogy meg kell adni egy időpontot, amikor le kell állítani "állj meg". Mindkét lehetőséget biztosítjuk. Ezek az idők a metódusokkal vannak beállítva ApplicationContainer Rajt и megáll. Ezek a módszerek típusparamétereket fogadnak el Time. Ebben az esetben a C++ konverziók explicit sorozatát használjuk a C++ felvételéhez kétszeresére 1.0, és alakítsa át tns-3 Time objektummá, amely a Seconds objektumot használja a másodpercekké alakításhoz. Ne feledje, hogy a konverziós szabályokat a modell szerzője szabályozhatja, a C++-nak pedig megvannak a maga szabályai, így nem mindig számíthat arra, hogy a paraméterek a várt módon konvertálódnak. Két sor

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

hatására az echo szerver alkalmazás elindul (automatikusan bekapcsol) egy másodperccel a szimuláció indítása után, és leáll (kikapcsol) a szimuláció XNUMX másodperce után. Tekintettel arra, hogy deklaráltunk egy szimulációs eseményt (alkalmazásleállási esemény), amely tíz másodpercen belül lefut, legalább tíz másodperces hálózati működést szimulálunk.

UdpEchoClientHelper

Ügyfél alkalmazás visszhang szinte a szerverhez hasonló módon konfigurálva. Van egy alapobjektum UdpEchoClientApplication, amelyet kezelnek
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));;

Az echo klienshez azonban öt különböző attribútumot kell beállítanunk. Az első két attribútum a létrehozáskor van beállítva UdpEchoClientHelper. Olyan paramétereket adunk át, amelyeket (a segítőn belül) használunk az attribútumok beállításához "RemoteAddress" и "RemotePort" megállapodásunknak megfelelően átadni a szükséges paramétereket a segítő kivitelezőnek.

Emlékezzünk arra, hogy használtuk IPv4InterfaceContainer az eszközeinkhez rendelt IP-címek nyomon követésére. Az interfészkonténer nulla interfésze megfelel a csomóponttároló nullcsomópontjának IP-címének. Az interfésztároló első interfésze a csomóponttárolóban lévő első csomópont IP-címének felel meg. Tehát a kód első sorában (fent) létrehozunk egy segítőt, és megmondjuk neki, hogy a kliens távoli címe az a gazdagéphez rendelt IP-cím lesz, ahol a szerver található. Azt is mondjuk, hogy gondoskodnunk kell arról, hogy a csomagokat a kilences portra küldjék.

A "MaxPackets" attribútum megmondja az ügyfélnek, hogy a szimuláció során hány csomagot küldhetünk el. Az "Interval" attribútum megmondja az ügyfélnek, hogy mennyi ideig kell várnia a csomagok között, a "PacketSize" attribútum pedig azt, hogy mekkora legyen a csomag hasznos terhelése. Ezzel az attribútumkombinációval azt mondjuk a kliensnek, hogy küldjön egyetlen 1024 bájtos csomagot.

Az echo szerverhez hasonlóan az echo kliens attribútumait is beállítjuk Rajt и megáll, de itt a szerver bekapcsolása után egy másodperccel (a szimuláció kezdete után két másodperccel) indítjuk el a klienst.

4.2.8 Szimulátor

Ezen a ponton le kell futtatnunk a szimulációt. Ez a globális függvény segítségével történik Szimulátor::Fut.

Simulator::Run ();

Amikor korábban módszereknek neveztük,

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

ténylegesen az eseményeket 1,0 másodpercre, 2,0 másodpercre és két eseményt 10,0 másodpercre ütemeztük a szimulátorban. A hívás után Szimulátor::Fut, a rendszer elkezdi megtekinteni az ütemezett események listáját és végrehajtja azokat. Először 1,0 másodperc elteltével elindít egy eseményt, amely elindítja az echo szerver alkalmazást (ez az esemény sok más eseményt is ütemezhet). Ezután egy t=2,0 másodpercre ütemezett eseményt indít el, amely elindítja az echo kliens alkalmazást. Ez az esemény is sok további eseményt tervezhet. A start esemény implementáció az echo kliensben a szimuláció adatátviteli fázisát egy csomag szerverre küldésével kezdi meg.

A csomag kiszolgálóra való küldése eseményláncot indít el, amely automatikusan ütemezésre kerül a színfalak mögött, és amely megvalósítja az echo-csomag küldésének mechanikáját a szkriptben beállított időzítési paraméterek szerint.

Ennek eredményeként, mivel csak egy csomagot küldünk (ne feledje, az attribútum MaxPackets értékre van állítva), az egyetlen kliens ping által kezdeményezett eseménylánc befejeződik, és a szimuláció készenléti módba kerül. Ha ez megtörténik, a fennmaradó ütemezett események lesznek az események megáll szerverhez és klienshez. Amikor ezek az események végrehajtásra kerülnek, nem marad semmilyen esemény további feldolgozásra és Szimulátor::Fut visszaadja az irányítást. A szimuláció befejeződött.

Már csak az marad, hogy kitakaríts magad után. Ez a globális függvény meghívásával történik Szimulátor::Elpusztítás. Mert meghívásra kerültek a segítő függvények (vagy alacsony szintű ns-3 kód), amelyek úgy vannak megszervezve, hogy a szimulátorba horgokat helyeztek be, hogy megsemmisítsék az összes létrehozott objektumot. Nem kellett saját maga követnie ezeket az objektumokat – mindössze hívnia kellett Szimulátor::Elpusztítás és menj ki. Az ns-3 rendszer elvégzi ezt a kemény munkát Ön helyett. Az első ns-3 szkriptünk, a first.cc fennmaradó sorai pontosan ezt teszik:

Simulator::Destroy ();
return 0;
}

Mikor áll le a szimulátor?

Az ns-3 egy diszkrét esemény (DE) szimulátor. Egy ilyen szimulátorban minden esemény hozzá van rendelve a végrehajtási idejéhez, és a szimuláció az események feldolgozásával folytatódik a szimuláció előrehaladtával bekövetkező sorrendben. Az események előidézhetik a jövőbeli események ütemezését (például egy időzítő átütemezheti magát, hogy a következő intervallumban befejezze a számlálást).

A kezdeti eseményeket általában az entitás kezdeményezi, például az IPv6 ütemezi a szolgáltatások felfedezését a hálózaton, a szomszéd kéréseket stb. Az alkalmazás ütemezi az első csomagküldési eseményt és így tovább. Egy esemény feldolgozása során nulla, egy vagy több eseményt generálhat. A szimuláció előrehaladtával események történnek, vagy véget érnek, vagy újakat hoznak létre. A szimuláció automatikusan leáll, ha az eseménysor üres vagy különleges eseményt észlel megáll. Esemény megáll függvény által generált Szimulátor::Stop (leállási idő).

Van egy tipikus eset, amikor a Simulator::Stop feltétlenül szükséges a szimuláció leállításához: amikor önfenntartó események vannak. Az önfenntartó (vagy ismétlődő) események olyan események, amelyeket mindig átütemeznek. Ennek következtében az eseménysort mindig nem üresen tartják. Számos protokoll és modul tartalmaz ismétlődő eseményeket, például:

• FlowMonitor – időszakos ellenőrzés az elveszett csomagok tekintetében;

• RIPng – az útválasztási tábla frissítéseinek időszakos sugárzása;

• stb.

Ilyen esetekben Szimulátor::Stop szükséges a szimuláció megfelelő leállításához. Ezen túlmenően, amikor az ns-3 emulációs módban van, a RealtimeSimulator szinkronizálja a szimulációs órát a gép órájával, és Szimulátor::Stop szükséges a folyamat leállításához.

A tankönyvben szereplő szimulációs programok közül sok nem hív Szimulátor::Stop kifejezetten, mivel automatikusan véget érnek, amikor a sorba állított események kimerülnek. Ezek a programok azonban elfogadják a Simulator::Stop hívást is. Például a következő kiegészítő utasítás az első példaprogramban explicit megállást ütemez 11 másodpercre:

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

A fentiek valójában nem változtatják meg ennek a programnak a viselkedését, mivel ez a szimuláció természetesen 10 másodperc után véget ér. De ha a fenti utasításban a leállítási időt 11 másodpercről 1 másodpercre módosítaná, észrevenné, hogy a szimuláció leáll, mielőtt bármilyen kimenet elérné a képernyőt (mivel a kimenet körülbelül 2 másodperces szimulációs idő után következik be).

Fontos, hogy a Simulator::Stop meghívása előtt hívja meg a Simulator::Run; ellenkező esetben előfordulhat, hogy a Simulator::Run soha nem adja vissza a vezérlést a főprogramhoz a leállítás végrehajtásához!

4.2.9 A forgatókönyv elkészítése

Az egyszerű szkriptek létrehozását triviálissá tettük. Mindössze annyit kell tennie, hogy a szkriptet be kell helyeznie a scratch könyvtárba, és az automatikusan létrejön, ha futtatja Waf. Próbáljuk meg. Menjen vissza a legfelső szintű könyvtárba, és másolja examples/tutorial/first.cc a katalógusba kaparni

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

Most készítse el az első mintaszkriptet a segítségével WAF:

$ ./waf

Üzeneteket kell látnia, amelyek jelzik, hogy az első példa sikeresen létrejött.

Waf: Entering directory `/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: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (2.357s)

Most már futtathatja a példát (vegye figyelembe, hogy ha a programot a scratch könyvtárba építi fel, akkor futnia kell kaparni):

$ ./waf --run scratch/myfirst

Hasonló kimenetet kell látnia:

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) Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2

Itt láthatja, hogy a build rendszer ellenőrzi, hogy a fájl elkészült-e, majd futtatja. Az echo kliens komponens bejegyzése azt jelzi, hogy egyetlen 1024 bájtos csomagot küldött a 10.1.1.2 echo szervernek. Ön is látja a naplózási összetevőt az echo-kiszolgálón, amely azt mondja, hogy 1024 bájtot kapott a 10.1.1.1-től. Az echo szerver csendben visszajátssza a csomagot, és az echo kliens naplójában láthatja, hogy visszakapta a csomagját a szervertől.

4.3 ns-3 Forráskód

Most, hogy az ns-3 segédprogramok egy részét használta, megtekintheti azokat a forráskódokat, amelyek ezt a funkciót megvalósítják. A legújabb kód megtekinthető webszerverünkön az alábbi linken: https://gitlab.com/nsnam/ns-3-dev.git. Itt láthatja az ns-3 fejlesztési fájunk Mercurial összefoglaló oldalát. Az oldal tetején számos linket láthat,

summary | shortlog | changelog | graph | tags | files

Menjen előre, és válassza ki a fájlok hivatkozását. Így fog kinézni legtöbb adattárunk legfelső szintje:

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

Példa szkriptjeink a könyvtárban találhatók példák. Ha a példákra kattint, megjelenik az alkönyvtárak listája. Az egyik fájl az alkönyvtárban bemutató - first.cc. Ha rákattint első.cc látni fogja az imént tanult kódot.

A forráskód főleg a könyvtárban található src. A forráskódot a könyvtár nevére vagy a könyvtárnévtől jobbra található fájlok hivatkozásra kattintva tekintheti meg. Ha az src könyvtárra kattint, megjelenik az src alkönyvtárak listája. Ha ezután rákattint az alapvető alkönyvtárra, megjelenik a fájlok listája. Az első fájl, amelyet látni fog (az útmutató írásakor) az megszakít.h. Ha rákattint a linkre megszakít.h, akkor a rendszer elküldi a forrásfájlhoz megszakít.h, amely hasznos makrókat tartalmaz a szkriptekből való kilépéshez, ha abnormális körülményeket észlel. A fejezetben használt segítők forráskódja a könyvtárban található src/Applications/helper. Nyugodtan nézelődhet a címtárfában, hogy kitalálja, hol van, és megértse az ns-3 programok stílusát.

Forrás: will.com

ns-3 hálózati szimulátor oktatóanyag. 4. fejezet