Ontwikkeling en Evaluatie van een Peer-to-Peer Applicatie a.h.v. JXTA Platform

Universiteit Gent Faculteit Toegepaste Wetenschappen

Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Ontwikkeling en Evaluatie van een Peer-to-Peer Applicatie a.h.v. JXTA Platform door

Benjamin DE TROCH en Tim VAN DER HULST

Promotoren: Prof. Dr. Ir. B. DHOEDT en Dr. Ir. F. DE TURCK Scriptiebegeleider: Ir. P. BACKX

Scriptie ingediend tot het behalen van de academische graad van licentiaat informatica

Academiejaar 2002-2003

Universiteit Gent Faculteit Toegepaste Wetenschappen

Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Ontwikkeling en Evaluatie van een Peer-to-Peer Applicatie a.h.v. JXTA Platform door

Benjamin DE TROCH en Tim VAN DER HULST

Promotoren: Prof. Dr. Ir. B. DHOEDT en Dr. Ir. F. DE TURCK Scriptiebegeleider: Ir. P. BACKX

Scriptie ingediend tot het behalen van de academische graad van licentiaat informatica

Academiejaar 2002-2003

Voorwoord Deze thesis is niet alleen het resultaat van ons hard labeur, en dus willen we graag deze gelegenheid aangrijpen om enkele mensen te bedanken. Zonder hen zouden we dit nooit kunnen verwezenlijkt hebben.

In eerste instantie betuigen we dan ook onze dank aan onze promoteren om ons de kans te geven op zelfstandige basis onderzoek te verrichten. Prof. Dr. Ir. B. Dhoedt bedanken we in het bijzonder voor de continue opvolging. Dr. Ir. F. De Turck zijn we dankbaar voor de inspirerende inbreng tijdens de proefverdediging waardoor onze echte verdediging des te vlotter verliep.

Veel lof en bejubelingen ook aan het adres van onze dagelijkse begeleider Ir. P. Backx, zonder wiens hulp deze scriptie niet zou zijn wat ze nu is. Zijn suggesties met betrekking tot het oplossen van de problemen die we hadden met het JXTA platform hebben ons in grote mate geholpen.

We kunnen hier uiteraard ook niet voorbijgaan aan Ir. T. Wauters voor zijn geduldige uitleg over de werking van het caching algoritme en voor het luisteren naar onze suggesties.

Tot slot willen we ook onze ouders, vrienden en kennissen bedanken voor het eindeloze geduld dat ze hebben getoond doorheen dit jaar.

Benjamin De Troch en Tim Van der Hulst Gent, 27 mei 2003

Toelating tot bruikleen: De auteurs geven 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.

29 mei 2003

Benjamin De Troch

Tim Van der Hulst

Ontwikkeling en Evaluatie van een Peer-to-Peer Applicatie a.h.v. JXTA Platform door

Benjamin DE TROCH en Tim VAN DER HULST

Scriptie ingediend tot het behalen van de academische graad van Licentiaat informatica Academiejaar 2002-2003 Promotoren: Prof. Dr. Ir. B. DHOEDT en Dr. Ir. F. DE TURCK Scriptiebegeleider: Ir. P. BACKX

Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Samenvatting In deze scriptie zullen we een peer-to-peer file-sharing applicatie bouwen aan de hand van het JXTA platform. We zullen aan deze applicatie caching functionaliteit toevoegen. Hiertoe zullen we een caching algoritme implementeren. Dit algoritme zullen we dan proefondervindelijk vergelijken met twee benchmarks. Na een inleiding en een korte uitleg over peer-to-peer en het JXTA platform zullen we de benchmarks en het cache algoritme uitdiepen in hoofdstuk 4. De opbouw van de applicatie in Java wordt besproken in hoofdstuk 5. De performantie van het geïmplementeerde caching algoritme wordt nader onderzocht in hoofdstuk 6. Met behulp van onze testen tonen we aan dat dit algoritme geschikt is om een afweging te maken tussen de kost om bestanden te cachen en de kost om bestanden te downloaden.

Trefwoorden: peer-to-peer, JXTA, caching, file-sharing

Inhoudsopgave 1. INLEIDING ................................................................................................. 1 2. PEER-TO-PEER CONCEPTEN............................................................... 2 2.1 WAT IS PEER-TO-PEER ...................................................................................................2 2.2 WAAROM PEER-TO-PEER? .............................................................................................5 2.3 P2P ARCHITECTUUR ......................................................................................................6 2.3.1 Centrale server......................................................................................................6 2.3.2 Puur.......................................................................................................................7 2.3.3 Hybride..................................................................................................................8 2.4 VOORBEELDAPPLICATIES ..............................................................................................9 2.4.1 Instant messaging..................................................................................................9 2.4.2 File-sharing...........................................................................................................9 2.4.3 Distributed computing.........................................................................................11

3. JXTA........................................................................................................... 12 3.1 INLEIDING ...................................................................................................................12 3.2 CONCEPTEN .................................................................................................................14 3.2.1 Peer .....................................................................................................................14 3.2.2 Peergroup............................................................................................................15 3.2.3 Service .................................................................................................................16 3.2.4 Endpoint ..............................................................................................................16 3.2.5 Pipe .....................................................................................................................16 3.2.6 Message...............................................................................................................17 3.2.7 Advertisement......................................................................................................17 3.2.8 Protocol...............................................................................................................17 3.3 PROTOCOLS .................................................................................................................18 3.3.1 Endpoint Routing Protocol .................................................................................18 3.3.2 Peer Resolver Protocol .......................................................................................19 3.3.3 Peer Discovery Protocol .....................................................................................20 3.3.4 Pipe Binding Protocol.........................................................................................20 3.3.5 Peer Information Protocol ..................................................................................20 3.3.6 Peer Membership Protocol .................................................................................21 3.4 HET DRIELAGENMODEL ...............................................................................................21 3.5 CMS SERVICE .............................................................................................................22

4. CACHING ALGORITMES..................................................................... 24 4.1 EERSTE BENCHMARK: NIET CACHEN ............................................................................24

4.2 TWEEDE BENCHMARK: PUUR CACHEN .........................................................................25 4.3 CACHE HEURISTIEK .....................................................................................................26

5. DE IMPLEMENTATIE ........................................................................... 31 5.1 INLEIDING ...................................................................................................................31 5.2 CACHE PEER................................................................................................................32 5.2.1 Oorspronkelijk… .................................................................................................32 5.2.2 Protocol...............................................................................................................34 5.2.3 Implementatie......................................................................................................37 5.3 CLIENT PEER ...............................................................................................................43

6. PERFORMANTIETESTS ....................................................................... 46 6.1 HET TESTNETWERK .....................................................................................................46 6.2 PROBLEMEN ................................................................................................................48 6.3 EERSTE BENCHMARK: NIET CACHEN ............................................................................48 6.4 TWEEDE BENCHMARK: PUUR CACHEN .........................................................................49 6.5 CACHE ALGORITME .....................................................................................................51 6.6 VERGELIJKING .............................................................................................................57

7. CONCLUSIES........................................................................................... 60 7.1 WAT HEBBEN WE BEREIKT?.........................................................................................60 7.2 ERVARINGEN MET DE JXTA OMGEVING ......................................................................61 7.3 MOGELIJKE UITBREIDINGEN… ....................................................................................61

REFERENTIES............................................................................................. 63 APPENDIX A: PROTOCOLBOODSCHAPPEN IN XML...................... 66 A.1 BEVEL TOT CACHEN....................................................................................................66 A.2 BEVEL TOT UNCACHEN ...............................................................................................67 A.3 BEVESTIGING VAN CACHE-OPERATIE ..........................................................................68 A.4 BEVESTIGING VAN EEN UNCACHE-OPERATIE ..............................................................69 A.5 MELDING VAN NIEUWE CACHE PEER OP HET NETWERK ...............................................70 A.6 MELDING VAN EEN AFSLUITENDE CACHE PEER ...........................................................71 A.7 MELDING VAN EEN DOWNLOAD ..................................................................................72

APPENDIX B. TESTRESULTATEN ......................................................... 73 B.1 Α = 0,1 ........................................................................................................................73 B.2 Α = 0,25 ......................................................................................................................73 B.3 Α = 0,5 ........................................................................................................................74 B.4 Α = 0,75 ......................................................................................................................74 B.5 Α = 1 ...........................................................................................................................75 B.6 Α = 1,25 ......................................................................................................................75 B.7 Α = 1,5 ........................................................................................................................76 B.8 Α = 1,75 ......................................................................................................................76 B.9 Α = 2 ...........................................................................................................................77

1. Inleiding Onze scriptie behandelt de opbouw en evaluatie van een peer-to-peer applicatie die gebruikt zal worden om aan file-sharing te doen.

Traditioneel zou men van een client/server architectuur gebruik maken om bestanden beschikbaar te maken aan een groot publiek. Meestal zullen er dan op strategische plaatsen tussen de clients en de servers dan ook nog caches geplaatst worden, die voor een betere toegangstijd moeten zorgen en de kwaliteit van de dienst zullen verbeteren. Het gebruik van een peer-to-peer oplossing hiervoor heeft ook zo zijn voordelen, zoals meer flexibiliteit en een betere robuustheid en spreiding van de netwerkbelasting. Een korte inleiding tot P2P vindt u in hoofdstuk 2. In concreto zullen wij het JXTA platform aanwenden, waarover u meer zal vernemen in hoofdstuk 3.

De bedoeling is om in onze file-sharing applicatie ook een systeem met caches in te bouwen. Net zoals het bij client/server architecturen wordt aangewend, is het ook hier de bedoeling dat deze caches de toegangstijd tot de gegevens verbeteren en zo dus ook de kwaliteit van de dienstverlening. Gezien we met een peer-to-peer architectuur werken in plaats van client/server, zal dit ons in staat stellen de intelligentie in de applicatie te verspreiden over het netwerk. Meer over de implementatie vindt u terug in hoofdstuk 5.

Om de caches te vullen zullen we gebruik maken van een algoritme dat beslist wat/wanneer/waar moet opgeslagen worden. Het gebruikte algoritme wordt verder uit de doeken gedaan in hoofdstuk 4. We zullen dit dan naast twee vergelijkende benchmarks plaatsen en de performantie ervan nagaan in hoofdstuk 6.

1

2. Peer-to-peer concepten 2.1 Wat is peer-to-peer Uitleggen wat peer-to-peer (P2P) inhoudt, is blijkbaar niet zo makkelijk. Er bestaat niet echt een standaard definitie van. De “peer-to-peer working group” (bestaande uit mensen van onder andere Intel, Hewlett-Packard en IBM) definieert peer-to-peer als het delen van computerbronnen door directe uitwisseling tussen de systemen [1]. Hierin worden met bronnen zaken bedoeld als informatie, bestanden, rekenkracht, … Belangrijk in de definitie is dat er directe uitwisseling staat. Dit staat in tegenstelling tot gecentraliseerde uitwisseling zoals in client/server netwerken. We zullen in de volgende paragraaf wat meer uitleg over client/server netwerken verschaffen om daarna dan het verschil met P2P te maken.

De traditionele architectuur in netwerkomgevingen is de client/server architectuur. Hierin is de server de machine die een dienst aanbiedt en de client de machine die van die dienst gebruik maakt. Hierbij is het meestal zo dat het meeste rekenwerk op de server verricht wordt en dat de client met relatief lichte processen gebruik kan maken van de diensten van de server. Op dit moment is het client/server-model de architectuur voor de meest gebruikte applicaties op het Internet (WWW, FTP, e-mail, IRC, …).

2

De server moet: - luister naar requests - requests behandelen - antwoord terugsturen

Elke client moet: - requests sturen - antwoorden ontvangen

Figuur 2.1 Client/Server model

Er zijn aan dit model echter belangrijke nadelen verbonden:

•

De toegang tot de server vormt een bottleneck als er veel clients gebruik

willen maken van de aangeboden dienst(en)

•

Niet iedereen kan zomaar een server starten die toegankelijk en vindbaar is

voor de rest van de wereld (dynamische IP-adressen, firewalls, … vormen hiervoor problemen)

•

Als de server wegvalt, valt de dienst weg

Tegenover dit client/server model staan dan de P2P-netwerken. Letterlijk vertaald betekent peer “gelijke”, en peer-to-peer dus “gelijke tot gelijke”. Vergeleken met het client/server model zou in een P2P netwerk elke computer dus de rol van zowel server als client op zich nemen. Er zijn echter nog voorwaarden waaraan voldaan moeten zijn om van P2P te spreken. Zo moeten ook de computers “aan de rand van het net” voldoende autonoom en betrokken in het netwerk zijn. Dit betekent dus een oplossing voor het tweede probleem van het client/server-model vinden. Ook moet men rekening houden met het feit dat niet

3

elke computer constant met het netwerk verbonden is en vaak ook niet hetzelfde IP-adres kan behouden (derde en tweede probleem bij client/server netwerken).

Elke peer moet: - requests sturen - antwoorden ontvangen - luisteren naar requests - requests behandelen - antwoord terugsturen -requests naar anderen doorsturen

Figuur 2.2 P2P model

Samengevat spreken we over een P2P applicatie als deze bronnen deelt tussen computers aan de rand van het netwerk, en dit door directe uitwisseling van de bronnen [3].

P2P netwerken pakken ook de problemen aan die in het client/server-model zitten. Gezien er niet één server meer is waarop de dienst (of bron) beschikbaar is, zal het netwerk gelijkmatiger belast worden en zal er dus geen bottleneck rond één machine ontstaan. Gezien we zeggen dat P2P-netwerken computers aan de rand van het net moeten (kunnen) bevatten, zal een P2P applicatie geen probleem hebben met dynamische IP-adressen, firewalls, … Dit betekent ook dat het uitvallen van één of meer machines in het netwerk, de dienst niet doet wegvallen.

