Ontwikkelen van een GUI voor een peer-to-peer netwerksimulator

Transcriptie

1 Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie (INTEC) IBCN groep Ontwikkelen van een GUI voor een peer-to-peer netwerksimulator Ehsan Karimi Rad Promotor: Prof. Dr. Ir. B. Dhoedt Begeleider: Ir. T. Wauters Scriptie ingediend tot het behalen van de academische graad van master na master in de toegepaste informatica. Academiejaar

2

3 De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. Ondertekend op 12 april 2010 Ehsan Karimi Rad

4 Voorwoord Beweren dat een proefschrift slechts door één persoon gemaakt wordt, is onzin. In elke fase zijn er mensen die een handje toesteken om het werk tot een goed einde te brengen. Dit voorwoord is het uitgelezen moment om al deze mensen te bedanken voor hun gewaardeerde hulp. Allereerst zou ik mijn promotor Prof. Dr. Ir. B. Dhoedt willen bedanken voor het aanreiken van het onderwerp. Speciale dank gaat uit naar mijn begeleider Ir. Tim Wauters voor zijn inspanningen en de bijgebrachte kennis. Verder wil ik Peter Coussement bedanken voor de informatie die hij mij heeft gegeven om de P2P-netwerksimulator beter te begrijpen. Tenslotte uit ik mijn dank aan mijn moeder en twee broers voor de morele steun die zij mij hebben gegeven gedurende mijn academische jaren. Universiteit Gent i

5 Samenvatting Het doel van deze scriptie is het ontwerp van een grafische gebruikersinterface voor een P2P netwerksimulator die gebaseerd is op het protocol van Gnutella. De scriptie is opgedeeld in twee delen: een eerste deel waar de inputbestanden voor de simulator gegenereerd worden en een tweede deel waar de outputbestanden verwerkt worden. In het eerste deel wordt het Gnutella netwerk opgebouwd en worden er enkele gegevens aan de gebruiker gevraagd. Aan de hand van deze gegevens worden de nodige inputbestanden gecreëerd en opgeslagen. Hierna wordt het bestaande P2P netwerksimulatieprogramma opgeroepen en uitgevoerd. Dit programma levert een outputbestand dat in het tweede deel ingelezen, geparst en verwerkt wordt. Voor didactische doeleinden is er tevens voor gezorgd dat de verzonden berichten tijdens de simulatie, naderhand opnieuw grafisch getoond kunnen worden. De gebruikersinterface draait bovenop de P2P netwerksimulator waardoor een volledige scheiding tussen de twee delen kan gerealiseerd worden. Hierdoor kan het P2P netwerksimulator als een black box beschouwd worden. Aanpassingen aan het P2P netwerksimulatieprogramma kunnen gedaan worden zonder de gebruikersinterface te moeten veranderen indien de input en outputbestanden ongewijzigd blijven. De gebruikersinterfaces werden geschreven in de programmeertaal Java aangezien het bestaande P2P netwerksimulator in Java geschreven is. Hierbij is het gebruik van de klasse Swing door zijn flexibele gebruikersinterfacecomponenten onontbeerlijk. Universiteit Gent ii

6 Inhoudsopgave Hoofdstuk 1. Inleiding Doelstelling... 1 Hoofdstuk 2. P2P-netwerken Wat zijn P2P-netwerken P2P-architecturen en toepassingen Gecentraliseerde P2P-systemen: Napster Gedecentraliseerde P2P-systemen: Freenet (Gnutella v0.4) Semi-gecentraliseerde P2P-systemen: KaZaa (Gnutella v0.6)... 7 Hoofdstuk 3. Het Gnutella-protocol Algemeen Protocolberichten Group membership Search File transfer Headers van berichten Descriptor Routing Broadcasten en Back-propagation Caches Statische en dynamische routing Het Gnutella-poort en het HTTP-poort Bootstrapping Hooking Discovery Search Query routing bij leaf nodes Query routing bij ultrapeers Download Hoofdstuk 4. Netwerksimulator Algemeen J-Sim simulator Het bestaande programma Gnutella-implementatie Hoofdstuk 5. Input- en outputbestanden Algemeen Inputbestanden Simulatiecommando s Topologie van het netwerk Nodes Outputbestand Hoofdstuk 6. Implementatie van de input Java en Swing De structuur van de GUI Start Universiteit Gent iii

7 6.4 DrawGraph Algemeen Constructor Taakbalken Taakbalk Taakbalk Taakbalk ViewButtons ListenButtonPanel ListenGraphPanel Hoofdstuk 7. Implementatie van de output Algemeen Output Messages (descriptors) MessageTable MessageGraph Dynamic Neighbours (Updates) Zoekresultaten Statistieken Save Hoofdstuk 8. Conclusies Input Output Lijst van figuren Lijst van tabellen Referenties Universiteit Gent iv

8 Hoofdstuk 1. Inleiding 1.1 Doelstelling Het doel van deze scriptie is het ontwerpen van een Graphical User Interface (GUI) voor een bestaande P2P-netwerksimulator. Deze P2P-netwerksimulator is geïmplementeerd volgens het Gnutella-protocol. Het bevat een aantal inputbestanden waarin een netwerk voorgesteld wordt. Ook andere gegevens die gerelateerd zijn met het netwerk en de simulatie, zoals bijvoorbeeld een zoekstring en de maximale bandbreedte van een link, zijn hierin beschreven. Aan de hand van deze inputgegevens wordt de P2P-netwerksimulatie uitgevoerd en een outputbestand gegenereerd. Dit outputbestand bevat alle berichten die verzonden en ontvangen zijn door de verschillende nodes van het Gnutella-netwerk. Voor de gebruiker is het echter niet eenvoudig deze input- en outputbestanden op te stellen of te analyseren. Het is erg tijdrovend en fouten kunnen zich snel voordoen. Deze fouten zijn tevens niet gemakkelijk op te sporen. Het ontwikkelen van een GUI is bijgevolg noodzakelijk. In deze scriptie wordt getracht een gebruiksvriendelijke GUI te ontwikkelen waarbij het aanmaken van nieuwe netwerken heel wat vereenvoudigd wordt. De gebruiker zal het netwerk moeten tekenen en enkele noodzakelijk gegevens invoeren. Onderliggend worden de verschillende nodes en directories gecreëerd. Elk node zal voorzien worden van een aantal bestanden die gedownload kunnen worden tijdens de netwerksimulatie. De inhoud van de bestanden is minder belangrijk aangezien de bedoeling van het P2P-netwerksimulatieprogramma het onderzoeken van de verschillende berichten in het Gnutella-netwerk is. Deze bestanden kunnen bijgevolg automatisch aangemaakt worden. Het outputbestand zal vervolgens ingelezen worden en in een overzichtelijkere vorm gegoten worden. De gebruiker zal de mogelijkheid krijgen de berichten in tabelvorm of via een grafische simulatievoorstelling te bekijken. Er zullen tevens enkele gegevens in verband met eventuele congestie getoond worden. Uit de outputfile zullen ook de resultaten van een zoekopdracht in tabelvorm gevisualiseerd worden. De node die de zoekopdracht initieert krijgt informatie over de andere nodes van het Gnutella-netwerk. Aan de gebruiker zal de mogelijkheid verleend worden deze informatie te bekijken. Universiteit Gent 1

9 Hoofdstuk 1 Inleiding Bovendien zal er een functie voorzien worden om de resultaten van de verwerking op een gepaste wijze te bewaren in een tekstbestand. Dit tekstbestand zal dan via een ander programma, zoals bijvoorbeeld Excel, bekeken kunnen worden. Om wat meer vertrouwd te raken met P2P-netwerken wordt in Hoofdstuk 2 uitgelegd wat P2P-netwerken zijn. Hierbij worden de verschillende P2P-architecturen en enkele toepassingen besproken. In Hoofdstuk 3 zullen de verschillende onderdelen van het Gnutella-protocol nader bekeken worden. Hoofdstuk 4 handelt over de netwerksimulator en de aspecten van het Gnutella-protocol die hierin zijn geïmplementeerd. Hoofdstuk 5 gaat over de structuur van de verschillende input- en outputbestanden die nodig zijn om de simulator aan te sturen en de resultaten te interpreteren. In het hierna volgende hoofdstuk wordt uitgelegd hoe de GUI voor het inputgedeelte ontwikkeld is. In Hoofdstuk 7 zal dit outputbestand geparst wordt zodat overzichtelijk informatie verkregen wordt. Het laatste hoofdstuk geeft de conclusie en enkele mogelijke uitbreidingen van de GUI. Universiteit Gent 2

10 Hoofdstuk 2. P2P-netwerken 2.1 Wat zijn P2P-netwerken Peer-to-peer (P2P) systemen zijn per definitie gedecentraliseerde en gedistribueerde systemen. Bij client-server applicaties hebben cliënten toegang tot een centrale server om bijvoorbeeld bestanden te bewaren of op te vragen. In tegenstelling hiermee is een P2P-systeem zo opgesteld dat alle nodes dezelfde mogelijkheden en bronnen hebben en dat alle partijen een verbinding kunnen opstarten. Elk node kan zowel de rol van een client als van een server spelen. Nodes worden ook servents genoemd, wat in feite een combinatie van server en client is. Een P2P-netwerk is bijgevolg een netwerk tussen gelijke peers. Een veel gebruikte protocol voor bestandenuitwisseling voor P2Papplicaties is het Gnutella-protocol. Voorbeelden van P2P-programma s zijn: Napster LimeWire Kazaa Peers zijn autonome eenheden. Hierdoor kunnen ze elkaar niet vertrouwen en zijn schaalbaarheid en redundancy heel belangrijk. Elk thuisgebruiker kan zich als een peer aanmelden aan het netwerk. Dit wil zeggen dat het netwerk geen vaste structuur heeft en continu verandert met het aan- en afmelden van gebruikers. De datatransfer kan, door gebruik te maken van een P2Pnetwerk, zeer efficiënt gebeuren aangezien gebruikers gegevens rechtstreeks met elkaar uitwisselen zonder interventie van een server. Bij het client-server model moeten alle cliënten de bandbreedte van één server delen en een toenemend aantal cliënten zal de datatransfer steeds vertragen. In tegenstelling hiervan kan bij het P2P-model de bandbreedte van alle cliënten gebruikt worden, zodat de totale bandbreedte toeneemt met het aantal verbonden nodes. Kortom, P2P-netwerken hebben wegens hun gedecentraliseerde aard, volgende voordelen: een verhoogde schaalbaarheid en betrouwbaarheid een hoge dynamiek een verhoogde autonomie en anonimiteit Universiteit Gent 3

