Bachelor Informatica

Performance en diagnostiek mo-nitor voor heterogene ad hocnetwerken

Erik Landkroon

17 augustus 2016

Supervisor(s): Anthony van Inge

Signed: Anthony van Inge

Informatica—

Universiteit

vanAmst

erdam

2

Samenvatting

Ad hoc netwerk zijn zelf organiserende netwerken zonder centrale sturing. Het is nietnoodzakelijk dat alle nodes direct met elkaar verbonden zijn binnen een ad hoc netwerk,doordat er gecommuniceerd kan worden tussen de nodes door middel van (multi-)hopping.Een (heterogeen) ad hoc netwerk heeft verschillende karakteristieken die invloed hebben ophoe het netwerk zich gedraagt [8].

In deze scriptie is onderzocht of de karakteristieken van een heterogeen ad hoc netwerkte visualiseren zijn door middel van een monitor systeem. Deze karakteristieken moeten zoworden weergegeven dat deze interpreteerbaar zijn, waardoor het gedrag van het ad hocnetwerk geanalyseerd kan worden.

Hiervoor is onderzocht hoe de karakteristieken van het ad hoc netwerk en de individu-ele nodes gemeten kunnen worden. Tevens is er onderzocht hoe de verzamelde gegevensvan de individuele nodes en het ad hoc netwerk gevisualiseerd kunnen worden zodat dekarakteristieken van het ad hoc netwerk interpreteerbaar zijn. Er wordt gefocust op vijf ka-rakteristieken (structuur, in- en ouput, performance, CPU load en node status), aangeziendeze worden gezien als de vooraanstaande karakteristieken van het ad hoc netwerk.

Om de karakteristieken van het ad hoc netwerk en de individuele nodes te meten ente visualiseren wordt er gebruik gemaakt van twee processen, het monitor node proces(MNP) en het monitor visualisatie proces (MVP). Het MNP is een gedistribueerd procesdat geımplementeerd is op elke node in het netwerk. Dit proces verzamelt de informatie vande nodes en verstuurd deze telkens na een interval naar het MVP. Het MVP verwerkt envisualiseert de gegevens die verzameld zijn door het MNP. Het MNP en het MVP commu-niceren door middel van een communicatie laag.

Tevens is er gekeken of de visualisatie van de karakteristieken interpreteerbaar zijn zodater uitspraken gedaan kunnen worden over het gedrag. Dit is gedaan door middel van drieexperimenten. Het resultaat hiervan is dat zowel de data flow binnen het netwerk als dewerking van een gedistribueerd algoritme, dat wordt uitgevoerd binnen het ad hoc netwerk,afgeleid kunnen worden door middel van de visualisatie van de karakteristieken van het adhoc netwerk.

Bovendien is onderzocht wat de invloed van een dergelijk monitor systeem is op deperformance van de nodes en dus het gehele ad hoc netwerk. Hiervoor is de overheadgemeten dat het monitor systeem veroorzaakt op de performance van de nodes en dus hetgehele ad hoc netwerk. Dit is gemeten voor netwerken met verschillende aantallen nodes.Het resultaat hiervan is dat het monitor systeem voor een overhead zorgt tussen de 15.5 en17.2 procent ongeacht het aantal nodes binnen het ad hoc netwerk.

3

4

Inhoudsopgave

1 Introductie 7

2 Gerelateerd werk 92.1 ViTAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 INSpect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 VIVAGr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 ViSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Vergelijking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Specificaties van de monitor 13

4 Implementatie 154.1 Communicatie protocols (TCP en UDP) . . . . . . . . . . . . . . . . . . . . . . . 154.2 Test platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.1 Communicatie (test platform) . . . . . . . . . . . . . . . . . . . . . . . . . 174.2.2 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2.3 Netwerk discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3 Monitor systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.1 Monitor node proces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.2 Communicatie (monitor systeem) . . . . . . . . . . . . . . . . . . . . . . . 214.3.3 Monitor visualisatie proces (MVP) . . . . . . . . . . . . . . . . . . . . . . 224.3.4 Grafisch user interface(GUI) . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Experimenten 295.1 Visualisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.1 Experiment 1: Pakket-tracing(IO) . . . . . . . . . . . . . . . . . . . . . . 295.1.2 Experiment 2: Performance en IO . . . . . . . . . . . . . . . . . . . . . . 305.1.3 Experiment 3: Wave equation . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2 Invloed op de performance van het netwerk . . . . . . . . . . . . . . . . . . . . . 34

6 Future work 376.1 Invloed overige karakteristieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2 Invloed overige schaalbaarheidsfactoren . . . . . . . . . . . . . . . . . . . . . . . 37

7 Conclusie 39

A Lijst van meetbare gegevens 41

5

6

HOOFDSTUK 1

Introductie

Draadloze netwerken worden steeds belangrijker. Tegenwoordig beschikken de meeste apparatenzoals laptops en mobiele telefoons over de technologie om draadloos te kunnen communiceren. Aldeze apparaten zouden gebruikt kunnen worden als nodes binnen een (mobile) ad hoc netwerk.

Ad hoc netwerken zijn zelf organiserende netwerken en worden voor verschillende toepassin-gen gebruikt [5] [8]. Een ad hoc netwerk kan bijvoorbeeld worden gebruikt om gedistribueerdealgoritmes uit te voeren. Ook kan het bijvoorbeeld worden gebruikt om gegevens te verzamelen(sensor ad hoc netwerken). Een ander voorbeeld is het verzamelen van gegevens van voertuigenom zo een infrastructuur beter in kaart te brengen (vehicular ad hoc netwerken) [1].

Een van de eigenschappen van een ad hoc netwerk is dat ze geen centrale sturing hebben endat het netwerk constant kan veranderen [8]. Dit zou kunnen komen doordat nodes verplaatsenbinnen het netwerk, of dat nodes zich toevoegen aan het netwerk of het netwerk verlaten. Bo-vendien hoeven nodes niet direct met elkaar verbonden te zijn om met elkaar te communiceren(zie figuur 1.1). Er kan dan door middel van (multi-) hopping data worden verstuurd tussen denodes.

Het doel van deze scriptie is om te onderzoeken of de karakteristieken van een heterogeenad hoc netwerk te visualiseren zijn door middel van een monitor systeem. Deze karakteristiekenmoeten zo worden weergegeven dat deze interpreteerbaar zijn, waardoor het gedrag van het adhoc netwerk geanalyseerd kan worden.

Hiervoor moet worden onderzocht hoe de karakteristieken van het ad hoc netwerk en deindividuele nodes gemeten kunnen worden. Tevens moet er worden onderzocht hoe de verzameldegegevens van de individuele nodes en het ad hoc netwerk gevisualiseerd kunnen worden zodatdeze interpreteerbaar zijn. Daarnaast moet worden onderzocht wat de invloed van een dergelijkmonitor systeem is op de performance van de nodes en dus het gehele ad hoc netwerk.

Een (heterogeen) ad hoc netwerk heeft verschillende karakteristieken die invloed hebben ophoe het netwerk zich gedraagt [8]. In deze scriptie wordt er gefocust op de volgende vijf karak-teristieken: structuur, in- en ouput, performance, CPU load en node status.

• De structuur van het netwerk heeft invloed op het gedrag van het ad hoc netwerk doordatbijvoorbeeld een ’fully connected network’ meestal het aantal hops wat nodig is om eenpakket tussen twee nodes te versturen verlaagt. Terwijl in een ’sparsely connected network’er meestal meer hops nodig zijn om een pakket tussen twee nodes te versturen. Dit heeftinvloed op bijvoorbeeld de overdrachtssnelheid van pakketten binnen het netwerk.

• De in- en output van het ad hoc netwerk heeft invloed op het gedrag doordat als eenverbinding wordt overbelast met in- en output, dit er voor kan zorgen dat pakketten erlanger over doen om de bestemming te bereiken.

• De performance van de nodes hebben invloed op het gedrag doordat bijvoorbeeld bij hetuitvoeren van bijvoorbeeld een gedistribueerd algoritme, waarin berekeningen worden ge-daan, de performance van de nodes een rol speelt. In het geval dat er een of meerderenodes in het netwerk zitten die een lagere performance hebben dan de andere nodes, kandit de performance van het volledige netwerk verminderen.

7

Figuur 1.1: Voorbeeld van de structuur van een ad hoc netwerk

• De CPU load van een node heeft invloed op het gedrag doordat als bijvoorbeeld een nodewordt overbelast met taken, kan dat de performance van die node en dus het gehele ad hocnetwerk negatief beınvloeden.

• De status van een node heeft invloed op het gedrag doordat als een node bijvoorbeelduitvalt, kan deze geen taken meer uitvoeren en heeft dat invloed op het ad hoc netwerk.

8

HOOFDSTUK 2

Gerelateerd werk

Voor het monitoren van de karakteristieken van ad hoc netwerk bestaan al enkele monitor sys-temen. Voor het onderzoek worden vier bestaande monitor systemen namelijk ViTAN, INSpect,VIVAGr en ViSim met elkaar vergeleken.

2.1 ViTAN

ViTAN is een tool om connectiviteit en de verbindings kwaliteit te visualiseren tussen nodes in adhoc netwerken [7]. ViTAN gebruikt de locatie (gespecificeerd door de Cartesiaanse coordinaten)en de verbindings kwaliteit tussen de nodes als input. ViTAN meet niet zelf de connectiviteit enverbindings kwaliteit van het ad hoc netwerk, maar gebruikt de verzamelde gegevens van anderetools of simulaties. Om de gegevens uit te wisselen wordt een communicatie interface gebruikt.Dit zorgt er voor dat ViTAN gebruikt kan worden door een wijde selectie van applicaties. ViTANis getest op een link-level simulatie voor IEEE802.11a van de University of Ferrara [7].