Er zijn natuurlijk ook nadelen verbonden aan het gebruik van het P2P model tegenover client/server. De belangrijkste reden voor deze nadelen is de grote flexibiliteit van deze netwerken. Doordat er constant computers kunnen in het netwerk bijkomen en er ook constant uitgaan, zullen de beschikbare bronnen veranderen van het ene moment op het andere. Aanvragen voor dezelfde bron zullen ook niet altijd naar dezelfde computers in het

4

netwerk gaan. Zo zullen twee gebruikers die hetzelfde bestand opvragen, het beiden mogelijks van een andere computer downloaden. Het veranderen van de beschikbare bronnen houdt ook in dat niet aan elke aanvraag op elk moment kan voldaan worden. Iemand die nu bestand A zoekt kan pech hebben en niks vinden, maar vijf minuten later is het bestand misschien wel opeens beschikbaar.

2.2 Waarom peer-to-peer? Als er dan toch nadelen zijn aan P2P, waarom is het dan zo populair? Behalve als middel om illegaal muziek, films en dergelijke te verspreiden zijn er ook goede redenen waarom P2P belangrijk is. De eerste reden hiervoor is dat de problemen verbonden aan P2P netwerken niet als onoverkomelijk worden beschouwd door de meeste gebruikers. Het feit dat er bronnen op bepaalde momenten niet beschikbaar zijn kan omzeild worden door deze op meerdere computers in het netwerk te ‘mirroren’. En hoe meer computers in het netwerk zitten, hoe kleiner de kans dat een vraag onbeantwoord blijft. Dus de flexibiliteit van het netwerk kan ook gebruikt worden om de problemen die ze creëert op te lossen.

De tweede reden is dat P2P-netwerken heel geschikt zijn voor sommige problemen op te lossen. Een goed voorbeeld hiervan is de huidige zoekpagina- (search engine) technologie op het Internet. Deze zoekpagina houdt een databank bij met alle door hun geïndexeerde informatie. Deze databank wordt dagelijks bijgewerkt door het Internet af te zoeken naar nog niet geïndexeerde pagina’s. Reeds geïndexeerde pagina’s zullen ook geupdate worden als ze overlopen worden door de zoekrobots. Maar door de enorme hoeveelheid aan webpagina’s in de wereld (Google indexeert er op dit moment zo een 3.083.324.652), is het onmogelijk om elke pagina in de databank elke dag te updaten (zelfs niet elke week, of elke maand). Hierdoor zal een zoekopdracht heel vaak onbruikbare informatie teruggeven (webpagina’s die niet meer bestaan, die niet meer over hetzelfde onderwerp handelen, die totaal verouderd zijn, …). Op deze manier verliest de zoekpagina natuurlijk een groot stuk van zijn gebruiksgemak. Een ander nadeel is dat het opslaan van de databank en het bijwerken veel computerkracht vragen. Alles dient op één plaats onderhouden te worden (Google gebruikt een cluster van 10.000 computers). Behalve deze nadelen is er ook het feit dat zoals bij alle client/server applicaties de server een kritieke machine is. Als de server offline gaat, is de hele service niet meer bereikbaar. Zoekpagina’s kunnen ook

5

onmogelijk aan de machines die “aan de rand” van het Internet staan, waardoor de informatie waarover ze beschikken zeker onvolledig zal zijn.

Stellen we ons nu een gelijkaardige service voor, maar dan aangeboden met behulp van P2P. Iedere machine die een webserver draait, zou antwoorden op zoekopdrachten met een lijst van documenten die hij als host aanbiedt en die daarenboven aan de zoekopdracht beantwoorden. Op die manier hoeft de server enkel zijn eigen document te indexeren, wat een heel stuk makkelijker is dan een databank voor het hele Internet bijhouden. De informatie die op een zoekopdracht teruggestuurd wordt zou dus veel recenter zijn en heel wat accurater dan wat huidige zoekpagina’s kunnen aanbieden. Een groot voordeel is ook dat wanneer een server de verbinding met het netwerk verbreekt, er geen zoekresultaten met zijn pagina’s kunnen bekomen worden. Op deze manier is het dus (bijna) onmogelijk een resultaat terug te krijgen dat niet meer te vinden is in het netwerk.

Samengevat kunnen we stellen dat P2P applicaties vooral het delen van informatie verbeteren terwijl ze ook de beschikbare bandbreedte beter gebruiken.

2.3 P2P architectuur We hadden in het begin al gezegd dat we over een peer-to-peer netwerk spreken als er sprake is van directe uitwisseling tussen de in het netwerk zittende machines. Meestal is de uitwisseling tussen machines op te splitsen in het verzenden van data enerzijds en het sturen en ontvangen van controlecodes anderzijds. We zullen nu de definitie van een peerto-peer netwerk iets verfijnen door te zeggen dat enkel de data-uitwisseling met directe verbindingen tussen twee peers moet gebeuren. Hierdoor splitsen we de netwerken op in drie verschillende architecturen, naargelang de wijze waarop de controlelaag is geïmplementeerd [2].

2.3.1 Centrale server Deze P2P netwerken zullen toch nog een deel van de client/server architectuur gebruiken voor de controle uit te voeren. Alle peers moeten inloggen op een centrale server. Deze

6

server kan ook nog extra functionaliteit aanbieden, zoals een databank bijhouden met welke bronnen elke peer aanbiedt en dergelijke. Zoals te zien in figuur 2.3 loopt de controlelaag via de server, maar de datatransfer zal rechtstreeks tussen de clients onderling verlopen.

Data

Controle

Figuur 2.3 Centrale server P2P architectuur

2.3.2 Puur Pure P2P netwerken zullen alles doorsturen via directe verbindingen. Controlecodes zullen over het algemeen doorheen het netwerk moeten doorgestuurd worden. Hierdoor genereren ze vrij veel extra verkeer naast de eigenlijke datatransfers over het netwerk.

7

Data

Controle

Figuur 2.4 Pure P2P architectuur

2.3.3 Hybride

Data

Controle

Figuur 2.5 Hybride P2P architectuur

Deze laatste architectuur is een samensmelting van de twee vorige. Een hybride architectuur zal met speciale server peers werken boven de gewone client peers, maar deze servers vervullen hun rol enkel voor een deel van de clients in het netwerk. De server peers zelf zullen via een puur P2P netwerk verbonden zijn met elkaar. Dit is dus een gelaagde architectuur, onderaan de clients die allemaal met één (of meerdere) server(s) verbonden

8

zijn en bovenaan de servers die met elkaar verbonden zijn door middel van een puur P2P netwerk. Deze architectuur is op dit moment de populairste.

2.4 Voorbeeldapplicaties Op dit moment zijn er drie soorten applicaties die vaak gebruik maken van P2P netwerken: instant messaging, file-sharing en distributed computing.

2.4.1 Instant messaging Instant messaging applicaties geven de gebruikers de mogelijkheid om snel te communiceren met elkaar. Eén van de bekendste programma’s in deze categorie is ICQ van Mirabilis [7]. Dit programma laat zijn gebruikers toe andere gebruikers als vrienden te definiëren en zal ze op de hoogte brengen als deze vrienden inloggen. Dan kunnen ze dus gemakkelijk communiceren door boodschappen heen en weer te sturen. ICQ laat ook overdracht van files toe. De onderliggende netwerkarchitectuur maakt gebruik van een centrale server. Deze server wordt gebruikt om de gebruikers te laten inloggen, zodat deze de aanmeldboodschappen naar vrienden van de gebruikers kan doorsturen. De rest van de communicatie tussen gebruikers onderling verloopt via directe verbindingen en is dus puur P2P.

Er zijn uiteraard nog meer applicaties die deze service aanbieden. Voorbeelden zijn MSN messenger, AOL Internet Messenger, … Al deze applicaties gebruiken echter een ander protocol voor de communicatie en dus kunnen gebruikers van de ene applicatie geen boodschappen uitwisselen met gebruikers van een andere.

2.4.2 File-sharing Zonder twijfel de meest beruchte applicatie om bestanden (in dit geval muziekbestanden) te delen is Napster. Hiervoor gebruikte Napster een centrale server (zie figuur 2.3) die een lijst bijhoudt van alle bestanden die op dat moment in het netwerk te vinden zijn met hun locatie. De server zal dus antwoorden op de zoekaanvragen van de gebruikers. De

9

overdracht van de bestanden gebeurt dan rechtstreeks tussen de gebruikers. Napster gebruikt dus ook een architectuur met centrale server en geeft de server nog meer verantwoordelijkheden dan ICQ (ICQ alleen inloggen, tegenover inloggen, lijst bijhouden, antwoorden op zoekaanvragen bij Napster).

Figuur 2.3 Napster architectuur

Na Napster kwam Gnutella. Dit project elimineerde de nood aan een centrale server zoals bij Napster. Het werd ook mogelijk gemaakt om gelijk welk bestand te delen, niet enkel muziekbestanden. Peers op het Gnutella netwerk zijn dus zelf verantwoordelijk voor het delen van hun bestanden en antwoorden op zoekaanvragen, maar ook om boodschappen door te sturen naar andere peers in het netwerk. Gnutella elimineerde zo wel de nood aan een centrale server om een databank van bestanden bij te houden en om op zoekaanvragen te reageren, maar toch moet er een manier zijn voor een peer om aan het IP-adres van een peer die al in het netwerk zit te geraken. Om die reden werden er een aantal peers met een statisch IP-adres opgezet die permanent in het netwerk bleven. Zo hebben peers die zich in het netwerk willen voegen een startpunt. Uiteindelijk zijn ook in het Gnutella netwerk “superpeers” geïntroduceerd, die als een soort servers continu in het netwerk verblijven. Het is dus op dit moment geen pure P2P architectuur meer, maar ook een hybride vorm.

Andere file-sharing applicaties zijn onder andere Freenet, KaZaA (en zijn equivalente, Morpheus) en MojoNation. Freenet is een applicatie die berust op een puur P2P netwerk en op die manier (samen met encryptie) volledige anonimiteit garandeert. Morpheus en KaZaA gebruiken metadata om de zoekmogelijkheden uit te breiden.

10

2.4.3 Distributed computing Applicaties voor distributed computing proberen een moeilijk probleem op te lossen door het in deelproblemen op te splitsen die onafhankelijk van elkaar kunnen opgelost worden. Elk van deze deelproblemen kan dan opgelost worden door een computer in het netwerk.

Een voorbeeld van distributed computing is SETI@Home [5], dat zoekt naar bewijs van buitenaards leven. De gebruikers downloaden een screensaver van de site. Terwijl deze screensaver actief is, zal het programma stukken radiotelescoopdata downloaden en verwerken en dan de resultaten terugsturen. SETI@Home is geen P2P applicatie, gezien er geen interactie tussen de gebruikers onderling is, maar het illustreert wel goed het concept van distributed computing.

Op dit moment zijn er nog geen wereldbekende applicaties die gebruik maken van P2P netwerken om distributed computing te doen, maar dit zal waarschijnlijk snel veranderen. Eén groot bedrijf dat alvast doorheeft dat P2P netwerken hiervoor heel goed van pas kunnen komen is Intel. Ze hebben het “Intel philanthropic peer-to-peer program” [4] opgezet om onderzoekers over de hele wereld in staat te stellen rekenkracht aangeboden door computers over de hele wereld te gebruiken bij hun onderzoek. Dit programma bestaat uit meerdere onderzoeksprojecten tegelijkertijd. De gebruiker kan kiezen voor welk project hij zijn computer laat werken. De applicatie zal in de achtergrond draaien en kleine pakketten tegelijk afhalen van een datacenter en na verwerking de resultaten terugsturen. De computers onderling kunnen ook data naar elkaar sturen om te vergelijken en eventueel resultaten te verzamelen om ze in één brok terug te sturen naar een datacenter.

11

3. JXTA 3.1 Inleiding De laatste jaren heeft peer-to-peer (P2P) een enorme opmars gemaakt wat populariteit betreft. Dat zie je ook aan de vele P2P applicaties die vandaag de dag beschikbaar gesteld worden. Bepaalde onderdelen en functionaliteiten vind je echter in meerdere van die applicaties terug. Vanzelfsprekend gaat het hier in eerste instantie om basisvereisten van peer-to-peer software zoals het vinden van andere peers op het netwerk en het sturen van boodschappen tussen de verschillende peers. Maar ook op een hoger niveau vinden we overlapping tussen verschillende commerciële toepassingen terug. We hoeven bijvoorbeeld maar te denken aan het programma ICQ (uitgesproken als ‘I seek you’) [7]. Dit biedt hoofdzakelijk instant messaging aan maar daarnaast kan het ook voor filesharing worden gebruikt.

Ook nu nog is het de gewoonte om bij het ontwikkelen van een P2P applicatie deze functionaliteit telkens opnieuw from scratch te programmeren. Herbruikbaarheid van code wordt tot een minimum herleid. Dit weerspiegelt zich vanzelfsprekend nadelig in de ontwikkelingsduur en de kwaliteit van het product. Softwarehuizen dienen extra kostbare tijd aan het project spenderen. Logischerwijze zijn die dan niet zo snel geneigd om hun code met anderen te delen. Elke toepassing zal gebruik maken van een volstrekt eigen protocol. Precies daardoor is er van compatibiliteit tussen de diverse softwarepakketten nog maar weinig sprake. En net die mogelijkheid om allerlei toestellen en omgevingen in netwerkverband te brengen is dé grote sterkte van peer-to-peer.

Deze situatie toont aan dat er nood is aan een raamwerk voor peer-to-peer toepassingen. Dit is precies wat Sun Microsystems wil bereiken met Project JXTA (uit te spreken als 12

‘juxta’) [8]. De naam is afgeleid van het woord juxtapose wat zoveel betekent als ‘het dichter bij elkaar brengen van twee entiteiten’. JXTA is in eerste instantie een set van éénduidige peer-to-peer protocolspecificaties. Deze solide uitgangspositie is net wat JXTA zo krachtig maakt. Het laat P2P ontwikkelaars toe zich toe te leggen op het programmeerwerk op een hoger niveau zonder zich ook maar iets te moeten aantrekken van de onderliggende P2P communicatielaag.