11 Hoofdstuk 2 P2P-netwerken kosten kunnen bespaard worden op dure infrastructuur zoals bijvoorbeeld centrale servers P2P-netwerken hebben echter ook minpunten. Het probleem van veiligheid en privacy is een belangrijk punt daar geen enkele programma kan garanderen dat de computer van de gebruiker volledig afgeschermd is. Het illegaal verspreiden van muziek, films, boeken en dergelijke schenden het copyright van artiesten. Een ander probleem is de congestie. Doordat de peers het netwerk zelf in stand moeten houden, is vaak een grote hoeveelheid controletrafiek vereist [1]. 2.2 P2P-architecturen en toepassingen In de praktijk blijkt dat niet alle P2P-systemen volledig gedecentraliseerd zijn. P2Psystemen worden onderverdeeld in drie types, allen gedistribueerde computersystemen: Gecentraliseerde P2P-systemen: Napster Gedecentraliseerde P2P-systemen: Gnutella v0.4 Semi-gecentraliseerde P2P-systemen: Gnutella v Gecentraliseerde P2P-systemen: Napster Napster is een P2P-systeem dat voornamelijk gebruikt werd om muziekbestanden uit te wisselen. Het heeft een centrale server die informatie over alle peers in het systeem bijhoudt. Een gecentraliseerde P2P-systeem wordt ook wel eens mediated architectuur genoemd. Wanneer een peer zich aanmeldt bij de server, publiceert hij een lijst van bestanden die hij gemeenschappelijk stelt voor andere peers. Hierdoor bevat de centrale server alle informatie over de peers en de bestanden die zij delen. Zoekopdrachten naar bestanden worden naar de server gestuurd. De server zoekt vervolgens de peers op die in het bezit zijn van het opgevraagde bestand en stuurt deze lijst naar de peer die de zoekactie heeft geïnitieerd. Aangezien de server alle informatie van de peers bevat, kan de zoekopdracht (query) zeer snel uitgevoerd worden. De peers hebben de mogelijkheid te specificeren met welke peers zij in contact willen komen. Zo kan bijvoorbeeld een peer specificeren dat enkel peers met een bepaald minimum bandbreedte en/of maximum bestandsgrootte in aanmerking mogen komen voor een zoekopdracht. De server houdt rekening met deze voorkeuren alvorens een lijst terug te sturen. Deze lijst bevat de adressen van peers die aan de zoekopdracht en de voorkeuren voldoen. Universiteit Gent 4

12 Hoofdstuk 2 P2P-netwerken De peer die een zoekopdracht heeft uitgevoerd, kan nu rechtstreeks in contact komen met een of meerder peers uit de lijst. Een bestand kan vervolgens uitgewisseld worden zonder de inmenging van de centrale server. Figuur 1 toont het gecentraliseerde model van Napster. Figuur 1 Een gecentraliseerde P2P-model Ondanks hun hoge performantie wordt een gecentraliseerd systeem zoals Napster geplaagd door twee belangrijke problemen. Het eerste probleem is de bottleneck aan de server. De bottleneck treedt op wanneer zeer veel peers een zoekopdracht hebben geïnitieerd en de server bezet is. Dit knelpunt wordt algemeen benoemd als single point of failure. Het twee probleem betreft het gebrek aan anonimiteit in het systeem. Daar de centrale server informatie bezit over het IP-adres en de gedeelde bestanden van een peer, kan er geen sprake zijn van anonimiteit. Door de server te spoofen kan achterhaald worden welke peers betrokken zijn bij het uitwisselen van een bestand. Universiteit Gent 5

13 Hoofdstuk 2 P2P-netwerken Het schenden van de copyrightwet, door vooral muziek te kopiëren, heeft ertoe geleid dat Napster geen lang leven was beschoren Gedecentraliseerde P2P-systemen: Freenet (Gnutella v0.4) Gnutella v0.4 is een protocol voor volledig gedecentraliseerde (pure) P2P-systemen. Een bekend voorbeeld van een applicatie die gebaseerd is op het Gnutella-protocol is Freenet. Gnutella gebruikt een broadcast-protocol om bestanden op te zoeken in het Gnutella-netwerk. Het is bijgevolg noodzakelijk dat elk peer minstens één andere Gnutella-peer kent om verzoeken naar te kunnen versturen. Er is geen centrale server die informatie bezit over adressen van peers. Wanneer een peer het Gnutella-netwerk betreedt, maakt het contact met een aangewezen peer en ontvangt een lijst van peers die recent aangemeld zijn in het Gnutella-netwerk. Er moet opgemerkt worden dat een aangewezen peer geen informatie bijhoudt over alle peers en hun gedeelde bestanden. Het bezitten enkel een lijst van recent aangemelde peers en dit gedurende een welbepaalde tijd. Slechts een deel van deze peers (meestal zeven) zullen fungeren als buur voor de zopas ingetreden peer. Als deze peers een gezocht bestand niet bezitten, zullen zij op hun beurt de zoekopdracht naar hun buren doorsturen. Figuur 2 toont de berichten voor een zoekopdracht die worden verzonden in een eenvoudig gedecentraliseerd P2P-systeem. Figuur 2 Een vereenvoudigd gedecentraliseerde P2P-systeem Universiteit Gent 6

14 Hoofdstuk 2 P2P-netwerken P1 wil een bestand downloaden en verspreidt (broadcast) zoekberichten naar zijn buren P2, P3 en P4. Indien deze buren het gevraagde bestand niet bezitten, wordt het bericht verder verspreid naar hun eigen buren. Dit proces gaat steeds maar verder en genereert een exponentieel aantal berichten. Om congestie tegen te gaan, dient het aantal berichten dat verstuurd wordt beperkt te worden. Dit wordt gerealiseerd door in het protocol een parameter Time To Live (TTL) mee te gegeven. Bij elke hop wordt de waarde van de TTL met één verminderd. Wanneer de TTL-waarde tot nul gedaald is, wordt het bericht verwijderd uit het systeem. In geval dat het gevraagde bestand gevonden wordt, zal een bevestigingsbericht (QueryHit) teruggestuurd worden naar de oorsprong volgens dezelfde pad gevolgd door het zoekbericht. Dit mechanisme garandeert een volledige anonimiteit aangezien geen enkele peer weet wie gevraagd en wie geantwoord heeft. Gnutella is een robuust protocol daar het falen van een peer niet de rest van het systeem aantast en dus een single point of failure komt niet voor. Daartegenover leidt het Gnutella-protocol tot heel wat trafiek. Als gevolg hiervan zijn de antwoorden traag en niet gegarandeerd, wat leidt tot een lage quality of service. Zelfs wanneer een bestand aanwezig is in het systeem, kan het voorkomen dat het bestand niet kan gevonden aangezien TTL een beperking oplegt op het aantal hops. Er is tevens geen mogelijkheid om te weten of een bestand wel degelijk aanwezig is in het systeem Semi-gecentraliseerde P2P-systemen: KaZaa (Gnutella v0.6) KaZaa is momenteel een zeer populair P2P-programma, dat gebaseerd is op het Gnutella-protocol. Het gebruikt echter een nieuwere versie van Gnutella (Gnutella v0.6) en is in feite een combinatie van gecentraliseerde en gedecentraliseerde P2P-systemen. Hierbij bestaat het netwerk uit peers en ultrapeers. De ultrapeers vormen onderling een pure gedecentraliseerde architectuur. Iedere ultrapeer kan een mediated architectuur vormen met normale peers. Normale peers worden ook leaf nodes genoemd. Elke peer is steeds verbonden met minstens één ultrapeer. Wanneer een peer een verbinding wil opstarten met een ultrapeer, wordt een lijst van bestanden die gedeeld mogen worden, meegegeven aan de ultrapeer. Hierdoor weet een ultrapeer welke bestanden alle verbonden peers bevatten. Bij het initiëren van een zoekopdracht door een peer, wordt de ultrapeer die verbonden staat met de peer, het eerst aangesproken. Deze ultrapeer controleert of het opgevraagde Universiteit Gent 7

15 Hoofdstuk 2 P2P-netwerken bestand in zijn lijst voorkomt. Indien één of meerdere records gevonden worden, wordt een lijst met adressen van peers die het opgevraagde bestand bezitten, opgestuurd naar de oorspronkelijke peer. Deze peer kan dan een rechtstreekse verbinding aangaan met een peer uit de lijst om het bestand te downloaden. Indien geen record gevonden wordt, zal de ultrapeer de zoekopdracht doorsturen naar alle ultrapeers waarmee hij zelf verbonden is. Het gebruik van ultrapeers reduceert het aantal berichten en vermindert de vertraging van antwoordberichten. Door het meegeven van een TTL-parameter kan het aantal verspreide berichten nog verder gereduceerd worden. Ultrapeers kunnen een bottleneck vormen en problemen kunnen optreden indien een ultrapeer faalt. Het aantal leaf nodes per ultrapeer wordt echter beperkt tot ongeveer honderd en indien nodig kunnen leaf nodes echter snel overschakelen naar een andere ultrapeer. Aangezien ultrapeers informatie en adressen bijhouden, is de anonimiteit niet gewaarborgd. Figuur 3 toont een voorbeeld van een semi-gecentraliseerd P2P-systeem zoals Gnutella v0.6. Figuur 3 Een semi-gecentraliseerd P2P-systeem Universiteit Gent 8

16 Hoofdstuk 3. Het Gnutella-protocol 3.1 Algemeen Gnutella is een gedecentraliseerd peer-to-peer systeem. Het laat toe dat servents hun bestanden op het systeem kunnen delen met andere servents die deze bestanden kunnen bekijken en downloaden. Gnutella is dus een protocol om bestanden tussen verschillende nodes uit te wisselen (file sharing protocol). Alle peers zijn in dit model gelijk en kunnen met andere woorden zowel dienst doen als client en als server. Gnutella servents voorzien interfaces (Gnutella-clients) waardoor de gebruikers met andere Gnutella-nodes kunnen connecteren. Voorbeelden van bekende Gnutella-clients zijn: LimeWire: dit is een open source Gnutella-client die geschreven is in Java. Het bevat de recentste versie van Gnutella en kan op de meeste platforms draaien. BearShare: deze is enkel geïmplementeerd voor Windows en wordt regelmatig herzien en bijgewerkt. Gnutella-clients kunnen queries uitvoeren en zoekresultaten bekijken. Ze kunnen ook queries accepteren van andere servents, deze vergelijken met hun eigen locale data en antwoorden met overeenkomstige resultaten. Aan de hand van de zoekresultaten kunnen servents bestanden downloaden. Tegenwoordig zijn twee versies van het Gnutella-protocol in omloop. Gnutella v0.4 werd ontwikkeld in Omdat deze versie tot heel wat trafiek leidde, werd in 2001 Gnutella v0.6 bedacht om het netwerk in een wat meer gestructureerde vorm te organiseren. Het begrip ultrapeer werd gelanceerd waardoor peers van elkaar onderscheiden werden. Het Gnutella-netwerk verliest hiermee zijn homogeniteit want een peer moet nu ofwel een gewone peer (leaf node) ofwel een ultrapeer zijn. Ultrapeers gedragen zich als descriptorrouters en moeten over een grote bandbreedte beschikken. De ultrapeers vormen onderling een pure gedecentraliseerde architectuur (Gnutella v0.4). Iedere ultrapeer kan een client/server architectuur vormen met leaf nodes. Om te kunnen communiceren met andere nodes (ultrapeers of leaf nodes) moeten leaf nodes steeds verbonden zijn met minstens één ultrapeer. In de praktijk zet een leaf node Universiteit Gent 9