ViTAN maakt van de connectiviteit en verbindings kwaliteit van de nodes een netwerk graaf.Deze graaf kan gebruikt worden om het netwerk te analyseren. Door middel van de breedte vande lijn die getekend wordt voor de verbinding tussen twee nodes in de graaf, wordt er in de graafaangegeven wat de kwaliteit van een verbinding is. Ook wordt er gebruik gemaakt van kleurenom het bereik van de nodes weer te geven. ViTAN is ook in staat om een energieconsumptieplot te maken.

Het doel van ViTAN is om op een simpele manier de netwerk graaf te visualiseren van hetad hoc netwerk, zodat de structuur van het netwerk geanalyseerd kan worden [7]. ViTAN geeftechter niets weer over de andere karakteristieken van het netwerk zoals IO en performance.

2.2 INSpect

INSpect maakt gebruik van de network simulator 2 (NS-2) [9]. NS-2 is een populaire en krachtigetool voor het simuleren van netwerken [6] [9]. Ondanks dat NS-2 origineel was bedoeld voor hetsimuleren van bedrade netwerken, is het uitgebreid zodat het ook ondersteuning biedt voordraadloze netwerken, inclusief mobile ad hoc networks (MANET).

INSpect is een tool om NS-2 simulaties van draadloze netwerken te visualiseren, door middelvan de trace-files van de NS-2 simulatie. INSpect gebruikt de locaties van de nodes (gespecificeerddoor de Cartesiaanse coordinaten) om een netwerk graaf te maken. In deze netwerk graaf is ookde beweging te zien van de nodes gedurende de simulatie.

In de netwerk graaf wordt echter niet de links tussen de nodes weergegeven, aangezien desimulatie er vanuit gaat dat deze verbonden is met alle nodes die in range zijn. In plaats daarvan geeft INSpect de overdracht van data weer binnen het netwerk. Dit wordt gedaan door eenlink te maken tussen nodes waar tussen data is verstuurd. Hierdoor geeft INSpect duidelijk weerwat de route is die een data pakket heeft afgelegd.

9

INSpect geeft voornamelijk de data overdracht weer binnen een ad hoc netwerk en kan hier-door goed gebruikt worden voor het analyseren van routing protocollen binnen ad hoc netwerken[9].

2.3 VIVAGr

In een vehicular ad hoc network(VANET) is er communicatie tussen voertuigen onderling en tus-sen voertuigen en infrastructuur. VANETs kunnen gebruik worden om informatie te verzamelenover infrastructuren en het gedrag van de voertuigen binnen deze infrastructuren. VIVAGr iseen real time visualisatie tool voor vehicular ad hoc networks(VANET). VIVAGr kan gebruiktworden om antwoorden te kunnen geven op meerdere kernvragen over de vorm en het gedragvan VANETs [14].

VIVAGr is een grafisch georienteerde tool die het mogelijk maakt om de karakteristiekenvan VANETs te analyseren. Dit wordt gedaan door het importeren van trace-files die wordengegenereerd door de nodes in het netwerk. Deze trace files bevatten informatie over de nodes enhet netwerk op een gegeven moment. Daarnaast worden omgeving parameters zoals draadloosbereik, topologie, penetratie ratio, signaal verspreiding, mobiliteit modellen, ervaren interferentieen road-maps gebruikt. Van al deze gegevens wordt een real-time network graaf gemaakt diede mobiliteit patronen van de voertuigen laat zien binnen een omgeving. VIVAGr kan hierdoorvisualiseren hoe topologie karakteristieken van VANETs veranderen over tijd bij verschillendemobiliteit patronen [14]. Deze visualisatie kan vervolgens gebruikt worden om het VANET teanalyseren.

2.4 ViSim

ViSim is net als INSpect een tool om NS-2 simulaties van mobile ad hoc networks(MANET)te visualiseren door middel van de trace-files van de NS-2 simulatie [13] [6]. ViSim gebruikt delocatie en het bereik van de nodes om een netwerk graaf weer te geven. In de netwerk graafwordt door middel van een cirkel aangegeven wat het bereik is van een node. Hierdoor kan ergezien worden welke nodes er binnen bereik zijn van elkaar en dus een connectie tussen gemaaktkan worden. ViSim geeft verder informatie weer over de throughput, goodput en routing loadvan de simulatie. Ook kan er een plot worden weergegeven van de throughput over tijd.

ViSim is bedoelt om routing protocols van ad hoc netwerken te simuleren en analyseren [13].Ook biedt het de mogelijkheid om routing protocols onderling te vergelijken.

2.5 Vergelijking

In tabel 2.1 is een overzicht te zien van de vergelijking van de bovenstaande tools. Zoals tezien is focussen deze tools voornamelijk op de structuur van het netwerk. INSpect en ViSimmaken beide gebruikt van NS-2 simulaties en bieden geen ondersteuning om werkelijke ad hocnetwerken te visualiseren. ViSim en INSpect zijn daarnaast ook voornamelijk gefocust om routingprotocollen te analyseren en te vergelijken waardoor ook de in- en output van het netwerk wordtgemeten. VIVAGr is een tool die speciaal gemaakt is voor vehicular ad hoc netwerken en kanhierdoor niet geımplementeerd worden op bijvoorbeeld een MANET. ViTAN daarentegen biedtwel ondersteuning om data te gebruiken van werkelijke ad hoc netwerken, doordat deze niet zelfde metingen doet, maar de informatie over de nodes van andere tools kan ontvangen via eencommunicatie interface. Deze tool geeft echter alleen een visualisatie weer van de structuur vanhet netwerk. Verder geeft geen van deze tools informatie over de performance, CPU load enstatus van de nodes. Geen van de bovengenoemde tools visualiseert zowel de structuur, in- enoutput, performance en CPU load.

10

Tabel 2.1: Vergelijking toolsNetwerk type Structuur In- en output Performance CPU load

ViTANSimulatie en Ad Hoc(MANET, VANETen sensor netwerk)

Ja Nee Nee Nee

INSpect Simulatie Ja Ja Nee NeeVIVAGr VANET Ja Nee Nee NeeViSim Simulatie Ja Ja Nee Nee

11

12

HOOFDSTUK 3

Specificaties van de monitor

Zoals aangegeven wordt er in deze scriptie gefocust op de structuur, in- en output, performance,CPU load en node status van het het ad hoc netwerk. Om deze karakteristieken te kunnenvisualiseren moet er eerst informatie over deze karakteristieken worden verzameld. Deze gegevenskunnen worden verzameld door metingen te doen op de nodes binnen het netwerk. Deze metingenkunnen worden gedaan door middel van een proces. Vervolgens moeten de gemeten gegevensworden samengebracht zodat deze verwerkt en gevisualiseerd kunnen worden tot een visualisatievan het gehele netwerk. Dit betekent dat de nodes de gemeten gegevens moeten versturen naareen proces die de verwerking en visualisatie doet.

Om bovenstaande goed te kunnen ondersteunen is gekozen om een modulair monitor systeemte implementeren. Dit monitor systeem bestaat uit twee delen, een monitor node proces(MNP) eneen monitor visualisatie proces(MVP). Om de communicatie tussen deze twee soorten processenmogelijk te maken, is een aparte communicatie laag nodig. Deze communicatie laag staat los vande communicatie laag van het ad hoc netwerk en zal alleen worden gebruikt om te communicerentussen de monitor processen. Het is hierdoor noodzakelijk dat elke node in het bereik is van hetmonitor visualisatie proces, zodat het monitor node proces van de node kan communiceren methet monitor visualisatie proces.

Het monitor node proces is een gedistribueerd proces dat op elke node binnen het netwerkgeımplementeerd moet worden. Dit proces verzameld de gegevens over de structuur, in- enoutput, performance, CPU load, status en taak van de node. Een taak binnen het ad hocnetwerk is een taak die door het gehele netwerk wordt uitgevoerd, iedere node voert vervolgenseen deel van deze taak uit. Een taak kan bijvoorbeeld een gedistribueerd algoritme zijn. Degegevens worden gemeten en vervolgens verstuurt naar het monitor visualisatie proces op eeninterval (zie sectie 4.3.1). In bijlage A is de lijst met gegevens te zien die door het monitor nodeproces gemeten worden.

Het monitor visualisatie proces ontvangt de informatie van de monitor node processen enverwerkt deze. Bij het verwerken worden alle metingen van de nodes samengevoegd zodat ereen compleet overzicht ontstaat over de structuur, in- en output, performance, CPU load enstatus van het netwerk. Vervolgens wordt hiervan een visualisatie. Op deze visualisatie moeteen graaf zichtbaar zijn waarin de structuur en data flow van het netwerk en de statussen van denodes zichtbaar is. Daarnaast moeten er een grafiek over tijd van de performance en een grafiekover tijd van de in- en output van de nodes zichtbaar zijn. Ook moet er informatie wordenweergegeven over de taak van het ad hoc netwerk.

13

14

HOOFDSTUK 4

Implementatie

Voor de ontwikkeling van het monitor systeem is een test platform nodig. Dit test platform zalgebruikt worden om het monitor systeem op te ontwikkelen en om experimenten op de monitoruit te voeren. Het test platform is een ad hoc netwerk dat beschikt over een communicatie,routing en netwerk discovery protocol. Om experimenten op de monitor uit te kunnen voerenmoet het ook mogelijk zijn om gedistribueerde algoritmes op het test platform te implementeren.Het test platform bestaat dus feitelijk uit een combinatie van hardware en software.

Het monitor systeem en het test platform hebben allebei een communicatie laag nodig. Ditzijn twee verschillende communicatie lagen en staan los van elkaar (zie figuur 4.1). De communi-catie laag van het test platform wordt namelijk gebruikt om te communiceren tussen de processenvan een gedistribueerde taak. Terwijl de communicatie laag van het monitor systeem gebruiktwordt om te communiceren tussen de monitor node processen en het monitor visualisatie proces.