Daarenboven is JXTA volledig open-source. Het staat ter beschikking van iedereen die er gebruik van wil maken of het wil uitbreiden. Dit komt de ontwikkeling zeker ten goede, in die zin dat het platform voortdurend bij nieuwe situaties ten tonele wordt geroepen en dus constant op de proef wordt gesteld. Op die manier komen bugs en tekortkomingen soms veel sneller aan het licht dan bij een commerciële toepassing.

JXTA maakt intensief gebruik van XML [9]. XML staat voor eXtensible Markup Language en lijkt steeds meer en meer zijn grote doorbraak aan het bewerkstelligen. Het uitgebreide aanbod aan XML parsers en tools vereenvoudigt het gebruik.

Bovendien zijn de JXTA protocols onafhankelijk van de gebruikte programmeertaal en het onderliggende platform. Tot nog toe zijn er een aantal implementaties beschikbaar, waaronder een Java- en een C-implementatie. Niets staat echter de ontwikkeling van bijvoorbeeld een Perl- of Python- of Smalltalk-versie in de weg. Meer nog, JXTA is ontworpen met het oog op een zo hoog mogelijke graad van netwerkonafhankelijkheid. Vandaag de dag is TCP/IP het dominante netwerkprotocol, maar wie garandeert dat dit in de toekomst ook nog zo is? Precies om deze reden zijn ze er bij de ontwikkeling van uitgegaan dat andere protocols deze rol zouden kunnen overnemen in de nabije toekomst. We hoeven bijvoorbeeld maar te denken aan Bluetooth van IBM [10].

De eenvoud van de JXTA protocols maakt het ook mogelijk om uiteenlopende P2P toepassingen te ontwikkelen voor een brede waaier aan apparaten, zoals PDA’s en mobiele telefoons, in onze ogen een tot nog toe vrij onontgonnen markt. Deze mogelijkheid tot alomtegenwoordigheid in de digitale wereld biedt uiteraard interessante perspectieven en opportuniteiten, wat ons doet geloven dat JXTA zeker geen ééndagsvlieg zal blijken.

13

Het dient gezegd dat JXTA nog volop in ontwikkeling is. Bepaalde componenten zijn tot nader order nog niet geïmplementeerd (denken we hierbij maar aan het Peer Information Protocol, waarover later meer), andere componenten worden nog aangepast of in sommige gevallen zelfs compleet opnieuw geprogrammeerd, elke dag nog worden nieuwe bugs ontdekt. Ook wij zijn bij het ontwikkelen van onze applicatie meermaals op onvolkomenheden en gebreken gestoten wat de vooruitgang niet ten goede kwam.

3.2 Concepten Laten we eerst en vooral even de basisconcepten kort bespreken. Voor een meer diepgaande bespreking raden we U aan [6] te raadplegen.

3.2.1 Peer Een peer is niet meer of niet minder dan een knoop in het netwerk. Dit kan eender welk digitaal toestel zijn. Elke peer implementeert een aantal JXTA protocols.

Men onderscheidt 3 types van peers: gewone peers, rendezvous peers en router peers. Elke peer op het netwerk doet dienst als één of meer van die types, wat zijn verantwoordelijkheid in het grote geheel specificeert.

Gewone peer

De gewone peer kan je zien als de vertegenwoordiger van één enkele eindgebruiker. Dit type peer heeft dan ook de laagste graad van verantwoordelijkheid in het netwerk. De gewone peer biedt diensten aan over het P2P netwerk vanwege de eindgebruiker en stelt diezelfde eindgebruiker in de mogelijkheid om gebruik te maken van diensten die worden aangeboden door andere peers op het netwerk.

Rendezvous peer

14

Deze houden in een lokale cache informatie (“advertisements”, zie verder) bij over de peers in het netwerk en de diensten die de peers aanbieden. Gewone peers kunnen deze informatie dan opvragen om een beeld te krijgen van de beschikbare bronnen.

Daarnaast staan ze in voor het verder verspreiden van berichten over het P2P netwerk. Dit gaat als volgt: een peer die een boodschap wil sturen naar de andere peers, stuurt deze naar al de peers die hij zelf kent, zowel gewone als rendezvous peers, de rendezvous peers zenden die op hun beurt verder, en zo gaat verspreidt de boodschap zich over het netwerk.

Router peers

Dit type stelt peers die achter een firewall of NAT (Network Address Translation) opgesteld staan, in staat om te communiceren met de rest van het netwerk. Ook zullen peers van dit type doorheen de tijd informatie verzamelen over het netwerk en hoe berichten zo te routeren dat ze hun eindebestemming veilig en wel kunnen bereiken. Hoe dit precies werkt kunt u te weten komen in [6].

3.2.2 Peergroup Een peergroup is simpelweg een groepering van peers met een zelfde functionaliteit. Zo kan je bijvoorbeeld een groep creëren voor peers die onderling bestanden delen. Een peergroup kan aan zijn ‘leden’ bepaalde diensten aanbieden die niet kunnen geraadpleegd worden door peers die niet tot die groepering behoren. Deze mogelijkheid tot onderverdeling maakt het geheel efficiënter, doelgerichter en ordelijker. Ook aan beveiliging is gedacht: elke peergroup kan een authenticatie van de peer die wenst lid te worden, vereisen.

JXTA zegt geenszins wanneer peers tot eenzelfde peergroup dienen te behoren, de programmeur heeft dit volledig in eigen handen. Uiteraard is een peer niet beperkt tot lidmaatschap van één peergroup, net zoals een peergroup een oneindig aantal peers mag bevatten. Elke peer behoort sowieso één peergroup, de zogenaamde NetPeerGroup.

15

3.2.3 Service Een service stelt een zekere functionaliteit ter beschikking aan peers en peergroups. Dit kan bijvoorbeeld gaan om het uitwisselen van een bestand. Services kan je in twee categorieën onderverdelen: enerzijds heb je de peer services, anderzijds de peergroup services.

De eerste categorie groepeert diensten die aangeboden worden door één specifieke peer. Wanneer deze peer het netwerk verlaat is deze dienst niet meer beschikbaar.

De tweede categorie bevat de services die aangeboden worden door meerdere peers die tot een welbepaalde groep behoren. Zolang één van die peers online is, blijft deze dienst voor de peers van deze peergroup beschikbaar.

3.2.4 Endpoint

Elk endpoint stemt overeen met een netwerkinterface die verantwoordelijk is voor het versturen en ontvangen van data. Alle gegevens die verstuurd worden over het netwerk, hebben dus een zeker endpoint als bron en een zeker endpoint als doel.

3.2.5 Pipe Dit is een unidirectioneel, asynchroon, virtueel communicatiekanaal dat twee of meer endpoints met elkaar verbindt. JXTA definieert een pipe als unidirectioneel om een zo generiek mogelijke netwerkcommunicatie mogelijk te houden met het oog op de ondersteuning van zoveel mogelijk onderliggende netwerktransportprotocols.

Bemerk dat het hier gaat om een abstractie: in praktijk is er nergens zoiets als een pipe te bemerken, enkel een endpoint dat dienst doet als input pipe (vanwaar de data verzonden wordt) en een endpoint dat dienst doet als output pipe (waar de data ontvangen wordt). Het zijn de endpoints die een beroep doen op de onderliggende netwerkinterface die de verdere afhandeling verzorgt.

16

3.2.6 Message Een message is de eenheid van data die tussen twee endpoints over een pipe verzonden wordt. Alles wat over een pipe dient verstuurd te worden, wordt dus eerst als een message verpakt.

3.2.7 Advertisement Een advertisement is een gestructureerde boodschap die één van bovengenoemde concepten beschrijft. Advertisements in JXTA zijn allemaal opgemaakt in het XML formaat. Een voorbeeld van zo een advertisement vind je in figuur 3.1.

<jxta:PipeAdvertisement xmlns:jxta="http://jxta.org"> urn:jxta:uuid4D6113128072796E204272756E6F202021FA910EE3C94D23841C895826E2A 48C04 JxtaPropagate Cache Pipe Figuur 3.1 Een pipe advertisement

3.2.8 Protocol

Een protocol beschrijft hoe een peer interageert met de rest van het netwerk. Het betreft hier onder andere het vinden van andere peers en peergroups, het uitzoeken van welke services beschikbaar zijn, het toetreden en verlaten van groepen, het opzetten van pipes en dergelijke meer.

17

Een protocol maakt gebruik van bovengenoemde advertisements voor het organiseren van die informatie. Het doet dus niet meer dan simpelweg zeggen hoe die advertisements dienen uitgewisseld te worden. JXTA beschrijft een set van zes dergelijke protocols. Deze staan één voor één besproken in 3.3.

3.3 Protocols De protocols die JXTA specificeert, kunnen we ordenen in een stapelstructuur. Dit wordt geïllustreerd in figuur 3.2. Hierbij maakt elk protocol gebruik van de onderliggende protocols om zijn functionaliteit te verzorgen.

3.3.1 Endpoint Routing Protocol

Onderaan de stapel vinden we het endpoint routing protocol. Dit protocol zorgt ervoor dat er een route wordt gevonden zodat twee endpoints met elkaar kunnen communiceren.

Wanneer peer A een bericht wenst te sturen naar peer B, zal A eerst en vooral in zijn lokale cache kijken of het daar geen route-informatie kan vinden. Onder het begrip routeinformatie verstaan we in dit geval een rij van peers waarlangs het bericht van peer tot peer gestuurd wordt tot het zo de eindbestemming bereikt.

Wanneer peer A niet voldoende informatie heeft, stuurt het een zogenaamde Route Query Message uit naar alle router peers die het kent. Deze antwoorden met een Route Response Message (RRM), waarin een mogelijke route staat uitgestippeld. Peer A stuurt deze RRM mee met bericht naar de eerste peer in de routebeschrijving. Vanaf dan zal elke peer die het bericht in handen krijgt, uit het meegestuurde routebericht de volgende peer op het pad opmaken en het te versturen bericht doorzenden.

18

Figuur 3.2 JXTA Protocolstack

3.3.2 Peer Resolver Protocol

Het Peer Resolver Protocol maakt gebruik van het Endpoint Routing Protocol om zijn ding te doen. Dit beslaat het uitsturen van Resolver Query Messages, een generieke voorstelling van een vraag tot bepaalde informatie, en de daarbij horende antwoorden, Resolver Response Messages.

19

Bij het ontvangen van een query message zal het Peer Resolver Protocol de bijhorende query handler oproepen. Deze kan op basis van de vraagstelling een antwoord formuleren in de vorm van een response message (hoewel het geen verplichting is voor een peer om elke query te beantwoorden). Wanneer de ontvanger een Rendezvous Peer is, zal deze het bericht doorsturen naar alle gekende peers.

Bij het ontvangen van een response message zal het Peer Resolver Protocol het antwoord opnieuw overmaken aan diezelfde query handler, die dan het verkregen resultaat verwerkt.

3.3.3 Peer Discovery Protocol Aan de hand van dit protocol maken peers bekend aan de buitenwereld welke faciliteiten zij beschikbaar stellen. De informatie zit bevat in een advertisement en kan betrekking hebben op een service, een pipe, de peer zelf, een peergroup die de peer aangemaakt heeft, enzovoort.

Het Peer Discovery Protocol maakt gebruik van het bovengenoemde Peer Resolver Protocol om queries (hier de vraag voor een beschikbare bron) en antwoorden (in dit geval de advertisements) doorheen het netwerk te gidsen.

3.3.4 Pipe Binding Protocol Dit protocol is verantwoordelijk voor het opzetten van pipes tussen peers. Zoals reeds uitgelegd in 3.2 is een pipe een virtuele verbinding tussen twee endpoints in het netwerk. Hiermee kunnen de peers dan informatie uitwisselen. Het Pipe Binding Protocol doet een beroep op het Endpoint Routing Protocol om zijn diensten aan te kunnen bieden.

3.3.5 Peer Information Protocol Peer monitoring maakt een belangrijk onderdeel uit van een peer-to-peer netwerk. Door middel van het Peer Information Protocol wordt het mogelijk voor peer A om informatie over peer B te verkrijgen. Om de privacy te garanderen is gesteld dat peers deze dienst niet

20

hoeven te voorzien. Wanneer een peer een PIP-aanvraag uitstuurt, is er dan ook geen enkele garantie dat de bevraagde peer zal antwoorden. Dit protocol steunt volledig op het Peer Resolver Protocol.

3.3.6 Peer Membership Protocol

Zoals reeds duidelijk gemaakt groeperen peers zich in peergroups. Het is precies met betrekking tot die peergroups dat dit protocol zijn waarde heeft. Het Peer Memberschip Protocol stelt peers in staat om te kijken welke vereisten noodzakelijk zijn om een peergroup te joinen, een lidmaatschap aan te vragen voor een bepaalde peergroup, zich uit te schrijven uit een bepaalde peergroup, …

Het is vrij aan de ontwikkelaar hoe te bepalen of een peer een peergroup mag vervoegen. Dit kan bijvoorbeeld door een simpele paswoordcontrole of door de groepsleden te laten stemmen.

3.4 Het drielagenmodel

U vraagt u af hoe al deze componenten zich structureren in een groter geheel? Wel, JXTA is gebouwd volgens een model van drie lagen, zoals u kunt zien in figuur 3.3, waarbij elke laag verder bouwt op de capaciteiten van de onderliggende laag om extra functionaliteit en complexiteit toe te voegen.

De eerste laag betreft de JXTA Core. Deze laag groepeert wat absoluut nodig is voor elk peer-to-peer netwerk om te functioneren zoals het hoort. Het gaat hier om de basisconcepten die hierboven zijn behandeld: peers, peergroups, pipes, beveiliging. Ook functionaliteit als het vinden van andere peers (zie het peer discovery protocol) en andere protocols vinden we hier terug.

