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

1,2. fejezet
3. fejezet
4. fejezet

5 Beállítások
5.1 A naplózó modul használata
5.1.1 Naplózás áttekintése
5.1.2 Naplózás engedélyezése
5.1.3 Naplózás hozzáadása a kódhoz
5.2 Parancssori argumentumok használata
5.2.1 Az alapértelmezett attribútumértékek felülbírálása
5.2.2 Saját parancsok rögzítése
5.3 A nyomkövető rendszer használata
5.3.1 ASCII nyomkövetés
ASCII nyomok elemzése
5.3.2 PCAP nyomkövetés

Fejezet 5

beállítás

5.1 A naplózó modul használata

Már röviden megnéztük az ns-3 naplózó modult a szkript megtekintésével első.cc. Ebben a fejezetben közelebbről megvizsgáljuk a naplózási alrendszer lehetséges felhasználásait.

5.1.1 Naplózás áttekintése

Sok nagy rendszer támogat valamilyen üzenetnaplózási lehetőséget, és ez alól az ns-3 sem kivétel. Egyes esetekben csak a hibaüzenetek íródnak a "kezelői konzolra" (amely Unix alapú rendszereken általában stderr). Más rendszereken figyelmeztető üzenetek és részletesebb információk is megjelenhetnek. Egyes esetekben naplózó eszközöket használnak olyan hibakeresési üzenetek kiadására, amelyek gyorsan elhomályosíthatják a kimenetet.

Az ns-3-ban használt subHRD azt feltételezi, hogy az információtartalom ezen szintjei mindegyike hasznos, és szelektív, rétegzett megközelítést biztosítunk az üzenetnaplózáshoz. A naplózás teljesen letiltható, komponensenkénti alapon vagy globálisan engedélyezhető. Erre a célra az információtartalom állítható szintjeit használják. Az ns-3 naplózó modul viszonylag egyszerű módot kínál hasznos információk beszerzésére a szimulációból.

Meg kell értenie, hogy biztosítunk egy általános célú mechanizmust – a nyomkövetést – az adatok kinyerésére a modellekből, amelyek a szimulációk előnyben részesített kimenetei lehetnek (a nyomkövetési rendszerünkről további információkért lásd az oktatóanyag 5.3 szakaszát). A naplózás legyen az előnyben részesített módszer a hibakeresési információk, figyelmeztetések, hibaüzenetek megszerzésére, illetve a szkriptekből vagy modellekből származó üzenetek gyors kimenetére.

Jelenleg a rendszer a naplóüzenetek hét szintjét (típusát) határozza meg az információtartalom növekvő sorrendjében.

• LOG_ERROR - naplózási hibaüzenetek (kapcsolódó makró: NS_LOG_ERROR);
• LOG_WARN - Figyelmeztető üzenetek naplózása (kapcsolódó makró: NS_LOG_WARN);
• LOG_DEBUG - A viszonylag ritka speciális hibakeresési üzenetek naplózása (kapcsolódó makró: NS_LOG_DEBUG);
• LOG_INFO - a program előrehaladásáról szóló információs üzenetek regisztrációja (kapcsolódó makró: NS_LOG_INFO);
• LOG_FUNCTION – Az egyes meghívott függvényeket leíró üzeneteket naplózza (két kapcsolódó makró: NS_LOG_FUNCTION, a tagfüggvényekhez és NS_LOG_FUNCTION_NOARGS, statikus függvényekhez);
• LOG_LOGIC - a függvényen belüli logikai folyamatot leíró üzenetek naplózása (kapcsolódó makró: NS_LOG_LOGIC);
• LOG_ALL – A fent említett mindent naplóz (nincs társított makró).
  Minden típushoz (LOG_TYPE) tartozik egy LOG_LEVEL_TYPE is, amely, ha használja, lehetővé teszi az összes felette lévő szint naplózását a saját szintjén kívül. (As a consequence, LOG_ERROR and LOG_LEVEL_ERROR, and LOG_ALL and LOG_LEVEL_ALL are functionally equivalent.) For example, enabling LOG_INFO will only allow messages provided by the NS_LOG_INFO macro, while enabling LOG_LEVEL_INFO will also include messages provided by the macros NS_LOG_DEBUG, NS_LOG_WARN and NS_LOG_ERROR.

Biztosítunk egy feltétel nélküli naplózási makrót is, amely mindig megjelenik, függetlenül a naplózási szinttől vagy a kiválasztási összetevőtől.

• NS_LOG_UNCOND - A társított üzenet feltétel nélküli naplózása (nincs társított naplózási szint).

Minden szint egyedileg vagy összesítve is lekérdezhető. A naplózás az NS_LOG sh környezeti változóval vagy egy rendszerfüggvényhívás naplózásával konfigurálható. Amint korábban bemutattuk, a naplózási rendszer rendelkezik Doxygen dokumentációval, és most itt az ideje annak áttekintésére, ha még nem tette meg.

Most, hogy nagyon részletesen elolvasta a dokumentációt, használjuk fel ezt a tudást, hogy érdekes információkat nyerjünk a példaszkriptből scratch/myfirst.ccamelyeket már összeállítottál.