17 Hoofdstuk 3 Het Gnutella-protocol slechts een klein aantal connecties op met ultrapeers. Door het onderscheid in peers kan een grotere schaalbaarheid bereikt worden. Ultrapeers vormen in feite de backbone van het logische netwerk. Het logische netwerk is het Gnutella-netwerk. Figuur 4 geeft het verschil tussen het fysische netwerk en het logische netwerk weer. In het fysische netwerk worden er geen onderscheid gemaakt tussen ultrapeers en leaf nodes. In het logische netwerk komen geen routers voor, enkel leaf nodes en ultrapeers. Merk op dat leaf nodes niet rechtstreeks met elkaar communiceren maar steeds via de ultrapeers waarmee ze zijn verbonden. Het downloaden van een bestand gebeurt echter wel rechtstreeks tussen de leaf nodes. Figuur 4 Fysisch en logisch netwerk Voorts toont de figuur dat leaf nodes subnetten vormen die verbonden zijn aan de backbone. Elk node kan beslissen of het een leaf node of een ultrapeer is. Om een ultrapeer te kunnen zijn moet en node volgende vereisten beschikken [1][3]: voldoende bandbreedte mag niet achter een firewall staan zodat inkomende connecties aanvaarden worden voldoende running time voldoende CPU en RAM resources Universiteit Gent 10

18 Hoofdstuk 3 Het Gnutella-protocol 3.2 Protocolberichten Een servent kan volgende berichten sturen [1]: Group membership: Ping Pong Bye Search: Query QueryHit File transfer: Push Group membership Het Gnutella-protocol is gebaseerd op het in stand houden van een aantal TCPconnecties met andere Gnutella-peers. Deze peers worden ook de buren genoemd. Elk node die zich op het Gnutella-netwerk wil aanmelden initieert een gebroadcast Ping-bericht naar al zijn buren. Hierdoor maakt hij zijn aanwezigheid op het netwerk kenbaar. Elk node die een Ping-bericht ontvangt, stuurt het bericht door naar zijn eigen buren en initieert een back-propagated Pong-bericht. Back-propagated houdt in dat het Pong-bericht teruggestuurd wordt volgens de pad die het ontvangen Ping-bericht heeft afgelegd. Het Pong-bericht bevat informatie over de node zoals zijn IP-adres en het aantal en de grootte van de gedeelde bestanden. Een servent kan een Bye-descriptor gebruiken om de remote host in te lichten dat hij zich heeft afgemeld uit het Gnutella-netwerk. De Bye-descriptor is optioneel Search Een Query-bericht is gelijkaardig aan een Ping-bericht behalve dat aan een Query - bericht een zoekstring meegegeven wordt. Query-berichten bevatten tevens informatie die noodzakelijk is om een bestand te downloaden. Ook het Query-bericht wordt gebroadcast naar zijn buren. Elke buurnode controleert of de zoekstring in het Querybericht overeenkomt met bestanden die hij deelt. Indien deze buren het gevraagde bestand niet bezitten, wordt het Query-bericht verder verspreid naar hun eigen buren. In Universiteit Gent 11

19 Hoofdstuk 3 Het Gnutella-protocol geval dat het gevraagde bestand gevonden wordt, zal een back-propagated QueryHitbericht teruggestuurd worden File transfer De Push-descriptor is het enige bericht dat gerelateerd is aan file-transfer. Het is een mechanisme dat firewalled servents toelaat om bestanden aan te bieden op het Gnutella netwerk. 3.3 Headers van berichten Elk Gnutella-bericht heeft een header. De header bevat informatie over het type bericht, hoeveel hops een bericht kan doorgestuurd worden en een unieke identiefier. Tabel 1 beschrijft de verschillende velden in de header van een Gnutella-bericht. Tabel 1 Velden van de header van een Gnutella-bericht Bytes Beschrijving 0-15 Message ID 16 Payload type 17 TTL (Time To Live) 18 Hops Payload length Alle descriptors: Ping, Pong, Bye, Query, QueryHit en Push, zijn gespecificeerd met een vast gedeelte en een variabel gedeelte (Payload Length). De message ID is een unieke code die een bericht identificeert op het Gnutella-netwerk. Het wordt ook de unieke ID (UID) genoemd. Het payload type duidt het type bericht aan. De verschillende mogelijkheden zijn reeds vermeld in paragraaf 3.2. Tengevolge van het broadcasten van berichten kan er veel trafiek in het netwerk ontstaan. Om dit zoveel mogelijk te beperken, wordt aan het bericht een TTL-parameter (Time To Live) meegegeven. Bij elke hop wordt de waarde van de TTL met één verminderd. Wanneer de TTL-waarde tot nul gedaald is, wordt het bericht verwijderd uit het systeem. Merk op dat een hop betrekking heeft tot het logische netwerk en niet in het fysische netwerk. Het geeft het aantal keer voor dat een bericht kan geforward worden. De payload length bevat de lengte van het bericht na de header en mag niet groter dan 4kB zijn [2]. Universiteit Gent 12

20 Hoofdstuk 3 Het Gnutella-protocol 3.4 Descriptor Routing Broadcasten en Back-propagation De berichten (zie paragraaf 3.2 ) kunnen gebroadcast of back-propagated worden. Broadcasten (forward-descriptor) wil zeggen dat een node het bericht verstuurd naar alle nodes waarmee het een TCP-verbinding is aangegaan. Het bericht wordt met andere woorden naar al zijn buren gestuurd. Deze procedure leidt tot een exponentiele toename van het aantal berichten en is afhankelijk van de TTL-parameter. Een node kan hierdoor eenzelfde bericht dit wordt gecontroleerd aan de hand van de message ID meermaals ontvangen. Deze duplicaten worden verwijderd uit het systeem. Ook berichten waar de waarde van de TTL nul heeft bereikt, worden uit het systeem verwijderd. Merk op dat leaf nodes geen berichten mogen forwarden. Voorbeelden van berichten die gebroadcast worden zijn Ping- en Query-berichten. Back-propagation (backward-descriptor) houdt in dat een bericht verstuurd wordt over een specifieke connectie. Een backward-descriptor wordt gegenereerd als een antwoord op een forward-descriptor en volgt de weg die de forward-descriptor heeft afgelegd. Hiervoor is bijgevolg een routing cache nodig die informatie bijhoudt over de forwarddescriptors die door die node zijn gepasseerd. Pong- en QueryHit-berichten zijn backward-descriptors in Gnutella [1] Caches Elk servent heeft twee types caches: Routing cache Topologie van de locale cache De routing cache wordt gebruikt om geforwarde discriptors bij te houden. Dit is een klein stuk geheugen dat noodzakelijk is om herbroadcasting te voorkomen en backpropagation mogelijk te maken. De records in de routing cache bevatten de message ID (UID) en het adres van de peer die de descriptor heeft gestuurd. Door het bijhouden van de message ID kan een peer gedupliceerde berichten ontdekken en verwijderen. De topologie cache wordt gebruikt om de adressen van de buren van de node bij te houden en wordt geïnitialiseerd uit configuratiebestanden van de applicatie. Elk node heeft een verzameling van buren die bij het aanmelden in het Gnutella-netwerk moeten getest worden of ze actief zijn [1]. Universiteit Gent 13

21 Hoofdstuk 3 Het Gnutella-protocol Statische en dynamische routing Statische routing kan enkel in een statisch netwerk gebeuren. Een statisch netwerk is een netwerk dat tijdens de simulatie niet verandert en uit een configuratiebestand kan gelezen worden. Dit wil zeggen dat alle nodes in het statische netwerk tijdens de simulatie actief blijven en zich niet afkoppelen van het netwerk. De topologie cache zal dus ook niet veranderen tijdens de simulatie. In de praktijk komen statische netwerken niet voor aangezien nodes zich continu aanen afschakelen op het systeem. Simulatie op statische netwerken kan echter nuttig zijn om tijdsonafhankelijke P2P topologie-eigenschappen te onderzoeken. Voor meer waarheidsgetrouwe simulatie wordt dynamische routing gebruikt. Aan de hand van Ping-, Pong-, Query- en QueryHit-berichten kan het dynamische netwerk en de caches aangepast worden [1] Het Gnutella-poort en het HTTP-poort Bij het aanmelden op het Gnutella-netwerk wordt niet alleen de IP-adressen van remote peers ontvangen maar ook de poortnummers. Meestal worden twee poorten gebruikt, de Gnutella-poort en de HTTP-poort. De Gnutella-poort wordt gebruikt voor de descriptor routing en de HTTP-poort staat in voor de file transfer (upload en download van bestanden). Wanneer de remote peer zich achter een firewall bevindt, kan de file transfer niet plaatsvinden. De Push descriptor wordt gebruikt om het mogelijk te maken bestanden achter een firewall te downloaden. Een servent die een QueryHit-bericht ontvangt van een servent die geen connecties accepteert, zendt een Push-bericht naar die servent. Een Push-descriptor bevat de velden beschreven in Tabel 2. Tabel 2 Velden van een Push-descriptor Bytes Beschrijving 0-15 Servent identifier File index IP Port Servent identifier is de ID van de servent achter de firewall. File index is de index van het opgevraagde bestand. Het IP-veld en het Port-veld zijn respectievelijk het IP-adres en poortnummer van de servent die het bestand opvraagt. Universiteit Gent 14

22 Hoofdstuk 3 Het Gnutella-protocol Wanneer de servent achter de firewall het Push-bericht ontvangt, probeert het een rechtstreekse verbinding te maken met het aangegeven IP-adres en poortnummer [1]. 3.5 Bootstrapping Servents kunnen zich aanmelden in het Gnutella-netwerk door TCP-connecties aan te gaan met nodes die reeds deel uitmaken van het netwerk (online buren). Nodes kunnen het logische netwerk veranderen door zich aan te melden of het netwerk te verlaten. Bijgevolg is het Gnutella-netwerk een dynamisch netwerk die zich steeds moet reorganiseren tengevolge van veranderingen. Dit proces van aanmelden en reorganiseren wordt bootstrapping genoemd en bestaat uit volgende twee onderdelen [1][4]: Hooking Discovery Hooking Hooking is de fase waarin een node zich probeert aan te sluiten op het Gnutella-netwerk waarbij gebruikt wordt gemaakt van de initiële topologie cache (zie paragraaf ) of GWebCache servers. Eerst wordt in de locale (topologie) cache gezocht naar actieve peers om het initialisatie proces op te starten. Enkel indien dit niet lukt wordt de GWebCache server aangesproken. De GWebCache server bevat informatie over actieve peers en kan dus ingezet worden voor de hooking van aanmeldende peers. Aangezien het gebruik van een centrale server het gedecentraliseerde P2P-model tegenspreekt, moet deze zoveel mogelijk vermeden worden. Servents kunnen met elkaar een connectie aangaan en informatie uitwisselen via een handshakingprotocol. Het Gnutella-handshakingprotocol bestaat uit drie headerblokken. De node die connectie initieert stuurt een initiële header blok zoals hieronder weergegeven [4]: GNUTELLA CONNECT/0.6 Listen-IP: :6346 Remote-IP: User-Agent: Shareaza Accept: application/x-gnutella2 Universiteit Gent 15

23 Hoofdstuk 3 Het Gnutella-protocol X-Ultrapeer: False De ontvanger antwoordt met volgende headerblok: GNUTELLA/ OK Listen-IP: :6346 Remote-IP: User-Agent: Shareaza Content-Type: application/x-gnutella2 Accept: application/x-gnutella2 X-Ultrapeer: True X-Ultrapeer-Needed: False De stichter van de connectie accepteert de headerblok van de ontvanger en voorziet in een volgend bericht enkele finale informatie. GNUTELLA/ OK Content-Type: application/x-gnutella2 X-Ultrapeer: False The latter two stages may be replaced with an error condition if the connection is being rejected. Appropriate error status codes are returned in this case, for example: GNUTELLA/ Too many connections (more headers) Discovery Discovery is een fase waarin een node recente informatie over het dynamische Gnutellanetwerk probeert te vergaren. Deze informatie kan gebruikt worden voor de hooking wanneer de node zich de volgende keer wil connecteren aan het Gnutella-netwerk. Het updaten gebeurt op regelmatige tijdstippen en op basis van ontvangen Pong en QueryHit-berichten en via cache transfers tijdens de handshaking. Universiteit Gent 16