4.1 Communicatie protocols (TCP en UDP)

Het test platform en het monitor systeem hebben beide een communicatie laag. Beide com-municatie lagen hebben communicatie protocollen nodig, om pakketten te versturen over decommunicatie lagen. Voor de communicatie protocollen van de communicatie lagen kan hetTCP of het UDP protocol worden gebruikt [11] [12].

Het TCP protocol zorgt voor error vrije data overdracht[11]. Dit houd in dat er wordtgezorgd dat alle pakketten volledig aankomen bij de ontvanger. Voor ieder pakket dat wordtontvangen door de client of server wordt een acknowledgement (ACK) pakket teruggestuurd omte bevestigen dat het pakket is ontvangen. Als na het sturen van een pakket geen ACK pakketwordt ontvangen, weet de verzender dat het pakket niet of beschadigt is aangekomen en dusopnieuw gestuurd moet worden.

Bij het maken van een TCP verbinding tussen de client en server, moet als eerste een ver-binding worden geınitialiseerd. Dit wordt gedaan door vanaf de client een SYN pakket te sturennaar de server. Vervolgens stuurt de server een SYN-ACK pakket terug naar de client. Alslaatste bevestigt de client dit pakket te hebben ontvangen door nog een ACK pakket terug testuren naar de server. Het SYN pakket zorgt ervoor dat de ’sequence’ (SEQ) nummers wordengesynchroniseerd tussen de client en de server. Het SEQ nummer is een identificatie nummer vanhet pakket, voor ieder pakket dat wordt verstuurd wordt het SEQ nummer met een verhoogt.Het SEQ nummer is nodig om in het ACK pakket aan te geven welk pakket is ontvangen enom een beschadigt of verloren pakket opnieuw op te kunnen vragen. Na het initialiseren van deverbinding kunnen de data pakketten worden verstuurd. Voor ieder data pakket dat wordt ont-vangen, wordt ook de ’checksum’ van het pakket gecontroleerd. Als hier een fout in zit wordt hetdata pakket opnieuw opgevraagd. Als alle data is verstuurd wordt de TCP verbinding verbrokentussen de client en server. Dit wordt gedaan door een FIN pakket te sturen.

Bij een UDP verbinding hoeft er niet eerst een connectie te worden geınitialiseerd tussen declient en de server. In plaats daarvan stuurt de client direct het data pakket naar de server.

15

Figuur 4.1: Ad hoc netwerk met monitor systeem. De zwarte hele pijlen tussen de nodes zijnde communicatie tussen de nodes onderling (Bluetooth). De oranje gestippelde pijlen zijn decommunicatie tussen de monitor node processen en het monitor visualisatie proces (WiFi).

Er wordt niet gecontroleerd of het verstuurde data pakket is aangekomen bij de server. Als eendata pakket is aangekomen bij de server wordt de ’checksum’ van het pakket gecontroleerd. Hetpakket wordt echter niet opnieuw aangevraagd als hier een fout in zit.

Het voordeel van een TCP verbinding is dat er garantie wordt gegeven dat alle pakketten(in de juiste volgorde) aankomen bij de server. Het nadeel is echter dat het initialiseren van deverbinding en het opnieuw sturen van verdwenen of beschadigde pakketten voor overhead zorgt.Bij een UDP verbinding wordt deze garantie niet gegeven, pakketten kunnen in een anderevolgorde of zelfs helemaal niet aan komen. Daar in tegen hoeft er bij een UDP verbinding nieteerst een connectie te worden geınitialiseerd of pakketten opnieuw te worden verstuurd. Dit zorgter voor dat een UDP verbinding sneller is dan een TCP verbinding.

In sectie 4.2.1 wordt beschreven welk communicatie protocol gebruikt wordt voor de commu-nicatie tussen de nodes in het test platform. In sectie 4.3.2 wordt beschreven welk communicatieprotocol gebruikt wordt om te communiceren tussen het monitor node proces en het monitorvisualisatie proces van het monitor systeem.

4.2 Test platform

Om het monitor systeem te ontwikkelen is een test platform nodig. Dit test platform moetgebruikt kunnen worden om experimenten uit te voeren op het ad hoc netwerk. Het test platformis een ad hoc netwerk waar gedistribueerde algoritmes op uitgevoerd kunnen worden. Door dezegedistribueerde algoritmes uit te voeren kan er worden onderzocht of de karakteristieken van hetnetwerk interpreteerbaar zijn op de grafisch user interface van de monitor.

Om een gedistribueerd algoritme uit te kunnen voeren op een ad hoc netwerk moet het netwerkbeschikken over een communicatie laag en een routing protocol, zodat er gecommuniceerd kanworden tussen de nodes in het netwerk. Ook moeten de nodes weten hoeveel nodes er in hetnetwerk zitten en wat hiervan de adressen zijn. Hiervoor wordt een netwerk discovery protocolgebruikt.

Voor het test platform wordt een mobile ad hoc netwerk (MANET) gebruikt. Dit netwerkzal worden geımplementeerd door middel van het Android platform.

16

Figuur 4.2: DSR: een route-request pakket wordt vanaf A verstuurd om de route naar F op tevragen

4.2.1 Communicatie (test platform)

Zoals aangegeven is er een communicatie laag nodig om te communiceren tussen de nodes on-derling. Voor het test platform wordt gebruik gemaakt van Android devices, deze beschikken(vrijwel) allemaal over WiFi en Bluetooth. De ondersteuning binnen het Android platform voormeerdere concurrent connecties is uitgebreider voor Bluetooth dan voor WiFi. Om deze redenis dan ook Bluetooth gekozen als communicatie laag voor het ad hoc netwerk omdat concurrentconnecties een essentieel onderdeel zijn voor een ad hoc netwerk.

Om pakketten te versturen tussen de nodes over de communicatie laag is een communicatieprotocol nodig. Hierbij is het belangrijk dat alle pakketten aankomen bij de ontvanger. Voorhet communicatie protocol kan TCP of UDP worden gebruikt. Zoals aangegeven in sectie 4.1zorgt het TCP protocol voor een error vrije data overdracht. Het UDP protocol biedt niet dezegarantie. Hierom wordt voor de communicatie tussen de nodes het TCP protocol gebruikt.

4.2.2 Routing

Om data te kunnen versturen tussen nodes binnen het ad hoc netwerk is het soms nodig om dezedata via een of meerdere hops naar de bestemming te sturen. Dit komt dan omdat de node nietdirect verbonden is met de node waarnaar het pakket verstuurd moet worden. Om het pakketvia (multi-) hopping naar de bestemming te sturen moet er een route worden bepaald waaroverhet pakket wordt gestuurd. Om deze route te bepalen is er een routing algoritme nodig. Eenrouting algoritme bepaald de route die een pakket neemt.

In het test ad hoc netwerk wordt er gebruik gemaakt van het direct source routing(DSR)algoritme [2]. Dit algoritme stuurt eerst door middel van een broadcast een route-request pakketnaar de nodes. Bij een broadcast stuurt een node het pakket naar alle nodes waarmee dezeverbonden is, vervolgens sturen deze nodes het pakket ook door naar alle nodes waarmee zeverbonden zijn. Als een node het pakket voor de tweede keer ontvangt, dan verstuurd deze hetpakket niet nog een keer. In de pakketten wordt bijgehouden welke route ze hebben afgelegd.In figuur 4.2, is te zien hoe node ’A’ een route-request stuurt naar node ’F’ door middel vaneen broadcast. Als node ’F’ het pakket heeft ontvangen, stuurt deze via dezelfde route die hetpakket heeft afgelegd, een reply-pakket terug naar node ’A’ (zie figuur 4.3). Als node ’A’, hetreply-pakket binnen krijgt, slaat deze de route die het pakket heeft genomen op. Vervolgens alsnode ’A’ een data pakket wilt versturen naar node ’F’, voegt deze de route toe aan het datapakket(zie figuur 4.4). Als een data pakket wordt verstuurd naar een node, maar de route die ismeegegeven niet meer klopt, wordt er een error-pakket teruggestuurd naar de node. Vervolgensstuurt de node dan opnieuw een route-request pakket om de nieuwe route te verkrijgen.

17

Figuur 4.3: DSR: een reply-pakket wordt vanaf F naar A verstuurd via de route die het route-request pakket heeft afgelegd

Figuur 4.4: DSR: een data pakket wordt vanaf A naar F verstuurd via de route die A heeftopgeslagen

18

4.2.3 Netwerk discovery

Een node binnen het ad hoc netwerk weet standaard alleen met welke nodes die direct verbondenis. De node weet niet hoeveel nodes er totaal in het netwerk zitten en wat de adressen zijn vandeze nodes. Om deze informatie beschikbaar te maken voor de nodes wordt het neighbourhooddiscovery protocol (NHDP) gebruikt. Het neighbourhood discovery protocol zorgt er voor datnodes weten welke nodes er nog meer in het netwerk zitten [4].

Iedere node in het netwerk stuurt een periodiek HELLO-pakket naar alle nodes waarmee dezedirect is verbonden. Dit pakket bevat alle nodes waarvan de node het bestaan af weet. Als eennode een HELLO-pakket ontvangt, voegt de node de nog niet bekende nodes toe aan de lijst vanbestaande nodes.

4.3 Monitor systeem

De monitor bestaat uit twee delen, een monitor node proces en een monitor visualisatie proces (ziefiguur 4.1). Het monitor node proces is een gedistribueerd proces wat wordt geımplementeerdop elke node in het netwerk. Dit proces is verantwoordelijk voor het verzamelen en metenvan de gegevens van de nodes. Omdat het monitor node proces op elke node in het netwerkgeımplementeerd moet worden, zou het kunnen dat deze moet worden aangepast, zodat dezecompatibel is met het besturingssysteem van de node.