5.1.2 Naplózás engedélyezése

Használjuk az NS_LOG környezeti változót további naplók futtatásához, de először, hogy tájékozódjon, futtassa az utolsó szkriptet, ahogy korábban,

$ ./waf --run scratch/myfirst

Látnia kell az első ns-3 példaprogram ismerős kimenetét

$ Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' 'build'
finished successfully (0.413s)
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2

Kiderült, hogy a fent látható "elküldött" és "fogadott" üzenetek valójában naplózott üzenetek UdpEchoClientApplication и UdpEchoServerApplication. Például megkérhetjük az ügyfélalkalmazást, hogy nyomtasson ki további információkat, ha beállítja a naplózási szintjét az NS_LOG környezeti változón keresztül.

Mostantól azt fogom feltételezni, hogy egy sh-szerű shellt használsz, amely a "VARIABLE=value" szintaxist használja. Ha csh-szerű parancsértelmezőt használsz, akkor a példáimat át kell konvertálnod a parancsértelmezők által megkövetelt "setenv változó érték" szintaxisára.

Jelenleg az UDP echo kliens alkalmazás a következő kódsorra reagál scratch/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Engedélyezi a LOG_LEVEL_INFO naplózási szintet. Amikor átadunk egy naplózási szint jelzőt, akkor ténylegesen engedélyezzük azt a szintet és az összes alacsonyabb szintet. Ebben az esetben engedélyeztük az NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN és NS_LOG_ERROR funkciókat. Növelhetjük a naplózási szintet, és több információhoz juthatunk script változtatások és újrafordítás nélkül, ha az NS_LOG környezeti változót az alábbiak szerint állítjuk be:

$ export NS_LOG=UdpEchoClientApplication=level_all

Tehát az NS_LOG sh shell változót a következő értékre állítjuk:

UdpEchoClientApplication=level_all

A hozzárendelés bal oldalán a konfigurálni kívánt naplózott komponens neve, a jobb oldalon pedig az a zászló, amelyet alkalmazni szeretnénk. Ebben az esetben engedélyezni fogjuk a hibakeresés minden szintjét az alkalmazásban. Ha így futtatja a szkriptet az NS_LOG paraméterrel, az ns-3 naplózó rendszer elfogadja a változtatásokat, és a következő 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.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Received 1024 bytes from 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Az alkalmazás által biztosított további hibakeresési információk az NS_LOG_FUNCTION szinten vannak. Megjeleníti a függvényhívás minden példányát a szkript végrehajtása során. Általános szabály, hogy a metódusfüggvényekben előnyösebb (minimum)NS_LOG_FUNCTION (this)... Használat NS_LOG_FUNCTION_NOARGS ()
csak statikus függvényekben. Azonban vegye figyelembe, hogy az ns-3 rendszernek nem kell támogatnia semmilyen naplózási funkciót. A rögzítésről szóló döntést az egyes modellfejlesztőkre bízzuk. Echo alkalmazások esetén nagy mennyiségű naplózási kimenet áll rendelkezésre.

Most megtekintheti az alkalmazás által végrehajtott függvényhívások naplóját. Ha alaposan megnézi, észrevesz egy kettőspontot a vonal között UdpEchoClientApplication és a metódus neve, ahol várhatóan megjelenik a C++ hatókör operátora (: :). Ez szándékos.

Ez valójában nem az osztály neve, hanem a naplózási összetevő neve. Ha egyezés van egy forrásfájl és egy osztály között, az általában az osztály neve, de észre kell venni, hogy valójában ez nem az osztály neve, és kettős kettőspont helyett egyetlen kettőspont van. Ez egy módja annak, hogy viszonylag finoman elválaszthassa a naplózó komponens nevét az osztály nevétől.

Bizonyos esetekben azonban nehéz lehet meghatározni, hogy valójában melyik módszer hozza létre a naplóüzenetet. Ha megnézi a fenti szöveget, felteheti a kérdést, hogy hol van a sor "Received 1024 bytes from 10.1.1.2" Ezt a problémát a szint beállításával oldhatja meg prefix_func az NS_LOG környezeti változóhoz. Próbáld ki a következőket:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Vegye figyelembe, hogy az idézőjelek azért szükségesek, mert a függőleges sáv, amelyet az VAGY művelet ábrázolására használunk, szintén Unix csőcsatlakozó. Ha most futtatja a szkriptet, látni fogja, hogy a naplózó rendszer biztosítja, hogy egy adott naplóban minden üzenet előtagja legyen az összetevő nevével.

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

Most már láthatja, hogy az UDP echo kliens alkalmazásból érkező összes üzenet ilyenként van azonosítva. Üzenet "Received 1024 bytes from 10.1.1.2" most egyértelműen az echo kliens alkalmazásból származik. A fennmaradó üzenetnek az UDP echo szerver alkalmazástól kell származnia. Ezt az összetevőt úgy tudjuk engedélyezni, hogy az NS_LOG környezeti változóban megadjuk az összetevők kettősponttal elválasztott listáját.

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