24 Hoofdstuk 3 Het Gnutella-protocol Door gebruik te maken van Ping- en Query-broadcastberichten kunnen heel wat connecties doorlopen worden. Dit zal tot gevolg hebben dat Pong- en QueryHitdescriptors teruggestuurd worden waardoor een aantal actieve peers gevonden worden. Dit aantal is afhankelijk van de TTL-parameter. Bij het Gnutella handshakingproces kan op twee manieren de locale cache geüpdate worden. De eerste manier vindt plaats wanneer een servent een verbinding weigert. In dit geval moet de servent (indien mogelijk) de remote host een lijst van Gnutella-hosts voorzien zodat de remote host met deze kan connecteren. Dit wordt gedaan door middel van een X-Try header. De X-Try header ziet er als volgt uit: X-Try: :1234, :3456 Met deze X-Try header kan de remote servent met twee Gnutella hosts connecteren. Voor elk Gnutella host wordt in de X-Try header het IP-adres en het poortnummer waarnaar geluisterd wordt, meegegeven. De tweede manier gebeurt wanneer een servent connecteert met een remote host. In dit geval wordt gevraagd de locale cache op te sturen. 3.6 Search Het zoeken naar bestanden in het Gnutella-netwerk wordt gedaan met een Querydescriptor. Het bevat een zoekstring en wordt gebroadcast naar alle buurnodes in het logische netwerk. Alle servents die het Query-bericht ontvangen, doorzoeken hun cache waarin de gedeelde bestanden voorkomen. Een QueryHit-descriptor wordt terug gestuurd wanneer de zoekopdracht één of meerdere resultaten oplevert. Ook bestanden die slechts een deel van de zoekstring bevatten worden in de resultatenset opgenomen. De Query Routing Protocol (QRP) is een essentieel onderdeel van de ultrapeerspecificatie [5]. Het zorgt ervoor dat queries beheerd worden door ultrapeers en als gevolg hiervan zeer efficiënt uitgevoerd kunnen worden. QRP bepaalt hoe een ultrapeer een query filtert en doorstuurt naar leaf nodes die zeer waarschijnlijk een QueryHit produceren. Het doel van QRP is om geen queries naar leaf nodes te sturen die geen QueryHit leveren. De realisatie hiervan bij leaf nodes en ultrapeers wordt hierna beschreven. Universiteit Gent 17

25 Hoofdstuk 3 Het Gnutella-protocol Query routing bij leaf nodes Elk leaf node moet de namen van zijn gedeelde bestanden opsplitsen in individuele woorden (tokens). Deze tokens worden omgevormd tot ASCII-karakters en hoofdletters worden omgezet in kleine letters. Woorden kleiner dan drie letters worden niet weerhouden. Er bestaat ook de mogelijkheid meervoudsvormen te elimineren. Vervolgens wordt voor elke token een bekende hash-functie berekend en ingevoerd in een hash-tabel. In plaats hiervan kan ook een aanwezigheidsvlag wordt aangevinkt in het overeenkomstige hash-slot. De boolean vector die in een latere fase opgebouwd wordt, kan optioneel gecompresseerd worden. Het wordt opgedeeld in kleinere berichten en wordt via andere Gnutella-traffic naar de ultrapeer gestuurd Query routing bij ultrapeers Zolang een ultrapeer de boolean vector niet volledig ontvangen heeft van de leaf node, worden alle queries doorgestuurd naar de leaf node. Daarna wordt de boolean vector gebruikt als Query Routing tabel voor die node. Wanneer de ultrapeer een Querydescriptor ontvangt, wordt de query opgesplitst in tokens. Voor elke Query Routing tabel wordt voor elke token een hash-functie berekend. Afhankelijk van de gevolgde regels, moet een aantal tokens voorkomen in de Query Routing tabel zodat een Query Routing hit kan gegenereerd worden. Wanneer een Query Routing hit optreedt, wordt de Query-descriptor naar de leaf node doorgestuurd. 3.7 Download Wanneer een servent een QueryHit-descriptor ontvangt, kan het een directe verbinding initiëren om één van de bestanden uit de resultatenset te downloaden. Dit wil zeggen dat een rechtstreekse verbinding opgezet wordt tussen bron en doelservent om de data transfer uit te voeren. Bestanden worden nooit over het logische Gnutella-netwerk uitgewisseld en het downloadprotocol is HTTP. Universiteit Gent 18

26 Hoofdstuk 4. Netwerksimulator 4.1 Algemeen In dit hoofdstuk wordt toegelicht welke netwerksimulator gebruikt werd voor het bestaande P2P-programma. Voorts worden enkele aspecten van het bestaande programma besproken en wordt er in tabelvorm aangegeven wat van het Gnutellaprotocol geïmplementeerd is in de simulator. 4.2 J-Sim simulator Het bestaande P2P-netwerkprogramma heeft gebruik gemaakt van een bestaande netwerksimulator, namelijk J-Sim. J-Sim is volledig ontwikkeld in Java. Het dynamic thread execution framework in J-Sim zorgt ervoor dat simulaties uitgevoerd kunnen worden in real-time. Dit wordt real-time processed-based simulatie genoemd. De basisentiteiten in J-Sim zijn componenten en een applicatie is een compositie van componenten. Poorten zijn een onderdeel van componenten en worden gebruikt voor de communicatie met andere componenten. J-Sim componenten zijn loosely coupled en autonoom. Met loosely coupled wordt bedoeld dat het gedrag van een component gespecificeerd wordt in termen van contracten ( cookbooks ). Een contract is verbonden aan een specifieke poort of een groep van poorten en definieert de voorwaarden die gerespecteerd moeten worden om datatransfer tussen de componenten die de betreffende poorten bezitten, toe te laten. Met autonoom wordt bedoeld dat wanneer data aankomt op een poort, er een nieuwe thread aangemaakt wordt om het te behandelen. J-Sim definieert een generiek pakket switched netwerkmodel dat bestaat uit abstracte componenten. Een netwerk is een groep van kleinere netwerken, links en nodes. Nodes zijn ook samengestelde componenten die bestaan uit applicaties, protocol modules, en een core service layer (CSL). The core service layer encapsuleert de functies van de fysische, link en netwerk lagen. Upper protocol layer (UPL) bevat transport protocollen, applicaties en andere modulen [1]. Universiteit Gent 19

27 Hoofdstuk 4 Netwerksimulator 4.3 Het bestaande programma Aan de hand van de simulator kunnen verschillende P2P-protocollen onderzocht worden. In het bestaande programma is Gnutella v0.6 geïmplementeerd. Het doel van een simulatieprogramma is volgende hoofdprocessen in een P2P-netwerk te bestuderen: Ontdekken van actieve peers in een dynamisch netwerk Zoeken naar relevante informatie Downloaden van informatie Optimaliseren van queries Optimalisatie van het beheer van de topologie en de trafiek door specifiek gedrag toe te kennen aan de peers (ultrapeers) Dit doel kan bereikt worden door: het genereren van logbestanden het opvolgen van descriptor routing de evolutie van de topologie bij te houden het ontdekken van gedeelde bestanden download- en trafiekstatistieken bij te houden De bestaande applicatie heeft drie types van bestanden nodig: configuratiebestanden (.conf): deze bestanden definiëren het fysische en logische netwerken simulatiebestand (.in): dit is een bestand dat gebruikt wordt om commando s door te geven aan de simulator logbestand (.log): dit is een outputfile die de simulatieresultaten toont Deze bestanden worden in het volgende hoofdstuk nader toegelicht. Momenteel zijn er drie types instructies mogelijk, namelijk: Discovery Search Download De betekenis van deze berichten werd reeds in Hoofdstuk 3 uitgelegd. Universiteit Gent 20

28 Hoofdstuk 4 Netwerksimulator 4.4 Gnutella-implementatie In Tabel 3 wordt aangegeven welke elementen uit het Gnutella-protocol dat in het vorige hoofdstuk besproken werd, geïmplementeerd is. Tabel 3 Implementatie van het Gnutella-protocol Implementatie Ja Nee Leaf nodes x Ultrapeers x Ping-descriptor x Pong-descriptor x Bye-descriptor x Query-descriptor x QueryHit-descriptor x Push-descriptor x Broadcasting x Back-propagation x Topologie cache x Routing cache x Static Routing x Dynamic Routing x 1 Hooking 2 x GWebCaches x Handshaking x Discovery d.m.v. Pong en QueryHit x Cache transfer 3 x 1 Dynamische routing is voorlopig enkel geïmplementeerd op basis van het Ping/Pong-mechanisme. 2 Hooking is enkel door middel van de topologie cache geïmplementeerd. 3 De cache transfer functionaliteit is geïmplementeerd, niet volgens de X-Try headers specificatie maar als een reguliere download via de file transfer (HTTP) socket. Universiteit Gent 21

29 Hoofdstuk 5. Input- en outputbestanden 5.1 Algemeen Vanaf hier wordt het bestaande P2P-programma als een black box beschouwd. Het programma voert een P2P-netwerksimulatie uit op basis van invoergegevens. Het programma zal na de simulatie een logbestand genereren met resultaten van de simulatie. Deze werkwijze wordt in Figuur 5 visueel weergegeven. Via de GUI worden bepaalde gegevens, bijvoorbeeld het tekenen van een netwerk, ingegeven. Wanneer alle gegevens ingevoerd zijn, worden de verschillende inputbestanden aangemaakt en vervolgens kan de simulatie beginnen. Wanneer de simulatie afgelopen is, zal het gegenereerde outputbestand ingelezen worden. In dit hoofdstuk worden de inhouden van deze invoer- en uitvoerbestanden nader bekeken. In Hoofdstuk 6 wordt uitgelegd hoe voor de invoergegevens een Graphical User Interface (GUI) ontwikkeld is. Het daaropvolgende hoofdstuk legt uit hoe de informatie uit het outputbestand gefilterd en aan de gebruiker getoond wordt. Figuur 5 De verschillende onderdelen van het geïntegreerde programma Universiteit Gent 22

30 Hoofdstuk 5 Input- en outputbestanden Vooreerst moet steeds een directory root aangemaakt worden. In deze folder worden alle bestanden verzameld bestaat uit: request.in: dit is een bestand dat bestaat uit commando s om de simulator aan te sturen (zie paragraaf ). topology.conf: dit is een configuratiebestand dat de definitie van het fysische netwerk weergeeft (zie paragraaf ). een subfolder per logische node en een storage folder(zie paragraaf ). output.log: dit is het logbestand dat automatisch aangemaakt wordt bij het uitvoeren van het P2P netwerksimulatieprogramma en bevat de resultaten van de simulatie (zie paragraaf 5.3 ). 5.2 Inputbestanden Simulatiecommando s Het bestand request.in bevat simulatiecommando s die de simulator aansturen. De simulatiecommando s komen in groepen voor. Er zijn twee regimes, namelijk gelijktijdig of sequentieel. Gelijktijdige instructies worden simultaan gestart en er is geen garantie over de volgorde hun uitvoering. Lege regels en regels die beginnen met een sterretje worden genegeerd. De structuur van request.in wordt in Tabel 4 weergegeven: Tabel 4 De structuur van request.in Sessie 1 #... Sessie n # Sessie k: Commando 1... Commando n Een #-teken maakt een onderscheid tussen verschillende sessies. De sessies worden sequentieel uitgevoerd. De commando s in één sessie worden gelijktijdig uitgevoerd. Universiteit Gent 23