Het monitor visualisatie proces verwerkt en visualiseert de gegevens die verzameld zijn doorde monitor node processen. Het monitor visualisatie proces heeft drie taken, het ontvangenvan de node informatie pakketten, het verwerken van de node informatie pakketten naar eennetwerk informatie object en het visualiseren van het netwerk informatie object op een grafischuser interface.

Het monitor node proces en het monitor visualisatie proces communiceren onderling via eencommunicatie laag. Deze communicatie laag wordt gebruikt om data te versturen tussen deprocessen. Dit is een andere communicatie laag dan de communicatie laag van het test platform.

Zoals eerder aangegeven is het noodzakelijk dat alle monitor node processen direct verbondenzijn met het monitor visualisatie proces. Dit zorgt er voor dat het bereik van de communicatielaag de maximale afstand bepaald tussen een node en het monitor visualisatie proces. Hieromis er gekozen om voor de communicatie laag van het monitor systeem WiFi te gebruiken. Wifiwordt net als Bluetooth door de (meeste) Android telefoons ondersteund, daarnaast heeft WiFieen groter bereik dan Bluetooth.

4.3.1 Monitor node proces

Bij het uitvoeren van een meting verzamelt het monitor node proces de gegevens van de node envoegt deze toe aan een node informatie pakket. De gegevens over de verbindingen, de status, hetproces en de taak kunnen verkregen worden door deze op te vragen aan de node. De gegevensover de performance, CPU load en in- en output op het tijdstip van de meting moet wordenberekend door het monitor node proces.

Het aantal bytes wat een node heeft verstuurd kan worden berekend door het totaal aantalverstuurde bytes op twee tijdstippen te meten. Het verschil tussen het aantal verstuurde bytestussen deze twee tijdstippen is het aantal bytes wat over deze periode is gestuurd. Door ditaantal te delen door het verschil in secondes tussen de twee metingen kan het aantal bytesdat is verstuurd per seconden worden berekend. Hetzelfde kan worden gedaan voor het aantalontvangen bytes. Door het aantal ontvangen en verstuurde bytes per seconden bij elkaar op tetellen kan het totaal aantal bytes per seconden worden berekend die door de in- en output vaneen node is verwerkt.

Om de data flow weer te kunnen geven binnen het netwerk moet er voor iedere verbindingtussen de nodes worden bijgehouden hoeveel data er verstuurd is. Hierbij is het belangrijk datook de richting van verstuurde data wordt bijgehouden. Het is tevens mogelijk dat er beiderichtingen tegelijk data wordt verstuurd, hierdoor is het noodzakelijk om voor beide richtingenapart bij te houden hoeveel data er is verstuurd.

19

Figuur 4.5: Performance grafiek van het aantal duizend ’clock cycles’per seconden wat de CPUis bezig geweest met het uitvoeren van de applicatie.

Figuur 4.6: Performance grafiek van een node gemeten door middel van de relatieve performancemeet methode.

De performance van de node kan op twee manieren worden berekend. De eerste methode isdoor te berekenen hoeveel ’clock cycles’ per seconden de CPU van een node heeft besteed aanhet uitvoeren van de applicatie in een bepaalde tijdsperiode. Het nadeel hiervan is dat niet alleenhet aantal ’clock cycles’ wordt meegerekend dat de CPU bezig was met het algoritme, maar ookhet aantal ’clock cycles’ wat de CPU bezig was met het versturen en ontvangen van data en hetin stand houden van het ad hoc netwerk. Dit zorgt ervoor dat er ruis ontstaat in de performancemeting. De performance grafiek die ontstaat door deze methode is te zien in figuur 4.5, hierin ishet aantal duizend ’clock cycles’ per seconden weergegeven.

De tweede manier is het berekenen van de relatieve performance van het algoritme dat wordtuitgevoerd op een nodes. Deze performance wordt gemeten door bij te houden hoe vaak eenbepaalde operatie van een algoritme wordt uitgevoerd. Een voordeel hiervan is dat er geenruis ontstaat door de in- en output en het in standhouden van het netwerk, maar alleen deperformance van de node t.a.v. het algoritme wordt weergegeven. De performance grafiek dieontstaat door deze methode is te zien in figuur 4.6. Het nadeel is dat deze methode niet op allealgoritmes kan worden geımplementeerd, maar alleen op algoritmes die een herhalende operatiehebben.

Zoals te zien is zijn de grafieken van de twee methodes ongeveer hetzelfde. Op het tijdstip22:06:50 wordt bij de tweede methode de performance 0, omdat de node bezig is met in- enoutput. Bij de eerste methode wordt op het tijdstip 22:06:50 de performance niet 0, aangeziendeze methode ook het aantal ’clock cycles’ per seconden laat zien die de CPU bezig is met in-en output.

Om de CPU load te berekenen van de node wordt er net als de eerste methode van het metenvan de performance gekeken naar het aantal ’clock cycles’ wat de CPU bezig is met het uitvoerenvan de applicatie. Dit moet vervolgens gedeeld worden door het totaal aan ’clock cycles’ wat deCPU maximaal kan besteden. Het resultaat van deze deling is het percentage dat de applicatiegebruikt van de CPU van de node.

20

Net als de in- en output worden de performance en CPU load gemeten over een interval. Deformule die hiervoor wordt gebruikt is formule 4.1. De variabelen t1 en t2 zijn de tijdstippenin secondes van de metingen, waardet1 en waardet2 zijn de waardes op de tijdstippen. Eerstwordt het verschil in waarde berekent tussen de tijdstippen. Vervolgens wordt dit gedeeld doorhet verschil in tijd.

waarde∆

∆t=

waardet2 − waardet1t2 − t1

(4.1)

Als alle gegevens gemeten zijn door het monitor node proces en deze zijn toegevoegd aan eennode informatie pakket, wordt er een time-stamp toegevoegd aan het node informatie pakket.De time-stamp geeft het tijdstip aan wanneer de meting gedaan is. Vervolgens wordt het nodeinformatie pakket over de communicatie laag naar het monitor visualisatie pakket gestuurd. Demetingen worden periodiek gedaan door het monitor node proces.

De grote van het interval van de metingen heeft invloed op de precisie van de grafiekenen de overhead op de nodes. De overhead op de node en het monitor systeem wordt groterbij een kleiner interval doordat er meer metingen per seconden worden gedaan en verstuurdworden. Hierdoor geldt hoe kleiner het interval, hoe gedetailleerder de grafieken en hoe hogerde overhead op de node en het monitor systeem. Ook is de interval grootte afhankelijk vande taak die geımplementeerd is. Dit komt doordat het per taak kan verschillen wat de precisievan de metingen moeten zijn om een uitspraak te kunnen doen over de visualisatie van het adhoc netwerk en de daarop geımplementeerde taak. Bij het kiezen van een interval grootte moeter dus een afweging worden gemaakt tussen precisie en performance, dit kan het beste wordengedaan door ’trial-and-error’. Voor de interval grootte die wordt gebruikt voor experimenten isgekeken naar intervallen met een grootte van 100, 200, 500 en 1000 milliseconden. De intervalgrootte van 500 milliseconden gaf de beste visualisatie van de geteste intervallen en is daaromook gebruikt voor de experimenten.

4.3.2 Communicatie (monitor systeem)

Omdat het belangrijker is dat node informatie pakketten zo snel mogelijk aankomen bij hetmonitor visualisatie proces, dan dat alle node informatie pakketten aankomen, wordt het UDPprotocol gebruikt om de node informatie te versturen. Doordat het sturen van node informatiepakketten door het UDP protocol sneller is dan het TCP protocol, kunnen de node informatiepakketten ook op een kleiner interval worden gestuurd.

Bij het maken van de node informatie pakketten wordt een time-stamp toegevoegd die de tijdaangeeft wanneer de meting is gedaan. Deze time-stamp is nodig voor het monitor visualisatieproces om de node informatie op het juiste tijdstip te visualiseren (zie sectie 4.3.3). Het probleemis echter dat de tijd van het monitor visualisatie proces en die van de nodes niet synchroonloopt. Dit kan een paar milliseconden zijn, maar kan ook enkele seconden tot minuten zijn.Hierdoor kan het monitor visualisatie proces de metingen van de nodes op een bepaald tijdstipniet combineren tot een netwerk informatie object van een bepaald tijdstip, doordat de time-stamps van de metingen van elkaar verschillen.

Er moet dus voor worden gezorgd dat de tijd van het monitor visualisatie proces en dievan de nodes synchroon lopen. Hiervoor kan het Precision Time Protocol (PTP) [10] gebruiktworden. Het Precision Time Protocol is een protocol om de tijd tussen twee nodes/apparaten tesynchroniseren. Zoals te zien is in figuur 4.7, stuurt apparaat ’A’ een pakket met daarin de tijddat dit pakket is verstuurd, dit is T1. Apparaat ’B’ ontvangt vervolgens dit pakket en onthoudde tijd waarop deze het pakket heeft ontvangen, dit is T ′1. Vervolgens stuurt apparaat ’B’ naarapparaat ’A’ een pakket met daarin T1 en T ′1, en voegt hieraan de tijd toe dat dit pakket wordtverstuurd, dit is T2. Vervolgens ontvangt apparaat ’A’ dit pakket en slaat de tijd dat dit pakketwas ontvangen op, dit is T ′2. Nu kan apparaat ’A’ de tijd offset berekenen wat apparaat ’A’ en’B’ van elkaar verschillen met de formule uit 4.2.

offset =T ′1 − T1 − T ′2 + T2

2(4.2)

Doordat het bij het Precision Time Protocol belangrijk is dat alle pakketten aankomen, wordthiervoor een nieuw kanaal (naast het UDP kanaal voor de node informatie pakketten) geopend

21

Figuur 4.7: Precision Time Protocol(PTP): Synchronisatie mechanisme