Eén laag hoger vinden we de JXTA Services. Deze bevat enerzijds de services die door Sun Microsystems zelf ontwikkeld werden (zoals de CMS service waarover meer in 3.5) en anderzijds services die door vrijwilligers bedacht worden.

21

Last but not least is er de JXTA Applications laag. Alle end-user applicaties vallen onder deze categorie. Denken we maar aan instant messaging programma’s, file-sharing toepassingen, voice-over-P2P enzovoort. Allen maken ze gebruik van de verschillende services uit de onderliggende laag die tot hun beschikking staan.

Figuur 3.3 Drielagenarchitectuur

3.5 CMS Service

CMS staat voor Content Management System [11], en dat is precies wat het doet: content managen. Het begrip ‘content’ kan je heel ruim interpreteren en deze service is dan ook generiek genoeg geïmplementeerd om alle mogelijke interpretaties te kunnen behandelen.

Voor deze thesis leent deze service zich uitstekend als file management system. Om de bestanden op het netwerk éénduidig te kunnen aanduiden, is ervoor gekozen om de hashwaarde te berekenen van elke file en die als unieke aanduiding voor het bestand te beschouwen. In de praktijk is het vrijwel onmogelijk om twee verschillende files te creëren waarvan de bytereeks eenzelfde hashwaarde oplevert. Die hashwaarde wordt voortaan ContentID genoemd.

22

Naast een ContentID wordt er met een bestand ook een ContentAdvertisement geassocieerd, een uitbreiding op het algemene JXTA concept van een advertisement. Deze beschrijft het bestand in kwestie. Bestandsnaam, bestandsgrootte, type bestand, oorsprong, allemaal zijn het parameters die via het ContentAdvertisement kunnen doorgegeven worden.

23

4. Caching Algoritmes Om onze cache peers nuttig te gebruiken, hebben we uiteraard een algoritme nodig dat bepaalt wie welk bestand wanneer zal opslaan. Om dit te bepalen zullen we gebruik maken van een algoritme om de nodige parameters te berekenen. Om de efficiëntie van dit algoritme te testen en vergelijken hebben we ook twee benchmark algoritmes gebruikt. We zullen eerst deze benchmarks illustreren en dan het gebruikte algoritme uitleggen.

4.1 Eerste benchmark: niet cachen De eerste benchmark is de eenvoudigste: we gaan geen enkel bestand cachen. Elk bestand bestaat dus maar op 1 plaats in het netwerk van cache peers. De nodige opslagcapaciteit op de caches zal dus minimaal zijn, maar daar tegenover staat dat hiervoor de kost om bestanden te downloaden maximaal zal zijn. We illustreren dit met een voorbeeld.

Figuur 4.1 Benchmark 1: niet cachen

24

Het bestand dat de gebruiker in dit geval wil downloaden bevindt zich op de cache peer die het verst van hem verwijderd is. Het zal hier dus nog twee dichterliggende caches voorbijgaan bij het downloaden. Geen van die caches zal in de toekomst dit bestand uit eigen beweging gaan ophalen. Dus voor elke keer dat de gebruiker dat bestand wil downloaden, zal het dezelfde weg afleggen.

4.2 Tweede benchmark: puur cachen De eerste benchmark diende om een slechtste geval voor de kost van het downloaden aan te tonen. De tweede benchmark zal nu een beste geval voor deze kost proberen benaderen.

Bij het puur cachen zullen we de caches ten volle benutten. Elk bestand zal door de cache die het dichtste bij de downloadende client staat, gecached worden. Op die manier moet een client voor hetzelfde bestand dit maar één keer gaan downloaden van een verdere cache, waarna alle volgende downloads kunnen gebeuren van de dichtstbijzijnde cache peer. We verduidelijken dit ook even met een voorbeeld.

Figuur 4.2 Benchmark 2: puur cachen 25

De client in het voorbeeld wil weer een bestand van de verst gelegen cache peer downloaden. Het bestand zal dus de weg volgen die aangeduid wordt door de rode pijlen. De tussenliggende caches zullen nu echter wel reageren op deze download. In dit geval zal de cache peer rechtsonder beslissen dat hij niet de laatste cache op het pad naar de client is en dus niks doen. De cache linksonder zal daarentegen weten dat hij wel de laatste cache op het pad is, en dus beslissen dat hij het bestand ook wil cachen. Deze cache zal het bestand nu ook downloaden, via de groene pijl (uiteraard gaat de werkelijke transfer van het bestand over het fysieke netwerk, en dus zal ook deze download langs de derde cache passeren, maar met transfers tussen caches onderling wordt geen rekening gehouden om de caches op te vullen). Elke volgende keer dat de client het bestand nu wil downloaden zal hij het dus enkel moeten gaan zoeken op de cache peer linksonder. Op deze manier is de kost voor het downloaden van files zo klein mogelijk.

4.3 Cache heuristiek Het algoritme dat we geïmplementeerd hebben, is gebaseerd op een heuristiek die ontworpen is door Tim Wauters. Het zal proberen de kost om bestanden te cachen (op te slaan op de cache peers) af te wegen tegen de kost om bestanden te downloaden (overdracht van de cache peers naar de client peers).

Het is een gedistribueerd algoritme, dus elke cache peer moet zelf zijn berekeningen uitvoeren om te bepalen wat hij moet doen. De caches moeten een lijst bijhouden met alle bestanden op het netwerk. Voor elk bestand in deze lijst zullen ze een parameter bijhouden en aan de hand van die parameter zullen ze bepalen welke bestanden ze gaan cachen of verwijderen. Elke keer als een bestand gedownload wordt door een client, zal de parameter hiervoor op elke cache peer tussen de client en de broncache aangepast worden. Wordt de parameter groter dan een bepaalde waarde, dan zal die cache het bestand ook gaan downloaden en beschikbaar stellen. Daalt de parameter onder een bepaalde waarde, dan zal die cache het bestand verwijderen als hij het heeft, of wanneer het nie zo is, simpelweg niks doen.

Verduidelijking met een voorbeeld:

26

As < A0

As > A0

Figuur 4.3 Cache algoritme

Dezelfde client wil weer van dezelfde cache een bestand downloaden. Het passeert langs de twee onderste cache peers, die elk de parameter As behorend bij dat bestand aanpassen. Nemen we aan dat die As in de cache linksonder tussen de ondergrens –A0 en A0 blijft, dan gebeurt hier niks. Op de cache rechtsonder wordt As groter dan de bovengrens A0 en dus zal deze cache peer het bestand ook gaan downloaden (groene pijl) en vanaf dan ook cachen (blauwe cirkel).

Daarna zitten we dus in de situatie zoals op de figuur linksonder, waarbij het bestand op twee cache peers staat.

27

As < -A0

Figuur 4.4 Cache algoritme

Indien nu op de bovenste cache peer de parameter As zou dalen tot onder –A0, dan zal deze het bestand verwijderen (na eerst gecontroleerd te hebben of het nog wel op een andere cache in het netwerk beschikbaar is) en komen we in de situatie zoals in de figuur rechts.

Als een bestand ergens gecached of verwijderd wordt, zullen alle andere cache peers voor dit bestand de geassocieerde As aanpassen. Indien de cache peer het bestand zelf heeft, zal hij de As ervoor terugzetten op A0. Als het bestand echter niet op de cache peer te vinden is, zal de As ervoor op –A0 gezet worden.

De berekening van de parameter As kan in twee delen opgesplitst worden. Als er een bestand passeert op de cache, dan zal As als volgt aangepast worden:

As = vorige As + Ss

Ss = kost van de verbinding tussen deze cache en de cache waarop het bestand zich bevindt

28

Ss stelt hier dus de downloadkost voor die zou uitgespaard worden indien de client op deze cache zou staan in plaats van op de cache waarop het bestand nu staat. Indien de kost voor elke netwerkverbinding één gekozen wordt is dit het aantal hops tussen de broncache (met het bestand) en de cache waarin de berekening gedaan wordt.

Als As alleen zou verhoogd worden als er een bestand passeert, zullen we uiteraard nooit in een situatie komen waar As < -A0 kan worden (gezien Ss altijd positief is). Dus zullen we na elke tijdseenheid As als volgt aanpassen:

As = vorige As – α * Cs

Cs = kost om een bestand te cachen

Met de kost om een bestand te cachen willen we uitdrukken wat de kost is verbonden aan het op schijf opslaan van het bestand. De α in de formule is een gewichtsfactor, deze zal dus uitdrukken hoe zwaar de kost om te cachen zal doorwegen tegenover Ss (uitgespaarde downloadkost) in de vorige formule.

Als we de twee formules samenvoegen, krijgen we dan:

As = vorige As + Ss – α * Cs

Hierin is duidelijk te zien dat als we α groter maken de invloed van de cachekost kleiner wordt, en als we α klein maken de invloed van die kost groot zal zijn. Op deze manier moet het mogelijk zijn om te beslissen wat belangrijker is in het netwerk: dat elke client elk bestand tegen een zo klein mogelijke kost kan downloaden (α groot), of dat de cache peers zo weinig mogelijk opslagruimte gebruiken (α klein).

Op figuur 4.5 zien we grafisch het effect van de parameter α op As. Beide lijnen stellen de parameter As voor van een bestand op een cache waar dit bestand nog niet gecached is. Beide lijnen tonen het verloop van As voor hetzelfde downloadpatroon: tussen tijdstip 4 en 5 passeert het bestand, nog eens tussen 6 en 7, tussen 7 en 8 en tenslotte tussen 12 en 13.

29

De waarde voor A0 is hier 5, dus het eerste moment waarop de lijnen boven 5 gaan zal de cache het bestand ook downloaden.

Alfa = 0.5

8

7

6

5

As 4 3

2

1

0 0

2

4

6

8

10

Tijd

12

14

Alfa = 1

Figuur 4.5 Invloed α op As

Deze tijdstippen zijn met een rode en een groene stip aangegeven op de lijnen. Voor het geval waarbij α 0.5 is, zal het bestand al op tijdstip 5 gecached worden, terwijl dit voor α 1 maar op tijdstip 8 zal gebeuren. Hierin blijkt dus inderdaad dat hoe groter de α hoe trager een bestand gecached zal worden. De lijn voor α gelijk aan 1 gaat ook veel steiler omlaag, en dus zal het bestand ook sneller verwijderd worden.

Wat we zullen testen met onze applicatie is of dit algoritme ervoor zorgt dat de downloadkost en de cachekost tussen de beste en slechtste waarden van de twee benchmarks blijven. We zullen dit doen door een aantal parameters vast te leggen, en door de gewichtfactor α te laten variëren. Op die manier kunnen we duidelijk het effect van die factor α aantonen op het resultaat.

30

5. De Implementatie 5.1 Inleiding In dit hoofdstuk zullen we dieper ingaan op de eigenlijke implementatie van onze filesharing applicatie. We zullen het in eerste instantie hebben over de opbouw van de applicatie, om daarna meer specifiek de implementatie tot op javacode-niveau te behandelen.

Bij iedere file-sharing applicatie onderscheidt men twee essentiële aspecten. Langs de ene kant moet er een onderdeel zijn dat de gebruiker in staat stelt bestanden op het netwerk te zoeken en de gevonden bestanden te downloaden. Langs de andere kant moet een filesharing omgeving uiteraard ook toelaten om bestanden over het netwerk beschikbaar te stellen.

Analoog is onze implementatie uiteen gevallen in twee componenten, de client peer implementatie en de cache peer implementatie. Eerstgenoemde zal de eindgebruiker in staat stellen het netwerk te doorzoeken, terwijl de tweede component ervoor zal zorgen dat bepaalde hosts op het netwerk de mogelijkheid hebben om lokale bestanden met de andere peers te delen.

Zoals de implementatie uiteen valt in twee delen, is ook dit hoofdstuk opgedeeld in de bespreking van de cache peer (5.2) en de bespreking van de client peer (5.3).

31

5.2 Cache Peer Een file-sharing omgeving zonder peers die bestanden delen is totaal ondenkbaar, dus bespreken we eerst de cache peer implementatie. Deze zal een peer dus in staat stellen bestanden aan de anderen beschikbaar te stellen. Bovendien zal deze ook de functionaliteit implementeren om bestanden lokaal te cachen en te verwijderen, alsook een cache peer op afstand te bevelen een bepaald bestand te cachen of te verwijderen.

5.2.1 Oorspronkelijk…

Oorspronkelijk was het de bedoeling de caching functionaliteit te groeperen in een JXTA service naar analogie met de 3-lagenarchitectuur van JXTA. De cache service zou dan beroep doen op de onderliggende laag, de kernlaag, die zoals reeds aangehaald, de essentiële primitieven voor P2P-communicatie omvat. De uiteindelijke applicatie zou dan in de bovenste laag vervat zitten en extensief gebruik maken van de zelf ontwikkelde JXTA service.

Dit concept wordt duidelijk geïllustreerd in figuur 5.1. Daar ziet u de verschillende lagen van opbouw in overeenstemming met de JXTA specificatie.

Echter, tijdens de programmeerfase zijn we op onoverkomelijke problemen gestoten bij deze aanpak. Het bleek onmogelijk om onze eigen JXTA service te combineren met de door ons gecreëerde peergroup van cache peers. Er werd door JXTA nooit melding gegeven van eventuele programmeerfouten, doch wanneer wij vanuit de applicatielaag trachtten beroep te doen op de onderliggende cache service, bleek JXTA niet in staat deze te vinden. Wij schrijven dit toe aan het vroege stadium van ontwikkeling waarin Project JXTA zich nog bevindt. We zijn er dan ook zeker van dat dit probleem in toekomstige versies zal verholpen zijn zodat alsnog een conceptueel betere implementatie mogelijk zal worden.

32