Figyelmeztetés: A fenti példaszövegben el kell távolítani az újsor karaktert a kettőspont (:) után, ez a dokumentum formázására szolgál. Most, ha futtatja a szkriptet, látni fogja az összes naplóüzenetet a kliens és a kiszolgáló echo alkalmazásokból. Láthatja, hogy ez nagyon hasznos lehet hibakereséskor.

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

Néha hasznos az is, ha láthatjuk a szimulációs időt, amikor a naplóüzenet létrejött. Ezt megteheti a VAGY bit hozzáadásával előtag_idő:

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

Ismét el kell távolítania a fenti újsor karaktert. Ha most futtatja a szkriptet, a következő 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)
0s UdpEchoServerApplication:UdpEchoServer()
0s UdpEchoClientApplication:UdpEchoClient()
0s UdpEchoClientApplication:SetDataSize(1024)
1s UdpEchoServerApplication:StartApplication()
2s UdpEchoClientApplication:StartApplication()
2s UdpEchoClientApplication:ScheduleTransmit()
2s UdpEchoClientApplication:Send()
2s UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Felhívjuk figyelmét, hogy a kivitelező a UdpEchoServer szimuláció során hívták 0 másodpercig. Ez valójában a szimuláció megkezdése előtt történik, de az idő nulla másodpercben jelenik meg. Ugyanez igaz a konstruktor üzenetére is UdpEchoClient.

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

Emlékezzünk vissza, hogy a forgatókönyv scratch/first.cc egy másodperccel a szimuláció kezdete előtt elindította az echo szerver alkalmazást. Most láthatja, hogy a módszer StartApplication a szervert valójában az első másodpercben hívják meg. Azt is észreveheti, hogy az echo kliens a szimuláció második másodpercében elindul, ahogy a szkriptben kértük.

Most már hívás közben követheti a szimuláció folyamatát ÜtemezésTransmit a HandleRead visszahívást hívó kliensben. Küldés az echo szerver alkalmazásban. Vegye figyelembe, hogy a csomag pont-pont kapcsolaton keresztüli elküldésének ideje 3,69 ezredmásodperc. Látható, hogy az echo-kiszolgáló naplóz egy üzenetet, hogy válaszolt a csomagra, majd egy csatornakésleltetés után azt látja, hogy az echo-kliens a HandleRead metódusában kapja meg az echo-csomagot.

Ebben a szimulációban sok minden történik anélkül, hogy észrevennéd. De a teljes folyamatot nagyon egyszerűen nyomon követheti, ha engedélyezi a rendszer összes naplózási összetevőjét. Próbálja meg az NS_LOG változót a következő értékre állítani,

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

A fenti csillag a naplózási összetevő helyettesítő karaktere. Ez magában foglalja a szimulációban használt összes komponens összes bejegyzését. A kimenetet itt nem reprodukálom (az írás idején 1265 sornyi kimenetet produkál egyetlen echo-csomaghoz), de átirányíthatja ezt az információt egy fájlba, és megtekintheti kedvenc szerkesztőjében.

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

Én személy szerint a naplózásnak ezt a rendkívül bőbeszédű változatát használom, ha problémám van, és fogalmam sincs, hol rontottak el a dolgok. Könnyen követhetem a kód végrehajtását anélkül, hogy töréspontokat állítanék be, és nem lépnék át a kódon a hibakeresőben. Csak szerkeszthetem a kimenetet a kedvenc szerkesztőmben, és megkereshetem, mire számítok, és látom, hogy valami történik, amire nem számítottam. Miután általános elképzelésem van arról, hogy mi a baj, beugrok a hibakeresőbe, hogy elmélyüljek a problémában. Ez a fajta kimenet különösen hasznos lehet, ha a szkript valami teljesen váratlan dolgot hajt végre. Ha csak a hibakeresőt használja, előfordulhat, hogy teljesen kihagy egy csavart. A regisztráció észrevehetővé teszi az ilyen fordulatokat.

5.1.3 Naplózás hozzáadása a kódhoz

Új bejegyzéseket adhat a szimulációihoz, ha több makróból hívja meg a naplóösszetevőt. Csináljuk forgatókönyvben myfirst.cc, amely a „clean” könyvtárban található. Emlékezzünk vissza, hogy ebben a forgatókönyvben definiáltunk egy naplózási összetevőt:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Tudja, hogy az NS_LOG környezeti változó különböző szinteken történő beállításával engedélyezheti az összes üzenet naplózását ebből az összetevőből. Menjünk tovább, és adjunk hozzá néhány bejegyzést a szkripthez. Az információszintű üzenetek naplóhoz való hozzáadásához használt makró az NS_LOG_INFO. Adjunk hozzá egy üzenetet (közvetlenül a csomópontok létrehozásának megkezdése előtt), amely közli, hogy a szkript a „Topológia létrehozása” fázisban van. Ez a következő kódrészletben történik,
Nyissa meg scratch/myfirst.cc kedvenc szerkesztőjében, és adja hozzá a sort,
NS_LOG_INFO ("Creating Topology");
közvetlenül a sorok előtt,

NodeContainer nodes;
nodes.Create (2);

Most fordítsa le a szkriptet a segítségével WAF, és törölje az NS_LOG változót a korábban engedélyezett naplózási adatfolyam letiltásához:

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