31 Hoofdstuk 5 Input- en outputbestanden Er is sterke input datavalidatie zodat geen corrupte simulatiefile uitgevoerd wordt. Tabel 5 geeft een voorbeeld van een correct request.in bestand: Tabel 5 Voorbeeld van een inputbestand P # Q # D # Momenteel zijn er drie commando s (requests) geïmplementeerd. Deze commando s zijn gebaseerd op de requests in het Gnutella protocol. Ze bevatten een aantal argumenten die hieronder worden uitgelegd. Een Ping-request bevat vier argumenten: Argument 1: De letter P duidt aan dat het om een Ping-request gaat. Argument 2: Dit is het fysische adres van de node die de Ping-request verstuurt. Argument 3: Dit is de initiële TTL van de Ping-descriptor Argument 4: Dit is de initiële TTL van de corresponderende Pongdescriptor Een Query-request bevat zes argumenten: Argument 1: De letter Q duidt aan dat het om een Query-request gaat. Argument 2: Dit is het fysische adres van de node die de Query-request verstuurt. Argument 3: Dit is de initiële TTL van de Query-descriptor Argument 4: Dit is de initiële TTL van de corresponderende QueryHitdescriptor Argument 5: Dit is de bandbreedte van alle links. Er wordt aangenomen dat alle links dezelfde bandbreedte hebben. Argument 6: De string tussen is de zoekstring van Query. Een Download-request bevat vier argumenten: Argument 1: De letter D duidt aan dat het om een Download-request gaat. Universiteit Gent 24

32 Hoofdstuk 5 Input- en outputbestanden Argument 2: Dit getal geeft aan om welke Download-request type het gaat. Het getal nul betekent dat de download op de traditionele manier gebeurt. Het getal één betekent dat de download op basis van swarming gebeurt. Swarming wil zeggen dat een bestand in delen wordt gesplitst en dat deze delen vanuit verschillende plaatsen gedownload worden. Swarming is momenteel nog niet geïmplementeerd. Argument 3: Dit is het fysische adres van de node die het bestand ontvangt. Argument 4: Dit getal bepaalt welke template gedownload wordt uit de lijst van resultaten van de query. Merk op dat elk node in het fysische netwerk een uniek nummer krijgt dat in feite overeenkomt met het IP-adres in de werkelijkheid. Hiermee wordt ook de implementatie eenvoudiger. De noden blijven hun nummer behouden in het logische netwerk Topologie van het netwerk Het fysische netwerk wordt voorgesteld door middel van een graaf. Er wordt een onderscheid gemaakt tussen hosts en routers. Routers komen niet voor in het logische netwerk. De edges van de graaf stellen connecties voor, met elk een propagation delay. Alle nodes hebben een bandbreedte dat de trafiek doorheen hen limiteert. Het logische netwerk (Gnutella-netwerk) wordt ook voorgesteld als een graaf, waarin de nodes peers worden genoemd. Alle buren van een peer zijn ontdekte peers die bewaard worden in de topologie cache. De structuur van topology.conf wordt in Tabel 6 weergegeven. Tabel 6 De structuur van topology.conf Np (aantal nodes in het fysische netwerk) (open regel) buren van node p[0] (p[0]... p[np - 1] = fysische nodes) buren van node p[np 1] (open regel) propagation delay bandbreedte (open regel) Universiteit Gent 25

33 Hoofdstuk 5 Input- en outputbestanden fysische adressen van alle logische nodes (open regel) Statisch routing? (y/n) Swarming? (y/n) Merk op dat in de lijst {p[0], p[1],,p[np-1]} alle routers van het netwerk eerst komen te staan. Dit wil zeggen dat als een netwerk twee routers bezit, dan zullen p[0] en p[1] de buren van de twee routers weergeven. Tabel 7 geeft een voorbeeld van een correct topology.conf bestand: Tabel 7 Voorbeeld van topology.conf Nodes y n Voor alle nodes, met uitzondering van de routers, wordt een folder aangemaakt met de naam nk. Hierbij is k het fysische adres van de node. Als bijvoorbeeld een node een leaf node is met het nummer 10, dan wordt een folder met de naam n10 aangemaakt. In elke folder wordt vervolgens drie nieuwe folders en een bestand aangemaakt: Universiteit Gent 26

34 Hoofdstuk 5 Input- en outputbestanden complete incomplete shares topology.conf In de complete folder komen de bestanden die gedownload worden terecht. Wanneer de download niet compleet is, wordt het bestand in de incomplete folder geplaatst. De shares folder is een folder die de gedeelde bestanden bevat. De storage folder beschikt over een aantal bestanden die automatisch aangemaakt worden. Deze bestanden worden willekeurig verspreid naar alle shares folders zodat alle nodes beschikken over bestanden die ze kunnen delen. Hoe dit exact verloopt, wordt in het volgende hoofdstuk uitgelegd. Er wordt tenslotte een bestand topology.conf geproduceerd, wat niet te verwarren is met het bestand uit paragraaf De inhoud van het bestand wordt via Tabel 8 weergegeven. Tabel 8 De structuur van topology.conf Is node initieel actief? (y/n) Is node een ultrapeer? (y/n) s[0].. s[ns - 1] = statische buren van de node (ns = number of static neighbours) Tabel 9 geeft een voorbeeld van een correct topology.conf bestand: 5.3 Outputbestand Tabel 9 Voorbeeld van topology.conf y y 4 6 Nadat de simulatie afgelopen is, wordt een logbestand (output.log) aangemaakt dat informatie over de verstuurde berichten en de simulatie zelf bevat. Wegens de grootte van het bestand wordt hier niet een volledig voorbeeld gegeven, maar worden de belangrijkste delen toegelicht. Het logbestand kan opgedeeld worden in vijf onderdelen. Resultaten van Ping en Pong berichten Updates Universiteit Gent 27

35 Hoofdstuk 5 Input- en outputbestanden Resultaten van Query en QueryHit berichten Gevonden templates Download resultaat Voor elk onderdeel wordt in tabelvorm een voorbeeld gegeven. De structuur van de resultaten van Query- en QueryHit-berichten is analoog aan die van de Ping- en Pongberichten. Tabel 10 Voorbeeld van een Ping bericht Time: simulatietijd Logical Node: 6 fysisch adres van de node UID: UID van het bericht Descriptor of type Ping type bericht TTL: 8 Hop Count: 2 TTL + hopcount Root: 4 fysisch adres van de node die de request verstuurd heeft Source: 5 fysisch adres van de node die het bericht verstuurd heeft Static Broadcast to active static neighbours actie die de node wil verrichten Destination: 4 fysisch adres van de bestemming van deze actie Send pong actie die de node verricht Destination: 5 fysisch adres van de bestemming van deze actie Iedere sessie wordt in het logbestand afgesloten ( End of session n ) met sessiespecifieke informatie (afhankelijk van de soort requests die behandeld werden in de sessie). Tabel 11 Updates voor node 4 Dynamic neighbours of node 4: Node 5 sharing 3 files, 0 KB Node 6 sharing 3 files, 0 KB Universiteit Gent 28

36 Hoofdstuk 5 Input- en outputbestanden Tabel 12 Resultaten van de query Logical node:114 Search results, querystring = a swarming = false counttemplates=22 Template 0: File Name: a.txt File Size: 24 Hash Value: 5665 Remote Address: 515 File Index: 0 fysisch adres van de node die Query-request heeft verstuurd de desbetreffende zoekstring wordt er swarming gebruikt? aantal templates = resultaten templatenummer bestandsnaam bestandsgrootte hash-waarde fysisch adres van de node die de file shared file index van de file in de sharelist van de node die de file sharet Tabel 13 Resultaat van de download Node 114 has downloaded template 0 Melding of node al dan niet succesvol een template heeft gedownload. Universiteit Gent 29

37 Hoofdstuk 6. Implementatie van de input 6.1 Java en Swing Aangezien de simulator in de Java programmeertaal geschreven is, werd gekozen om de GUI ook in Java te ontwikkelen. Java maakt het, aan de hand van de Abstract Window Toolkit (AWT) klasse en de JFC-klasse, zeer eenvoudig GUI s te ontwerpen. AWT is de originele grafische bibliotheek van Java waarop de JFC-klasse gebaseerd is. De JFCklasse is beter bekend onder de bijnaam Swing. Swing is een bouwpakket dat grafische gebruikersinterfacecomponenten bevat. Het behoudt de basisstructuur van de AWT klasse, maar voegt er heel wat eigenschappen aan toe. De Swing componenten zijn meer flexibel dan deze uit de AWT klasse omdat ze volledig in Java zijn geïmplementeerd. Ze zijn bijgevolg platformonafhankelijk. Bovendien bezitten de Swing componenten ook een wijzigbare look & feel, waardoor ze het uitzicht van een component kan veranderen. In een grafische applicatie kunnen over het algemeen drie types van objecten onderscheiden worden: Applicatieobjecten zijn verantwoordelijk voor: het definiëren van de componenten die de gebruiker te zien moet krijgen het definiëren van de lay-out van deze componenten de logica van de applicatie De interfaceobjecten zijn verantwoordelijk voor: de eigenlijke visualisatie van het object het onderscheppen van de interactie van de gebruiker De luisterobjecten zijn verantwoordelijk voor: de uitvoer van de nodige actie bij interactie van de gebruiker Alle klassen die gebruikt worden voor het ontwerp van de GUI worden in op de volgende manier gehanteerd. Alle nodige Swing-componenten worden aangemaakt. Deze componenten worden, op basis van een gekozen lay-outmanager, op de juiste positie geplaatst. Daarna worden de luisterobjecten gecreëerd. Deze luisterobjecten worden dan geassocieerd aan hun Swing-objecten. Dit wil zeggen dat een link gelegd wordt tussen de luisterobjecten en de Swing-objecten. Wanneer de gebruiker een Universiteit Gent 30

38 Hoofdstuk 6 Implementatie van de input bepaalde actie uitvoert, bijvoorbeeld het drukken op een knop, zal de betrokken luisteraar opgeroepen worden. De luisteraar bevat een aantal actie die uitgevoerd dienen te worden [6]. 6.2 De structuur van de GUI Het hoofddoel van deze scriptie is het ontwerpen van een GUI voor het genereren van de inputbestanden (zoals besproken in Hoofdstuk 5) en voor het parsen van het outputbestand. De structuur van het geïntegreerde programma (GUI en simulator) wordt getoond in Figuur 6. De tekening geeft aan hoe het programma wordt opgestart en hoe de klassen zich binnen andere klassen situeren. Figuur 6 De structuur van het geïntegreerde programma Om het programma te runnen, moet het bestand run.bat geactiveerd worden. Dit bestand bevat volgende instructie: java -classpath jgraph.jar;jlfgr-1_0.jar;jsim13.jar;. Start Universiteit Gent 31