Figuur 5.1 Aangepast drielagenmodel

Hoe hebben we dit probleem dan omzeild? Wel, door niet effectief een JXTA service interface te implementeren maar een zelfstandig werkende cache “service” te ontwerpen, zoals duidelijk wordt op figuur 5.2. De applicatie, die gebruik maakt van de cache “service”, merkt er dus eigenlijk niks van.

Figuur 5.2 Onze oplossing

33

Verder in de tekst zullen we het steeds over de “cache service” hebben, met in het achterhoofd deze ideale constructie. Bemerk dus dat het hier niet gaat over een JXTA service, hoewel dit in verdere implementaties perfect mogelijk is.

5.2.2 Protocol

Het protocol dat wij opgesteld hebben om de communicatie tussen de verschillende cache peers op het netwerk te laten gebeuren, bestaat uit een zevental berichten. Al deze berichten zijn opgemaakt in XML volgens de JXTA specificaties.

Op figuur 5.3 ziet u een voorbeeld van een dergelijk bericht. Het is een voorbeeld van een bericht dat een bepaalde peer opdracht geeft tot het cachen van een bepaald bestand.

De algemene structuur van de diverse berichten kan gemakkelijk onderscheiden worden. Zo bevat het bericht steeds welke peer op het netwerk het bericht uitstuurt (het element met als naam jxta:SourceAddress).

Daarnaast is er ook een controleveld voorzien waarin aangegeven staat dat het effectief gaat om een bericht dat voor de cache service bestemd is (het element met als naam service). Verder vinden we een element met de naam order terug, waarin omschreven wordt om welk type bericht het gaat.

34

<Message version="0"> <Element name="jxta:SourceAddress" mime_type="text/plain"> tcp://123.456.205.212 <Element name="service" mime_type="text/plain"> CacheService <Element name="order" mime_type="text/plain"> cache <Element name="subject" mime_type="text/plain"> md5:226a264092109419423acbc99a71336a

<Element name="target" mime_type="text/plain"> Server30

Figuur 5.3 Voorbeeldbericht

Op dit moment zijn voor de cache service zeven berichten gedefinieerd, aangegeven in tabel 5.1:

Veldwaarde ‘order’-element Cache

Uncache

Betekenis Peer waarvoor dit bericht bestemd is, dient het beschreven bestand te cachen. Peer waarvoor dit bericht bestemd is, dient het beschreven bestand te verwijderen.

35

Dit bericht wordt uitgestuurd door een cache peer Cached

naar alle cache peers om duidelijk te maken dat de peer in kwestie het bestand succesvol heeft gecached. Dit bericht wordt uitgestuurd door een cache peer

Uncached

naar alle cache peers om duidelijk te maken dat de peer in kwestie het bestand succesvol heeft verwijderd.

Join

Exit

Download

Uitgestuurd naar alle cache peers wanneer een nieuwe peer het netwerk betreedt. Uitgestuurd naar alle cache peers wanneer een peer het netwerk verlaat. Uitgestuurd door een client peer wanneer die een bestand begint te downloaden.

Tabel 5.1

Met het subject-element wordt aangegeven welk bestand het hier betreft. Elk bestand wordt uniek aangeduid door een hashwaarde, die bekomen wordt aan de hand van de bytestream van dat bestand. Terwijl in theorie twee bestanden wel eens dezelfde hashwaarde zouden kunnen hebben, is het in de praktijk zo goed als onmogelijk om in een dergelijke situatie terecht te komen. Door middel van het target-element tenslotte geeft het bericht aan welke cache peer de bestemmeling is.

Afhankelijk van bericht tot bericht kan het voorkomen dat een bepaald veld niet voorkomt omdat het geen nut heeft.

Op te merken valt dat een download bericht één extra veld heeft. Het gaat om een vermelding die aangeeft vanaf welke cache peer de client peer het bestand in kwestie afhaalt.

Voor een overzicht van alle berichten in XML notatie verwijs ik u door naar dienaangaande appendix A.

36

5.2.3 Implementatie Wanneer we het over de implementatie van de cache peer entiteit hebben, refereren we daarbij naar 4 componenten. Het betreft de 4 rechtsgelegen onderdelen zoals in figuur 5.4 weergegeven: de CMS proxy, de cache service, de heuristiek interface en de topologie klasse.

We zullen deze 4 modules nu één voor één, in overeenstemming met de lagenstructuur, bespreken…

Figuur 5.4 Architectuur

CMS Proxy

Deze component is eigenlijk niet meer of niet minder dan een bufferklasse tussen de CMS en de verdere implementatie van de cache peer. Hij zal de onbelangrijke delen van de Sun Microsystems CMS service verbergen en er in zekere mate ook extra functionaliteit aan toevoegen.

37

Enkele van de geïmplementeerde functies voor de CMS proxy zijn de volgende:

public void search (String searchString, boolean expanding)

Deze zal een zoekquery uitsturen naar alle cache peers. Om de inkomende resultaten te kunnen verwerken, wordt een nieuwe thread opgestart. Dit is nodig aangezien de antwoorden van de cache peers geleidelijk aan zullen binnensijpelen, afhankelijk van de belasting van de verschillende delen van het netwerk en de afstand tussen de aanvrager en de peer die antwoordt. De boolean (mogelijke waarden true of false) die als parameter kan worden meegegeven maakt het mogelijk om, in plaats van de zoekresultaten van de vorige query weg te gooien, een cumulatieve resultatenset te maken, dus met de resultaten van beiden queries samen. De thread zal dan telkens wanneer er nieuwe antwoorden binnenkomen de collectie uitbreiden.

public void download (String dir, int index)

Uiteraard dient er dan ook een functie te zijn die, aan de hand van gevonden collectie van beschikbare bestanden, toelaat om één van die bestanden te downloaden. Het is dan ook precies dát wat deze functie doet. Parameters zijn de lokatie waar het bestand dient opgeslagen te worden en het indexnummer van het te downloaden bestand in de resultatenset.

public boolean cachedLocal (String contentID)

Deze functie zal nagaan of een bestand lokaal gecached staat. Het bestand wordt uniek aangeduid door de ContentID, welke overeenkomt met de hashwaarde van de inhoud van het bestand. Op die manier zullen de twee kopieën van een bestand dat op twee cache peers op het netwerk staat, ook herkend worden als zijnde hetzelfde bestand.

public boolean cachedRemote (String contentID)

38

Analoog is er ook een functie om na te gaan of een bestand nog ergens anders opgeslagen is. Dit is vooral nodig voor de heuristiek, die op deze manier kan nagaan of het bestand lokaal verwijderd mag worden. Het is immers niet de bedoeling dat er gegevensverlies optreedt.

public int share(File localFile, String peerName)

Uiteraard dienen bestanden door de cache peer aangeboden te worden. Met deze functie wordt dat mogelijk. De eerste parameter specificeert welk (lokaal) bestand als gecached dient te worden aangegeven, met behulp van de tweede parameter wordt meegegeven welke peer het bestand ter beschikking stelt, gezien de CMS service dit niet zelf kan te weten komen. Uit het bestand zal een ContentID berekend worden, dat vanaf dan het bestand uniek zal aanduiden.

public int unShare (String contentID)

Logischerwijze is er dan ook een functie waarmee een gedeeld bestand kan verwijderd worden. Zoals u ziet wordt nu het bestand geïdentificeerd door het ContentID in plaats van door het pad van het bestand in het lokale bestandssysteem.

Cache Service

De cache service is de service die verantwoordelijk is voor het ter beschikking stellen van de cache functionaliteit in zijn meest elementaire vorm. In concreto betekent dit dat deze in de eerste plaats zal toelaten om een bestand dat ergens op het netwerk staat, te downloaden om die vervolgens zelf aan te bieden aan de andere peers. Ook is het deze cache service die ervoor zal zorgen dat andere peers op de hoogte gehouden worden van alle wijzigingen met betrekking tot zijn aangeboden bestanden. Wanneer de peer een bepaald bestand beslist te cachen, meldt hij dit ook aan de andere cache peers op het netwerk, zodat dezen daarop gepast kunnen reageren indien nodig. Daarnaast maakt deze service het ook mogelijk om bevelen uit te sturen naar andere cache peers, zoals het bevel tot cachen of verwijderen van een bepaald bestand. Het reageren op inkomende berichten gebeurt in de functie public void pipeMsgEvent (PipeMsgEvent event). 39

Niet onbelangrijk met het oog op de generieke bouw van deze applicatie, is het feit dat de cache service toelaat om aparte componenten mee te laten luisteren op het netwerk. Op deze manier krijgen zij alle boodschappen die de cache peer zelf ontvangt, ook ter verwerking toegestuurd. Hiertoe is er een interface CacheServiceListener ontworpen. Deze interface voorziet in twee functie die geïmplementeerd dien te zijn om een volwaardige “luister”-module te hebben.