Nem fogja látni az új üzenetet, mert a kapcsolódó naplózási összetevő (FirstScriptExample) nincs engedélyezve. Az üzenet megtekintéséhez engedélyeznie kell a naplózási összetevőt FirstScriptPélda NS_LOG_INFO-nál nem alacsonyabb szinttel. Ha csak ezt a konkrét naplózási szintet szeretné látni, engedélyezheti a következőképpen:

$ export NS_LOG=FirstScriptExample=info

Ha most futtatja a szkriptet, új üzenetet fog látni: „Topológia létrehozása”.

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.404s)
Creating Topology
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2

5.2 Parancssori argumentumok használata

5.2.1 Az alapértelmezett attribútumértékek felülbírálása

Az ns-3 szkriptek viselkedésének szerkesztés vagy felépítés nélküli megváltoztatásának másik módja a parancssori argumentumok használata. Mechanizmust biztosítunk a parancssori argumentumok elemzésére, valamint az eredmények alapján a helyi és globális változók automatikus beállítására.

A parancssori argumentumrendszer használatának első lépése egy parancssori elemző deklarálása. Ez meglehetősen egyszerű (a fő programban), mint a következő kódban,

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

Ez az egyszerű kétsoros részlet valójában önmagában is nagyon hasznos. Megnyitja az ajtót az ns-3 globális változó- és attribútumrendszerhez. Adjunk hozzá két sor kódot a fő szkriptfüggvény elejéhez scratch/myfirst.cc. Továbbhaladva lefordítjuk a szkriptet és lefuttatjuk, indításkor segítségkérést teszünk az alábbiak szerint:

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

Ez a parancs megkérdezi Waf script futtatása scratch/myfirst és adj át neki egy parancssori argumentumot — Nyomtatási súgó. Az idézőjelek szükségesek annak jelzésére, hogy az argumentum melyik programra vonatkozik. A parancssori elemző észleli az argumentumot — Nyomtatási súgó és megjeleníti a választ,

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.413s)
TcpL4Protocol:TcpStateMachine()
CommandLine:HandleArgument(): Handle arg name=PrintHelp value=
--PrintHelp: Print this help message.
--PrintGroups: Print the list of groups.
--PrintTypeIds: Print all TypeIds.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintGlobals: Print the list of globals.

Most nézzük a lehetőséget —PrintAttributes. Az ns-3 attribútumrendszert már említettük a first.cc szkript tanulmányozásakor. A következő kódsorokat láttuk,

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

és azt mondták Adatsebesség valójában egy tulajdonság PointToPointNetDevice. Használjuk a parancssori argumentumelemzőt az attribútumok megtekintéséhez PointToPointNetDevice. A súgólista tartalmazza, hogy mit kell megadnunk TypeId. Ez annak az osztálynak a neve, amelyhez az érdeklődésre számot tartó attribútumok tartoznak. A mi esetünkben az lesz ns3::PointToPointNetDevice. Menjünk előre, lépjünk be,

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

A rendszer kinyomtatja ennek a hálózati eszköztípusnak az összes attribútumait. Látni fogja, hogy a listában szereplő attribútumok között

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

Ez az alapértelmezett érték, amelyet a rendszer az objektum létrehozásakor fog használni PointToPointNetDevice. Ezt az alapértelmezett értéket a paraméter használatával felülírjuk Attribútum в PointToPointHelper magasabb. Használjuk a pont-pont eszközök és csatornák alapértelmezett értékeit. Ehhez töröljük a hívásokat SetDeviceAttribute и SetChannelAttribute A myfirst.cc, amely egy tiszta könyvtárban található.

A szkriptnek most egyszerűen deklarálnia kell PointToPointHelper és ne végezzen semmilyen telepítési műveletet az alábbi példában látható módon,

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

Lépjen tovább, és hozzon létre egy új szkriptet Waf (./waff).

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Ha futtatja a szkriptet, a következő 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.405s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.25732s Received 1024 bytes from 10.1.1.1
2.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Emlékezzünk vissza, hogy amikor legutóbb megnéztük a szimulációs időt, abban a pillanatban, amikor a csomagot az echo szerver megkapta, az 2,00369 másodperc volt.

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

Most 2.25732 másodperc alatt kapja meg a csomagot. Ennek az az oka, hogy egyszerűen visszaállítottuk a PointToPointNetDevice adatsebességét öt megabit/másodpercről az alapértelmezett értékre, ami 32768 bit/s. Ha a parancssor használatával helyettesítenénk egy új DataRate-et, ismét felgyorsíthatnánk a szimulációt. Ezt a következőképpen fogjuk megtenni, a súgóelem által feltételezett képlet szerint:

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

Ezzel visszaállítja a DataRate attribútumot az alapértelmezett, öt megabit/másodperc értékre. Meglep az eredmény? Kiderült, hogy a szkript eredeti viselkedésének visszaállításához a csatorna késleltetését is be kell állítanunk a fénysebességhez. Megkérhetjük a parancssori rendszert a csatornaattribútumok kinyomtatására, akárcsak a hálózati eszköznél:

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