39 Hoofdstuk 6 Implementatie van de input Hiermee wordt het hoofdbestand Start.java en samen met drie jarfiles opgestart. De drie jarfiles zijn bibliotheken die bepaalde functionaliteiten bieden. De bibliotheek JGraph zorgt ervoor dat grafen, waarin noden (vertices), verbindingen (edges) en poorten (ports) getekend kunnen worden. De klassen DrawGraph (zie paragraaf 6.4) en Output (zie paragraaf 7.2 ) maken hiervan gebruik. De bibliotheek jlfgr-1_0 bevat standaard tekeningen die gebruikt kunnen worden om knoppen in de toolbar te verfraaien. Het wordt gebruikt in de klasse DrawGraph. De laatste bibliotheek, J-Sim, zorgt ervoor dat de simulatie kan uitgevoerd worden en wordt in de klasse Gnutella aangewend. Zoals Figuur 6 aangeeft, worden in de klasse Start drie hoofdtaken georganiseerd: GUI (INPUT): deze taak wordt uitgevoerd door de klassen DrawGraph en ViewButton. In de klasse DrawGraph worden de klassen VertexInfo, EdgeInfo, WriteTopologyConf, WriteNodeTopologyConf, WriteRequestIn en StorageFiles gebruikt. SIMULATIE: deze taak wordt uitgevoerd door de klasse Gnutella en behoort niet tot de GUI. De klassen die in Gnutella worden gebruikt, zijn niet weergegeven in de figuur. GUI (OUTPUT): deze taak wordt vervuld door de klasse Output. Ouput maakt gebruik van de klassen MessageTable, MessageGraph, SearchResult en Statistic. De klasse Start voert dus deze drie taken chronologisch uit. Eerst wordt de GUI aangesproken (GUI INPUT) voor de invoer van gegevens. Wanneer de gebruiker de gegevens ingevuld heeft en kan de simulatie uitgevoerd worden. Na de simulatie zal de GUI (GUI OUTPUT) de resultaten van de simulatie tonen. In dit hoofdstuk wordt het ontwerp voor het aanmaken van de inputbestanden toegelicht. Dit wil zeggen dat de klassen onder GUI (INPUT) besproken worden. Om de structuur van het programma beter te begrijpen wordt eerst de klasse Start nader bekeken. In het volgende hoofdstuk wordt de aandacht gevestigd op de klasse Output. In de verschillende klassen die hieronder besproken worden, hebben de meeste gegevenselementen een private zichtbaarheid (zichtbaar binnen de klasse zelf) en de actie-elementen een publieke zichtbaarheid (zichtbaar voor alle klassen). Soms kunnen de gegevenselementen een beschermde zichtbaarheid (protected) hebben. Hierdoor zijn die gegevenselementen naast de eigen klasse ook zichtbaar in zijn subklassen. Universiteit Gent 32

40 Hoofdstuk 6 Implementatie van de input 6.3 Start De klasse Start zorgt voor de organisatie van de verschillende taken die uitgevoerd dienen te worden. In Figuur 7 wordt de ULM-schema van Start gegeven. Een UMLschema van een klasse bestaat uit drie onderdelen. Het eerste onderdeel geeft de naam van de klasse. Het tweede onderdeel bevat de gegevenselementen. In het laatste onderdeel worden de methoden in de klasse weergegeven. De figuur geeft aan dat de klasse van JFrame overerft en de interface ActionListener gebruikt. De ActionListener-interface zal gebruikt worden voor de interactie met de gebruiker. Figuur 7 UML-schema van Start.java Bij het opstarten van het programma wordt de constructor van de klasse opgeroepen waarbij de titel van het project P2P network simulator wordt meegegeven. De constructor heeft als taak de GUI op te zetten. Er is gekozen om de GUI aan te maken aan de hand van een JDesktopPane object. JDesktopPane is een container voor meervoudige documentinterfaces. Door JInternetFrame objecten aan te maken en ze toe te voegen aan het JDesktopPane object kunnen meerdere interface simultaan getoond Universiteit Gent 33

41 Hoofdstuk 6 Implementatie van de input worden. Met de methode createframegraph() wordt het DrawGraph object toegevoegd aan het JDesktopPane object. Met de methode createframebuttons() wordt het ViewButtons object toegevoegd aan het JDesktopPane object. Bijgevolg dienen de klassen DrawGraph en ViewButtons over te erven van JInternalFrame. De klasse Start bevat daarnaast nog twee andere klassen, namelijk ListenGraphPanel en ListenButtonPanel. Deze klassen treden op wanneer de JInternalFrames (drawgraph en viewbuttons) door de gebruiker afgesloten worden. Het is daarom noodzakelijk eerst de klassen DrawGraph en ViewButtons uit te leggen alvorens over te gaan naar de klassen ListenGraphPanel en ListenButtonPanel (zie paragrafen 6.6 en 6.7 ). Figuur 8 toont een vereenvoudigde afbeelding van Start.java DrawGraph Algemeen Figuur 8 Start.java en de twee JInternalFrames De hoofdtaak van de klasse DrawGraph is er voor te zorgen dat een P2P netwerk kan ingevoerd worden door de gebruiker. Deze klasse erft, zoals reeds vermeld, over van de klasse JInternalFrame, wat noodzakelijk is om getoond te kunnen worden. Bij het 4 De afbeeldingen van DrawGraph en ViewButton zijn te groot om ze op één tekening weer te geven. De twee JInternalFrames zullen in paragraaf 6.4 en 6.5 getoond worden. Universiteit Gent 34

42 Hoofdstuk 6 Implementatie van de input oproepen van deze klasse zal de constructor de titel van het venster op Graph Panel zetten. De gebruiker heeft de mogelijk het venster te vergroten of te verkleinen, maximaliseren, minimaliseren en te sluiten. Voor deze gebruikersinterface werd gekozen voor een BorderLayout aangezien hiermee een duidelijke en gestructureerde lay-out wordt bekomen. In Figuur 9 wordt een afbeelding van DrawGraph.java getoond. De gebruikersinterface bestaat uit: drie taakbalken twee tabbladen (het fysische netwerk, het logische netwerk) een knop om de simulatie te starten (initieel gedeactiveerd). Figuur 9 DrawGraph.java Constructor Er wordt een panel aangemaakt waarin de drie taakbalken naast elkaar geplaatst kunnen worden. Elk taakbalk is van de klasse JToolbar en bevat een aantal knoppen. Door de seticon commando kan elke knop gedecoreerd worden met een icoon. De iconen bevinden zich in de bibliotheek jlfgr-1_0 die met opstarten van het programma waren meegegeven. Voor de gebruiksvriendelijkheid worden de knoppen van uitleg voorzien via settooltip commando. De functies van de verschillende knoppen worden in paragraaf besproken. Universiteit Gent 35

43 Hoofdstuk 6 Implementatie van de input Hierna worden de twee tabbladen aangemaakt. Daarvoor werd eerst een JTabbedPane object geïnstantieerd. In beide tabbladen wordt een JGraph-object toegevoegd. Met de JGraph-klasse kunnen objecten en hun onderling verbanden gevisualiseerd worden. Een JGraph bevat in feite geen data, het is slecht een manier om de data te visualiseren. De objecten die JGraph kan voorstellen worden cellen genoemd. Cellen kunnen volgende objecten zijn: Vertex Edge Port (poort) Deze drie cellen worden in Figuur 10 gevisualiseerd. Voor een netwerk komt een vertex overeen met een node. Een edge is een (TCP) verbinding en een port is voor te stellen als een socket. Alle vertices moeten ten minste één port bezitten om verbindingen met andere vertices te kunnen maken. Een edge verbindt aldus twee ports met elkaar waardoor dus ook de vertices met elkaar in verbinding komen te staan. Elke edge heeft steeds een source en een target. De source is de vertex die de verbinding opzet en de target is de vertex (port) die de verbinding accepteert. Deze laatste twee termen zijn louter informatief. Figuur 10 De verschillende vormen van een cell In het eerste tabblad wordt het fysische netwerk getekend. Aangezien het logische netwerk meestal verschillend is van het fysische netwerk, moet de gebruiker in het tweede tabblad het logische netwerk ingeven. Routers kunnen nooit voorkomen in het logische netwerk. Er is bijgevolg een maatregel getroffen waardoor de routerknop niet werkzaam wordt wanneer het tweede tabblad actief is. Voorts wordt er een knop aangemaakt zodat de simulatie van start kan gaan. Deze knop is initieel gedeactiveerd daar de simulatie niet mag starten zonder dat de gegevens die ingevuld moeten worden in het venster van het ViewButtons object, opgeslagen zijn. Er moet opgemerkt worden dat de gegevens in het ViewButtons object enkel kunnen ingevuld kunnen worden indien het netwerk getekend is. Figuur 11 toont de juiste werkwijze om de simulator op te starten. Universiteit Gent 36

44 Hoofdstuk 6 Implementatie van de input Figuur 11 Werkwijze om de simulatie te kunnen starten Tenslotte worden aan alle knoppen een luisterobject gekoppeld zodat interactie met de gebruiker mogelijk wordt Taakbalken De verschillende taakbalken bevatten knoppen die de gebruiker toelaten een netwerk te tekenen, aanpassen of verwijderen. In deze paragraaf worden de functionaliteiten van de knoppen van de verschillende taakbalken besproken. De middelste en de laatste taakbalk zal eerst toegelicht worden aangezien hiermee een netwerk kan gebouwd worden Taakbalk 1 Deze taakbalk bevat drie knoppen zoals te zien is in Figuur 12. Figuur 12 Taakbalk 1 De drie knoppen werken gelijkaardig. Wanneer een knop ingedrukt wordt, zal een vertex aangemaakt en op grafiek getoond worden. Hiervoor wordt telkens de methode createvertex opgeroepen. Deze methode creëert voor elk vertex een standaardpoort zodat later de vertices met elkaar verbonden kunnen worden. Een vertex kan dus een router, ultrapeer of een computer (leaf node) zijn. De vertices verschijnen op een welbepaalde plaats op het scherm bij het indrukken van een knop. Deze plaats verschuift steeds bij het aanmaken van een nieuwe vertex. Hierdoor worden de vertices niet over elkaar getekend en kan de gebruiker onmiddellijk zien wat reeds aangemaakt is. Volgende figuur verduidelijkt dit. Figuur 13 Cascade van vertices Universiteit Gent 37

45 Hoofdstuk 6 Implementatie van de input Routers worden steeds in het blauw getekend, ultrapeers in het groen en computers in het geel. De naamgeving van de vertices gebeurt automatisch en volgens een aantal regels. Elke vertex bevat een letter gevolgd door een getal. Routers krijgen de letter R, ultrapeers de letter U en computers de letter C. Het getal duidt aan als hoeveelste vertex een bepaalde vertex aangemaakt is, beginnende van nul. Dit wil zeggen dat een vertex met de naam C6 een computer (leaf node) is en dat het als zevende vertex aangemaakt is. Wanneer echter een router gecreëerd wordt, gelden deze regels niet meer. Routers moeten steeds in het begin van de aangemaakte rij vertices komen te staan. De reden hiervoor is in paragraaf uitgelegd. Dit wil dus zeggen dat wanneer in het voorbeeld in Figuur 13 een router aangemaakt wordt, deze de naam R3 krijgt aangezien er reeds twee andere routers aanwezig zijn. Het getal in de naam van de andere vertices (alle andere vertices behalve de routers) wordt vermeerderd met één. Dit wordt gerealiseerd door de methode renamecells(). De methode doorloopt alle cellen en controleert of alle routers in het begin van de rij staan. In het geval er reeds verbindingen getekend waren, wordt de situatie een beetje complexer. Zoals in Figuur 10 te zien was, worden edges ook benoemd. Dit wordt gedaan door de getallen in de namen van de twee vertices, die met elkaar verbonden zijn, naast elkaar te schrijven, gescheiden door een - teken. In Figuur 10 zijn bijvoorbeeld U0 en U1 met elkaar verbonden. Dit wil dus zeggen dat de edge 0-1 wordt genoemd. Wanneer een router toegevoegd wordt, krijgt deze de naam R0. De methode renamecells zorgt ervoor dat de twee ultrapeers van naam veranderen en U1 en U2 worden. Merk op dat de naam van de edge dezelfde gebleven is. Dit is niet juist en dient aangepast te worden. De methode renamecells zal bij het doorlopen van alle cells ook de edges tegenkomen. Voor elke edge kunnen de sourcevertex en targetvertex opgevraagd worden. Hierdoor kan een edge eenvoudig juist benoemd worden. Het is belangrijk op te merken dat er voor gezorgd is dat bij het invoeren van een ultrapeer of een computer in het fysische netwerk automatisch dezelfde vertex in het logisch netwerk aangemaakt wordt. Dit gebeurt niet bij het creëren van een router aangezien er geen routers in het logische netwerk mogen voorkomen Taakbalk 2 Deze taakbalk bevat vier knoppen zoals te zien is in Figuur 14. Universiteit Gent 38