tussen de node en het monitor visualisatie proces. Dit kanaal gebruikt het TCP protocol, zodater wordt gecontroleerd of alle pakketten aankomen. Dit kanaal wordt vervolgens weer geslotenals de synchronisatie voltooid is, omdat de synchronisatie maar een keer per node gedaan hoeftte worden.

4.3.3 Monitor visualisatie proces (MVP)

Het Monitor visualisatie proces (MVP) is verantwoordelijk voor het ontvangen van de node in-formatie pakketten van de monitor node processen(MNP) en deze te verwerken zodat er eenoverzicht kan worden gemaakt van het volledige netwerk (netwerk informatie object). Het mo-nitor visualisatie proces moet twee server sockets hebben, een UDP (voor de node informatiepakketten) en TCP (voor de tijd synchronisatie). Ook moet het monitor visualisatie proces buf-fers kunnen aanmaken voor het bufferen van de node informatie pakketten. Verder moet er eenhttp web server aanwezig zijn om het grafisch user interface te kunnen weergeven (zie sectie 4.3.4).Python biedt ondersteuning voor al deze eisen. Ook is python besturingssysteem onafhankelijk,waardoor het monitor visualisatie proces op verschillende besturingssystemen geımplementeerdkan worden. Verder is python een veel gebruikte programmeer taal onder onderzoekers. Hetmonitor visualisatie proces is dan ook geschreven in python.

De UDP server socket krijgt de node informatie pakketten binnen van de nodes. Het monitorvisualisatie proces maakt een buffer aan voor iedere node waarvan deze een node informatiepakket binnen krijgt en voegt het pakket toe aan deze buffer. Als er al een buffer bestaat voor denode, wordt er geen nieuwe buffer aangemaakt, maar wordt alleen het pakket aan de bestaandebuffer toegevoegd. De buffers hebben een maximale grootte. Als dit maximum is bereikt wordthet oudste pakket uit de buffer verwijderd, zodat er plaats is voor een nieuw pakket. De nodeinformatie pakketten worden op volgorde in de buffer geplaatst, dit wordt gedaan door te kijkennaar de time-stamp (tijd waarop de meting is gedaan) van het pakket.

Vervolgens verwerkt het monitor visualisatie proces al deze losse node informatie pakkettentot een informatie object van het hele netwerk. Dit netwerk informatie object bevat alle infor-matie van het netwerk op een bepaald tijdstip en wordt gebruikt om de karakteristieken van hetnetwerk te visualiseren. Het netwerk informatie object van een bepaald tijdstip wordt gemaaktdoor voor iedere node het informatie pakket dat gemeten is op het tijdstip uit de buffer te halenvan de node. Vervolgens worden al deze pakketten verwerkt tot een netwerk informatie object.

Het synchroniseren van de tijd tussen de monitor en de nodes door middel van het PrecisionTime Protocol (PTP) zorgt er voor dat de tijd van de monitor en de nodes gelijk lopen. Dit zorgt

22

er echter niet voor dat de metingen van de monitor node processen synchroon lopen. Hierdoorworden de metingen niet op (precies) hetzelfde tijdstip gedaan. Er moet dus voor een tijdstipworden bepaald welk node informatie pakket van iedere node bij het tijdstip hoort, ondanks datde metingen niet op precies hetzelfde tijdstip gedaan zijn.

Om dit probleem op te lossen wordt er gebruik gemaakt van een timeslot. Een timeslot heefteen bepaalde grootte, deze grootte geeft de tijdsperiode aan waarin er in de buffer van de nodemoet worden gezocht naar pakketten. Zoals te zien is in figuur 4.8 wordt er een tijdstip (T1)gekozen waarvan het netwerk informatie object moet worden berekend. Vervolgens worden allepakketten gepakt die tussen de periode zitten van het tijdstip en het tijdstip min de timeslotgrootte (tijdslot van T1). Als er een of meer pakketten zijn gevonden die in deze periode vallen,wordt het meest recente pakket gepakt (pakket op tijd T1). Als er geen pakketten zijn gevondenbetekent het dat er voor dat tijdstip geen informatie pakket is van de node.

Figuur 4.8: Het pakket op T1 wordt gezocht in de buffer door middel van een tijdslot.

Doordat de node informatie pakketten worden opgeslagen in de buffers van de nodes, is hetook mogelijk om een netwerk informatie object van een eerder tijdstip te berekenen door middelvan de timeslots in plaats van alleen die van het huidige tijdstip. Dit kan worden gedaan zoalste zien is in figuur 4.9. Dit biedt de mogelijkheid om niet alleen de real-time node informatie tevisualiseren, maar ook die van bijvoorbeeld twintig seconde terug. Hierdoor kan er een terug-spoel functie worden toegevoegd aan het monitor systeem waardoor er meerdere keren een stukvan de virtualisatie kan worden weergegeven (zie sectie 4.3.4 voor meer informatie).

Figuur 4.9: Het pakket op T2 wordt gezocht in de buffer door middel van een tijdslot.

4.3.4 Grafisch user interface(GUI)

Nadat de data verwerkt is door het monitor visualisatie proces tot een netwerk informatie object,kunnen de karakteristieken van het netwerk worden gevisualiseerd. Om dit grafisch weer te geven

23

Figuur 4.10: Overzicht van de grafisch user interface van de monitor

wordt een interactief grafisch user interface (GUI) geımplementeerd. Een optie is om de GUI teimplementeren in het monitor visualisatie proces, door een van de GUI libaries van python tegebruiken. Echter het nadeel hiervan is dat als er een fout optreedt in de grafisch user interface,dit er voor kan zorgen dat ook de rest van het monitor visualisatie proces niet meer functioneert.Een ander nadeel is dat de GUI dan alleen zichtbaar is op het apparaat waarop het monitorvisualisatie proces geımplementeerd is.

Een andere optie is om de GUI als web applicatie te implementeren. Hierdoor is het mogelijkom de GUI weer te geven in een web browser. Dit kan worden gedaan door in het monitorvisualisatie proces een web service te hosten die het mogelijk maakt om vanuit een web browserde user interface te openen. Vervolgens wordt de netwerk informatie op een interval door deGUI opgevraagd aan het monitor visualisatie proces via de web service. Het voordeel hiervanis dat als er een fout optreedt bij de GUI, het monitor visualisatie proces gewoon blijft werken.Ook kan er hierdoor vanaf andere apparaten worden gekeken naar het GUI, in plaats van alleenvanaf het apparaat waarop het monitor visualisatie proces is geımplementeerd. Het nadeel is datdoordat de netwerk informatie verstuurd moet worden naar de GUI, hierdoor een vertraging kanontstaan.

Omdat het gebruik van een GUI door middel van een webserver het mogelijk maakt om opandere apparaten de GUI te bekijken en bij een fout in de GUI het monitor visualisatie procesblijft werken, is er voor gekozen om een GUI te maken door middel van een web service.

Op de GUI moeten de karakteristieken van het netwerk gevisualiseerd worden zo dat dezeinterpreteerbaar zijn. Door middel van de visualisatie moeten er uitspraken gedaan kunnenworden over het gedrag van het netwerk. De GUI is te zien in figuur 4.10.

Op de GUI wordt de structuur van het netwerk gevisualiseerd. Alle nodes en de verbindingentussen de nodes zijn hierop zichtbaar 4.11. De kleur van de node geeft de status aan van denode. De verschillende statussen van de nodes en de bijbehorende kleur en uitleg zijn te zien intabel 4.1.

Doordat er per verbinding wordt bijgehouden hoeveel data er is verstuurd en ontvangen, kanook de data ’flow’ binnen het netwerk visueel worden weergegeven. De kleur van de verbindingentussen de nodes kunnen oranje of groen zijn. Als de verbinding oranje is betekent het dat ergeen data wordt verstuurd over de verbinding. Als de kleur groen is betekent het dat er datawordt verstuurd over de verbinding. Als er over een verbinding data wordt verstuurd, wordt erdoor middel van een pijltje aangegeven welke node er data verstuurd. Het kan ook voorkomendat beide nodes tegelijk data versturen over een verbinding. In figuur 4.12 is zichtbaar hoe erop de verbinding wordt aangegeven of er data wordt verstuurd en welke node de data verstuurd.Door op een verbinding tussen twee nodes te klikken, verschijnt er een schermpje waarop wordtaangegeven hoeveel bytes er over deze verbinding is verstuurd en ontvangen door de nodes.

Naast de structuur van de nodes wordt ook een in- en output grafiek weergegeven. Deze

24

Figuur 4.11: Weergaven van de structuur van het netwerk op het grafisch user interface

Status Kleur BeschrijvingIdle Oranje De node is niet actief

Starting Licht groen De node is aan het voorbereiden om te beginnen met processenProcessing Groen De node is aan het processen

Waiting Rood De node is aan het wachten op een andere nodeUnknown Blauw De status van de node is niet bekend

Tabel 4.1: Statussen van de nodes met de bijbehorende kleur en beschrijving

Figuur 4.12: In voorbeeld A wordt er geen data verstuurd tussen de nodes. In voorbeeld B stuurtC0:EE:FB:35:07:1E data naar 00:90:A2:9B:17:9B. in voorbeeld C stuurt 00:90:A2:9B:17:9B datanaar C0:EE:FB:35:07:1E. In voorbeeld D sturen 00:90:A2:9B:17:9B en C0:EE:FB:35:07:1E tege-lijk data naar elkaar.

grafiek laat zien hoeveel bytes er totaal is verstuurd en ontvangen per seconden door iedere nodein het netwerk. De grafiek is te zien in figuur 4.13, in deze grafiek is het aantal verstuurde enontvangen bytes per seconden bij elkaar opgeteld. Door een node te selecteren wordt alleen de in-en output van de geselecteerde node getoond. Ook wordt dan apart het aantal verstuurde en ont-vangen bytes per seconden van de node weergegeven, in plaats van het totaal. De gedetailleerdegrafiek van een node is te zien in figuur 4.14.