Azt tapasztaljuk, hogy a csatorna késleltetés attribútuma a következőképpen van beállítva:

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

Ezután a parancssori rendszeren keresztül beállíthatjuk mindkét alapértelmezett értéket.

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

ebben az esetben visszaállítjuk azt az időt, amikor kifejezetten beállítottuk a DataRate-et és a Delay-t a szkriptben:

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.00369s Received 1024 bytes from 10.1.1.1
2.00369s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Ne feledje, hogy a csomagot 2,00369 másodperc múlva újra megkapja a szerver. Valójában a szkriptben használt attribútumok bármelyikét beállíthatjuk így. Különösen a MaxPackets attribútumokat állíthatjuk be nem egy értékekre UdpEchoClient.

Hogyan használnád? Megpróbál. Ne feledje, hogy megjegyzésbe kell írnia azt a helyet, ahol felülírjuk az alapértelmezett attribútumértéket és kifejezetten beállítjuk MaxPackets a forgatókönyvben. Ezután újra kell építeni a szkriptet. A parancssor segítségével szintaktikai segítséget is kérhet egy új alapértelmezett attribútumérték beállításához. Ha ezt megértette, szabályozhatja a parancssorban megjelenő csomagok számát. Mivel szorgalmas emberek vagyunk, a parancssorunk valahogy így néz ki:

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

A természetes kérdés, amely ezen a ponton felmerül, az, hogyan lehet tudni mindezen tulajdonságok létezéséről. A parancssori rendszernek van egy súgó funkciója is. Ha a parancssorból kérünk segítséget, a következőket kell látnunk:

$ ./waf --run "scratch/myfirst --PrintHelp"
myfirst [Program Arguments] [General Arguments]
General Arguments:
--PrintGlobals: Print the list of globals.
--PrintGroups: Print the list of groups.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintTypeIds: Print all TypeIds.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintHelp: Print this help message.

Ha a "PrintGroups" argumentumot választja, látnia kell az összes regisztrált csoport listáját TypeId. A csoportnevek összhangban vannak a forráskönyvtár moduljainak nevével (bár nagybetűvel). Az összes információ egyszerre történő kinyomtatása túl terjedelmes lenne, ezért egy további szűrő áll rendelkezésre az információk csoportonkénti nyomtatásához. Tehát ismét a pont-pont modulra összpontosítva:

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

Itt találhat elérhető TypeId neveket attribútumkeresésekhez, például in
--PrintAttributes = ns3 :: PointToPointChannelahogy fentebb látható.

Az attribútumok megismerésének másik módja a Doxygen ns-3. Van egy oldal, amely felsorolja a szimulátorban regisztrált összes attribútumot.

5.2.2 Saját parancsok rögzítése

Saját horgokat is hozzáadhat a parancssori rendszeren keresztül. Ez egyszerűen a parancssori értelmező módszerrel történik Hozzáadott érték.
Ezzel a funkcióval határozzuk meg a megjelenítendő csomagok számát egészen más módon. Adjunk hozzá egy helyi változót nPackets függvénybe fő-. Egyre állítjuk, hogy megfeleljen korábbi alapértelmezett viselkedésünknek. Ahhoz, hogy a parancssori értelmező módosítsa ezt az értéket, rögzítenünk kell ezt az értéket az értelmezőben. Ezt hívás hozzáadásával tesszük Hozzáadott érték. Menj és változtasd meg a forgatókönyvet scratch/myfirst.cc tehát a következő kóddal kezdjük,

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

Görgessen le a szkriptben arra a pontra, ahol beállítjuk a MaxPackets attribútumot, és módosítsa úgy, hogy az nPackets változó legyen az 1 konstans helyett, amint az alább látható.

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

Ha most futtatja a szkriptet, és megadja a -PrintHelp argumentumot, látnia kell az új felhasználói argumentumot. a súgó kijelzőjén. Belép,

$ ./waf --run "scratch/myfirst --PrintHelp"
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.403s)
--PrintHelp: Print this help message.
--PrintGroups: Print the list of groups.
--PrintTypeIds: Print all TypeIds.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintGlobals: Print the list of globals.
User Arguments:
--nPackets: Number of packets to echo

Ha módosítani szeretné a továbbított csomagok számát, ezt a - -nPackets parancssori argumentum megadásával teheti meg.

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

Most látnia kell

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.25732s Received 1024 bytes from 10.1.1.1
2.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
Sent 1024 bytes to 10.1.1.2
3.25732s Received 1024 bytes from 10.1.1.1
3.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Most két csomagot küldött. Elég egyszerű, nem?
Láthatja, hogy ns-3 felhasználóként használhatja a parancssori argumentumrendszert a globális értékek és attribútumok manipulálására. Ha Ön a modell szerzője, új attribútumokat adhat hozzá az objektumokhoz, és ezek automatikusan elérhetők lesznek a felhasználók számára a parancssori rendszeren keresztül történő konfiguráláshoz. Ha Ön szkript szerző, új változókat adhat hozzá a szkriptekhez, és zökkenőmentesen csatlakoztathatja őket a parancssori rendszerhez.

5.3 A nyomkövető rendszer használata