46 Hoofdstuk 6 Implementatie van de input Figuur 14 Taakbalk 2 Remove De remove knop kan vertices en edges verwijderen uit de tekening. Een aantal zaken dienen hierbij in acht genomen te worden. Indien een node wordt verwijderd in het ene netwerk, moet dezelfde node ook verwijderd worden in het ander netwerk. Indien een edge wordt verwijderd in het ene netwerk, mag dezelfde edge (indien deze bestaat) in het ander netwerk niet verwijderd worden. Bij het verwijderen van een node het kan voorkomen dat bepaalde verbindingen verbroken moeten worden waardoor er losse edges ontstaan. Deze edges moeten automatisch geëlimineerd worden. Door te ontdekken welke tabblad actief is en de geselecteerde cellen af te lopen kan er aan deze eisen tegemoet gekomen worden. Cellen kunnen ook verwijderd worden door erop rechts te klikken zodat een popup tevoorschijn komt. Figuur 15 toont hoe dit te werk gaat. Figuur 15 Popup window om een cell te verwijderen Om dit mogelijk te maken, moet een MouseListener object aangemaakt en gekoppeld worden aan beide grafen (JGraph). De inhoud van de popup is een JMenuItem. Universiteit Gent 39

47 Hoofdstuk 6 Implementatie van de input Connect Deze knop is verantwoordelijk voor het connecteren van twee of meerdere vertices. Wanneer twee vertices geselecteerd worden, kan er eenvoudig een edge aangemaakt worden. Dit wordt gedaan door de methode connectnode waarbij de poorten van de vertices met elkaar geconnecteerd worden. Wanneer meerdere vertices geselecteerd worden, zal een verbindingslijn getrokken worden door alle mogelijke combinaties tussen vertices. In volgende versies van de GUI kunnen slimmer verbindingsmethode geïmplementeerd worden waarbij bijvoorbeeld het type van de vertices een rol speelt. Merk op dat het aanmaken van een edge in het ene netwerk het ander netwerk niet mag wijzigen. Grid Deze knop wordt gebruikt om de grid al dan niet weer te geven. Een grid is een patroon van punten op een tekening. Hiermee kan de gebruiker de vertices gemakkelijker positioneren ten opzichte van elkaar. Figuur 16 toont dezelfde voorbeeld als Figuur 10 maar met een grid. Figuur 16 Visualisatie van de gridpatronen Universiteit Gent 40

48 Hoofdstuk 6 Implementatie van de input Show Deze knop is louter toegevoegd voor foutendetectie. Momenteel laat het toe hiermee de buren van de verschillende vertices op de console-output te laten zien. Het bepalen van de buren van een vertex is een essentieel onderdeel van de GUI aangezien hiermee het bestand topology.conf kan aangemaakt worden. Hiervoor wordt beroep gedaan op de klasse VertexInfo. De UML-schema van de VertexInfo ziet er uit zoals is weergegeven in Figuur 17. Figuur 17 UML-schema van VertexInfo.java Deze klasse houdt dus het nummer, de positie, de afmetingen, het type en de label van de vertex bij. Voor elke vertex kan een object van deze klasse gecreëerd worden. Alle VertexInfo objecten worden vervolgens gebundeld in een Vector die dient om de methode showvertexvector op te roepen. Deze methode doorloopt alle VertexInfo objecten en laat alle gegevenselementen ervan zien Taakbalk 3 Deze taakbalk bevat drie knoppen zoals te zien is in Figuur 18. Figuur 18 Taakbalk 3 Universiteit Gent 41

49 Hoofdstuk 6 Implementatie van de input Clear Met deze knop kan de gebruiker het netwerk volledig verwijderen. Dit wordt simpelweg gedaan door alle cellen in JGraph te elimineren. Open Hiermee kan een netwerk vanuit een bestand geopend worden. Zulke bestanden zijn van de vorm voorgesteld in Tabel 14. Tabel 14 Netwerk.txt PHYSICAL NETWORK Router R Router R Router R Computer C Ultrapeer U Ultrapeer U Computer C Computer C Computer C Ultrapeer U Ultrapeer U Ultrapeer U Computer C Computer C Computer C Computer C Computer C Computer C Computer C Computer C20 3 LOGICAL NETWORK Computer C Ultrapeer U Ultrapeer U Computer C7 6 Universiteit Gent 42

50 Hoofdstuk 6 Implementatie van de input Computer C Computer C Ultrapeer U Ultrapeer U Ultrapeer U Computer C Computer C Computer C Computer C Computer C Computer C Computer C Computer C20 5 Save Hiermee wordt de inhoud van de vector van VertexInfo objecten naar een bestand geschreven. Dit netwerk kan later geopend worden met de openknop. Door het aanmaken van een JFileChooser object kunnen de gegevens opgeslagen worden. Een afbeelding van de JFileChooser wordt getoond in Figuur 19. Universiteit Gent 43

51 Hoofdstuk 6 Implementatie van de input 6.5 ViewButtons Figuur 19 JFileChooser De gebruikersinterface van ViewButtons laat toe gegevens aan de gebruiker op te vragen zodat het bestand request.in (zie paragraaf ) kan samengesteld worden. Om het ontwerp eenvoudig te houden, werd gekozen steeds de standaardcommando s zoals in Tabel 5 te hanteren. Dit wil dus zeggen dat er steeds drie sessies geopend worden, waarbij achtereenvolgens een Ping commando, een Query commando en een Download commando uitgevoerd worden. Deze drie commando s zijn voldoende om heel wat onderzoek uit te kunnen voeren in verband met congestie. In de toekomst kan de GUI uitgebreid worden door simultane commando s (bijvoorbeeld twee Ping-commando s tegelijk) toe te laten. Universiteit Gent 44

52 Hoofdstuk 6 Implementatie van de input Om de noodzakelijke gegevens op te vragen, werd de gebruikersinterface in Figuur 20 ontwikkeld. Figuur 20 ViewButtons.java Universiteit Gent 45

53 Hoofdstuk 6 Implementatie van de input Hierin is Start Node de node die de zoekopdracht initieert, TTLping, TTLpong, TTLquery en TTLqueryHit zijn de TTL s voor respectievelijk de Ping, Pong, Query en QueryHit-descriptors. In het veld Bandwidth moet de bandbreedte van een link ingevuld worden. Er wordt verondersteld dat alle links over dezelfde bandbreedte beschikken. In het veld Propagation Delay dient de propagatievertraging aangegeven te worden. In het tekstveld van Search moet de zoekstring ingegeven worden. Dit kan de naam van het bestand zijn, of een onderdeel van de naam van een bestand. Met de knop Open New Directory wordt een JFileChooser object geopend waarin de gebruiker een folder moet aanmaken. In de aangemaakte folder zullen later alle inputen outputbestanden terecht komen. Dit is belangrijk om alle bestanden bij elkaar te houden. De knop Save Input zorgt ervoor dat het bestand request.in aangemaakt en in de juiste folder geplaatst wordt. Alvorens dit uit te voeren, wordt nagegaan of alle invulvelden ingevuld zijn en correct waarden bevatten. In Tabel 15 worden de mogelijke waarden voor de verschillende velden aangegeven. Tabel 15 Invulwaarden voor ViewButtons.java Veld Start Node TTLping TTLpong TTLquery TTLqueryHit Bandwidth Propagation Delay Search Open New Directory Toegelaten waarden int int int int int int double String Path (String) Universiteit Gent 46

54 Hoofdstuk 6 Implementatie van de input Figuur 21 Mogelijke foutmeldingen Indien aan deze voorwaarden niet voldaan wordt, verschijnen er foutmeldingen in het Warning vakje. Figuur 21 toont mogelijke foutmeldingen. Wanneer er geen enkele foutmelding optreedt, zal het bestand request.in geschreven worden. Dit wordt uitgevoerd door de klasse WriteRequestIn. Het schrijven naar een file kan gerealiseerd worden via volgende instructies: File file = new File(directory, "request.in"); PrintWriter out = new PrintWriter(new BufferedWriter(new FileWriter(file))); //schrijf gegevens in file //schrijf gegevens in file //schrijf gegevens in file out.close(); Hierna wordt de gebruikersinterface ViewButtons afgesloten. Merk op dat enkele gegevens uit Tabel 5 niet aan de gebruiker gevraagd worden. De reden hiervoor is dat deze gegevens steeds dezelfde waarden hebben en bijgevolg automatisch kunnen ingevuld worden. 6.6 ListenButtonPanel Zoals Figuur 7 weergeeft, is de klasse ListenButtonPanel een onderdeel van Start.java. De klasse ListenButtonPanel implementeert de InternalFrameListener interface. Dit wil zeggen dat deze klasse acties kan uitvoeren nadat bijvoorbeeld een JInternalFrame afgesloten is. Een object van de klasse ListenButtonPanel wordt als luisterobject gebruikt dat gekoppeld wordt aan het object viewbuttons in de klasse Start. Wanneer de gebruiker Universiteit Gent 47

55 Hoofdstuk 6 Implementatie van de input de gegevens in ViewButtons.java correct heeft ingevuld, wordt dat JInternalFrame (viewbuttons) afgesloten. Hierdoor zorgt het luisterobject ervoor dat een aantal acties worden uitgevoerd. Ten eerste worden de ingevulde gegevens in viewbuttons opgevraagd daar deze nodig zijn voor het creëren van enkele andere inputbestanden. Het scherm van drawgraph gebruikersinterface wordt vergroot zodat de gebruiker meer ruimte krijgt om een netwerk te ontwerpen. Ten laatste wordt de knop Start P2P Simulation in drawgraph geactiveerd zodat de gebruiker de simulatie kan starten. 6.7 ListenGraphPanel Zoals in Figuur 7 weergegeven is, is ook de klasse ListenGraphPanel een onderdeel van Start.java. De klasse ListenGraphPanel implementeert de InternalFrameListener interface. Wanneer de gebruiker op de knop Start P2P Simulation drukt, wordt het drawgraph venster afgesloten en via het luisterobject van ListenGraphPanel kunnen volgende taken uitgevoerd worden: Het opvragen van de vector van VertexInfo s voor het fysische netwerk Het opvragen van de vector van VertexInfo s voor het logische netwerk Het creëren van topology.conf. Dit wordt gerealiseerd aan de hand van de klasse WriteTopologyConf. De structuur van dit bestand wordt bepaald door Tabel 6. Het creëren van de verschillende folders en de bestanden topology.conf voor alle nodes van het logische netwerk. Per node moeten er drie folders aangemaakt worden: complete, incomplete en shares. Een folder aanmaken kan door de instructie mkdir(). De structuur van het bestand topology.conf moet er uitzien zoals weergegeven in Tabel 8. Dit wordt uitgevoerd door de klasse WriteNodeTopologyConf. Het creëren van een storage folder Het aanmaken van een aantal bestanden in de storage folder. Elk bestand wordt opgebouwd uit veertig willekeurig gekozen opeenvolgende letters. Er worden momenteel tien verschillende bestanden geconstrueerd. Deze getallen kunnen eenvoudig aangepast worden. Het verspreiden van de bestanden in de storage folder naar de shares folders van de verschillende nodes van het logische netwerk. Dit kan gedaan worden door eerste een willekeurig getal tussen één en de helft van het aantal bestand in Universiteit Gent 48

