5 Beállítás
5.1 A naplózó modul használata
5.1.1 A naplózás áttekintése
5.1.2 A naplózás engedélyezése
5.1.3 A naplózás hozzáadása a kódodhoz
5.2 Parancssori argumentumok használata
5.2.1 Az alapértelmezett attribútumok értékeinek felülírása
5.2.2 Saját parancsok megfogása
5.3 Átviteli rendszer használata
5.3.1 ASCII Átviteli naplózás
ASCII naplózás elemzése
5.3.2 PCAP Átviteli naplózás
5. fejezet
Beállítás
5.1 A naplózó modul használata
Már röviden áttekintettük az ns-3 naplózó modulját a script áttekintésekor, first.cc. Ebben a fejezetben alaposabban megvizsgáljuk a naplózó alrendszer használati lehetőségeit.
5.1.1 A naplózás áttekintése
Sok nagy rendszer támogat valamilyen üzenetnyilvántartási eszközt, és az ns-3 sem kivétel. Egyes esetekben, a "operátor konzoljába" (amely általában a stderr a Unix-alapú rendszerekben) csak hibaüzenetek kerülnek bejegyzésre. Más rendszerekben figyelmeztető üzenetek, valamint részletesebb információk is megjelenhetnek. Bizonyos esetekben a naplózási eszközöket a hibakeresési üzenetek kinyomtatására használják, amelyek gyorsan "elhomályosíthatják" a kimenetet.
Az ns-3-ban alkalmazott megközelítés azt feltételezi, hogy ezek az információs szintek hasznosak, és egy szelektív, többszintű megközelítést biztosítunk az üzenetek nyilvántartásában. A naplózás teljesen letiltható, engedélyezhető egyes komponensek számára vagy globálisan. Ehhez testreszabható információs szintek állnak rendelkezésre. Az ns-3 naplózó modulja viszonylag egyszerű módot biztosít hasznos információk nyerésére a szimulációdból.
Meg kell értened, hogy általános célú mechanizmust biztosítunk — az átvitelt — az adatok lekéréséhez a modelljeidből, amely a modellezés során a Preferált kimeneti módszer (további információkért a nyomkövető rendszerünkről lásd a 5.3 fejezetet). A naplózásnak a hibakeresési információk, figyelmeztetések, hibaüzenetek és a szkriptek vagy modellek bármikor történő gyors üzenetkiadásának Preferált módszerének kell lennie.
Jelenleg a rendszerben hét szint (típus) van meghatározva növekvő informativitással.
- LOG_ERROR — hibak üzenetek regisztrálása (kapcsolódó makró: NS_LOG_ERROR);
- LOG_WARN — figyelmeztető üzenetek regisztrálása (kapcsolódó makró: NS_LOG_WARN);
- LOG_DEBUG — viszonylag ritkán jelentkező hibakeresési üzenetek regisztrálása (kapcsolódó makró: NS_LOG_DEBUG);
- LOG_INFO — információs üzenetek regisztrálása a program végrehajtásának előrehaladásáról (kapcsolódó makró: NS_LOG_INFO);
- LOG_FUNCTION — minden meghívott funkciót leíró üzenetek regisztrálása (két kapcsolódó makró: NS_LOG_FUNCTION, amelyet tagfüggvényekhez használnak, és NS_LOG_FUNCTION_NOARGS, amelyet statikus függvényekhez használnak);
- LOG_LOGIC — a funkción belüli logikai folyamatot leíró üzenetek regisztrálása (kapcsolódó makró: NS_LOG_LOGIC);
- LOG_ALL — az összes fent említett üzenet regisztrálása (nincs kapcsolódó makró).
Minden típushoz (LOG_TYPE) kapcsolódik egy LOG_LEVEL_TYPE, ami, ha használják, lehetővé teszi a saját szintje mellett az összes fölötte lévő szint regisztrálását is. (Ennek következtében a LOG_ERROR és LOG_LEVEL_ERROR, valamint a LOG_ALL és LOG_LEVEL_ALL funkcionálisan egyenértékűek.) Például a LOG_INFO engedélyezése csak az NS_LOG_INFO makró által biztosított üzeneteket engedélyezi, míg a LOG_LEVEL_INFO engedélyezése az NS_LOG_DEBUG, NS_LOG_WARN és NS_LOG_ERROR makrók által biztosított üzeneteket is magában foglalja.
Továbbá biztosítunk egy feltétel nélküli naplózási makrót, amely mindig megjelenik, függetlenül a naplózási szinttől vagy a választott komponenstől.
- NS_LOG_UNCOND — feltétel nélküli üzenet regisztrálása (nincs kapcsolódó naplózási szint).
Minden szint külön-külön vagy kumulatívan kérhető. A naplózás beállítható az NS_LOG környezeti változóval vagy a rendszerhívás regisztrálásával. Ahogy azt korábban bemutattuk, a naplózási rendszernek van Doxygen dokumentációja, és itt az idő, hogy átnézd, ha még nem tetted meg.
Most, hogy nagyon részletesen átnézted a dokumentációt, használjuk fel ezt a tudást, hogy érdekes információkat kapjunk egy példasorozatból. scratch/myfirst.cc, amelyet már lefordítottál.
5.1.2 A naplózás engedélyezése
Használjuk az NS_LOG környezeti változót, hogy még több naplót indítsunk, de először, csak a tájékozódás érdekében, futtassuk az utolsó szkriptet, ahogyan korábban tettük,
$ ./waf --run scratch/myfirstMár ismerős kimenetet kell látnod az ns-3 példaprogram első programjáról.
$ Waf: Belépés a könyvtárba `/{/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' Waf: Kilépés a könyvtárból `/{/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' 'build' Sikeresen befejeződött (0.413s) 1024 bájt küldve a 10.1.1.2 címre 1024 bájt fogadva a 10.1.1.1 címről 1024 bájt fogadva a 10.1.1.2 címrőlA fenti "elküldött" és "kapott" üzenetek valójában regisztrált üzenetek az UdpEchoClientApplication és UdpEchoServerApplication. Például kérhetjük a kliensalkalmazást, hogy nyomtasson ki további információkat, a naplózási szint beállításával az NS_LOG környezeti változó által.
Mostantól azt feltételezem, hogy sh-szerű héjat használ, amely a "VÁLTOZÓ = érték" szintaxist használja. Ha csh-szerű héjat használ, akkor át kell alakítania példáimat a "setenv változó érték" szintaxisra, melyet ezek a héjak igényelnek.
Jelenleg az UDP echo kliens program a következő kódra válaszol scratch/myfirst.cc,
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);Ez aktiválja a LOG_LEVEL_INFO naplózási szintet. Amikor a naplózási szint zászlóját átadjuk, valójában ezt a szintet és az annál alacsonyabb szinteket kapcsoljuk be. Ebben az esetben aktiváltuk az NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN és NS_LOG_ERROR szinteket. Emelhetjük a naplózási szintet és több információt kaphatunk anélkül, hogy a skripten változtatnánk vagy újra lefordítanánk, az NS_LOG környezeti változó a következőképpen való beállításával:
$ export NS_LOG=UdpEchoClientApplication=level_allÍgy az NS_LOG sh-héjának a következő értékét állítjuk be,
UdpEchoClientApplication=level_allA bal oldali hozzárendelés az a naplózandó komponens neve, amelyet be szeretnénk állítani, a jobb oldali pedig az a zászló, amelyet ehhez alkalmazni szeretnénk. Ebben az esetben minden hibakeresési szintet be fogunk kapcsolni az alkalmazásban. Ha a skriptet így indítja el az NS_LOG beállítással, az ns-3 naplózási rendszer észleli a változásokat, és a következő kimenetet kell látnia:
Waf: Belépés a könyvtárba `/{/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' Waf: Kilépés a könyvtárból `/{/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' 'build' Sikeresen befejeződött (0.404s) UdpEchoClientApplication:UdpEchoClient() UdpEchoClientApplication:SetDataSize(1024) UdpEchoClientApplication:StartApplication() UdpEchoClientApplication:ScheduleTransmit() UdpEchoClientApplication:Send() 1024 bájt küldve a 10.1.1.2 címre 1024 bájt fogadva a 10.1.1.1 címről UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20) 1024 bájt fogadva a 10.1.1.2 címről UdpEchoClientApplication:StopApplication() UdpEchoClientApplication:DoDispose() UdpEchoClientApplication:~UdpEchoClient()A kiegészítő hibakeresési információ, amelyet az alkalmazás nyújt, most már megfelel az NS_LOG_FUNCTION szintnek. Megmutatja a funkcióhívások minden esetét a szkript futása során. Általában a metódusokban ajánlott használni (legalábbis)NS_LOG_FUNCTION (this). Használja NS_LOG_FUNCTION_NOARGS ()
csak statikus funkciókban. Ne feledje azonban, hogy az ns-3 rendszerben nincs követelmény bármilyen naplózási funkcionalitás fenntartására. Az, hogy mennyi információt naplóznak, a modell fejlesztőjének egyéni döntése. Az echo alkalmazások esetében sok kimeneti adat érhető el a naplózáshoz.
Most már megtekintheti az alkalmazás által végrehajtott funkcióhívások naplóit. Ha alaposan megnézi, észre fogja venni a kettőspontot a sor és a metódus neve között, ott, ahol esetleg a C++ láthatósági operátort (: :) várta volna. Ezt szándékosan tették. UdpEchoClientApplication Valójában ez nem az osztály neve, hanem a naplózási komponens neve. Amikor van megfelelés a forrásfájl és az osztály között, általában ez az osztály neve, de meg kell értenie, hogy valójában ez nem az osztály neve, és ott egy kettőspont van a dupla kettőspont helyett. Ez egy módja annak, hogy segítse Önt viszonylag finom módon elkülöníteni a naplózási komponens nevét az osztály nevétől.
Mindazonáltal néha nehéz megállapítani, hogy melyik metódus generálja valójában a naplóüzenetet. Ha megnézi a fent említett szöveget, kérdése támad, hogy honnan származik a "
Received 1024 bytes from 10.1.1.2" szöveg. Ezt a problémát úgy oldhatja meg, hogy beállítja a szintetprefix_func az NS_LOG környezeti változóban. Próbálja ki a következőt, $ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'
Ne feledje, hogy a zárójelek szükségesek, mivel a függőleges vonal, amelyet az 'VAGY' művelet jelölésére használunk, a Unix csövek összekötője is. Most, ha futtatja a szkriptet, látnia kell, hogy a naplózási rendszer biztosítja, hogy az adott naplóból származó üzenetek mindegyike a komponens neve előtagjára van beállítva.Kérjük, vegye figyelembe, hogy a zárójelek szükségesek, mivel a függőleges vonal, amelyet az VAGY művelet jelölésére használunk, szintén a Unix csövek összekötésére szolgál. Most, ha futtatja a szkriptet, láthatja, hogy a naplózási rendszer biztosítja, hogy a megadott napló minden üzenetének előtagja legyen a komponens neve.
Waf: Belépve a könyvtárba `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf: Kilépve a könyvtárból `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'A build' sikeresen befejeződött (0.417s)\nUdpEchoClientApplication:UdpEchoClient()\nUdpEchoClientApplication:SetDataSize(1024)\nUdpEchoClientApplication:StartApplication()\nUdpEchoClientApplication:ScheduleTransmit()\nUdpEchoClientApplication:Send()\nUdpEchoClientApplication:Send(): 1024 bájt küldve a 10.1.1.2 címre\n1024 bájt érkezett a 10.1.1.1 címről\nUdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)\nUdpEchoClientApplication:HandleRead(): 1024 bájt érkezett a 10.1.1.2 címről\nUdpEchoClientApplication:StopApplication()\nUdpEchoClientApplication:DoDispose()\nUdpEchoClientApplication:~UdpEchoClient()Most már láthatja, hogy minden, az UDP echo kliens alkalmazásából érkező üzenet, mint ilyen van azonosítva. Az üzenet „" szöveg. Ezt a problémát úgy oldhatja meg, hogy beállítja a szintet” most egyértelműen meghatározott, mint az echo kliens alkalmazástól érkező. A fennmaradó üzenet az UDP echo szerver alkalmazásból kell, hogy érkezzen. Ezt az összetevőt aktiválhatjuk úgy, hogy a komponensek listáját, kettőspontokkal elválasztva, beírjuk az NS_LOG környezeti változóba.
$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func:\n UdpEchoServerApplication=level_all|prefix_func'Figyelmeztetés: A fenti szövegmintában el kell távolítania az új sor karaktert a kettőspont után (:), amely a dokumentum formázására szolgál. Most, ha futtatja a szkriptet, láthatja az összes naplóüzenetet a kliens és a szerver echo alkalmazásból. Láthatja, hogy ez nagyon hasznos lehet a hibakeresés során.
Waf: Belépve a könyvtárba `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf: Kilépve a könyvtárból `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'A build' sikeresen befejeződött (0.406s)\nUdpEchoServerApplication:UdpEchoServer()\nUdpEchoClientApplication:UdpEchoClient()\nUdpEchoClientApplication:SetDataSize(1024)\nUdpEchoServerApplication:StartApplication()\nUdpEchoClientApplication:StartApplication()\nUdpEchoClientApplication:ScheduleTransmit()\nUdpEchoClientApplication:Send()\nUdpEchoClientApplication:Send(): 1024 bájt küldve a 10.1.1.2 címre\nUdpEchoServerApplication:HandleRead(): 1024 bájt érkezett a 10.1.1.1 címről\nUdpEchoServerApplication:HandleRead(): Visszhangzó csomag\nUdpEchoClientApplication:HandleRead(0x624920, 0x625160)\nUdpEchoClientApplication:HandleRead(): 1024 bájt érkezett a 10.1.1.2 címről\nUdpEchoServerApplication:StopApplication()\nUdpEchoClientApplication:StopApplication()\nUdpEchoClientApplication:DoDispose()\nUdpEchoServerApplication:DoDispose()\nUdpEchoClientApplication:~UdpEchoClient()\nUdpEchoServerApplication:~UdpEchoServer()Néha hasznos lehet látni a szimuláció idejét, amikor a naplóüzenet létrejött. Ezt úgy érheti el, hogy hozzáad egy időbélyeget prefix_time:
$ 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 új sor karaktert. Ha most futtatja a skripttet, akkor a következő kimenetet kell látnia:
Waf: Belépés a könyvtárba `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Kilépés a könyvtárból `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
`build` sikeresen befejeződött (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(): 1024 bájt küldve a 10.1.1.2 címre
2.00369s UdpEchoServerApplication:HandleRead(): 1024 bájt érkezett a 10.1.1.1 címről
2.00369s UdpEchoServerApplication:HandleRead(): Csomag visszaküldése
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): 1024 bájt érkezett a 10.1.1.2 címről
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()Kérjük, vegye figyelembe, hogy az konstruktor UdpEchoServer a szimuláció 0. másodpercében lett meghívva. Ez valójában a szimuláció kezdete előtt történik, de ez az idő nulla másodpercként jelenik meg. Ugyanez igaz a konstruktor üzenetre is, UdpEchoClient.
Waf: Belépés a könyvtárba `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Kilépés a könyvtárból `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
`build` sikeresen befejeződött (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(): 1024 bájt küldve a 10.1.1.2 címre
2.00369s UdpEchoServerApplication:HandleRead(): 1024 bájt érkezett a 10.1.1.1 címről
2.00369s UdpEchoServerApplication:HandleRead(): Csomag visszaküldése
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): 1024 bájt érkezett a 10.1.1.2 címről
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()Emlékeztetőül, a scratch/first.cc script egy másodperccel a szimuláció kezdete előtt elindította az echo-server alkalmazást. Most láthatja, hogy a módszer StartApplication a szerveren ténylegesen a első másodpercben lett meghívva. Azt is észlelhetjük, hogy az echo-client a szimuláció második másodpercében indul el, ahogyan azt a scriptben kértük.
Most nyomon követheti a szimuláció folyamatát a ScheduleTransmit metódus hívásával a kliensben, amely a Send visszahívást biztosít a echo-server alkalmazásban. Kérjük, vegye figyelembe, hogy a csomag kétpontos kapcsolatán keresztüli elküldési idő 3,69 milliszund. Láthattuk, hogy az echo-server nyilvántartást tart arról, hogy válaszolt a csomagra, majd a csatorna késleltetése után láthatjuk, hogy az echo-client megkapja az echo-csomagot a HandleRead metódusában.
Ebben a szimulációban sok minden történik, ami észrevétlen marad a számára. De nagyon könnyen nyomon követheti az egész folyamatot, ha minden naplózási komponenst bekapcsol a rendszerben. Próbálja meg a NS_LOG változóhoz a következő értéket beállítani,
$ export 'NS_LOG=*=level_all|prefix_func|prefix_time'A fent említett csillag a naplózó komponens helyettesítőjele. Ez lehetővé teszi az összes rekordot az összes szimulációs komponensben. Nem fogom itt reprodukálni a kimenetet (a cikk írásakor 1265 sort generál az egy echo-csomaghoz), de ezt az információt átirányíthatja egy fájlba, és megnézheti a kedvenc szerkesztőjében.
$ . /waf --run scratch/myfirst > log.out 2>&1Én személy szerint ezt a rendkívül részletes naplózási verziót használom, amikor problémám adódik, és fogalmam sincs, hol mentek félre a dolgok. Egyszerűen követhetem a kód végrehajtását anélkül, hogy megszakítási pontokat vagy lépésről lépésre történő kódolást kellene beállítanom a hibakeresőben. Csak szerkeszthetem a kimenetet a kedvenc szerkesztőmben, kereshetem, amit várok, és láthatom, hogy mi történik, amit nem vártam. Amikor van egy általános elképzelésem arról, hogy mi megy félre, áttérek a hibakeresőre a probléma részletes vizsgálatához. Ez a fajta kimenet különösen hasznos lehet, amikor a szkripted valami teljesen váratlanul viselkedik. Ha csak a hibakeresőt használod, teljesen elmulaszthatod a váratlan fordulatokat. A naplózás kiemeli ezeket a fordulatokat.
5.1.3 A naplózás hozzáadása a kódodhoz
Új bejegyzéseket adhatsz a szimulációidhoz, ha log komponenst hívsz meg több makróból. Tegyük ezt a szkriptben. myfirst.cc, amely a "tiszta" könyvtárunkban található. Ne felejtsük el, hogy ebben a szkriptben meghatároztuk a naplózási komponenst:
NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");Tudjátok, hogy a NS_LOG környezeti változó különböző szinten történő beállításával engedélyezheted ennek a komponensnek minden üzenetének naplózását. Folytassuk, és adjunk hozzá néhány bejegyzést a szkripthez. Az információs szintű üzenetek naplózására használt makró a NS_LOG_INFO. Adjunk hozzá egy üzenetet (közvetlenül az előtt, hogy elkezdenénk a csomópontok létrehozását), amely elmondja neked, hogy a szkript a topológia létrehozásának szakaszában van ("Creating Topology"). Ezt a következő kódrészletben végezzük el:
Nyisd meg scratch/myfirst.cc a kedvenc szerkesztődben, és adj hozzá egy sort,
NS_LOG_INFO ("Creating Topology");
éppen a sorok előtt,
NodeContainer nodes;
nodes.Create (2);Most fordítsd le a szkriptet a következő használatával. waf, és töröld a NS_LOG változót, hogy lekapcsold a naplózási folyamatot, amelyet korábban engedélyeztél:
$ . /waf
$ export NS_LOG=
Most, ha futtatod a szkriptet,
$ . /waf --run scratch/myfirstnem fogod látni az új üzenetet, mert a hozzá kapcsolódó naplózási komponens (FirstScriptExample) nincs bekapcsolva. Ahhoz, hogy láthasd az üzenetedet, engedélyezned kell a naplózási komponenst FirstScriptExample NS_LOG_INFO szintnél nem alacsonyabb üzenetekhez. Ha csak ezt a konkrét naplózási szintet szeretnéd látni, így engedélyezheted.
$ export NS_LOG=FirstScriptExample=infoHa most elindítja a szkriptet, új üzenetet fog látni: „Topology létrehozása”.
Waf: Belépés a következő könyvtárba `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf: Kilépés a következő könyvtárból `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'A build' sikeresen befejeződött (0.404s)\nTopology létrehozása\n1024 byte elküldve a 10.1.1.2 címre\n1024 byte fogadva a 10.1.1.1 címről\n1024 byte fogadva a 10.1.1.2 címről5.2 Parancssori argumentumok használata
5.2.1 Az alapértelmezett attribútumok értékeinek felülírása
A ns-3 viselkedésének megváltoztatásának egy másik módja a parancssori argumentumok használata, szerkesztés és fordítás nélkül. Mechanizmust biztosítunk a parancssori argumentumok elemzésére és a helyi és globális változók automatikus beállítására az eredmények alapján.
A parancssori argumentumok használatának első lépése a parancssori elemző deklarálása. Ezt meglehetősen egyszerűen lehet megtenni (a fő programjában), az alábbi kód szerint:
int\nmain (int argc, char *argv[])\n{\n...\nCommandLine cmd;\ncmd.Parse (argc, argv);\n...\n}Ez az egyszerű két soros kód valójában nagyon hasznos önmagában. Megnyitja az ajtót a globális ns-3 változó és az attribútumok rendszeréhez. Adjunk hozzá két sort a szkriptünk főfunkciójának elejéhez. scratch/myfirst.cc. Továbbhaladva fordítsuk le a szkriptet, és indítsuk el; indításkor kérjük a súgót az alábbiak szerint:
$ .\/waf --run "scratch\/myfirst --PrintHelp"Ez a parancs arra kéri Waf a szkript futtatására scratch\/myfirst és a parancssori argumentumot --PrintHelp. A zárójelek szükségesek ahhoz, hogy megmutassák, melyik programhoz tartozik az argumentum. A parancssori elemző észleli az argumentumot, --PrintHelp és válaszként kiírja,
Waf: Belépés a következő könyvtárba `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf: Kilépés a következő könyvtárból `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'A build' sikeresen befejeződött (0.413s)\nTcpL4Protocol:TcpStateMachine()\nCommandLine:HandleArgument(): Arg név=PrintHelp érték=\n--PrintHelp: Ez a súgóüzenet.\n--PrintGroups: A csoportok listáját írja ki.\n--PrintTypeIds: Minden TypeId-t kiír.\n--PrintGroup=[group]: Kiírja a csoport összes TypeId-ját.\n--PrintAttributes=[typeid]: Kiírja a typeid összes attribútumát.\n--PrintGlobals: A globálisak listáját írja ki.Most nézzük meg az --PrintAttributesopciót. Már említettük az ns-3 attribútrendszert, amikor a first.cc szkriptet tanulmányoztuk. A következő kódsorokat láttuk:
PointToPointHelper pointToPoint;\npointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));\npointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));és azt mondtuk, hogy a DataRate valójában egy attribútum a PointToPointNetDevice. Alkalmazzuk a parancssori argumentum elemzőt az attribútumok megtekintésére. PointToPointNetDevice. A súgólistából kiderül, hogy meg kell adnunk TypeIdEz az osztály neve, amelyhez a keresett attribútumok tartoznak. Ebben az esetben ez a következő lesz: ns3::PointToPointNetDevice. Folytassuk, írja be a következőt:
$ ./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointNetDevice"A rendszer kinyomtatja ennek a hálózati eszköztípusnak az összes attribútumát. Látni fogja, hogy az attribútumok között van:
--ns3::PointToPointNetDevice::DataRate=[32768bps]:
Az alapértelmezett adatátviteli sebesség pont-pont kapcsolatokhozEz az alapértelmezett érték, amelyet a rendszer használni fog az objektum létrehozásakor. PointToPointNetDevice. Ezt az alapértelmezett értéket felülírjuk a következő paraméterrel: Attribútum be. PointToPointHelper fent. Használjuk az alapértelmezett értékeket a pont-pont eszközökhöz és csatornákhoz. Ehhez távolítsuk el a hívásokat SetDeviceAttribute és SetChannelAttribute a myfirst.cc, amelyeket a tiszta könyvtárban találunk.
A szkriptjének most már csak nyilatkoznia kell: PointToPointHelper és nem kell telepítési műveleteket végeznie, ahogy azt az alábbi példa mutatja:
...
NodeContainer nodes;
nodes.Create (2);
PointToPointHelper pointToPoint;
NetDeviceContainer devices;
devices = pointToPoint.Install (nodes);
...Folytassa, és hozzon létre egy új szkriptet a következővel: Waf (./waf) és térjünk vissza, és aktiváljunk egy feljegyzést az UDP echo alkalmazás szerveréből, és kapcsoljuk be az időbélyegzőt.
$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'Ha futtatja a szkriptet, a következő kimenetet kell látnia:
Waf: Belépés a könyvtárba `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf: Kilépés a könyvtárból `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'build' sikeresen befejeződött (0.405s)\n0s UdpEchoServerApplication:UdpEchoServer()\n1s UdpEchoServerApplication:StartApplication()\n1024 bájt küldve a 10.1.1.2-nek\n2.25732s 1024 bájt érkezett a 10.1.1.1-től\n2.25732s Csomag echozása\n1024 bájt érkezett a 10.1.1.2-től\n10s UdpEchoServerApplication:StopApplication()\nUdpEchoServerApplication:DoDispose()\nUdpEchoServerApplication:~UdpEchoServer()Emlékezzünk, hogy az utolsó alkalommal, amikor a szimuláció időtartamát néztük, az echo server csomag fogadásának pillanata 2,00369 másodperc volt.
2.00369s UdpEchoServerApplication:HandleRead(): 1024 bájt érkezett a 10.1.1.1-tőlMost 2.25732 másodpercben kapja meg a csomagot. Ennek oka, hogy egyszerűen visszaminősítettük a PointToPointNetDevice adatátviteli sebességét ötmillió bit/másodpercről az alapértelmezett 32768 bit/másodpercre. Ha a parancssoron keresztül új DataRate-t állítunk be, akkor ismét felgyorsíthatjuk a modellezést. Ezt a következő módon tesszük, a súgóelem által implikált képlet szerint:
$ ./waf --run "scratch/myfirst --ns3::PointToPointNetDevice::DataRate=5Mbps"Ennek eredményeként az alapértelmezett DataRate attribútum értéke visszatér öt megabit másodpercenként. Meglepetést okoz az eredmény? Kiderül, hogy a forgatókönyv kezdeti viselkedésének visszaállításához a fénysebességnek megfelelő csatorna késleltetést is be kell állítanunk. Megkérhetjük a parancssort, hogy nyomtassa ki a csatorna attribútumait, akárcsak a hálózati eszköznél:
$ ./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointChannel"Azt tapasztaljuk, hogy a csatorna késleltetéseként az alábbi érték lett beállítva:
--ns3::PointToPointChannel::Delay=[0ns]:
Az átkonvertálási késleltetés a csatornán keresztülEzután a parancssoron 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 helyreállítjuk azt az időt, amelyet akkor állítottunk be, amikor kifejezetten a DataRate-t és a Delay-t a forgatókönyvben állítottuk be:
Waf: Belépés a könyvtárba `~/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Kilépés a könyvtárból `~/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'a build' sikeresen befejeződött (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
1024 bájt küldve a 10.1.1.2 címre
2.00369s 1024 bájt fogadva a 10.1.1.1 címről
2.00369s Echoing packet
1024 bájt fogadva a 10.1.1.2 címről
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()Vegyük észre, hogy a csomag ismételten megérkezik a szerverhez 2,00369 másodperc után. Valójában bármelyik forgatókönyvben használt attribútumot ilyen módon beállíthatnánk. Különösen a MaxPackets attribútumok más mint 1 értéket is beállíthatnánk. UdpEchoClient.
Hogyan használnád ezt? Próbáld ki. Ne feledd, hogy ki kell kommentálnod azt a helyet, ahol felülbíráljuk az alapértelmezett attribútum értékét és kifejezetten beállítjuk a MaxPackets értéket a forgatókönyvben. Ezután újra kell építened a szkriptet. A parancssoron keresztül is kérhetsz segítséget az új alapértelmezett attribútum értékének beállításához. Miután megértetted, képes leszel kezelni a parancssorban megjelenített csomagok számát. Mivel szorgalmas emberek vagyunk, a parancssorunk valahogyan így kell kinézzen:
$ ./waf --run "scratch/myfirst
--ns3::PointToPointNetDevice::DataRate=5Mbps
--ns3::PointToPointChannel::Delay=2ms
--ns3::UdpEchoClient::MaxPackets=2"Egy természetes kérdés merül fel itt, hogy hogyan tudhatsz meg mindezekről az attribútumokról. Ismét csak a parancssor rendelkezik segítség funkcióval ebben a kérdésben. Ha kérjük a parancssor segítségét, akkor látnunk kell:
$ ./waf --run "scratch/myfirst --PrintHelp"
myfirst [Program Arguments] [General Arguments]
General Arguments:
--PrintGlobals: Kiírja a globális változók listáját.
--PrintGroups: Kiírja a csoportok listáját.
--PrintGroup=[group]: Kiírja a csoport összes TypeId-ját.
--PrintTypeIds: Kiírja az összes TypeId-t.
--PrintAttributes=[typeid]: Kiírja a typeid összes attribútumát.
--PrintHelp: Kiírja ezt a segítségüzenetet.Ha a «PrintGroups» argumentumot választja, látnia kell minden regisztrált csoport listáját. TypeId. A csoportnevek megegyeznek az alapértelmezett könyvtárban található modulok neveivel (bár nagy kezdőbetűvel). Az összes információ egyszerre történő kiírása túl nagy lenne, ezért egy kiegészítő szűrő érhető el az információk csoportok szerinti kiírására. Így, újra a «pont-pont» modulra összpontosítva:
./waf --run "scratch/myfirst --PrintGroup=PointToPoint"
TypeIds a PointToPoint csoportban:
ns3::PointToPointChannel
ns3::PointToPointNetDevice
ns3::PointToPointRemoteChannel
ns3::PppHeaderItt találja a TypeId-k elérhető neveit az attribútumok kereséséhez, például a következőben:
--PrintAttributes = ns3::PointToPointChannel, ahogyan az fent látható.
Egy másik módja az attribútumok megismerésének a Doxygen ns-3-on keresztül. Ott van egy oldal, amely felsorolja az összes regisztrált attribútumot a szimulátorban.
5.2.2 Saját parancsok megfogása
Ezen kívül a parancssori rendszer segítségével saját horgokat is hozzáadhat. Ezt meglehetősen egyszerűen megteheti a parancssori elemző módszerével. AddValue.
Használjuk ki ezt a lehetőséget, hogy más módon határozzuk meg, hány csomag jelenjen meg. Adjunk hozzá egy helyi változót, amelyet úgy hívunk, hogy nPackets a függvényben. mainBeállítjuk 1-re, hogy megfeleljen az előző alapértelmezett viselkedésünknek. Ahhoz, hogy a parancssori elemző módosítani tudja ezt az értéket, le kell azt fogni az elemzőben. Ezt a következő hívás hozzáadásával tesszük: AddValueMenj és módosítsd a szkriptet, scratch/myfirst.cc úgy, hogy a következő kóddal kezdődjon:
int
main (int argc, char *argv[])
{
uint32_t nPackets = 1;
CommandLine cmd;
cmd.AddValue("nPackets", "A visszhangzó csomagok száma", nPackets);
cmd.Parse(argc, argv);
...Görgessen le a szkript azon pontjáig, ahol beállítjuk a MaxPackets attribútumot, és módosítsa úgy, hogy az a nPackets változóra legyen állítva, ahelyett, hogy 1 konstans lenne, ahogy az alább látható.
echoClient.SetAttribute ("MaxPackets", UintegerValue (nPackets));Most, ha elindítja a szkriptet és megadja a —PrintHelp argumentumot, látnia kell az új felhasználói argumentumot, amelyet a segítségkijelzőn felsorolnak. Írja be,
$ ./waf --run "scratch/myfirst --PrintHelp"
Waf: Belépés a mappába ` /home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Kilépés a mappából ` /home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' sikeresen befejeződött (0.403s)
--PrintHelp: Nyomtatás e segédesetet.
--PrintGroups: Csoportok listájának nyomtatása.
--PrintTypeIds: Minden TypeId nyomtatása.
--PrintGroup=[group]: Minden TypeId nyomtatása a csoportból.
--PrintAttributes=[typeid]: Minden attribútum nyomtatása a typeid alapján.
--PrintGlobals: Globálisok listájának nyomtatása.
Felhasználói Argumentumok:
--nPackets: Az átküldendő csomagok számaHa meg akarja változtatni az átküldendő csomagok számát, ezt megteheti, ha a parancssorban -nPackets argumentumot állít be.
$ ./waf --run "scratch/myfirst --nPackets=2"Most már látnia kell
Waf: Belépés a mappába ` /home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Kilépés a mappából ` /home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' sikeresen befejeződött (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
1024 byte küldve a 10.1.1.2 IP-címre
2.25732s 1024 byte fogadva a 10.1.1.1 IP-címtől
2.25732s Csomag visszhangzása
1024 byte fogadva a 10.1.1.2 IP-címtől
1024 byte küldve a 10.1.1.2 IP-címre
3.25732s 1024 byte fogadva a 10.1.1.1 IP-címtől
3.25732s Csomag visszhangzása
1024 byte fogadva a 10.1.1.2 IP-címtől
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()Most már elküldött két csomagot. Eléggé egyszerű, nem igaz?
Láthatja, hogy ns-3 felhasználóként használhatja a parancssori argumentum rendszert a globális értékek és attribútumok kezelésére. Ha Ön modell szerzője, új attribútumokat adhat a tárgyaihoz, amelyek automatikusan elérhetővé válnak a felhasználói beállítások számára a parancssori rendszeren keresztül. Ha Ön forgatókönyv író, új változókat adhat a szkriptekhez, és ezeket zökkenőmentesen csatlakoztathatja a parancssori rendszerhez.
5.3 Átviteli rendszer használata
A modellezés lényege az, hogy kimeneti adatokat hozzon létre a további vizsgálatokhoz, és az ns-3 nyomkövetési rendszere a fő mechanizmus ehhez. Mivel az ns-3 C++-ban íródott, a C++ programok kimeneti adatok generálására szolgáló szabványos eszközei is használhatók:
#include <iostream>
...
int main ()
{
...
std::cout << "The value of x is " << x << std::endl;
...
}Sőt, a naplózási modult is használhatja, hogy kis szerkezetet adjon a megoldásához. Sok problémát okoz ilyen megközelítés, ezért az ezek kezelésére szolgáló közös esemény-nyomkövetési alrendszert biztosítottunk.
Az ns-3 nyomkövetési rendszerének fő céljai:
Az alapvető feladatokhoz a nyomkövetési rendszernek lehetővé kell tennie a felhasználó számára, hogy standard nyomkövetést generáljon népszerű forrásokból, és kiválasztja, hogy mely objektumok generálják a nyomkövetést.
A köztes felhasználóknak lehetőséget kell adniuk a nyomkövető rendszer kibővítésére, hogy megváltoztassák a generált kimeneti formátumot vagy új nyomkövető forrásokat illeszthessenek be a szimulátor magjának módosítása nélkül;
A tapasztalt felhasználók módosíthatják a szimulátor magját új nyomkövető források és vevők hozzáadásához. Az ns-3 nyomkövető rendszere az önálló nyomkövető források és vevők, valamint a források és a fogyasztók csatlakozásának egységes mechanizmusán alapul.
Az ns-3 nyomkövető rendszere az önálló nyomkövető források és vevők, valamint a források és vevők egységes felszerelési mechanizmusán alapul. A nyomkövető források olyan objektumok, amelyek jelezni tudják a szimuláció során bekövetkező eseményeket, és hozzáférést biztosítanak az érdekes alapadatokhoz. Például egy nyomkövető forrás jelezheti, amikor egy hálózati eszköz csomagot kapott, és lehetővé teszi a csomag tartalmához való hozzáférést az érdeklődő nyomkövető vevők számára.
A nyomkövető források önállóan haszontalanok, ha nem 'kötődnek' más kód részeihez, amelyek valójában hasznos dolgokat tesznek az információval, amelyet a vevő szolgáltat. A nyomkövetők az események és adatok fogyasztói, amelyeket a nyomkövető források biztosítanak. Például létrehozható egy nyomkövető vevő, amely (az előző példa nyomkövető forrásához való csatlakozással) kiírja a megkapott csomag érdekes részeit.
A kifejezett különválasztásnak racionális alapja van, amely lehetővé teszi a felhasználók számára, hogy új típusú vevőket csatlakoztassanak meglévő nyomkövető forrásokhoz anélkül, hogy a szimulátor magját kellene módosítaniuk vagy újra kellene fordítaniuk. Így a fenti példában a felhasználó új nyomkövetőt határozhat meg a skriptjében, és csatlakoztathatja azt egy meglévő nyomkövető forráshoz, amely a szimuláció magjában van, csak a felhasználói skript módosításával.
Ebből az útmutatóból megismerjük a néhány előre definiált forrást és fogadót, valamint azt, hogyan állíthatjuk be őket minimális felhasználói erőfeszítéssel. Lásd a ns-3 útmutatót vagy az utasítási szakaszokat az a nyomkövetési konfigurációk részletes információihoz, 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 Átviteli naplózás
A ns-3 segédprogram funkciót biztosít, amely alacsony szintű nyomkövetési rendszert nyújt, hogy segítsen Önnek a részletekben, amikor nem bonyolult csomagkövetéseket állít be. Ha engedélyezi ezt a funkciót, ASCII fájlokban látja a kimenetet. Azok számára, akik ismerik az ns-2 kimenetét, ez a típusú nyomkövetés hasonló. out.tr, amelyet számos szkripttel generálnak.
Lépjünk a lényegre, és adjunk 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"));Mint sok más ns-3 idiomában, ez a kód segédobjektumot használ az ASCII nyomkövetések létrehozásához. A második sor két beágyazott metódushívást tartalmaz. A "belső" módszer CreateFileStream () azonos névtelen objektumot használ egy fájl áramlási objektumának létrehozására a veremben (név nélküli objektum), és átadja azt a hívó metódusnak. A jövőben mélyebben foglalkozunk ezzel, de amit tudnia kell ebben a szakaszban, az az, hogy létrehoz egy objektumot a "myfirst.tr" nevű fájlhoz, és átadja azt a ns-3-nak. A ns-3-ra bízzuk, hogy az objektumot életciklusa alatt kezeli, amely során a C++ áramlási objektumok másoló konstruktoraiból adódó kevésbé ismert (szándékos) korlátozások problémáit megoldja. myfirst.tr és átadja azt a ns-3-nak. A ns-3-ra bízzuk, hogy az objektumot életciklusa alatt kezeli, amely során a C++ áramlási objektumok másoló konstruktoraiból adódó kevésbé ismert (szándékos) korlátozások problémáit megoldja.
A külső hívás EnableAsciiAll() értesíti a segédprogramot, hogy ASCII nyomkövetésbe szeretné bevonni a pont-pont eszközök összes kapcsolatát a szimulációjában, és hogy (megjelölt) nyomkövetőknek szeretné, hogy rögzítsék az adatcsomagok mozgásának információit ASCII formátumban.
Azok számára, akik ismerik az ns-2-t, a megfigyelt események egyenértékűek a jól ismert nyomkövetési pontokkal, amelyek a "+", "-", "d" és "r" eseményeket naplózzák.
Most összeállíthatja a szkriptet, és futtathatja a parancssorból:
$ ./waf --run scratch/myfirstHányszor is láttad már a Waf-tól érkező néhány üzenetet, majd a "'build' finished successfully" (a fordítás sikeresen befejeződött) üzenetet néhány működő program üzenetével együtt.
Program futása során egy fájl készül a következő névvel myfirst.tr. A működés sajátosságai miatt Waf, alapértelmezés szerint a fájl nem a helyi könyvtárban jön létre, hanem a tároló legfelső szintű könyvtárában. Ha meg szeretnéd változtatni azt az utat, ahol a nyomvonalakat menteni szeretnéd, akkor a Waf-hoz használhatod a --cwdparamétert. Mi ezt nem tettük meg, ezért ahhoz, hogy bele tudjunk nézni az ASCII nyomvonal fájlba, mint például myfirst.tr, a kedvenc szerkesztődben, át kell menjünk a tárolónk legfelső szintű könyvtárába.
ASCII naplózás elemzése
Itt rengeteg információ található meglehetősen sűrű formában, de az első dolog, amire érdemes figyelni, az az, hogy a fájl különálló sorokból áll. Ez világosan látható lesz, ha szélesebbre nyitod a megtekintő ablakot.
Minden sor a fájlban egy nyomvonal eseménynek felel meg. Ebben az esetben a továbbítási sorban nyomvonalazunk eseményeket, amelyek minden pont-pont hálózati eszközben jelen vannak a szimuláció során. A továbbítási sor az a sor, amelyen keresztül minden csomagnak át kell haladnia a pont-pont csatornán. Vedd észre, hogy minden sor a nyomvonal fájlban egyetlen karakterrel kezdődik (és egy szóköz követi azt). Ez a karakter a következő értéket fogja képviselni:
+: a készülék sorában egy sorba állítási művelet történt;
-: a készülék sorában egy elemet eltávolító művelet történt;
d: a csomag el lett dobva, jellemzően azért, mert a sor megtelt;
r: a csomag a hálózati eszköz által meg lett kapva.
Nézzük meg részletesebben a nyomvonal fájl első sorát. Felbontom darabokra (bejáratokkal a láthatóság kedvéért) és balra sorszámozva:
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)A bővített nyomvonal esemény első része (0. sor) egy művelet. Itt a + szimbólum van, ami a továbbításra várakozó sorba állítás műveletét jelenti. A második rész (1. sor) a szimuláció időzítése, másodpercekben kifejezve. Emlékezhetsz, hogy kérdeztük... UdpEchoClientApplication A csomagok küldése két másodpercen belül megkezdődik. Itt láthatjuk a megerősítést arról, hogy ez valóban megtörténik.
A nyomkövetési példa következő részében (a 2. sorból) látható, hogy melyik nyomkövetési forrás váltotta ki ezt az eseményt (a névtér is meg van adva). A névteret úgy képzelheti el, mint a fájlrendszer névterét. A névtér gyökere a NodeList. Ez a ns-3 fő kódjában kezelt tárolónak felel meg. Minden csomópont, amelyet a szkriptben létrehozunk, ebben található. Ahogyan a fájlrendszer gyökere is tartalmazhat könyvtárakat, úgy NodeList nekünk is lehet sok csomópontunk. Így a /NodeList/0 sor a NodeList nulladik csomópontjára utal, amelyet általában "0. csomópontként" értelmezünk. Minden csomópontban szerepel a telepített eszközök listája. Ez a lista a névtér következő részében található. Látja, hogy ez az esemény a DeviceList/0, amely a csomópontban található nulla eszköz.
A következő részszöveg, $ ns3 :: PointToPointNetDevice, megmondja, hogy melyik eszköz található a nulla pozícióban: a nulladik csomópont eszközlistájában. Emlékezzünk, hogy a 0. sorban lévő + művelet azt jelentette, hogy egy elem került hozzáadásra az eszköz átviteli sorába. Ez az utolsó szegmensek "nyomvonalának" visszatükröződik: TxQueue/Enqueue.
A nyomkövetés többi része elég intuitívan érthető kell, hogy legyen. A 3-4. sor azt jelzi, hogy a csomagot a pont-pont protokollba került beágyazva. Az 5-7. sorok azt mutatják, hogy a csomagnak IP4 verziójú fejlécük van, és felmerült az IP-címen 10.1.1.1 és szánták 10.1.1.2. A 8-9. sorok azt mutatják, hogy ez a csomag UDP fejlécet tartalmaz, és végül a 10. sor azt mutatja, hogy a hasznos teher várt 1024 bájt.
A nyomkövetési fájl következő sora azt mutatja, hogy ugyanazt a csomagot kivették 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 a csomópontban az echo szerverrel. Ezt az eseményt alább reprodukáltam.
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)Kérjük, 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 a kézikönyv utasításait, ez azt jelenti, hogy a hálózati eszközök DataRate értékét és a csatorna késleltetését az alapértelmezett értékeken hagyta. Ez az idő ismerős kell legyen, mivel már látta az előző szakaszban.
A nyomkövetési forrásnév-azonosító (2. sor) megváltozott, hogy tükrözze, hogy ez az esemény az 1. csomópontból származik (/NodeList/1) и пакет принят источником трассировки (/MacRx). Viszonylag könnyű nyomon követni a csomag forgalmát a topológia során a fennmaradó nyomok fájlban való megtekintésével.
5.3.2 PCAP Átviteli naplózás
Az ns-3 eszközsegédek szintén használhatók .pcap formátumú nyomkövetési fájlok létrehozására. Az akronim pcap általában kisbetűvel írva a csomagok rögzítését jelenti, és valójában egy API-t jelent, amely a .pcap fájlformátum definícióját tartalmazza. A legnépszerűbb program, amely képes olvasni és megjeleníteni ezt a formátumot, az Wireshark (korábban Ethereal). Azonban sok olyan nyomkövető elemző létezik, amely ezt a csomagformátumot használja. Javasoljuk a felhasználóknak, hogy használjanak több eszközt a pcap nyomok elemzéséhez. Ezen a útmutatón a pcap nyomok megtekintésére összpontosítunk a tcpdump.
A pcap nyomkövetés engedélyezése egy sor kód segítségével történik.
pointToPoint.EnablePcapAll ("myfirst");Illessze be ezt a kódot követő sort a már hozzáadott ASCII nyomkövetési kód után scratch/myfirst.cc. Kérjük, vegye figyelembe, hogy csupán a "myfirst" szót adtuk át, nem pedig a "myfirst.pcap"-ot vagy valami hasonlót. Ennek az az oka, hogy a paraméter egy előtag, nem pedig a fájl teljes neve. A szimuláció során a segédprogram valójában létrehoz egy nyomkövetési fájlt minden egyes pont-pont eszköz számára. A fájlnevek az előtag, a csomópont száma, az eszköz száma és a " suffix " felhasználásával épülnek fel.pcap».
A példa szkriptünk alapján végül az alábbi nevekkel rendelkező fájlokat fogunk látni: "myfirst-0-0.pcapés a "myfirst-1-0.pcap", amelyek a 0. csomópont 0. eszköze és az 1. csomópont 0. eszköze pcap nyomkövetései. Miután hozzáadtuk a pcap nyomkövetés engedélyezéséhez szükséges kódot, a szkriptet a szokásos módon futtathatja:
$ ./waf --run scratch/myfirstHa megnézi a disztribúciója legfelső szintű mappáját, három fájlt kell látnia: az ASCII nyomkövetési fájl myfirst.tr, amelyet korábban megtárgyaltunk, fájlok myfirst-0-0.pcap és myfirst-1-0.pcap — új pcap fájlok, amelyeket most generáltunk.
A kimenet olvasása tcpdump segítségével
Jelenleg a pcap fájlok megtekintéséhez a legjobb, ha tcpdump-ot használunk.
$ tcpdump -nn -tt -r myfirst-0-0.pcap
fájl olvasása: myfirst-0-0.pcap, linktípus PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, hossz 1024
2.514648 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, hossz 1024
tcpdump -nn -tt -r myfirst-1-0.pcap
fájl olvasása: myfirst-1-0.pcap, linktípus PPP (PPP)
2.257324 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, hossz 1024
2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, hossz 1024A dumpban myfirst-0-0.pcap (ügyféleszközön) látható, hogy az echo csomag 2 másodperces szimuláció után kerül elküldésre. Ha megnézi a második dumpot (myfirst-1-0.pcap), láthatja, hogy a csomag 2,257324 másodperckor érkezik. A második dumpban látható, hogy a csomag 2,257324 másodperckor kerül visszaküldésre, végül pedig, hogy a csomag 2,514648 másodperckor érkezik vissza az ügyfélnél az első dumpban.
A kimenet olvasása Wireshark segítségével
Ha nem ismeri a Wireshark, van egy webhely, ahonnan letöltheti a programokat és a dokumentációt: . Wireshark — ez egy grafikus felhasználói felület, amelyet használhat ezeknek a nyomkövetési fájloknak a megjelenítésére. Ha van Wireshark-ja, megnyithat bármelyik nyomkövetési fájlt, és megjelenítheti a tartalmát, mintha csomagokat fogott volna el egy csomag-analizáló használatával.
Forrás: habr.com