A modellezés lényege az, hogy kimenetet generáljon további tanulmányozáshoz, és ennek fő mechanizmusa az ns-3 nyomkövetési rendszer. Mivel az ns-3 egy C++ program, a C++ program kimenetének szabványos eszközei használhatók:

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

Akár egy naplózó modul segítségével is hozzáadhat egy kis szerkezetet a megoldáshoz. Ez a megközelítés sok ismert problémát okoz, ezért ezeknek a problémáknak a megoldására egy általános eseménykövető alrendszert biztosítunk.

Az ns-3 nyomkövető rendszer fő céljai a következők:

• Az alapvető feladatokhoz a nyomkövetési rendszernek lehetővé kell tennie a felhasználó számára, hogy szabványos nyomkövetést generáljon a népszerű forrásokhoz, és válassza ki a nyomkövetést létrehozó objektumokat;

• A középhaladó felhasználóknak képesnek kell lenniük a nyomkövetési rendszer kiterjesztésére a generált kimeneti formátum megváltoztatására vagy új nyomkövetési források beillesztésére a szimulátor magjának módosítása nélkül;

• A haladó felhasználók módosíthatják a szimulátor magját új nyomkövetési források és nyelők hozzáadásához. Az ns-3 nyomkövetési rendszer a független nyomkövetési források és vevők, valamint a források fogyasztókhoz való csatlakoztatásának egységes mechanizmusára épül.

Az ns-3 nyomkövetési rendszer a független nyomkövetési források és vevők elveire épül, valamint a források és a vevőegységek összekapcsolásának egységes mechanizmusára. A nyomkövetési források olyan objektumok, amelyek jelezhetik a szimuláció során előforduló eseményeket, és hozzáférést biztosítanak az érdeklődésre számot tartó mögöttes adatokhoz. Például egy nyomkövetési forrás jelezheti, ha egy hálózati eszköz kapott egy csomagot, és elérhetővé teheti a csomag tartalmát az érdeklődő nyomkövetési vevők számára.

A nyomkövetési források önmagukban haszontalanok, hacsak nincsenek "párosítva" a kód más részeivel, amelyek valóban valami hasznosat tesznek a nyelő által szolgáltatott információkkal. A nyomkövetők a nyomkövetési forrásokból származó események és adatok fogyasztói. Létrehozhat például egy nyomkövető-nyelőt, amely (ha az előző példa nyomkövetési forrásához csatlakozik) kinyomtatja a fogadott csomagban található érdekes részeket.

Ennek az explicit szétválasztásnak az az oka, hogy lehetővé teszi a felhasználók számára, hogy új nyelőtípusokat kapcsolódjanak a meglévő nyomkövetési forrásokhoz anélkül, hogy szerkeszteniük és újrafordítaniuk kellene a szimulátormagot. Tehát a fenti példában a felhasználó definiálhat egy új nyomkövetőt a szkriptjében, és csak a felhasználói parancsfájl szerkesztésével kapcsolhatja a szimulációs magban definiált meglévő nyomkövetési forráshoz.

Ebben az oktatóanyagban végigmegyünk néhány előre definiált forráson és elnyelőn, és megmutatjuk, hogyan konfigurálhatók a felhasználó legkevesebb erőfeszítésével. Tekintse meg az ns-3 kézikönyvét vagy az útmutató részeket a speciális nyomkövetési konfigurációval kapcsolatos információkért, beleértve a nyomkövetési névtér bővítését és új nyomkövetési források létrehozását.

5.3.1 ASCII nyomkövetés

Az ns-3 segítő funkcionalitást biztosít, amely alacsony szintű nyomkövetési rendszert biztosít, amely segít a részletekben az egyszerű csomagkövetések beállításakor. Ha engedélyezi ezt a funkciót, a kimenetet ASCII-fájlokban fogja látni. Azok számára, akik ismerik az ns-2 kimenetet, ez a fajta nyomkövetés hasonló a ki.tr, amelyet sok szkript generál.

Lépjünk a dolgokhoz, és adjunk hozzá néhány ASCII nyomkövetési eredményt a scratch/myfirst.cc szkriptünkhöz. Közvetlenül a hívás előtt Simulator :: Run (), adja hozzá a következő kódsorokat:
AsciiTraceHelper ascii;

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

Sok más ns-3 idiómához hasonlóan ez a kód is segítő objektumot használ az ASCII nyomkövetések létrehozásához. A második sor két beágyazott metódushívást tartalmaz. "Belül" módszer CreateFileStream() az anonim objektum idiómát használja egy fájlfolyam objektum létrehozásához a veremben (objektumnév nélkül), és átadja azt a meghívott metódusnak. A jövőben még mélyebben belemegyünk ebbe, de most csak annyit kell tudnia, hogy egy olyan objektumot hozunk létre, amely egy ún. myfirst.tr és vigye át az ns-3-ba. Az ns-3-ra bízzuk a létrehozott objektum teljes élettartama alatti gondozását, amely során megoldja a C++ stream objektummásolat konstruktorokhoz kapcsolódó, kevéssé ismert (szándékos) korlátozás okozta problémákat.

