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

Transcriptie

1 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

2

3 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

4 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

5 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

6 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 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

7 Inhoudsopgave 1. INLEIDING PEER-TO-PEER CONCEPTEN WAT IS PEER-TO-PEER WAAROM PEER-TO-PEER? P2P ARCHITECTUUR Centrale server Puur Hybride VOORBEELDAPPLICATIES Instant messaging File-sharing Distributed computing JXTA INLEIDING CONCEPTEN Peer Peergroup Service Endpoint Pipe Message Advertisement Protocol PROTOCOLS Endpoint Routing Protocol Peer Resolver Protocol Peer Discovery Protocol Pipe Binding Protocol Peer Information Protocol Peer Membership Protocol HET DRIELAGENMODEL CMS SERVICE CACHING ALGORITMES EERSTE BENCHMARK: NIET CACHEN...24

8 4.2 TWEEDE BENCHMARK: PUUR CACHEN CACHE HEURISTIEK DE IMPLEMENTATIE INLEIDING CACHE PEER Oorspronkelijk Protocol Implementatie CLIENT PEER PERFORMANTIETESTS HET TESTNETWERK PROBLEMEN EERSTE BENCHMARK: NIET CACHEN TWEEDE BENCHMARK: PUUR CACHEN CACHE ALGORITME VERGELIJKING CONCLUSIES WAT HEBBEN WE BEREIKT? ERVARINGEN MET DE JXTA OMGEVING 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, B.2 Α = 0, B.3 Α = 0, B.4 Α = 0, B.5 Α = B.6 Α = 1, B.7 Α = 1, B.8 Α = 1, B.9 Α =

9 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

10 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, , IRC, ). 2

11 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

12 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

13 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 ), 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 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

14 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] 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

15 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 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

16 Data Controle Figuur 2.4 Pure P2P architectuur 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

17 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 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 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

18 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

19 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 [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. 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

20 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

21 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

22 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 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

23 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] 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

24 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 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 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

25 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 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. <!DOCTYPE jxta:pipeadvertisement> <jxta:pipeadvertisement xmlns:jxta=" <Id> urn:jxta:uuid- 4D E E6F202021FA910EE3C94D23841C895826E2A 48C04 </Id> <Type> JxtaPropagate </Type> <Name> Cache Pipe </Name> </jxta:pipeadvertisement> Figuur 3.1 Een pipe advertisement 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

26 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 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 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

27 Figuur 3.2 JXTA Protocolstack 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

28 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 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 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 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

29 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 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 De waarde voor A0 is hier 5, dus het eerste moment waarop de lijnen boven 5 gaan zal de cache het bestand ook downloaden. 8 Alfa = As Tijd 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

39 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

40 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 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