Naast de in- en output grafiek is er ook een performance grafiek. Deze laat de performance vande nodes zien. De performance grafiek is te zien in figuur 4.15. Net als bij de in- en output grafiekkan een node geselecteerd worden om te zorgen dat alleen de performance van de geselecteerdenode wordt weergegeven (zie figuur 4.16). Door op de toggle (links boven) te klikken kan erworden gewisseld tussen de CPU performance en de CPU load. Op de CPU load grafiek is tezien voor hoeveel procent de applicatie gebruikt van de CPU van de node. De grafiek van deCPU load van een node is te zien in figuur 4.17.

25

Figuur 4.13: In- en output grafiek van de nodes. Deze grafiek laat het totaal aantal bytes(verstuurd plus ontvangen) per seconden zien van de nodes.

Figuur 4.14: In- en output grafiek van een node. In deze grafiek wordt het aantal verstuurde enontvangen bytes per seconden los weergegeven.

Op de linkerkant van het scherm wordt de taak informatie van het netwerk weergegeven.Als er een node geselecteerd wordt, veranderd deze informatie in de node informatie van degeselecteerde node. Hierop is de proces informatie te zien. Ook is hier te zien of en op welkenodes de node aan het wachten is.

Boven aan de GUI is een ’slider’ te zien, deze staat standaard op de waarde 0. De ’slider’ geeftaan met hoeveel seconde vertraging de netwerk informatie wordt gevisualiseerd. Als de ’slider’op 0 staat wordt de real-time netwerk informatie gevisualiseerd. Door de ’slider’ te verplaatsennaar bijvoorbeeld de waarde 10, wordt de netwerk informatie met een vertraging van 10 secondegevisualiseerd. Dit geeft de mogelijkheid om de visualisatie van het netwerk terug te spoelen.

26

Figuur 4.15: Performance grafiek van de nodes. De performance is gemeten door middel van derelatieve performance meet methode.

Figuur 4.16: Performance grafiek van een geselecteerde node. De performance is gemeten doormiddel van de relatieve performance meet methode.

Figuur 4.17: De CPU load van een geselecteerde node (in procenten).

27

28

HOOFDSTUK 5

Experimenten

De karakteristieken van het ad hoc netwerk moeten zo worden weergegeven op de monitor, zodatdeze geınterpreteerd kunnen worden en er uitspraken gedaan kunnen worden over het gedragvan het netwerk. Om te onderzoeken of het monitor systeem aan deze eis voldoet worden erverschillende experimenten uitgevoerd. De experimenten onderzoeken de visualisatie van dekarakteristieken van het netwerk.

Voor het meten van de karakteristieken van het netwerk wordt een monitor node procesgebruikt op iedere node. Dit proces zal voor extra overhead zorgen op de nodes. Er wordt hieromonderzocht wat de invloed van het monitor systeem is op de performance van de nodes en dushet gehele ad hoc netwerk. Dit wordt gedaan voor ad hoc netwerken met verschillende aantallennodes. Ook wordt er gekeken of het monitor systeem schaalbaar is voor grotere aantallen nodes.

5.1 Visualisatie

Er worden verschillende experimenten uitgevoerd om te onderzoeken of de visualisatie van hetnetwerk de karakteristieken zo weergeeft zodat deze interpreteerbaar zijn en er uitspraken ge-daan kunnen worden over het gedrag van het netwerk. Voor de experimenten wordt er gebruikgemaakt van gedistribueerde (benchmark) algoritmes. De visualisatie van de karakteristiekenvan het netwerk wordt vergeleken met de werking van het algoritme. Ook wordt er gekeken ofde visualisatie van het netwerk overeen komt met de verwachte visualisatie.

5.1.1 Experiment 1: Pakket-tracing(IO)

Het Pakket-tracing experiment onderzoekt of de route van een pakket dat verstuurd wordt vaneen node naar een andere node gevolgd kan worden door middel van de visualisatie. Het kun-nen zien van de route die een pakket aflegt kan worden gebruikt voor het onderzoeken van dewerking en het gedrag van een routing algoritme. Dit kan bijvoorbeeld worden gebruikt bij hetimplementeren of ontwikkelen van een routing algoritme op het ad hoc netwerk.

Om dit te onderzoeken wordt vanaf een node naar een andere node een data pakket verstuurd.In figuur 5.1 is de structuur te zien van het ad hoc netwerk tijdens het experiment. Er wordtvanaf node ’A’ een pakket gestuurd naar node ’F’. Het pakket moet door middel van hoppingworden verstuurd doordat node ’A’ en node ’F’ niet direct met elkaar verbonden zijn. Vervolgenswordt er gekeken of de route die het pakket heeft afgelegd te herleiden is door middel van devisualisatie.

Om te zien wat de route van een pakket is wordt er gebruik gemaakt van de visuele weergavenvan de data ’flow’ binnen het netwerk. In figuur 5.2 is de visualisatie te zien van het versturenvan het pakket van node ’A’ naar node ’F’. Zoals te zien is wordt het pakket vanaf ’A’ naar ’C’gestuurd. Vervolgens van ’C’ naar ’D’. Daarna van ’D’ naar ’E’. En als laatst van ’E’ naar ’F’.Door het groen worden van de verbindingen en de pijl die de richting aan geeft, kan er wordengezien welke route het pakket neemt.

29

Figuur 5.1: Structuur van het netwerk tijdens het experiment

Figuur 5.2: Structuur van het netwerk met daarop de verbindingen tussen de nodes. De kleurvan de verbinding laat zien of er data wordt verstuurd over de verbinding. Het pijltje geeft aanin welke richting de data wordt verstuurd.

5.1.2 Experiment 2: Performance en IO

In dit experiment wordt een gedistribueerd benchmark algoritme uitgevoerd op het test platform.De node waarop het benchmark algoritme wordt gestart maakt voor iedere node een verzamelingvan getallen aan en stuurt deze naar de nodes. Ook worden de nodes opeenvolgend genummerd.Vervolgens voeren de nodes dezelfde berekening uit op alle waardes in de verzameling van getal-len. Wanneer een node hiermee klaar is wordt de verzameling naar de node gestuurd met hetopeenvolgende nummer. De node die het hoogste nummer heeft stuurt de verzameling naar denode met het laagste nummer. De verzamelingen worden dus in een cirkel rond gestuurd. Wan-neer een node de nieuwe verzameling heeft ontvangen, kan deze weer beginnen met het uitvoerenvan de berekening op de getallen uit de verzameling. Dit wordt herhaald voor N iteraties.

De verwachting is dat de performance tijdens het uitvoeren van de berekeningen ongeveer

30

constant is (omdat dezelfde berekening wordt gedaan op alle waardes). Wanneer de node klaaris met het uitvoeren van de berekeningen zou de performance van de node 0 moeten worden enhet aantal bytes dat verstuurd wordt per seconden zou omhoog moeten gaan, tot de node klaaris met het versturen van de verzameling. Wanneer de nieuwe verzameling is ontvangen kan denode weer verder gaan met het uitvoeren van de berekeningen, de performance grafiek hoort dusomhoog te gaan. Dit zou N aantal keer herhaald moeten worden.

Het kan voorkomen dat een node de nieuwe verzameling heeft ontvangen voordat deze klaaris met het uitvoeren van de berekeningen op de oude verzameling. Hierdoor wordt er verwachtdat de performance dan niet naar 0 zal gaan wanneer deze klaar is met het uitvoeren vande berekeningen op de oude verzameling. Dit is echter alleen het geval wanneer de nieuweverzameling al volledig is ontvangen voordat de node klaar is met de oude verzameling.

In figuur 5.3 zijn de IO en de performance grafiek van een node te zien tijdens het uitvoeren vanhet algoritme. In de performance grafiek is te zien dat tijdens het uitvoeren van het algoritme deperformance ongeveer constant is. Ook is te zien dat wanneer een node klaar is met het uitvoerenvan de berekeningen, de verzameling verstuurd wordt en de performance naar 0 gaat. Nadat denode de nieuwe verzameling heeft ontvangen gaat de performance weer om hoog. In het figuuris ook te zien dat dit proces meerdere keren wordt herhaald. In figuur 5.4 is te zien dat wanneerde nieuwe verzameling is ontvangen voordat de node klaar was met de oude verzameling, deperformance niet naar 0 gaat.

Figuur 5.3: Performance en IO grafiek van een node tijdens het experiment

De verwachting en de daadwerkelijke visualisatie komen overeen met elkaar. Ook kan hetgedrag van het algoritme worden afgeleid door middel van de visualisatie. Zo kan er op basis vande visualisatie geconcludeerd worden dat een node moet wachten tot de nieuwe verzameling isontvangen, wanneer deze klaar is met het uitvoeren van de berekeningen op de oude verzameling.Ook is te zien dat wanneer een node klaar is met het uitvoeren van berekeningen, de verzamelingwordt verstuurd naar een andere node in het netwerk.

31

Figuur 5.4: Performance en IO grafiek van een node tijdens het experiment

5.1.3 Experiment 3: Wave equation

In het wave equation experiment wordt er onderzocht of het gedrag en de werking van de ge-distribueerde 1-dimensionale wave equation kan worden afgeleid door middel van de visualisatie.De 1-dimensionale wave equation berekent de beweging van een golf over tijd. Voor de golf wordter gebruik gemaakt van een discrete golf, dit betekent dat de golf wordt uitgedrukt als een arrayvan (amplitude) waardes (zie figuur 5.5). De uiterste punten aan beide kanten van de wave zijnaltijd 0. Om de nieuwe waardes van de golf te berekenen wordt formule 5.1 gebruikt. Zoals tezien is in de formule, wordt er gebruik gemaakt van de huidige waardes en de vorige waardesvan de golf om de waardes van de volgende tijdstap te berekenen. Om een waarde te berekenenwordt er ook gebruik gemaakt van de waardes rechts en links van deze waarde.