56 Hoofdstuk 6 Implementatie van de input de storage folder te bepalen. Dit getal legt het aantal willekeurig gekozen bestanden vast die gekopieerd moeten worden naar de shares folder van een node. Deze procedure herhaalt zich voor alle nodes. Het bewaren van het ingegeven netwerk. De manier waarop het netwerk wordt opgeslagen is identiek aan Tabel 14. Het opstarten van de simulatie. Hiervoor wordt de klasse Gnutella opgeroepen. Het creëren van een JInternalFrame voor de verwerking van de resultaten Universiteit Gent 49

57 Hoofdstuk 7. Implementatie van de output 7.1 Algemeen Het doel van dit hoofdstuk is een outputinterface ontwikkelen om de resultaten van de simulatie te kunnen visualiseren. De resultaten van de simulatie worden in een logbestand bewaard. De verschillende onderdelen van dit logbestand werden besproken in paragraaf 5.3. Afhankelijk van de simulatiecommando s in het bestand request.in zal de output.log een bepaalde structuur hebben. Aangezien gekozen werd voor steeds de drie basiscommando s (Ping, Query, Download) uit te voeren, zal het outputbestand een structuur zoals in Figuur 22 is weergegeven bevatten. Figuur 22 De structuur van de output.log Aan de hand van de descriptors (Ping, Pong, Query en QueryHit) kan een tabel van berichten gemaakt worden. De tabel toont op een duidelijkere manier hoe berichten in het netwerk propageren en kan gebruikt worden om de simulatie te bekijken op een grafiek. Deze functie kan ook voor didactische doeleinden dienen daar hiermee zeer eenvoudig het Gnutella-protocol kan gevisualiseerd worden. De updates worden in een lijst weergegeven. Dit houdt in dat een aangesproken ultrapeer een lijst terugstuurt naar de node die de zoekopdracht initieerde. In deze lijst staat het aantal gedeelde bestanden die de ultrapeer bezit beschreven. Het aantal nodes die bereikt worden is afhankelijk van de TTL. Voorts is een mogelijkheid voorzien de zoekresultaten te bekijken in Universiteit Gent 50

58 Hoofdstuk 7 Implementatie van de output tabelvorm. Er werd gekozen om steeds de eerste template te downloaden. De bedoeling van de simulatie is het netwerkverkeer te bepalen in een Gnutella-netwerk en bijgevolg is de keuze van welke template die gedownload wordt onbelangrijk. Enkele statistieken in verband met het netwerkverkeerd kunnen ook geraadpleegd worden. Tenslotte kan de gebruiker alle resultaten, of slechts een deel ervan, afdrukken in een tekstbestand. Dit tekstbestand kan bijvoorbeeld via Excel ingelezen en aangepast worden indien de gebruiker dit wenst. In wat volgt worden de verschillende klassen nader toegelicht. Output TableMessage GraphMessage SearchResult Statistic 7.2 Output De klasse Output organiseert het verwerkingsgedeelte. Het bevat vier tabbladen waarbij de eerste een menu is die door middel van knoppen naar de andere tabbladen verwijst. In Figuur 23 kan het menu van de output bekeken worden. Figuur 23 Menu van de output In het tweede en derde tabblad worden het fysische en het logische netwerk opnieuw getoond. Deze tabbladen zijn toegevoegd zodat de gebruiker deze grafen kan raadplegen om de resultaten beter te begrijpen. De grafen worden aan de hand van de vectoren van VertexInfo s voor het fysische en logische netwerk opgebouwd. Volgende figuren tonen screenshots van beide grafen. Universiteit Gent 51

59 Hoofdstuk 7 Implementatie van de output Figuur 24 Het fysische netwerk Figuur 25 Het logische netwerk In het laatste tabblad kan de gebruiker de gewenste resultaten bekijken. Er zijn vijf functies geïmplementeerd: Universiteit Gent 52

60 Hoofdstuk 7 Implementatie van de output Messages (descriptors) Dynamic Neighbours (Updates) Search Results Statistics Save Deze functies worden in de volgende paragrafen besproken. In Figuur 26 wordt het menu van de resultaten weergegeven. Figuur 26 Het menu van de resutaten Messages (descriptors) Deze functie maakt de berichten die tijdens de simulatie verzonden zijn zichtbaar. Er moeten hier twee keuzes gemaakt worden. Eerst zal de gebruiker specificeren welke berichten getoond moeten worden. Door het aanvinken van de checkbox wordt de corresponderende descriptor zichtbaar gemaakt. Standaard zijn alle descriptors geselecteerd. Het filteren van het outputbestand gebeurd als volgt. De eerste sessie in Universiteit Gent 53

61 Hoofdstuk 7 Implementatie van de output het bestand output.log bevat de Ping- en Pong-descriptors. Er wordt een rijvector aangemaakt die volgende velden omvat: Time: tijd waarop het bericht verzonden is na de aanvang van de simulatie Logical Node: node die het bericht stuurt UID: dit is de message ID Messege type: duidt aan welke descriptor gestuurd is TTL: geeft de waarde van de TTL aan Hop Count: dit zijn het aantal hops die gepasseerd zijn door de descriptor Root: geeft aan welke node de request heeft geïnitieerd Source: geeft het nummer van de node die een bericht naar deze node heeft verstuurd Action: dit is de eerste actie die ondernomen zal worden Destination: dit zijn de nummers van de nodes naar welke een bericht zal gestuurd worden Action: dit is de tweede actie die ondernomen zal worden (indien aanwezig) Destination: dit zijn de nummers van de nodes naar welke een bericht zal gestuurd worden Voor elke descriptor worden deze velden ingevuld. Voor alle velden die in het outputbestand ontbreken, wordt een lege string in dat veld ingevuld. Wanneer alle descriptors op deze manier doorlopen worden, kan een vector van rijvectoren aangemaakt worden. De tweede sessie in het bestand output.log bevat de Query- en QueryHit-descriptors. Er wordt op dezelfde wijze rijvectoren aangemaakt als in de eerste sessie. Deze rijvectoren omvatten dezelfde velden en worden toegevoegd aan de vector der rijvectoren. Deze functionaliteit wordt door de methode getdatavector() gerealiseerd. Wanneer de gebruiker specificeert dat een bepaalde descriptor niet mag weergegeven worden, zal de vector der rijvectoren doorlopen worden. Indien in een rijvector het veld Message type overeenkomt met de descriptors die de gebruiker wil bekijken, wordt de rijvector behouden. In het ander geval wordt de rijvector verwijderd. Universiteit Gent 54

62 Hoofdstuk 7 Implementatie van de output Ten tweede moet de gebruiker specificeren hoe de berichten getoond moeten worden. Er is hier keuze tussen: Table view: toont de geselecteerde berichten in tabelvorm (zie paragraaf ). Graph view: toont de geselecteerde berichten in de grafiek(zie paragraaf ) MessageTable De klasse MessageTable staat in voor het tonen van de tabel met de descriptorinformatie. In Figuur 27 wordt een voorbeeld gegeven. Door het aangeven van kolomnamen en een vector van rijvectoren kan aan de hand van JTable zeer eenvoudig een tabel aangemaakt worden. De visualisatie van de berichten in tabelvorm is zeer handig daar de gebruiker een overzichtelijk beeld krijgt van de verzonden berichten. De berichten zijn chronologisch gesorteerd. Figuur 27 Tabel met informatie over de verschillende descriptors Universiteit Gent 55

63 Hoofdstuk 7 Implementatie van de output MessageGraph De klasse MessageGraph zal in feite een replay van de simulatie uitvoeren. Dit wil zeggen dat vector der rijvectoren gebruikt zal worden om de berichten aan de hand van een tijdsvertraging op grafiek te tonen. In Figuur 28 zijn drie delen te onderscheiden. Bij Settings moet de gebruiker kiezen of de berichten die reeds getoond zijn op het scherm moeten blijven of moeten verdwijnen telkens er een nieuwe verbinding getekend wordt. Met de JSlider (en Timer) kan de tijdsvertraging vastgelegd worden. De Start knop start het weergeven van de verbindingen. Er is een tekstveld voorzien waarin het type bericht, de sourcenode en de targetnode neergeschreven worden. Figuur 28 Visualisatie van de simulatie Universiteit Gent 56

64 Hoofdstuk 7 Implementatie van de output Dynamic Neighbours (Updates) Deze functie laat de node die de request heeft geïnitieerd zien welke nodes (ultrapeers) in het netwerk antwoord op een Ping-bericht geven. Het aantal bestanden en de grootte van de bestanden wordt meegegeven aan de rootnode. Figuur 29 verduidelijkt dit. De updates in het logbestand worden steeds na de Ping en Pong berichten vertoond. Figuur 29 Updates Zoekresultaten Deze functie laat de gebruiker toe de verschillende templates die gedownload kunnen in een tabel voor te stellen. Zoals eerder vermeld wordt steeds de eerste template gedownload. Dit bestand komt na de download in de folder complete van de node die de zoekactie gestart heeft. Figuur 30 geeft een screenshot van de zoekresultaten. Universiteit Gent 57

65 Hoofdstuk 7 Implementatie van de output Figuur 30 Zoekresultaten Statistieken Met deze functie kan de gebruiker enkele statistieken van de simulatie verkrijgen. Tijdsstatistieken: geeft de begin- en eindtijden van de verschillende sessies. Netwerkstatistieken: geeft informatie over de verschillende vertices en edges in het netwerk. Descriptorstatistieken: geeft het aantal berichten die verstuurd zijn tijdens de simulatie. Deze gegevens kunnen gebruikt worden om de congestie te bepalen. Figuur 31 geeft een voorbeeld. Universiteit Gent 58

66 Hoofdstuk 7 Implementatie van de output Figuur 31 Statistieken van de simulatie Save Met deze functie worden de resultaten van vorige functies in een tekstbestand opgeslagen. Bij het drukken van de knop Save verschijnt de JFileChooser zoals in Figuur 19. De gebruiker kiest een directory en een naam voor het bestand. De gebruiker kan bepalen welke functies exact dienen bewaard te worden. Door middel van deze functie kan bijvoorbeeld de vector van rijvectoren opgeslagen worden. Het opgeslagen tekstbestand kan in een ander programma geopend worden voor verdere analyse. Universiteit Gent 59