Külső hívás EnableAsciiAll() közli az asszisztenssel, hogy az ASCII nyomkövetést be kívánja vonni a szimulációba minden pont-pont eszközkapcsolathoz, és azt szeretné, hogy a (meghatározott) nyomkövetési vevők ASCII formátumban rögzítsék a csomagmozgási információkat.

Azok számára, akik ismerik az ns-2-t, a követett események egyenértékűek az ismert nyomkövetési pontokkal, amelyek naplózzák a „+”, „-”, „d” és „r” eseményeket.
Most elkészítheti a szkriptet, és futtathatja a parancssorból:

$ ./waf --run scratch/myfirst

A korábbiakhoz hasonlóan számos üzenetet fog látni a Waf-tól, majd a futó program néhány üzenetével „az építés sikeresen befejeződött”.

Futás közben a program létrehoz egy nevű fájlt myfirst.tr. A munka jellegéből adódóan Waf, alapértelmezés szerint a fájl nem a helyi, hanem a tárhely legfelső szintű könyvtárában jön létre. Ha módosítani szeretné a nyomok mentési útvonalát, akkor a Waf paraméterrel megadhatja azt --cwd. Ezt nem tettük meg, ezért a myfirst.tr ASCII nyomkövetési fájl megtekintéséhez kedvenc szerkesztőjében meg kell navigálnunk a tárhelyünk legfelső szintű könyvtárába.

ASCII nyomok elemzése

Rengeteg információ található elég sűrű formában, de az első dolog, amit észre kell venni, hogy a fájl egyedi sorokból áll. Ez jól láthatóvá válik, ha szélesebbre bontja a megtekintési ablakot.

A fájl minden sora egy nyomkövetési eseménynek felel meg. Ebben az esetben a szimulációban minden egyes pont-pont hálózati eszközben jelen lévő átviteli sor eseményeit nyomon követjük. Az átviteli sor az a sor, amelyen minden csomagnak át kell haladnia egy pont-pont kapcsolathoz. Vegye figyelembe, hogy a nyomkövetési fájl minden sora egyetlen karakterrel kezdődik (és utána szóköz van). Ennek a szimbólumnak a következő jelentése lesz:

+: sorba állítási művelet történt az eszközsorban;
-: elemlekérési művelet történt az eszközsorban;
d: a csomagot eldobták, általában azért, mert a sor megtelt;
r: A csomagot egy hálózati eszköz fogadta.

Nézzük meg közelebbről a nyomkövetési fájl első sorát. Részekre bontom (az áttekinthetőség kedvéért behúzással) és a bal oldali sorszámmal:

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

Ennek a kiterjesztett nyomkövetési eseménynek az első része (0. sor) a művelet. Itt van egy + szimbólumunk, ami az átvitelhez való sorban állás műveletének felel meg. A második szakasz (1. sor) a szimulációs idő másodpercben kifejezve. Talán emlékszel, mit kérdeztünk UdpEchoClientApplication két másodpercen belül elkezdheti a csomagok küldését. Itt látjuk a megerősítést, hogy ez valóban megtörténik.

A nyomkövetési példa következő szakasza (a 2. sortól) megmutatja, hogy melyik nyomkövetési forrás generálta ezt az eseményt (jelezve a névtér nyomkövetését). A nyomkövetési névteret úgy képzelheti el, mint egy fájlrendszer névterét. A névtér gyökere az NodeList. Ez megfelel a fő ns-3 kódban kezelt tárolónak. Tartalmazza a szkriptben létrehozott összes csomópontot. Ahogy egy fájlrendszernek is lehetnek könyvtárak a gyökerében, NodeList sok csomópontunk lehet. Tehát a /NodeList/0 sor a NodeList null csomópontjára utal, amelyre általában "0-s csomópontként" gondolunk. Minden csomóponthoz tartozik egy lista a telepített eszközökről. Ez a lista a következő helyen található a névtérben. Láthatja, hogy ez a nyomesemény innen származik Eszközlista/0, amely a csomópontba telepített null eszköz.

Következő részkarakterlánc, $ ns3 :: PointToPointNetDevice, megmondja, hogy melyik eszköz van a nulla pozícióban: a nulla csomópont eszközlistája. Emlékezzünk vissza, hogy a 0. sorban található + művelet azt jelentette, hogy egy elemet hozzáadtunk az eszköz átviteli sorához. Ez tükröződik a „pályaút” utolsó szegmenseiben: TxQueue/Enqueue.

A nyomkövetés többi szakaszának meglehetősen intuitívnak kell lennie. A 3-4. sorok azt jelzik, hogy a csomag pont-pont protokollba van tokozva. Az 5-7. sorok azt mutatják, hogy a csomag IP4-verziós fejléccel rendelkezik, és az IP-címből származik 10.1.1.1 és arra szolgál 10.1.1.2. A 8-9. sorok azt mutatják, hogy ennek a csomagnak UDP fejléce van, végül a 10. sor azt mutatja, hogy a hasznos terhelés a várt 1024 bájt.

A nyomkövetési fájl következő sora azt mutatja, hogy ugyanazt a csomagot húzták ki az átviteli sorból ugyanazon a csomóponton.