Ai,t+1 = 2 ∗Ai,t −Ai,t−1 + 0.15 ∗ (Ai−1,t − (2 ∗Ai,t −Ai+1,t)) (5.1)

De 1-dimensionale wave equation kan worden gedistribueerd over verschillende nodes. Iederenode berekent dan een deel van de golf. Doordat de waardes rechts en links nodig zijn van eenwaarde om de nieuwe waarde te berekenen, ontstaat er overlap tussen de verschillende stukkenvan de golf. Dit komt doordat de nodes waardes nodig hebben die door een andere node wordenberekend (Zie figuur 5.6). Na iedere tijdstap moeten deze rand waardes worden gesynchroniseerdtussen de verschillende nodes voordat deze verder kunnen met het berekenen van de nieuwetijdstap. De beweging van de wave zal over N tijdstappen worden berekend.

De verwachting is dat in de visualisatie van de performance grafiek er pieken en dalen zijn.Wanneer er een piek is in de performance grafiek, berekent de node de nieuwe waardes van degolf. Wanneer de rand waardes worden gesynchroniseerd tussen de nodes, zal er een dal zijndoordat de performance 0 zal worden omdat de nodes moeten wachten tot de rand waardesontvangen zijn. Tijdens het dal in de performance grafiek zal de in- en output grafiek omhoogmoeten gaan. Wanneer de rand waardes gesynchroniseerd zijn zal de in- en output grafiek weer0 moeten worden. Dit zal N keer worden herhaald.

In figuur 5.7 zijn de IO en performance grafiek van een node te zien tijdens het uitvoerenvan het algoritme. Zoals verwacht werd zijn er in de performance grafiek pieken en dalen. De

32

Figuur 5.5: Voorbeeld van een discrete golf

Figuur 5.6: Voorbeeld van een wave die over drie stukken wordt verdeeld. Zoals te zien is zittener tussen twee delen rand waardes die gesynchroniseerd moeten worden tussen de tijdstappen.

33

dalen ontstaan door het synchroniseren van de randen tussen de nodes. Dit is te zien doordat alser een dal in de performance grafiek is, er een piek in de IO grafiek ontstaat. Echter, wordt deperformance niet altijd 0 tijdens het synchroniseren van de randen. Dit is te verklaren doordatde performance over een interval wordt gemeten. Hierdoor kan het zijn dat de performance voormaar een deel van de meting 0 was en er dus alleen een dal ontstaat.

Figuur 5.7: Performance en IO grafiek van het netwerk tijdens het experiment

5.2 Invloed op de performance van het netwerk

Het monitor node proces is geımplementeerd op elke node in het netwerk om de karakteristiekente verzamelen van de node en het netwerk. Om de gegevens van de node te verzamelen moethet monitor node proces gebruik maken van de CPU van de node. Ook moet de node informatieverstuurd worden naar het monitor visualisatie proces, hiervoor gebruikt het monitor node procesook de CPU en de in- en output van de node. Het monitor node proces zorgt dus voor extraoverhead op de node. Doordat het monitor systeem een aparte communicatie laag heeft, zal dezegeen extra overhead geven op de communicatie laag van het test platform.

In dit experiment wordt onderzocht hoeveel het monitor node proces de performance van denode beınvloed en dus de performance van het gehele netwerk. Ook wordt er onderzocht of ereen verband zit tussen de invloed van het monitor node proces op de performance en het aantalnodes in het netwerk.

Om de invloed op de performance van het netwerk te meten wordt de wave equation (zie sectie5.1.3) uitgevoerd op het ad hoc netwerk. Dit wordt gedaan met en zonder monitor systeem. Hetverschil in executie tijd is de overhead die het monitor systeem veroorzaakt in het netwerk. Ditexperiment wordt uitgevoerd op netwerken met verschillende aantallen nodes om te zien of ereen verband is tussen de overhead die het monitor systeem veroorzaakt en het aantal nodes inhet netwerk.

Om te zorgen dat de metingen zo accuraat mogelijk zijn worden er voor de meting met enzonder monitor dezelfde netwerk structuur gebruikt. Ook wordt er voor gezorgd dat de nodesdezelfde stukken van de array krijgen voor beide metingen, zodat het algoritme op dezelfde

34

manier wordt uitgevoerd. Verder wordt het algoritme 10 keer uitgevoerd om een gemiddeldeexecutie tijd te kunnen berekenen.

Voor de instellingen van het experiment wordt gebruik gemaakt van een meet interval van500 milliseconden (voor het monitor systeem). Er wordt een array grootte van 200000 elementengebruikt en de wave wordt over een periode van 300 tijdstappen berekent. De array grootte enhet aantal tijdstappen zijn zo gekozen om te zorgen dat zowel de performance en in- en outputvan de nodes worden belast tijdens het experiment.

De executie tijden met en zonder monitor systeem zijn te zien in figuur 5.8. Zoals in degrafiek te zien is, zorgt het monitor systeem voor overhead op de performance van het ad hocnetwerk. In figuur 5.9 is het percentage overhead te zien van het monitor systeem. De overheadbevindt zich ongeveer tussen de 15.5 en 17.2 procent voor het gebruikte meet interval ongeachthet aantal nodes binnen het netwerk.

Figuur 5.8: Gemiddelde executie tijd van de wave equation met een interval van 500 millisecon-den, een array grootte van 200000 en 300 tijdstappen

Dit is te verklaren doordat het monitor node proces een gedistribueerd proces is dat op elkenode is geımplementeerd. Hierdoor belast het monitor node proces iedere node ongeveer evenzwaar, ongeacht het aantal nodes in het netwerk. Doordat het UDP protocol wordt gebruikt,hoeft het monitor node proces niet te controleren of het pakket is aangekomen bij het monitorvisualisatie proces. Hierdoor kan het monitor node proces de node informatie versturen naar hetmonitor visualisatie proces, zonder dat het monitor node proces hoeft te wachten op een reactievan het monitor visualisatie proces.

De overhead die het monitor systeem veroorzaakt op de performance van het netwerk is bijbenadering constant bij verschillende aantallen nodes binnen het netwerk, dus er kan geconclu-deerd worden dat het monitor systeem schaalbaar is. Dit moet echter nog geverifieerd wordenwanneer nog rekening wordt gehouden met een uitgebreidere set factoren. In sectie 6.2 wordthierop dieper ingegaan.

35

Figuur 5.9: Percentage overhead van de monitor met een interval van 500 milliseconden, eenarray grootte van 200000 en 300 tijdstappen

36

HOOFDSTUK 6

Future work

6.1 Invloed overige karakteristieken

Naast structuur, in- en output, performance, CPU load en node status zijn er ook andere ka-rakteristieken die invloed hebben op het gedrag van een heterogeen ad hoc netwerk. Deze zijnechter niet behandeld doordat deze buiten de scope van dit project vallen. Dit zijn bijvoorbeeldde verbindings kwaliteit, node kwaliteit en de (geografische) coordinaten.

Niet alle verbindingen binnen het ad hoc netwerk hebben namelijk dezelfde kwaliteit. Ver-bindingen tussen nodes die verder uit elkaar staan of waartussen meer obstakels staan, zijn vaakvan slechtere kwaliteit dan verbindingen tussen nodes die dicht bij elkaar staan of waar geenobstakels tussen zitten. De verbindings kwaliteit heeft bijvoorbeeld invloed op het gedrag vanhet ad hoc netwerk doordat wanneer een verbinding tussen twee nodes een slechte kwaliteitheeft, er hoogstwaarschijnlijk minder data per seconden over verstuurd kan worden dan over eenverbinding met een goede kwaliteit. Dit kan effect hebben op de in- en output van het helenetwerk.

Doordat bij heterogene ad hoc netwerken de nodes verschillende hardware specificaties kunnenhebben zijn niet alle nodes van dezelfde kwaliteit. Een node met betere hardware specificaties isvan een hogere kwaliteit dan een node met slechtere hardware. De node kwaliteit kan bijvoorbeeldinvloed hebben op de performance van een node. Een node met een hogere node kwaliteit zalwaarschijnlijk een hogere maximale performance hebben dan een node met een lagere nodekwaliteit.

De netwerk graaf van het ad hoc netwerk wordt gegenereerd door middel van de informatieover de nodes en de informatie over de verbindingen. Van deze graaf wordt een visuele weergavengemaakt waarin de nodes en de verbindingen te zien zijn. De locatie van de nodes op deze visueleweergaven komen echter niet overeen met de werkelijke (geografische) locatie van de nodes. Doorde (geografische) coordinaten te meten van de nodes, kan ervoor worden gezorgd dat de locatiesvan de nodes op de visualisatie overeen komen met de werkelijke (geografische) locaties. Hierdoorkan bijvoorbeeld worden gezien wat de afstand is tussen de nodes. Dit kan helpen met hetanalyseren van het gedrag van het ad hoc netwerk.

6.2 Invloed overige schaalbaarheidsfactoren

In de experimenten is onderzocht wat de invloed van het monitor systeem is op de performancevan de nodes en dus het gehele ad hoc netwerk. Dit is gemeten met netwerken met verschillendeaantallen nodes. Het resultaat hiervan is dat de overhead die de monitor veroorzaakt op deperformance van het ad hoc netwerk tussen de 15.5 en 17.2 procent is, ongeacht het aantal nodesin het netwerk.

Dit zorgt ervoor dat de overhead die wordt veroorzaakt op de performance van de nodes geenbeperking is voor de schaalbaarheid van het monitor systeem. Er zijn echter andere factoren die

37

ook invloed hebben op de schaalbaarheid van het monitor systeem voor grotere hoeveelhedennodes.