public abstract interface CacheServiceListener { // de functie die het bericht toegestuurd zal krijgen public void notify(Message m);

// de startfunctie die de CachePeer als argument meekrijgt... public void start(CachePeer cP); }

Figuur 5.5 Listener Interface

Telkens wanneer de cache service een bericht toegestuurd krijgt, zal hij deze notify-functie oproepen met het bericht in kwestie als parameter, en dit voor elke geregistreerde listener.

Cache Service

Listener 1

Bericht

Listener 2

Figuur 5.6 Voorbeeld van listeners

40

Listener 3

Het opvolgen van een gestarte download gebeurt door middel van de klasse DownloadWrapper. Zoals uit de broncode ook blijkt, zal deze functie telkens na het verlopen van een vast aantal seconden (bij onze implementatie is gekozen voor een interval van 1 seconde) de bestandsgrootte vergelijken met de uiteindelijke grootte die het bestand moet aannemen. Dit hebben we zo voorzien om te kunnen detecteren wanneer een bestand volledig overgezet is. Immers, we ondervonden aanvankelijk problemen met grotere bestanden in die zin dat er geen ‘download complete’ berichten werden gegeven. Een zoektocht op Internet leerde ons dat wij niet alleen dit probleem hadden, en dit werd als remedie voorgeschreven. Het gebruik van deze wrapper-constructie toonde aan waar precies de oorzaak van dit probleem zich situeert, namelijk veel dieper in de JXTA omgeving. Wanneer we met grotere bestanden werkten met behulp van de wrapperklasse, kregen we nu wel effectief een bevestiging van een voltooide overzetting, maar wat bleek? De unieke ID van het overgezette bestand verschilde van dat van het originele, wat erop wijst dat het bestand foutief werd overgezet, gezien het ID simpelweg de MD5-hashwaarde is van de bestandsinhoud. En inderdaad, tot nog toe biedt JXTA nog geen betrouwbare overdracht van pakketten aan. Er is geen garantie dat een verzonden bericht ook effectief toekomt, zelfs bovenop een netwerkprotocol als TCP/IP. Uiteraard zal dit wel verholpen worden in toekomstige versies van JXTA, maar dit zorgde er wel voor dat we voor het testen van de performantie verplicht waren ons te houden aan kleine bestanden.

Heuristiek Interface

Eén zo’n listener zoals hierboven beschreven is de heuristiek interface. Ook deze zal dus alle berichten ter inzage krijgen. Op basis hiervan kan deze dan de nodige beslissingen nemen inzake het cachen en/of verwijderen door de cache service van bepaalde bestanden die op het netwerk aanwezig zijn.

Het gaat hier om een interface wat erop duidt dat eender welke heuristiek die deze interface implementeert, kan ingevoegd worden in de cache peer toepassing. Dit uiteraard om de generieke structuur te bewaren. Bij constructie van het heuristiek object wordt een referentie naar de cache service meegegeven zodat de heuristiek een beroep kan doen op de functionaliteit die de cache service aanbiedt, zoals hierboven uitvoerig beschreven.

41

Voor zijn goede werking kan de heuristiek ook een beroep doen op onderstaande topologie component.

Topologie

Vele caching heuristieken, alsook de heuristiek die wij geïmplementeerd hebben, hebben intrinsiek nood aan een zekere kennis met betrekking tot de netwerktopologie. Zo moeten zij op de hoogte zijn van het (kortste) pad tussen twee peers, en tevens ook de kost van een dergelijk pad. Teneinde hier een oplossing voor te bieden, hebben wij voorzien in een topologie klasse. Deze is op de hoogte van alle netwerkinformatie en zal de gevraagde gegevens hieruit berekenen.

public boolean isLink(String from, String to)

Geeft terug op er een directe verbinding is tussen de twee aangegeven knopen in het network

public boolean onPath(String node, String from, String to)

Controleert of een bepaalde knoop (aangeduid door parameter node) op het kortste pad ligt tussen de twee opgegeven knopen.

public int getHops (String from, String to)

Deze functie zal het aantal hops dat dient overbrugd te worden weergeven. We hebben ook voorzien in een getCost functie, wanneer we de kost zouden willen voorstellen door iets anders dan het aantal hops. Wij maken echter geen gebruik van die functie.

Voor ons vrij kleine testnetwerk hebben we ervoor gekozen de netwerktopologie hard te coderen. Een volledige implementatie van het Dijkstra algoritme bijvoorbeeld zou niet alleen veel overhead met zich meebrengen, ook zou het een overbodige inspanning zijn die

42

ons verder weinig tot geen verbeteringen brengt. Bovendien zijn er reeds verscheidene implementaties van dergelijke algoritmen publiek beschikbaar, zodat het inpassen van een bestaande oplossing in onze file-sharing omgeving weinig tot geen noemenswaardige problemen zou mogen opleveren.

5.3 Client Peer Uiteraard heeft een cache peer implementatie zoals beschreven in 5.2 weinig nut als er geen peers zijn die de beschikbare bestanden downloaden. En dus hebben we een client peer ontwikkeld die als enige doel heeft gedeelde bestanden van het netwerk te plukken. Vanwege de verdere doelstellingen van deze thesis, namelijk het testen van de performantie van de cache heuristiek en het vergelijken ervan met enkele benchmarks, leek het ons evident te kiezen voor een volautomatische client. De client peer zoekt daarbij het netwerk af op beschikbare bestanden, kiest er één willekeurig uit die lijst, zoekt de dichtstbijzijnde cache peer waar dat bestand beschikbaar is, en haalt het bestand af van die locatie.

We zullen nu wat dieper ingaan op de structuur van de client peer. Wanneer we op figuur 5.5 nu onze aandacht richten op de linkerhelft, onderscheiden we 3 componenten die samen de client peer uitmaken: dezelfde CMS proxy en topologie module als we gezien hebben bij de cache peer, en daarnaast nog de client zelf.

Over de eerste twee kunnen we vrij kort zijn, aangezien zij reeds werden besproken. Uiteraard zal voor de client peer veel minder van de aangeboden functionaliteit tot nut zijn. Toch leek het ons het meest logische om voor zowel client als cache peer dezelfde hulpklassen in te schakelen. Ondanks hun verschillende doeleinden hebben ze immers toch ook wel redelijk wat aspecten gemeen (zowel client als cache dienen in staat te zijn een bestand van een zekere cache peer te downloaden).

43

Figuur 5.5 Architectuur

CMS Proxy

De CMS proxy zal de client in staat stellen het netwerk af te zoeken op de aanwezigheid van bepaalde bestanden. Dit zoeken gebeurt op basis van een patroon waaraan de bestandsnamen moeten voldoen. De CMS voorziet ook in een uitbreiding van deze zoekbewerking. Zo is het in principe mogelijk om te zoeken met behulp van extra metadata. Elk bestand wordt dan niet alleen door de bestandsnaam gekarakteriseerd, maar daarnaast ook door bijvoorbeeld een aantal trefwoorden. Hiervan is echter tot op heden geen gebruik van gemaakt.

Ook voor het downloaden van een gevonden bestand zal de CMS proxy ingeschakeld worden.

Topologie

Wanneer een bestand gedownload wordt, gebeurt dit preferabel vanaf de dichtstbijzijnde bron. Door middel van deze topologie module is de client in staat te beslissen welke cache peer dat is.

44

Client pier

Dit brengt ons dan bij het virtuele hart van de client peer. Het is van hieruit dat het netwerk afgespoord wordt naar beschikbare bestanden. Onze implementatie zal uit deze collectie een willekeurig bestand kiezen. Vervolgens zal het de dichtstbijzijnde bron voor dat bestand nagaan, en uiteindelijk de downloadprocedure starten.

Ook de client is aangesloten op het communicatiekanaal van de cache peers. De client peer is echter niet in staat te luisteren naar de passerende berichten, hij is enkel in staat zelf berichten uit te sturen. Net voor de client peer de download van een bestand start, zal hij immers een bericht naar de caches uitsturen. Op deze manier komen ook zij te weten dat het bestand in kwestie opgevraagd is, wat eventueel kan verwerkt worden in de heuristiek. Het versturen van het bericht gebeurt aan de hand van de functie

public static void sendDownload(int invnum)

Stuurt een downloadbericht uit naar de cache peers zoals uitgeschreven in Appendix A. De parameter in de functieaanroep geeft aan welk bestand precies gedownload wenst te worden.

private static Vector filterResults(Vector results)

Wanneer de client peer ertoe komt een bestand te downloaden, zal dit het liefste gebeuren vanaf de dichtsbijzijnde bron. Deze functie laat toe om de gevonden zoekresultaten te filteren zodat een dubbel voorkomen van een zeker bestand herleid wordt tot enkel het beste, dus dichtstbijzijnde.

Zoals reeds gezegd werkt deze client automatisch. We hebben ook voorzien in een manuele versie waar de eindgebruiker vanaf het console venster bestanden kan zoeken en downloaden. Deze voorziening is echter vrij minimalistisch in die zin dat het totaal ontbreekt aan een grafische gebruikersinterface. Het was dan ook onze primaire taak om de heuristiek in te werken in de file-sharing omgeving en de performantie ervan na te gaan, eerder dan een gebruiksvriendelijke applicatie af te leveren. 45

6. Performantietests 6.1 Het testnetwerk Om onze applicatie te testen kregen we de beschikking over acht computers in het Atlantis testlab van Intec. Hiervan werden er vier gebruikt als client peer en vier als cache peer. De cache peers werden in een ring opgesteld, en elk ervan was verbonden met 1 client peer (zie figuur 6.1).

Client 32 10.10.10.30

Client 33 10.10.10.33

Server 30 10.10.10.30

Server 31 10.10.10.31

Server 35 10.10.10.35

Server 133 10.10.10.133

Client 134 10.10.10.134

Client 34 10.10.10.34

Figuur 6.1 Testnetwerk

Op deze cache peers hebben we dan een aantal bestanden verdeeld. Deze bestanden hebben we één keer willekeurig verdeeld (zie tabel 6.1), en we hebben voor alle volgende tests dezelfde beginsituatie genomen. De bestanden zijn ongeveer allemaal even groot, gezien

46

we door problemen met de CMS service grotere bestanden niet betrouwbaar over het netwerk konden sturen. Ook om deze reden hebben we voor de kost van het downloaden de hopcount genomen in plaats van de tijd die het duurt om een bestand te downloaden. De cache peers houden twee soorten logbestanden bij: een logbestand van alles wat ze cachen en verwijderen (met de tijdstippen uiteraard) en 2 logbestanden voor de As parameter. Eén van die twee schrijft de As waarde weg elke keer als de cachekost ervan afgetrokken wordt (dus elke interval), het andere logbestand bevat de As waarden op het moment dat de Ss (hopcount tussen broncache en de cache waarop het bestand passeert) erbij opgeteld wordt. Met de logresultaten van de gecachte en verwijderde bestanden kunnen we dan berekenen wat de gemiddelde opslagkost is voor de caches.

Server 133: Server 35: Server 30: Server 31: Totaal:

7 0 2 3 12

Tabel 6.1 Verdeling bestanden in het netwerk

De client peers laten we automatisch downloaden. Ze zullen de lijst met beschikbare bestanden in het netwerk voor elke download opvragen, en random een bestand kiezen uit die lijst om te downloaden (indien het bestand op meerdere cache peers te vinden is, zal het gedownload worden van de dichtstbijzijnde). Als het bestand volledig overgezet is, schrijven ze een regel weg naar hun logbestand met daarin het ID van het bestand, het aantal hops tussen de cache en de client en het tijdstip. Met deze gegevens voor alle clients kunnen we dan het verloop van de downloadkost voor een welbepaald bestand volgen, berekenen wat de gemiddelde hopcount was over alle bestanden die een bepaalde client downloadde en de totale gemiddelde hopcount (downloadkost) voor alle clients berekenen.

De twee criteria die we zullen meten en vergelijken zijn dus de cachekost en de downloadkost.

47

6.2 Problemen Bij onze tests zijn we op enkele problemen gestoten. Eén daarvan was het niet correct aangeven wanneer een download volledig was door de CMS service. Dit wisten we echter op te lossen door een downloadwrapper te schrijven die dit wel correct doet. Toen merkten we dat zelfs met die wrapper grote bestanden niet 100% correct over het netwerk gestuurd werden. Hierdoor moesten we ons dus beperken tot kleine bestanden.

Er was evenwel ook een probleem waarvoor we geen oplossing hebben. Het bleek namelijk dat de clients na een bepaald aantal downloads (meestal rond de 180-185) opeens geen bestanden meer vonden in het netwerk. Echter als we een nieuwe client apart startten, dan vonden we hiermee wel alle bestanden die nog in het netwerk zaten, het probleem lag dus niet aan de client. De cache peers begonnen rond dit tijdstip ook te falen om nog nieuwe bestanden af te halen van elkaar en te cachen. Maar ook als we een nieuwe cache startten, had deze er geen problemen mee om dit wel correct te doen. De oorzaak van het probleem ligt dus aan de CMS service die verantwoordelijk is voor het lokaliseren van bestanden op het netwerk. Wat er hier precies fout in liep, konden we niet achterhalen en zodoende konden we hiervoor ook geen work-around schrijven. Hierdoor konden we onze tests dus niet voor langere tijd laten lopen, maar moesten we telkens het hele netwerk opnieuw starten.

6.3 Eerste benchmark: niet cachen

Zoals in hoofdstuk 4 reeds gezegd, zullen er bij deze tests geen bestanden tussen de cache peers onderling uitgewisseld worden. De nodige opslagruimte blijft dus van begin tot einde hetzelfde (zoals tabel 6.1 dus). Dit is tegelijk ook het minimum dat nodig is om alle bestanden in het netwerk te houden.

De theoretische gemiddelde downloadkost voor alle clients is 2. Gezien het kleinste aantal links tussen een client en een cache 1 is en het grootste 3, en er in beide gevallen juist 1 zo’n pad is, zullen we inderdaad voor clients die random downloaden een gemiddelde kost van 2 verwachten.

48

Kijken we naar tabel 6.2, dan zien we inderdaad dat het totale gemiddelde rond de 2 zit. Voor de individuele clients is dit echter niet zo.

# downloads Client 134: Client 34: Client 33: Client 32: Totaal:

# hops 176 183 184 184 727

298 419 320 433 1470

# hops / download 1.693181818 2.289617486 1.739130435 2.35326087 2.022008253

Tabel 6.2 Benchmark 1: downloadkost

De kost voor client 134 is bijvoorbeeld het kleinste van allemaal. Dit is te verklaren doordat de cache peer het dichtste bij deze client (server 133: 7 bestanden) de meeste bestanden op het netwerk aanbiedt. Ook de client die het dichtste staat bij de cache peer die het tweedegrootste aantal bestanden (server 31: 3 bestanden) aanbiedt, heeft een gemiddelde downloadkost kleiner dan 2. De clients die verbonden zijn aan de cache peers die de minste bestanden delen hebben dan weer een gemiddelde downloadkost groter dan 2.

Bij het testen van het echte caching algoritme zullen we dus 12 nemen als beste geval voor de cachekost (dit is sowieso het beste geval, gezien er altijd 12 bestanden in het netwerk moeten zitten). Als slechtste geval voor de downloadkost zullen we 2 kiezen. Dit is strikt gezien niet het slechtst mogelijke resultaat (indien het een heel inefficiënt algoritme is, zou het maximum 3 kunnen zijn), maar indien het slechter zou presteren heeft het helemaal geen zin om het te gebruiken. Inderdaad, indien de gemiddelde downloadkost voor het algoritme slechter zou zijn dan die voor de “niet cachen” benchmark, dan is er geen voordeel verbonden aan het gebruik van dit algoritme. In tegendeel, de overhead van de uitgewisselde boodschappen en de transfer van bestanden tussen de cache peers onderling zullen de prestaties van het algoritme in dat geval enkel nog verslechteren.

6.4 Tweede benchmark: puur cachen

De cachekost voor deze benchmark zal uiteraard evolueren naar de maximumwaarde voor het netwerk. Deze waarde is hier gelijk aan het aantal caches maal het aantal unieke

49

bestanden, dus 4 * 12 = 48. Deze totale cachekost is te zien in tabel 6.3, samen met de gemiddelde cachekost.

# files begin Server 133: Server 35: Server 30: Server 31: Totaal:

7 0 2 3 12

# files einde 12 12 12 12 48

gemiddeld 9.5 6 7 7.5 30

Tabel 6.3 Benchmark 2: cachekost

# files / cache 14

12

10

Server31

8

Server35 Server30 6

Server133

4

2

0 15:04:19

15:05:46

15:07:12

15:08:38

15:10:05

15:11:31

15:12:58

15:14:24

Ti j d

Figuur 6.1 Benchmark 2, cachekost grafiek

Op figuur 6.1 zien we hoe de cache peers opgevuld worden met bestanden. Hierop zien we dat hoe meer bestanden de cache peer al heeft, hoe kleiner de kans dat een nieuw bestand gecached zal worden. Dit is ook logisch gezien hoe meer bestanden een cache peer heeft, hoe groter de kans dat hij het bestand dat “zijn” client peer vraagt heeft.

De downloadkost zou voor deze benchmark in de limiet naar 1 moeten evolueren, vermits uiteindelijk alle bestanden op alle caches staan kunnen alle clients elk bestand via 1 link downloaden. In tabel 6.4 is te zien dat dit voor onze tests zo lijkt te zijn. Helaas konden we wegens bovenvermelde problemen niet langere tests uitvoeren, waardoor de gemiddelde downloadkost gestrand is op 1,19. 50

# downloads 85 92 89 87 353

Client 34: Client 33: Client 32: Client 134: Totaal:

# hops # hops / download 112 1.317647059 102 1.108695652 109 1.224719101 96 1.103448276 419 1.186968839

Tabel 6.4 Benchmark 2: gemiddelde downloadkost

Uit deze resultaten halen we dus als slechtste geval voor de totale cachekost 48 en 30 als gemiddelde cachekost. Het beste geval voor de gemiddelde cachekost is dus (theoretisch) 1. Samen met de resultaten van de eerste benchmark kennen we nu de grenzen waar de waarden voor het algoritme moeten tussenliggen om efficiënt te zijn. De gemiddele downloadkost zal tussen 1 en 2 moeten liggen, de totale cachekost tussen 12 en 48 en de gemiddelde cachekost tussen 12 en 30.

6.5 Cache algoritme Alles draait in dit algoritme rond de berekening van de parameter As, dus we herhalen hier nog even de formule:

As = vorige As + Ss – α * Cs

En het interval waartussen deze As belangrijk is:

-A0 < As < A0

Voor deze berekeningen moeten we dus een aantal parameters vastleggen: keuze Ss, Cs, A0 en α . Gezien Ss de kost uitdrukt om een bestand te downloaden tussen twee caches, zullen we dit uitdrukken in het aantal links tussen caches. De kost om een bestand gedurende één interval op schijf op te slaan wordt voorgesteld door Cs, dit stellen we gelijk aan 1. Voor de startwaarde A0 hebben we 5 gekozen.

51

Ook van belang is de intervaltijd (update-interval), waarop we dus de cachekost in rekening zullen brengen. Deze hebben we op 60 seconden gezet. Hiermee samen hangt dan de snelheid waarmee clients downloads starten. Deze snelheid is onze testopstelling ongeveer 4 bestanden per interval, dus 4 per minuut.

De keuzes voor A0 en de lengte van het update-interval hebben elk een invloed op de snelheid waarmee gecached en verwijderd wordt. Indien we A0 groter zouden maken, dan zal het waardeninterval dat As moet doorlopen groter worden, en zijn er dus meer downloads van hetzelfde bestand nodig om het ergens te cachen. Gelijkaardig is er ook meer tijd nodig voor een bestand verwijderd wordt. Het omgekeerde geldt als we A0 kleiner maken. En indien we het update-interval groter maken zal een bestand sneller gecached en trager verwijderd worden. Het omgekeerde geldt uiteraard indien we het interval verkleinen. Toch hebben we deze parameters vast gekozen. We zullen de snelheid van cachen en verwijderen regelen door de laatste parameter α, waarvan we in hoofdstuk 4 (figuur 4.5) al aangetoond hebben wat de invloed op As is.

We hebben dus meerdere tests uitgevoerd, telkens voor een andere waarde van α. De waarden die we kozen voor α lagen allemaal tussen 0 en 2. Hoe dichter α bij 0 komt, hoe dichter we bij de resultaten voor puur cachen (benchmark 2) zullen komen, aangezien in dat geval de kost om een bestand te cachen niet meer in rekening wordt gebracht. En we merkten dat vanaf α groter dan 2 dat de resultaten slechter werden dan die voor no caching (benchmark 1), dus de interessante waarden voor α lagen inderdaad tussen 0 en 2.

We zullen de resultaten hier volgens oplopende waarden voor α bespreken. We zullen echter niet alle berekeningen hier uitgebreid tussenplaatsen. Alle berekeningen kunnen in appendix B gevonden worden.

Client 134: Client 32: Client 33: Client 34: Totaal:

# downloads 182 185 185 185 737

# hops 226 298 242 267 1033

# hops / download 1.241758242 1.610810811 1.308108108 1.443243243 1.401628223

Tabel 6.5 Downloadkost voor α = 0,1

52

Voor α gelijk aan 0,1 zien we in tabel 6.5 dat de gemiddelde downloadkost voor alle clients ongeveer 1,4 is. Ook hier is de kost voor client 134 weer het kleinste, gevolgd door client 33. Dit zijn weer de clients die met de cache peers die in het begin het meest gevuld zijn verbonden zijn. Zelfs voor een α zo dicht bij 0 zitten we hier nog vrij ver af van de theoretische minimumwaarde van 1 die we voor puur cachen verwachten.

# files begin Server 133: Server 35: Server 30: Server 31: Totaal:

7 0 2 3 12

# files einde 11 9 7 10 37

gemiddelde 9 4.5 4.5 6.5 24.5

Tabel 6.6 Cachekost voor α = 0,1

In tabel 6.6 zien we dan wel dat de gemiddelde en totale cachekost (respectievelijk 24,5 en 37) dan ook wel beter zijn dan de waarden voor puur cachen (30 en 48). Dus zelfs voor kleine waarden van α blijft de benodigde opslagcapaciteit op de cache peers kleiner dan bij puur cachen.

Verhogen we α dan tot 0,25 dan zien we in tabel 6.7 dat de downloadkost maar een weinig verhoogt tot ongeveer 1,42. Uit tabel 6.8 blijkt dat de totale cachekost een flink stuk daalt (-7). Uiteraard gaat hierdoor ook de gemiddelde cachekost omlaag.

Client 134: Client 32: Client 33: Client 34: Totaal:

# downloads 101 185 172 185 643

# hops 118 272 256 265 911

# hops / download 1.168316832 1.47027027 1.488372093 1.432432432 1.416796267

Tabel 6.7 Downloadkost voor α = 0,25

53

# files begin Server 133: Server 35: Server 30: Server 31: Totaal:

# files einde

7 0 2 3 12

gemiddelde 10 7 7 8 32

8.5 3.5 4.5 5.5 22

Tabel 6.8 Cachekost voor α = 0,25

Laten we α stijgen tot 0,5 (tabellen in appendix B) dan verhoogt de downloadkost tot ongeveer 1,44. De cachekost daalt verder tot 27 voor de totale kost en tot 19.5 voor de gemiddelde.

Vreemd is dat de resultaten voor α 0,75 dan weer (heel licht) in de andere richting verschuiven. De downloadkost gaat van 1,44 tot 1,43 en de totale cachekost van 27 naar 28 (dus de gemiddelde cachekost van 19.5 naar 20). Deze verschillen zijn zo klein dat ze waarschijnlijk te wijten zijn aan het random downloadgedrag van de clients.

In tabel 6.9 zien we dat de downloadkost terug stijgt voor α gelijk aan 1. Deze kost is nu ongeveer 1,52 en zit dus ongeveer op het midden tussen de beste waarde 1 (voor puur cachen) en de slechtste 2 (no caching). De cachekosten zitten hier wel een stukje onder het midden voor hun beste geval – slechtste geval interval. De gemiddelde cachekost is hiervoor 16,5 (midden tussen 12 en 30 is 21) en de totale kost is 21 (terwijl midden tussen 12 en 48 25 is).

# downloads Client 134: Client 32: Client 33: Client 34: Totaal:

# hops 183 185 185 185 738

244 274 292 311 1121

Tabel 6.9 downloadkost voor α = 1

54

# hops / download 1.333333333 1.481081081 1.578378378 1.681081081 1.51897019

# files begin Server 133: Server 35: Server 30: Server 31: Totaal :

# files einde 7 0 2 3 12

Gemiddelde

6 4 6 5 21

6.5 2 4 4 16.5

Tabel 6.10 Cachekost voor α = 1

Voor α = 1,25 zet de stijgende trend voor de downloadkost zich voort zoals verwacht. De downloadkost stijgt hier tot 1,62. De cachekosten blijven ook verder dalen tot 15 (totale) en 13,5 (gemiddelde). We zitten hier voor de cachekosten dus al vrij dicht bij het beste geval (12 en 12).

# files begin Server 133: Server 35: Server 30: Server 31: Totaal:

# files einde

7 0 2 3 12

Gemiddelde 5.5 1 2 3.5 12

4 2 2 4 12

Tabel 6.11 Cachekost voor α = 1,5

We zien in tabel 6.11 inderdaad dat voor α 1,5 de cachekosten al gedaald zijn tot het minimum. Gezien dit voor alle grotere waarden voor α ook zo blijft, laten we vanaf nu deze tabellen achterwege en vermelden we dit resultaat niet telkens opnieuw. De downloadkost stijgt hier ook terug, dit keer tot 1,79.

Voor α gelijk aan 1,75 stijgt de downloadkost verder tot 1,82. Dit begint al dicht te komen bij het slechtste geval van 2 (no caching).

Client 134: Client 32: Client 33: Client 34: Totaal:

# downloads 181 184 183 185 733

# hops 319 407 344 372 1442

# hops / download 1.762430939 2.211956522 1.879781421 2.010810811 1.967257844

Tabel 6.12 Downloadkost voor α = 2 55

Uit tabel 6.12 blijkt dat voor α gelijk aan 2 deze bovengrens al heel dicht benaderd wordt met 1,97. Voor waarden groter dan 2 voor α gaat de downloadkost ook inderdaad boven deze grens, en is het dus efficiënter om gewoon niet te cachen dan om het algoritme te gebruiken.

Kijken we dan ook eens naar de grafieken die weergeven wanneer elke cache een bestand opslaat of verwijdert.

# files / cache 12

10

8 Server 35 Server 31 6

Server 133 Server 30

4

2

0 15:00:00

15:07:12

15:14:24

15:21:36

15:28:48

15:36:00

15:43:12

Ti j d

Figuur 6.2 Cachekost grafiek voor α = 0,1

We zien op figuur 6.2 dat net zoals bij puur cachen (figuur 6.1) er in het begin heel snel na elkaar een aantal bestanden gecached worden, maar dat het na die beginperiode langzamer gaat. Het is jammer dat onze tests maar een beperkte tijd konden duren, want daardoor is het weinig waarschijnlijk dat bij de kleinere α-waarden er ook bestanden verwijderd zullen worden.

56

# files / cache 12

10

8 Server 133 Server 35 6

Server 31 Server 30

4

2

0 9:21:36

9:28:48

9:36:00

9:43:12

9:50:24

9:57:36

10:04:48

Ti j d

Figuur 6.3 Cachekost grafiek voor α = 0,75

We zien pas vanaf α 0,75 dat er ook bestanden verwijderd worden (figuur 6.3). Hier werden er dan weer na de opstartperiode geen nieuwe bestanden meer gecached.

6.6 Vergelijking

We hebben in de bespreking van de resultaten voor het cache algoritme wel al aangehaald hoe deze zich vergelijken tot die van de benchmarks, maar we zullen dit hier grafisch weergeven en samenvatten.

We hebben in figuur 6.4 de gemiddelde downloadkost voor de benchmarks en het algoritme uitgezet. We hebben dus als ondergrens het resultaat van de puur cachen benchmark (we hebben hier het resultaat uit onze tests uitgezet in plaats van de theoretische grens 1) en als bovengrens het resultaat van de no caching benchmark (ook hier weer het getal uit onze tests in plaats van mooi rond 2).

57

Gem. downloadkost 2.5

Hops / download

2

1.5

Algoritme No caching Puur cachen

1

0.5

0 0

0.5

1

1.5

2

2.5

Alfa

Figuur 6.4 Vergelijking downloadkost

Op figuur 6.4 is duidelijk te zien dat we voor alle waarden van α tussen 0,1 en 2 niet beter presteren dan puur cachen, maar ook niet slechter dan no caching. We merken wel op dat de downloadkost veel dichter bij de bovengrens komt dan dat ze ooit bij de ondergrens komt.

Tot. cachekost 60

Files / cache

50

40

Algoritme No caching

30

Puur cachen 20

10

0 0

0.5

1

1.5

2

Alfa

Figuur 6.5 Vergelijking cachekost

58

2.5

Op figuur 6.5 hebben we dan de totale cachekost uitgezet (het aantal bestanden die op het einde van elke test op de cache peers stonden). Hierin komen de boven- en ondergrens van de resultaten van respectievelijk de puur cachen benchmark en de no caching benchmark. Ook op deze grafiek is te zien dat de grens van de puur caching benchmark niet dicht benaderd wordt. Terwijl deze keer de ondergrens van de no caching benchmark niet alleen benaderd wordt, maar ook gehaald wordt.

Op deze grafieken zien we ook het verloop dat we voorop gesteld hadden: hoe groter α wordt, hoe groter de downloadkost en hoe kleiner de cachekost. Hiermee is dus aangetoond dat het algoritme inderdaad werkt zoals verwacht.

Uit de twee grafieken samen kunnen we besluiten dat het weinig zin heeft om α groter dan 1,5 te kiezen. Vermits we vanaf dat punt toch al aan het minimum voor de cachekost zitten, zouden we door α groter te kiezen enkel de downloadkost verslechteren zonder winst voor de cachekost. We kunnen dus stellen dat een “nuttige” α tussen 0 en 1,5 zou moeten liggen.

59

7. Conclusies 7.1 Wat hebben we bereikt? In eerste instantie hebben we een werkende file-sharing peer-to-peer applicatie ontwikkeld, en dit gebruikmakend van het JXTA platform. Deze applicatie valt uiteen in 2 delen, een cache peer gedeelte dat instaat voor het ter beschikking stellen van bestanden, en een client peer gedeelte dat toelaat om gedeelde bestanden te downloaden.

Bovendien hebben we getracht ervoor te zorgen dat deze applicatie zo uitbreidbaar mogelijk bleef. Dit hebben we bereikt door middel van het gebruik van interfaces waar mogelijk. Zo kan een alternatieve implementatie van de heuristiek interface toegevoegd worden mits minimale aanpassingen aan de oorspronkelijke code. Ook is het mogelijk om extra ‘listeners’ te registreren bij de cache service zoals besproken in hoofdstuk 5, wat toelaat om de communicatie tussen de cache peers onderling op te volgen.

Zelf hebben we ook voorzien in de implementatie van één algoritme en twee benchmarks, zoals te lezen is in hoofdstuk 4. Dit algoritme hebben we dan op de proef gesteld en de performantie ervan getest. Hierover kunt u alles terugvinden in hoofdstuk 6. Het belangrijkste resultaat dat te vermelden valt, is dat de performantie van het algoritme, afhankelijk van gekozen afweging tussen de benodigde opslagcapaciteit en de downloadkost, zal schommelen tussen de twee uitersten van de benchmarks.

60

7.2 Ervaringen met de JXTA omgeving Door de ontwikkelings- en testfase zijn we nog meermaals op tekortkomingen van JXTA gestoten. Kort samengevat komt het erop neer dat de implementatie van het JXTA platform nog te wensen overlaat. Zo zijn er problemen met de berichtversturing. Deze is tot nader order onbetrouwbaar, zelfs bovenop een betrouwbaar netwerkprotocol zoals TCP/IP. Daarnaast was er ook een probleem met de CMS service, welke verdere dienst weigerde bij een 180-tal downloads vanaf de clients.

We zijn er echter zeker van dat deze problemen in de nabije toekomst opgelost zullen zijn. Het idee van een uniform peer-to-peer platform is immers erg verdienstelijk en veelbelovend.

7.3 Mogelijke uitbreidingen…

Uiteraard zijn er nog een hele hoop uitbreidingen mogelijk aan onze applicatie. We zullen er hier in het kort enkele voorstellen.

Allereerst is het natuurlijk mogelijk om andere caching algoritmes te implementeren. Gezien de opbouw van onze applicatie zal dit het gemakkelijkste zijn als ze ook gedistribueerd rekenen, maar met enkele aanpassingen is een centraal berekend algoritme ook mogelijk.

Het zou ook handig zijn om de topologie van het netwerk niet meer hard te moeten coderen. Hiervoor zou de topologieklasse herschreven kunnen worden om zelf de structuur van het netwerk te ontdekken en dan met bijvoorbeeld het algoritme van Dijkstra de paden die bestanden in het netwerk afleggen te bepalen.

Gezien de bugs en fouten die nog aanwezig waren in de implementatie van het JXTA platform en de CMS service waarvan we gebruik gemaakt hebben, zou het aangewezen zijn om op een nieuwe versie van deze implementaties over te schakelen. Er zijn al nieuwe

61

versies hiervoor beschikbaar, maar deze kwamen te laat voor ons om ernaar over te schakelen gezien dit een hercodering van een groot stuk van onze applicatie zou vragen.

In onze implementatie van het caching algoritme hebben we de cachekost (Cs) voor elk bestand op 1 gesteld. Dit zou makkelijk kunnen vervangen worden door een getal gebaseerd op bijvoorbeeld de grootte van het bestand. Op die manier wordt uitgedrukt dat niet alle bestanden evenveel kosten om op te slaan op schijf. Dit is nu al mogelijk door bij het aanmaken van de lijst met de bestanden in het netwerk een andere waarde voor Cs te laten invullen in de Triple die met elk bestand geassocieerd is.

Op dit moment kunnen er ook geen bestand in het netwerk geïntroduceerd worden door cache of client peers eens deze gestart zijn. Het zou bijvoorbeeld mogelijk gemaakt kunnen worden voor cache peers om bestanden die lokaal staan alsnog te sharen eens ze gestart zijn. Client peers zou de mogelijkheid om bestanden naar een cache peer te uploaden geboden kunnen worden.

Buiten het testnetwerk zou er ook rekening gehouden moeten worden met het feit dat cache peers geen oneindig grote opslagcapaciteit hebben. Hiervoor zou een limiet kunnen ingesteld worden van hoeveel bestand (of hoeveel bytes) een cache kan bevatten. Indien de cache peer dan beslist om een nieuw bestand te cachen zal hij eerst moeten controleren of hij er wel plaats voor heeft.

Als laatste uitbreiding zou het mogelijk zijn om een grafische gebruikersinterface (GUI) te bouwen bovenop de applicatie. Indien de applicatie ook daadwerkelijk gebruikt zou worden is dit zeker noodzakelijk voor de client. Voor de cache peers is het niet strikt noodzakelijk, maar het zou wel makkelijk zijn indien cache peers nieuwe bestanden in het netwerk kunnen introduceren. Ook een grafische voorstelling van het voorbijgaande verkeer zou nuttig kunnen zijn.

62

Referenties [1] http://www.peer-to-peerwg.org/whatis/index.html (what is peer-to-peer)

[2] Peter Backx, Tim Wauters, Bart Dhoedt, Piet Demeester, "A comparison of peer-topeer architectures", Eurescom Summit 2002, Heidelberg, Germany

[3] Clay Shirky, What is P2P? … And what isn’t?, The O'Reilly Network, November 24, 2000, http://www.openp2p.com/pub/a/p2p/2000/11/24/shirky1whatisp2p.html

[4] http://www.intel.com/cure/index.htm

[5] http://setiathome.ssl.berkeley.edu/

[6] Brendon Wilson, JXTA, 1st edition, New Riders Publishing, 2002

[7] http://www.mirabilis.com

[8] http://www.jxta.org

[9] http://www.w3.org/XML/

[10] http://www.bluetooth.com

[11] http://cms.jxta.org 63

[12] Sing Li, Early Adopter JXTA: Peer-to-Peer Computing with Java, 1st edition, Wrox Press Inc, December 2001

[13] Joseph D. Gradecki, Mastering JXTA: Building Java Peer-to-Peer Applications, 1st edition, John Wiley & Sons, Augustus 2002

[14] Daniel Brookshier, Darren Govoni, Navaneeth Krishnan, Juan Carlos Soto, JXTA: Java P2P Programming, 1st edition, Sams, Maart 2002

[15] Scott Oaks, Bernard Traversat, Li Gong, JXTA in a Nutshell, O’Reilly & Associates, September 2002

[16] Robert Flenner, Michael Abbott, Toufic Boubez, Frank Cohen, Navaneeth Krishnan, Alan Moffet, Rajam Ramamurti, Bilal Siddiqui, Frank Sommers, Java P2P Unleashed: With JXTA, Web Services, XML, Jini, JavaSpaces, and J2EE, 1st edition, Sams, September 2002

[17] JXTA Protocols Specification, Sun Microsystems Inc., http://spec.jxta.org/nonav/v1.0/docbook/JXTAProtocols.html

[18] Li Gong, Project JXTA: A Technology Overview, Sun Microsystems, October 2002

[19] Tim Wauters, Jan Coppens, Bart Dhoedt, Piet Demeester, Distributed Replica Placement Algorithms for Peer-to-Peer Content Distribution Networks, Multimedia Telecommunications Track of EuroMicro 2003, Antalya, Turkey, September 2003

[20] Tim Wauters, Peter Backx, Jan Coppens, Bart Dhoedt, Piet Demeester, P2P Architectures for Content Delivery, interne publicatie vakgroep Intec

64

[21] Daniel Brookshier, Making Money With JXTA P2P, Sams, April 2002, http://www.informit.com/content/index.asp?product_id={5F3F076C-BEF7-445CBA10-0C544003E627}&session_id={60F3D744-9543-4C52-954E-A00F4BD22C9D}

[22] http://www.gnutella.com/

65

Appendix A: Protocolboodschappen in XML A.1 Bevel tot cachen



<Message version="0"> <Element name="jxta:SourceAddress" mime_type="text/plain"> tcp://123.456.205.212 <Element name="service" mime_type="text/plain"> CacheService <Element name="order" mime_type="text/plain"> cache <Element name="subject" mime_type="text/plain"> md5:226a264092109419423acbc99a71336a <Element name="target" mime_type="text/plain"> Server30

66

A.2 Bevel tot uncachen





<Message version="0"> <Element name="jxta:SourceAddress" mime_type="text/plain"> tcp://123.456.205.212 <Element name="service" mime_type="text/plain"> CacheService <Element name="order" mime_type="text/plain"> uncache <Element name="subject" mime_type="text/plain"> md5:226a264092109419423acbc99a71336a <Element name="target" mime_type="text/plain"> Server30

67

A.3 Bevestiging van cache-operatie





<Message version="0"> <Element name="jxta:SourceAddress" mime_type="text/plain"> tcp://123.456.205.212 <Element name="service" mime_type="text/plain"> CacheService <Element name="order" mime_type="text/plain"> cached <Element name="subject" mime_type="text/plain"> md5:226a264092109419423acbc99a71336a <Element name="name" mime_type="text/plain"> index.html <Element name="target" mime_type="text/plain"> Server30

68

A.4 Bevestiging van een uncache-operatie





<Message version="0"> <Element name="jxta:SourceAddress" mime_type="text/plain"> tcp://123.456.205.212 <Element name="service" mime_type="text/plain"> CacheService <Element name="order" mime_type="text/plain"> uncached <Element name="subject" mime_type="text/plain"> md5:226a264092109419423acbc99a71336a <Element name="name" mime_type="text/plain"> index.html <Element name="target" mime_type="text/plain"> Server30

69

A.5 Melding van nieuwe cache peer op het netwerk





<Message version="0"> <Element name="jxta:SourceAddress" mime_type="text/plain"> tcp://123.456.205.212 <Element name="service" mime_type="text/plain"> CacheService <Element name="order" mime_type="text/plain"> join <Element name="target" mime_type="text/plain"> Server30

70

A.6 Melding van een afsluitende cache peer





<Message version="0"> <Element name="jxta:SourceAddress" mime_type="text/plain"> tcp://123.456.205.212 <Element name="service" mime_type="text/plain"> CacheService <Element name="order" mime_type="text/plain"> exit <Element name="target" mime_type="text/plain"> Server30

71

A.7 Melding van een download





<Message version="0"> <Element name="jxta:SourceAddress" mime_type="text/plain"> tcp://123.456.205.212 <Element name="service" mime_type="text/plain"> CacheService <Element name="order" mime_type="text/plain"> download <Element name="target" mime_type="text/plain"> client31 <Element name="source" mime_type="text/plain"> server30 <Element name="subject" mime_type="text/plain"> md5: 226a264092109419423acbc99a71336a

72

Appendix B. Testresultaten B.1 α = 0,1

# downloads Client 134 : Client 32 : Client 33 : Client 34 : Totaal :

# hops 182 185 185 185 737

226 298 242 267 1033

# hops / download 1.241758242 1.610810811 1.308108108 1.443243243 1.401628223

Tabel B.1 downloadkost voor α = 0,1

# files begin Server 133 : Server 35 : Server 30 : Server 31 : Totaal :

# files einde 7 0 2 3 12

Gemiddelde 11 9 7 10 37

9 4.5 4.5 6.5 24.5

Tabel B.2 cachekost voor α = 0,1

B.2 α = 0,25

# downloads Client 134 : Client 32 : Client 33 : Client 34 : Totaal :

# hops 101 185 172 185 643

118 272 256 265 911

# hops / download 1.168316832 1.47027027 1.488372093 1.432432432 1.416796267

Tabel B.3 downloadkost voor α = 0,25

73

# files begin Server 133 : Server 35 : Server 30 : Server 31 : Totaal :

# files einde 7 0 2 3 12

Gemiddelde 10 7 7 8 32

8.5 3.5 4.5 5.5 22

Tabel B.4 cachekost voor α = 0,25

B.3 α = 0,5

# downloads Client 134 : Client 32 : Client 33 : Client 34 : Totaal :

# hops 172 181 185 179 717

# hops / download 216 1.255813953 272 1.502762431 292 1.578378378 254 1.418994413 1034 1.442119944

Tabel B.5 downloadkost voor α = 0,5 # files begin Server 133 : Server 35 : Server 30 : Server 31 : Totaal :

# files einde 7 0 2 3 12

Gemiddelde 9 7 6 5 27

8 3.5 4 4 19.5

Tabel B.6 cachekost voor α = 0,5

B.4 α = 0,75

# downloads Client 134 : Client 32 : Client 33 : Client 34 : Totaal :

# hops 184 185 185 185 739

# hops / download 227 1.233695652 287 1.551351351 265 1.432432432 281 1.518918919 1060 1.434370771

Tabel B.7 downloadkost voor α = 0,75

74

# files begin Server 133 : Server 35 : Server 30 : Server 31 : Totaal :

# files einde 7 0 2 3 12

Gemiddelde 10 6 6 6 28

8.5 3 4 4.5 20

Tabel B.8 cachekost voor α = 0,75

B.5 α = 1

# downloads Client 134 : Client 32 : Client 33 : Client 34 : Totaal :

# hops

# hops / download 244 1.333333333 274 1.481081081 292 1.578378378 311 1.681081081 1121 1.51897019

183 185 185 185 738

Tabel B.9 downloadkost voor α = 1 # files begin

# files einde

Server 133 : Server 35 : Server 30 : Server 31 : Totaal :

7 0 2 3 12

Gemiddelde 6 4 6 5 21

6.5 2 4 4 16.5

Tabel B.10 cachekost voor α = 1

B.6 α = 1,25

# downloads Client 134 : Client 32 : Client 33 : Client 34 : Totaal :

# hops 175 185 184 185 729

# hops / download 268 1.531428571 304 1.643243243 299 1.625 308 1.664864865 1179 1.617283951

Tabel B.11 downloadkost voor α = 1,25

75

# files begin Server 133 : Server 35 : Server 30 : Server 31 : Totaal :

# files einde 7 0 2 3 12

Gemiddelde 4 3 5 3 15

5.5 1.5 3.5 3 13.5

Tabel B.12 cachekost voor α = 1,25

B.7 α = 1,5

# downloads Client 134 : Client 32 : Client 33 : Client 34 : Totaal :

# hops 179 183 185 184 731

# hops / download 292 1.631284916 352 1.923497268 324 1.751351351 342 1.858695652 1310 1.792065663

Tabel B.13 downloadkost voor α = 1,5 # files begin Server 133 : Server 35 : Server 30 : Server 31 : Totaal :

# files einde 7 0 2 3 12

Gemiddelde 4 2 2 4 12

5.5 1 2 3.5 12

Tabel B.14 cachekost voor α = 1,5

B.8 α = 1,75

# downloads Client 134 : Client 32 : Client 33 : Client 34 : Totaal :

# hops 185 184 188 184 741

# hops / download 324 1.751351351 350 1.902173913 320 1.70212766 351 1.907608696 1345 1.81511471

Tabel B.15 downloadkost voor α = 1,75

76

# files begin Server 133 : Server 35 : Server 30 : Server 31 : Totaal :

# files einde 7 0 2 3 12

Gemiddelde 3 3 2 4 12

5 1.5 2 3.5 12

Tabel B.16 cachekost voor α = 1,75

B.9 α = 2

# downloads Client 134 : Client 32 : Client 33 : Client 34 : Totaal :

# hops 181 184 183 185 733

# hops / download 319 1.762430939 407 2.211956522 344 1.879781421 372 2.010810811 1442 1.967257844

Tabel B.17 downloadkost voor α = 2 # files begin Server 133 : Server 35 : Server 30 : Server 31 : Totaal :

# files einde 7 0 2 3 12

Gemiddelde 5 1 4 2 12

Tabel B.18 cachekost voor α = 2

77

6 0.5 3 2.5 12