A nyomkövetési fájl harmadik sora azt mutatja, hogy a csomagot egy hálózati eszköz fogadta az echo szerver gazdagépén. Az alábbiakban reprodukáltam az eseményt.

0 r
1 2.25732
2 /NodeList/1/DeviceList/0/$ns3::PointToPointNetDevice/MacRx
3   ns3::Ipv4Header (
4     tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
5     length: 1052 10.1.1.1 > 10.1.1.2)
6     ns3::UdpHeader (
7       length: 1032 49153 > 9)
8       Payload (size=1024)

Vegye figyelembe, hogy a nyomkövetési művelet most r, és a szimulációs idő 2,25732 másodpercre nőtt. Ha figyelmesen követte az oktatóanyagot, ez azt jelenti, hogy a hálózati eszközök DataRate és Link Delay értékeit az alapértelmezett értékeken hagyta. Ennek az időnek ismerősnek kell lennie, amint azt az előző részben láthatta.

A nyomkövetési forrás névtér bejegyzése (2. sor) módosult, hogy tükrözze, hogy ez az esemény az 1. csomópontból származik (/NodeList/1) és a csomagot a nyomkövetési forrás fogadja (/MacRx). Elég könnyen követheti a csomag mozgását a topológián keresztül, ha megnézi a fájl fennmaradó nyomait.

5.3.2 PCAP nyomkövetés

Az ns-3 Device Helpers .pcap formátumú nyomkövetési fájlok létrehozására is használható. Betűszó pcap (általában kisbetűvel írják) a csomagrögzítés rövidítése, és valójában egy API, amely magában foglalja a .pcap fájlformátum meghatározását. A legnépszerűbb program, amely képes olvasni és megjeleníteni ezt a formátumot Wireshark (korábban hívták Éteri). Azonban számos forgalom nyomkövetési elemzője használja ezt a csomagformátumot. Arra bátorítjuk a felhasználókat, hogy használják a rendelkezésre álló számos eszközt a pcap-nyomok elemzésére. Ebben az oktatóanyagban a pcap nyomkövetések megtekintésére összpontosítunk tcpdump.

A pcap nyomkövetés engedélyezése egy sor kóddal történik.

pointToPoint.EnablePcapAll ("myfirst");

Illessze be ezt a kódsort az imént hozzáadott ASCII nyomkövetési kód után scratch/myfirst.cc. Ne feledje, hogy csak a "myfirst" karakterláncot adtuk át, nem a "myfirst.pcap" vagy bármi hasonlót. Ez azért van, mert a paraméter egy előtag, nem pedig egy teljes fájlnév. A szimuláció során az asszisztens ténylegesen létrehoz egy nyomkövetési fájlt minden pont-pont eszközhöz. A fájlnevek az előtag, csomópontszám, eszközszám és utótag felhasználásával jönnek létre.pcap".

Példaszkriptünk esetében a végén a "" nevű fájlokat fogjuk látnimyfirst-0-0.pcap"És"myfirst-1-0.pcap", amelyek pcap nyomkövetések a 0. csomóponti 0. eszközhöz és az 1. csomóponti 0. eszközhöz. Miután hozzáadta a kódsort a pcap nyomkövetés engedélyezéséhez, a szkriptet a szokásos módon futtathatja:

$ ./waf --run scratch/myfirst

Ha belenéz a disztribúció legfelső szintű könyvtárába, három fájlt kell látnia: egy ASCII nyomkövetési fájlt myfirst.tr, amelyet korábban tanulmányoztunk, fájlokat myfirst-0-0.pcap и myfirst-1-0.pcap - új pcap fájlok, amelyeket most generáltunk.

Kimenet olvasása a tcpdump segítségével

Egyelőre a pcap fájlok legegyszerűbb módja a tcpdump használata.

$ tcpdump -nn -tt -r myfirst-0-0.pcap
reading from file myfirst-0-0.pcap, link-type PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, length 1024
2.514648 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 1024
tcpdump -nn -tt -r myfirst-1-0.pcap
reading from file myfirst-1-0.pcap, link-type PPP (PPP)
2.257324 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, length 1024
2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 1024

A szeméttelepen myfirst-0-0.pcap (kliens eszköz) 2 másodperces szimuláció után láthatja, hogy az echo csomag elküldésre kerül. Ha megnézed a második lerakóhelyet (myfirst-1-0.pcap), látni fogja, hogy a csomag 2,257324 másodpercnél érkezett meg. A második kiíratban látni fogja, hogy a csomag 2.257324 másodpercnél tér vissza, és végül, hogy az ügyfél az első kiíratban 2.514648 másodpercnél kapta vissza a csomagot.

Kimenet olvasása a Wireshark segítségével

Ha nem ismeri Wireshark, van egy weboldal, ahonnan programokat és dokumentációkat tölthet le: http://www.wireshark.org/. Wireshark egy grafikus felhasználói felület, amely ezen nyomkövetési fájlok megjelenítésére használható. Ha Wireshark-ot használ, bármelyik nyomkövetési fájlt megnyithatja, és a tartalmat úgy jelenítheti meg, mintha csomagszimulálóval rögzítette volna a csomagokat.

Forrás: will.com