Een factor is het fysieke bereik van de communicatie laag van het monitor systeem, doordatalle nodes direct verbonden moeten zijn met het monitor visualisatie proces. Voor de implemen-tatie van dit project is WiFi gebruikt, wat een beperkt bereik heeft. Hierdoor kan het voorkomendat wanneer het netwerk bestaat uit een groot aantal nodes, het netwerk zich verspreid over eengroter vervlak waardoor niet alle nodes in het bereik zijn van het monitor visualisatie proces.

Om dit probleem op te lossen zou onderzocht kunnen worden hoe het monitor systeem zichgedraagt wanneer er meerdere ’verzamelpunten’ zijn waarnaar de node informatie pakkettentoegestuurd kunnen worden. Deze ’verzamelpunten’ zouden dan alleen verantwoordelijk zijnvoor het ontvangen van de node informatie pakketten van de nodes die in de buurt zijn en hetdoorsturen van deze pakketten naar het monitor visualisatie proces. Hierdoor kan het bereik vanhet monitor systeem vergroot worden door meer ’verzamelpunten’ toe te voegen.

Een andere oplossing die onderzocht zou kunnen worden is dat de nodes die niet in het bereikvan het monitor visualisatie proces zijn, de node informatie pakketten naar nodes sturen die welin het bereik van het monitor visualisatie proces zijn. De node informatie pakketten kunnennaar deze nodes verstuurd worden via de bestaande communicatie laag van het ad hoc netwerk.Vervolgens sturen de nodes die in het bereik zijn van het monitor visualisatie proces de pakkettendoor naar het monitor visualisatie proces.

Ook zou er onderzocht kunnen worden hoe het monitor systeem zich gedraagt wanneer de nodeinformatie pakketten via mobiel internet(bijvoorbeeld 3G of 4G) naar het monitor visualisatieproces gestuurd worden.

Een andere factor die invloed heeft op de schaalbaarheid van het netwerk is het aantal nodeinformatie pakketten die het monitor visualisatie proces kan verwerken. Wanneer het aantalnodes binnen het netwerk groeit, zal ook het aantal node informatie pakketten die het monitorvisualisatie proces moet verwerken groeien. Er zou dus onderzocht kunnen worden wat het limietis van het aantal node informatie pakketten die het monitor visualisatie proces kan verwerken enof dit verhoogt kan worden door bijvoorbeeld het monitor visualisatie proces te parallelliseren.

38

HOOFDSTUK 7

Conclusie

In dit onderzoek is aangetoond dat de karakteristieken van een (heterogeen) ad hoc netwerk,zodanig kunnen worden weergegeven, dat deze interpreteerbaar zijn. Dit is onderzocht doorhet ontwikkelen en implementeren van een monitor systeem op een test platform. Hiervoor isonderzocht hoe de karakteristieken van het ad hoc netwerk gemeten kunnen worden. Tevensis er onderzocht hoe de verzamelde gegevens over de karakteristieken van het ad hoc netwerkgevisualiseerd kunnen worden zodat deze interpreteerbaar zijn.

Hiervoor zijn twee verschillende processen nodig, het monitor node proces en het monitorvisualisatie proces. Het monitor node proces is een gedistribueerd proces dat geımplementeerd isop elke node in het netwerk en wat de informatie verzameld van de nodes. Het monitor visualisatieproces verwerkt en visualiseert de gegevens die door de monitor node processen verzameld zijn.De visualisatie wordt weergegeven door middel van een interactieve grafisch user interface.

Op de grafische user interface worden de karakteristieken van het netwerk gevisualiseerd.Hierop is de structuur en de data flow van het netwerk te zien. Door middel van kleuren wordtde status van de nodes en de verbindingen weergegeven. Ook is te zien welke kant de data wordtverstuurd over een verbinding. Daarnaast zijn er ook een performance en IO grafiek te zien opde grafisch user interface. Deze grafieken laten de performance en IO zien van de nodes in hetnetwerk.

Door middel van de visualisatie van het netwerk, is het mogelijk om de data flow te zienbinnen het netwerk. Hierdoor kunnen bijvoorbeeld pakketten gevolgd worden op de monitor.Dit kan gebruikt worden voor bijvoorbeeld het ontwikkelen en implementeren van een routingalgoritme. Ook is het mogelijk om door middel van de performance en IO grafiek, het gedragvan een gedistribueerd algoritme te analyseren. Hierdoor kunnen er uitspraken gedaan wordenover het gedrag en de werking van een gedistribueerd algoritme binnen het netwerk.

Ook is onderzocht wat de invloed is van het monitor systeem op de performance van denodes en dus het gehele ad hoc netwerk. Doordat het monitor node proces een gedistribueerdproces is dat geımplementeerd is op elke node in het netwerk en metingen verricht, zorgt dit vooreen overhead op de performance van de node. Doordat het monitor node proces op elke nodeapart geımplementeerd is, wordt de performance niet beınvloed door het aantal nodes binnenhet netwerk. Dit zorgt ervoor dat de overhead die het monitor systeem veroorzaakt tussen de15.5 en 17.2 procent is voor het gebruikte meet interval ongeacht het aantal nodes binnen hetnetwerk.

De overhead die het monitor systeem veroorzaakt op de performance van het netwerk is bij be-nadering constant bij verschillende aantallen nodes binnen het netwerk, dus er kan geconcludeerdworden dat het monitor systeem schaalbaar is. Dit moet echter nog geverifieerd worden wanneernog rekening wordt gehouden met een uitgebreidere set factoren. Een factor is het fysieke be-reik van het monitor visualisatie proces. Ook is de verwerkingscapaciteit van de pakketten vanhet monitor visualisatie proces een factor wat invloed kan hebben op de schaalbaarheid van hetmonitor systeem.

39

40

BIJLAGE A

Lijst van meetbare gegevens

Waarden OmschrijvingStatus De status van de nodeTaak De taak waarmee de node bezig isProgress De voortgang de taakPayload De totale hoeveelheid werk van de taakPerfomance De performance van de nodeCPU load De CPU load van de node

Bytes sendHet aantal bytes dat de node heeftverstuurd sinds de laatste meting

Bytes receivedHet aantal bytes dat de node heeftontvangen sinds de laatste meting

Total bytes sendHet totaal aantal bytes datde node heeft verstuurd

Total bytes receivedHet totaal aantal bytes datde node heeft ontvangen

Packages sendHet aantal pakketten datde node heeft gestuurd

Packages receivedHet aantal pakketten datde node heeft ontvangen

Connections

De verbindingen die de node heeft met andere nodes.Voor iedere verbinding wordt bijgehouden:Met welke node de verbinding is.Hoeveel data er over de verbinding is gestuurd sinds de laatste meting.Hoeveel data er over de verbinding is ontvangen sinds de laatste meting.Hoeveel data er totaal over de verbinding is gestuurd.Hoeveel data er totaal over de verbinding is ontvangen.

41

42

Bibliografie

[1] Saif Al-Sultan, Moath M Al-Doori, Ali H Al-Bayatti, and Hussien Zedan. A comprehensivesurvey on vehicular ad hoc network. Journal of network and computer applications, 37:380–392, 2014.

[2] Josh Broch, David A Maltz, David B Johnson, Yih-Chun Hu, and Jorjeta Jetcheva. Aperformance comparison of multi-hop wireless ad hoc network routing protocols. In Pro-ceedings of the 4th annual ACM/IEEE international conference on Mobile computing andnetworking, pages 85–97. ACM, 1998.

[3] Timothy X Brown, Sheetalkumar Doshi, Sushant Jadhav, Daniel Henkel, and Roshan-George Thekkekunnel. A full scale wireless ad hoc network test bed. Proceedings of IS-ART05, pages 51–60, 2005.

[4] Thomas Heide Clausen, Justin W Dean, and Christopher Dearlove. Mobile ad hoc network(manet) neighborhood discovery protocol (nhdp). 2011.

[5] Marco Conti and Stefano Giordano. Mobile ad hoc networking: milestones, challenges, andnew research directions. Communications Magazine, IEEE, 52(1):85–96, 2014.

[6] Kevin Fall and Kannan Varadhan. The network simulator (ns-2). URL: http://www. isi.edu/nsnam/ns, 2007.

[7] Frank HP Fitzek, P Seeling, M Reisslein, and M Zorzi. Visualization tool for ad hoc networks(vitan). Technical report, Technical Report 003-02, acticom, www. acticom. de, 2002.

[8] Magnus Frodigh, Per Johansson, and Peter Larsson. Wireless ad hoc networking: the artof networking without a network. Ericsson Review, 4(4):249, 2000.

[9] Stuart Kurkowski, Tracy Camp, Neil Mushell, and Michael Colagrosso. A visualization andanalysis tool for ns-2 wireless simulations: inspect. In Modeling, Analysis, and Simulationof Computer and Telecommunication Systems, 2005. 13th IEEE International Symposiumon, pages 503–506. IEEE, 2005.

[10] David L Mills. Internet time synchronization: the network time protocol. Communications,IEEE Transactions on, 39(10):1482–1493, 1991.

[11] Jon Postel. Transmission control protocol. 1981.

[12] Jon Postel and User Datagram Protocol. Rfc 768. User datagram protocol, pages 1–3, 1980.

[13] Nazmus Saquib, Md Sabbir Rahman Sakib, and Al-Sakib Khan Pathan. Visim: A user-friendly graphical simulation tool for performance analysis of manet routing protocols. Ma-thematical and Computer Modelling, 53(11):2204–2218, 2011.

[14] Emmanouil Spanakis, Christodoulos Efstathiades, George Pallis, and Marios D Dikaiakos.Real-time graph visualization tool for vehicular ad-hoc networks:(vivagr: Visualization toolof vanet graphs in real-time). In Computers and Communications (ISCC), 2011 IEEESymposium on, pages 729–734. IEEE, 2011.

43