gone the winamp filesharing plugin - cs.ru.nlmarko/onderwijs/oss/gone.pdf · gone the winamp...

GOne

The WinAmp Filesharing Plugin Tom Evers (0115525) Chris Jager (0118060) Sjors Meekels (0138630) Tom de Valk (0115665) juni 2004

GOne Project documentatie 1

Inhoudsopgave Inleiding ................................................................................................................................3 Hoofdstuk 1: De casestudy ...................................................................................................4 Hoofdstuk 2: Algemene literatuurstudie over gebruik van middlewaretechnieken ..........5

2.1 Webservices .................................................................................................................5 2.1.1 Stateful / Stateless ...........................................................................................5 2.1.2 Webservices vs. webapplicaties.......................................................................6

2.2 .NET Remoting ............................................................................................................7 2.2.1 Introductie.......................................................................................................7 2.2.2 Architectuur ....................................................................................................7 2.2.3 Channels / Formatters......................................................................................8 2.2.4 References vs. Copies .....................................................................................9 2.2.5 Object Activation Lifetimes ............................................................................9

2.3 CLS en .NET..............................................................................................................10 2.3.1 CLS-Compliant Code....................................................................................10

2.4 Windows Messaging...................................................................................................11 Hoofdstuk 3: Gebruikte middlewaretechnieken en gemaakte keuzes in GOne...............12

3.1 Java Webservice, JaxRPC en SOAP ...........................................................................12 3.1.1 EJB 2.1 .........................................................................................................12 3.1.2 Jax-RPC........................................................................................................12 3.1.3 Datatypen in SOAP .......................................................................................14

3.2 .NET Remoting ..........................................................................................................16 3.3 Koppeling C++, C++ .NET & C# ...............................................................................18

3.3.1 Verschillen C++ en C++ .NET......................................................................18 3.3.2 Aanroepen C# methoden in C++ ...................................................................18 3.3.3 Managed en Unmanaged ...............................................................................18

3.4 Windows Messaging in Winamp ................................................................................20 Hoofdstuk 4: Evaluatie van de gebruikte middleware in GOne.......................................21

4.1 Java webservices ........................................................................................................21 4.1.1 Server ontwikkeling ......................................................................................21 4.1.2 Server Implementatie ....................................................................................22 4.1.3 Ant / asant .....................................................................................................22 4.1.3 Deploytool ....................................................................................................23 4.1.5 Koppeling C#................................................................................................23

4.2 .NET Remoting ..........................................................................................................25 4.2.1 Gebruikersgemak ..........................................................................................25 4.2.2 Aanpasbaarheid.............................................................................................25 4.2.3 Toepasbaarheid .............................................................................................25 4.2.4 Snelheid ........................................................................................................26

4.3 CLS en .NET..............................................................................................................27 4.3.1 Globale statische klasse.................................................................................27

4.4 GUI plugin .................................................................................................................28 Hoofdstuk 5: Conclusies.....................................................................................................29

5.1 Gebruikersgemak en Tools .........................................................................................29 5.2 Documentatie .............................................................................................................30 5.3 Snelheid en interoperabiliteit ......................................................................................30 5.4 Algemene conclusie....................................................................................................31


BIJLAGEN.........................................................................................................................32 1. Werkverdeling ..............................................................................................................32 2. Filesharing-systemen ....................................................................................................34 3. WSDL file extract.........................................................................................................36 4. Nullsoft’s Winamp .......................................................................................................37 5. SOAP Messages ...........................................................................................................38 6. Meetresultaten ..............................................................................................................41 7. Grafiek en tabellen bij meetresultaten...........................................................................42

7.1 Overdrachtsnelheid van Binary Tcp ..................................................................42 7.2 Overdrachtsnelheid verschillende configuraties.................................................42 7.3 Netwerk belasting verschillende configuraties...................................................42

8. Bronvermelding............................................................................................................43


Inleiding Het centrale onderwerp van dit werkstuk (en de bijbehorende practicumopdracht) draait om file-sharing door middel van het uitwisselen van bestanden over het internet. In het praktische gedeelte ontwerpen en implementeren wij een sharingsysteem voor muziekbestanden (mp3-, wma- en wav-bestanden). Dit in navolging van bekende systemen als Napster en KaZaa. De algemene opzet hierbij is dat gebruikers via een “Peer to Peer”-connectie een bestand kunnen downloaden. “Peer to Peer” betekent in feite een directe verbinding tussen twee (of meerdere) gebruikers om een bestand uit te wisselen. Er is veel gebeurd de laatste jaren op het gebied van filesharing en het onderwerp heeft veel publiciteit gekregen, met name over allerlei juridische vraagstukken. Aan het juridische aspect zullen we verder geen aandacht schenken. Onze aandacht is gericht op de technieken die hiervoor gebruikt kunnen worden. We hebben het hier over de techniek in de breedste zin van het woord, wat inhoudt dat we kijken naar verschillende architecturen, protocollen, gebruikte programmeertalen, tools en alle andere onderdelen. Onze onderzoeksdoelstelling voor dit werkstuk is dan ook dat we proberen door middel van een literatuurstudie en een casestudy kennis op te doen over verschillende middlewaretechnieken en de relaties tot elkaar. Deze doelstelling proberen we dus te behalen door het zelf ontwerpen en implementeren van een klein filesharing-systeem. Vervolgens hadden we nog een goede grafische gebruikersinterface nodig voor het filesharing-systeem, want zonder een goede en mooie GUI wordt de drempel te groot om van het programma gebruik te maken. We hebben toen gekozen voor Winamp, gezien deze muziekspeler freeware is en goede mogelijkheden biedt voor het schrijven van een plugin middels een gedocumenteerde interface file. Als een gebruiker zich heeft aangemeld bij de server, zal deze persoon de nummers in de playlist van Winamp delen met andere aangemelde gebruikers. In een plugin van Winamp worden deze gedeelde nummers getoond en is het mogelijk nummers te downloaden (het globale beeld van het systeem is terug te zien in Hoofdstuk 1). Ons programma had natuurlijk ook een naam nodig en onze keuze is op GOne gevallen. In dit document zal vanaf nu GOne dus refereren naar ons filesharing-systeem. In het eerste hoofdstuk wordt de casestudy beschreven en wordt GOne onderverdeeld in vier belangrijke stukken. In hoofdstuk twee worden de algemene theorieën en technieken van de vier onderdelen besproken, een literatuurstudie dus. Vervolgens gaan we in hoofdstuk drie in op de concrete middlewaretechnieken die we hebben gebruikt en hoe de implementatie daarvan is verwerkt in GOne. Natuurlijk hoort hier ook een verantwoording voor de gemaakte keuzes bij. In hoofdstuk vier komen er evaluaties over de gebruikte middlewaretechnieken in GOne, welke dingen gemakkelijk zijn verlopen en waar juist veel problemen zaten. Bovendien wordt hierin beschreven of de gemaakte keuzes wel zo goed waren achteraf gezien.


Hoofdstuk 1: De casestudy GOne is onder te verdelen in vier belangrijke stukken:

1. De server die een webservice bevat en de communicatie tussen deze service en een

client doormiddel van SOAP. 2. Het uitwisselen van muziekbestanden tussen twee clients. Dit gebeurt met behulp van

.NET Remoting. 3. Koppelen/bundelen van de clientcode om met de server te communiceren en de

Winamp plugin. De onderliggende techniek die hierbij gebruikt wordt, is de Common Language Specification (CLS).

4. De communicatie tussen Winamp en de Winamp plugin, wat gebeurt door middel van Windows Messaging.

Figuur 1 – Globale opzet van GOne.

Deze onderverdeling zal in de rest van dit document steeds centraal blijven staan. De manier waarop GOne gaat werken, is wanneer een gebruiker onze Winamp plugin opstart, deze persoon zich gelijk aanmeldt bij de server en zijn playlist deelt met alle andere gebruikers die zich aangemeld hebben bij die server. Vervolgens krijgt de gebruiker de playlist van de server terug, waar alle nummers van de andere gebruikers instaan. Via de Winamp plugin is het mogelijk een nummer te selecteren en te downloaden. Voor deze overdracht van het muziekbestand wordt dan een directe verbinding gemaakt met de andere gebruiker. Met behulp van GOne wordt het dus mogelijk online muziekbestanden met elkaar uit te wisselen.


Hoofdstuk 2: Algemene literatuurstudie over gebruik van middlewaretechnieken

2.1 Webservices Aan de server kant van onze applicatie hebben we gekozen voor het gebruik van webservices. Hierdoor kunnen de clients procedures aanroepen die aanwezig zijn op de server. Het klassieke voorbeeld van een webservice is zichtbaar in Figuur 1.

Figuur 2.1

Onze opzet wijkt iets af van dit klassieke beeld. Het gedeelte boven de rode lijn wordt (nog) niet gemaakt in onze applicatie. Het is niet zo dat onze webservice dingen met behulp van websites (html pagina’s) aanbiedt aan de gebruikers, zodat deze hun eigen client code kunnen schrijven. De client code is al geschreven voor de gebruikers en de gebruikers zullen dus niks meekrijgen van de webservices als zodanig (dit gebeurt ‘onder water’). Een van de redenen dat we gekozen hebben voor de webservices aan de server kant is dat het een goed voorbeeld is van middleware. De afwegingen omtrend de gekozen architectuur (centraal, decentraal of hybride) zijn beschreven in Bijlage 2. Bovendien staat het hele webservice gebeuren nog in zijn kinderschoenen en dat maakt het leuk om zo met de nieuwste ideeën en technologieën te experimenteren.

2.1.1 Stateful / Stateless Een webservice kan een stateful of stateless zijn. Aan beide kanten zijn er voor- en nadelen aan verbonden. Bijkomende problemen zijn bijvoorbeeld of er bij een invocatie van een procedure telkens een nieuwe instantie van het server object aangemaakt moet worden (stateless) of dat iedereen een kopie krijgt van het huidige en enige object (stateful). Er zijn deskundigen die stellen dat een ‘zuivere’ webservice geen state kan bewaren, tegenstanders stellen dat een stateless webservice veel van zijn nut verliest of erg veel resources nodig heeft om goed te kunnen functioneren.


2.1.2 Webservices vs. webapplicaties Een webapplicatie is een applicatie die het HTTP protocol gebruikt voor de communicatie tussen client en server. Gebruikers zien een HTML pagina en kunnen door middel van invoer met de applicatie communiceren. Het nadeel van deze applicaties is dat alles via HTML verloopt, eventuele antwoorden van een applicatie aan een gebruiker zitten altijd in een HTML pagina verstopt. Voordeel van webapplicaties is dat deze overal en voor iedereen met een internetverbinding toegankelijk zijn. Een webservice wordt ook via het internet aangesproken maar de communicatie verloopt allemaal via SOAP en XML. Hierdoor verloopt de communicatie gemakkelijker dan bij een webapplicatie, want er is geen HTML schil nodig om informatie naar een gebruiker te sturen.


2.2 .NET Remoting

2.2.1 Introductie .NET Remoting kan worden beschouwd als de opvolger van Distributed Component Object Model (DCOM). DCOM is een protocol dat de mogelijkheid biedt voor componenten om over een netwerk met elkaar te communiceren. .NET Remoting is naast webservices en DCOM één van de middleware technologieën die te vinden is in het .NET framework. .NET Remoting is een abstracte manier van communicatie tussen verschillende processen, waarbij de communicatieprotocollen, de levensduur van een object, de methode van objectcreatie en het serialisatieformaat instelbaar is. De meeste van deze zaken worden standaard al goed geregeld, maar kunnen naar wens worden aangepast. .NET Remoting kan volgens Microsoft het beste worden gebruikt bij applicaties waarbij performance belangrijk is en waarbij portabiliteit ondergeschikt is. Doordat .NET ook beschikbaar is of beschikbaar wordt gemaakt voor andere platformen zoals Linux, Unix en Macintosh zal de portabiliteit in de toekomst gunstiger worden. Een nadeel is wel dat het .NET Framework op de computer waar de applicatie op draait aanwezig dient te zijn.

2.2.2 Architectuur .NET Remoting kan worden gezien als een standaard Client – Server architectuur. Het idee is dat er verwijzingen naar objecten doorgegeven kunnen worden tussen deze processen. In .NET wordt dit op de volgende wijze verwezenlijkt: De client maakt een nieuwe instantie van het remote-object aan. In zijn proces wordt een proxy-object aangemaakt, oftewel een object dat zich voordoet als het object op de server. Als de client nu een aanroep doet op het proxy object, dan wordt deze aanroep doorgegeven aan de server. Deze behandelt de aanroep en geeft het resultaat terug aan het proxy object. Deze geeft het resultaat dan terug aan de aanroeper. Schematisch wordt dat weergegeven in de figuur hieronder.

De communicatie tussen client en server is in de praktijk natuurlijk ingewikkelder dan hierboven beschreven en zal in de komende paragrafen verder worden uitgediept. Eerst zullen we kijken naar welke netwerkprotocollen er gebruikt kunnen worden (Channels) en naar hoe de te versturen data wordt verpakt (Formatters). Vervolgens zullen we kijken naar het meegeven van objecten by-reference of by-value.


Het probleem van wie de levensduur van een object beheert, de server of de client, zullen we daarna bekijken. Na afloop van dit hoofdstuk hebben we voldoende aspecten van .Net Remoting behandelt om een idee te krijgen van de structuur van .Net Remoting en de keuzes die er bij komen kijken.

2.2.3 Channels / Formatters De informatie die verzonden moet worden voor de connectie tussen de client-zijde en de server-zijde moet eerst worden gecodeerd naar een formaat dat verzonden kan worden over een netwerkverbinding. Dit gebeurt door de Formatter. Hierbij kun je standaard kiezen uit de SOAP-Formatter en de Binary-Formatter. Het voordeel van SOAP is dat het ook door ander type applicaties kan worden aangeroepen, doordat SOAP een open standaard is. Binary heeft als voordeel dat het wat sneller is en dat er geen informatie verloren gaat, omdat het niet naar de SOAP standaard hoeft te worden geconverteerd. Hiervoor moeten de objecten die worden geconverteerd wel serialiseerbaar zijn. Vervolgens moet de geconverteerde data nog over het netwerk worden gestuurd. Ook daarvoor zijn verschillende protocollen beschikbaar. Standaard kun je kiezen uit HTTP of TCP. Het voordeel van HTTP is dat het bijvoorbeeld de beveiliging kan worden overgelaten aan de IIS server. Het nadeel is echter dat het iets minder snel is dan TCP. De combinatie van Formatter en Channel wordt Sink genoemd.


2.2.4 References vs. Copies Net als bij andere argumenten kun je ook bij remote objects aangeven of ze “by reference” of “by value” moeten worden gehanteerd. Deze objecten moeten overerven van de klassen MarshalByRefObject of MarshalByValueObject. De keuze tussen deze twee principes is afhankelijk van de situatie (grootte, type en functionaliteit van het object).

2.2.5 Object Activation Lifetimes Wanneer er gebruik wordt gemaakt van MarshalByRefObjects dan komt de vraag wie de levensloop van het object beheerd. Ook hier zijn weer enkele mogelijkheden instelbaar. Er kan gekozen worden voor “client-side activation”. Hierbij activeert iedere client zijn eigen object waarvan hij de state bepaalt. De levensduur is complex, doordat de objecten wel een keer van de server afmoeten als er iets fout gaat. Een andere mogelijkheid is “server-side activation”. Hierin kun je kiezen uit SingleCall of Singleton. Bij beide activeert de Server het object en beheert het. Doordat er bij elke call in het geval van SingleCall een nieuw object wordt aangemaakt, is er sprake van een stateless model. De levensduur is hierbij geen probleem. Bij Singleton wordt er één object op de server gemaakt voor alle clients. Hierdoor wordt de state gedeeld door de verschillende clients. Hierbij komt het probleem van de levensduur van dit ene object ook weer kijken.


2.3 CLS en .NET Om in .NET een applicatie te bouwen, die is opgebouwd uit verschillende talen, moeten er afspraken worden gemaakt. Een compiler voor C++ kan bijvoorbeeld niet een functie lezen die in Visual Basic is geschreven. En in dat geval kan het programma niet gecompileerd worden, laat staan tot één geheel. Daarvoor is de Common Language Specification (CLS) gedefinieerd. In CLS worden een groot aantal zaken beschreven over eigenschappen die talen met elkaar gemeen hebben en die door veel applicaties gebruikt worden (door MSDN CLS features genoemd). Doordat alle talen die voor .NET zijn geschreven allen voldoen aan CLS, weten de compilers van de verschillende talen op welke manier ze code uit een andere taal moeten aanroepen en welke stukken code uit een programmafragment voor een specifieke compiler niet interessant zijn. Zolang de geschreven code alleen gebruik maakt van CLS features, treden er geen problemen op wat betreft het uitwisselen van functies in verschillende talen. Deze stukken code worden CLS-compliant components genoemd. De meeste klassen uit de .NET framework class library (alle voorgedefinieerde functies) zijn CLS-compliant. Een verkorte lijst van alle features die in CLS zijn opgenomen, zijn terug te vinden bij referentie 4.

2.3.1 CLS-Compliant Code Er zijn nogal wat features in CLS opgenomen. Alle talen in het .NET framework moeten hieraan voldoen. Het is begrijpelijk dat de lezer gaat denken dat de talen uiteindelijk steeds meer op elkaar gaan lijken. Er zijn echter maar een paar punten waarop gelet dient te worden tijdens het programmeren, om CLS-compliant code te produceren:

1. de definities van de publieke klassen (public) dienen CLS-compliant te zijn; 2. de definities van de publieke methoden uit publieke klassen dienen CLS-compliant te

zijn; 3. de definities van de methoden uit afgeleide klassen (derived classes) die toegankelijk

zijn vanuit publieke klassen dienen CLS-compliant te zijn; 4. de parameters en andere return-values uit publieke methoden van publieke klassen

dienen CLS-compliant te zijn; 5. de parameters en andere return-values uit methoden uit afgeleide klassen die

toegankelijk zijn voor publieke methoden van publieke klassen dienen CLS-compliant te zijn.

Alle andere stukken code (denk aan private klassen (private classes), private methoden (private methods) uit publieke klassen en lokaal gedefinieerde variabelen) hoeven niet CLS-compliant te zijn, want deze kunnen toch niet aangeroepen worden door andere klassen. Het is ook mogelijk om niet CLS-compliant code te schrijven in het .NET framework. Dit kan handig zijn als je bijvoorbeeld bestaande C++ code wilt gebruiken in het .NET framework. Dit is realiseerbaar door een false waarde aan CLSCompliantAttribute te geven, een variabele die aangeeft welke delen wel en niet CLS-compliant zijn.


2.4 Windows Messaging Met behulp van Windows Messaging is het mogelijk om een proces te laten reageren op events van gebruikers of andere processen. Als een gebruiker bijvoorbeeld op een knop drukt, wordt er een bericht gestuurd door Windows naar een algemene Message Queue. Deze queue wordt door de functie Run (uit de klasse CWinApp) uitgelezen en de berichten worden doorgestuurd naar het juiste window, waar het event weer wordt afgehandeld door een event-handler.

Als de Message Queue geen messages bevat, dan wordt de methode OnIdle() uitgevoerd, welke idle-time processing uitvoert. De messages zijn onder te verdelen in drie categorieën: 1. Windows messages 2. Control notifications 3. Command messages Windows messages en control notifications worden vooral gebruikt bij het opbouwen van een window en alles wat daarmee te maken heeft. Command messages worden verzonden door user interface objecten, zoals knoppen en menu-item’s.


Hoofdstuk 3: Gebruikte middlewaretechnieken en gemaakte keuzes in GOne

3.1 Java Webservice, JaxRPC en SOAP

Het idee van webservices is ontstaan bij Microsoft en is een onderdeel van het .NET framework. Wij hebben echter gekozen om webservices met behulp van Java te implementeren. Hierdoor zou het mogelijk moeten zijn de server op verschillende Operating Systems te laten draaien. Bovendien is het leuker verschillende talen met elkaar te laten communiceren via webservices in dit geval. Waarschijnlijk zal het implementeren van webservices met behulp van Visual Studio .NET 2003 en C# een stuk makkelijker verlopen dan met behulp van Java. We zijn ook op zoek gegaan naar een webservicetool die met Java overweg kan.

3.1.1 EJB 2.1 Webservices onder Java werken met Enterprise JavaBeans 2.1 (EJB 2.1). Deze technologie is een serverside component architectuur voor de Java 2 Enterprise Edition (J2EE) platform voor het snel en gemakkelijk maken van een applicatie geschreven in Java. De Java API voor XML-Remote Procedure Calls (Jax-RPC) en de Java API voor XML-Messaging (JaxM) zijn twee API’s voor het maken van webservices die zijn meegeleverd in EJB 2.1. Met deze nieuwe versie van EJB is het mogelijk vanaf verschillende platformen en/of talen een methode van een webservice aan te roepen. Omdat Jax-RPC de meest gebruikte API op dit moment is en de verwachting is dat JaxM in de toekomst zal verdwijnen, hebben wij gebruik gemaakt van Jax-RPC bij de implementatie.

3.1.2 Jax-RPC Jax-RPC is een van de drie Java API’s die geschikt zijn om RPC’s te maken, de andere twee zijn Java IDL en RMI. Alle drie hebben een API voor marshalling en unmarshalling en voor het verzenden van RPC’s. Het grote verschil is dat Jax-RPC op SOAP gebaseerd is en


speciaal voor webservices is gemaakt en de andere API’s niet (Java IDL is bijvoorbeeld op CORBA gebaseerd). Het tussenliggende protocol (SOAP) bepaalt ook de platformen taalonafhankelijkheid. Jax-RPC kan zowel ondersteuning bieden voor het maken van de clientcode om een webservice aan te roepen (zie figuur 3.1.1) als ondersteuning bieden voor het maken van de webservice zelf (zie figuur 3.1.2). De endpoint interface is eenvoudig te implementeren, namelijk met behulp van de javax.rmi.Remote interface. Clientside:

Figuur 3.1.1

Er zijn drie manieren om een service op het endpoint aan te roepen vanaf de client, allen afhankelijk van de gekozen client-server implementatie. 1) Stub-based model (static stubs). Hierbij wordt op basis van een WSDL file of op basis van de service endpoint interface (zie figuur 3.1.2) een stub class gegenereerd. Hieraan moet daarna wel de business logic (de eigenlijke code) worden toegevoegd. Het genereren op basis van de WSDL file is platform onafhankelijk, op basis van de service endpoint interface is java afhankelijk. Deze methoden leveren een statische client op, welke niet dynamisch is uit te breiden met nieuwe invocaties op de webservice. Voor uitbreidingen zal er dus opnieuw gecompileerd moeten worden aan de clientside. 2) Dynamic proxies In tegenstelling tot de eerste methode wordt hier tijdens runtime de invocaties toegevoegd aan de client. Dit gebeurt met behulp van de javax.xml.rpc.Service interface en het zal duidelijk zijn dat dit alleen mogelijk is voor java implementaties. De service endpoint interface moet wel voor de client applicatie beschikbaar zijn. 3) DII (dynamic invocation interface) Hierbij is het niet nodig dat de client van te voren weet welke service er aangeroepen gaat worden. Een DII client kan deze services benaderen via een zogenaamde Broker.


Mogelijkheden zijn webdirectories waarin webservices hun services publiceren, in WSDL files. Voorbeelden hiervan zijn UDDI, ebXML registries. (zie ook figuur 2.1) Het meest stabiele is om statische stubs te gebruiken om webservices te implementeren. Er wordt dan niet runtime bekeken welke services er aangeboden worden en de webservices zijn dan ook niet afhankelijk van andere servers (UDDI) en Brokers. Bovendien wordt de webservice van GOne ook niet vaak aangepast en is het eenvoudiger om alle client code nogmaals te compileren dan de service dynamisch beschikbaar te maken. Het dynamisch aanbieden van de WSDL file is ook niet nodig, omdat waarschijnlijk niemand hier in geïnteresseerd is. Vandaar dat we dus voor een statische stub hebben gekozen bij GOne. Serverside:

Figuur 3.1.2

Er zijn twee java codefiles nodig om een webservice te implementeren. Een interface file en een daadwerkelijke code file. De interface file (Endpoint Interface) kan zoals hiervoor beschreven gebruikt worden om de clientstub te genereren. Omdat SOAP gebruikt wordt als communicatie protocol is het platform onafhankelijk en kunnen applicaties geschreven in welke taal / platform ook de webservice aanroepen, mits de SOAPcall voldoet aan de juiste specificatie.

3.1.3 Datatypen in SOAP Om webservices aan te roepen over HTTP is een speciaal protocol ontworpen, het eerder genoemde SOAP (Simple Object Access Protocol). SOAP is een XML-taal waarmee aanroepparameters naar de webservice toegestuurd en antwoorden teruggestuurd worden. SOAP is simpelweg een standaard voor het activeren van webservices over het Internet.


Omdat het Jax-RPC op SOAP is gebaseerd, worden niet alle bekende Java datatypen ondersteund. In tabel 3.1.3 worden de typen getoond welke op dit moment ondersteund worden. Samengestelde typen zijn vanzelfsprekend ook toegestaan. Tabel 3.1.3 String Boolean Byte Double Float Integer Long Short BigDecimal BigInteger Calender Date simple types als boolean, byte, double, float, int en long Het is wel mogelijk om zelfgemaakte types toe te voegen en te gebruiken. Het is dan echter wel noodzakelijk zelf de marshalling en unmarshalling code schrijven. Als mede te zorgen voor de serializing, voor zowel de client- en server-side. Indien de server- en clientside implementatie in Java geschieden, is het gebruik van complexere Java datatypen wel mogelijk (dit is overigens wel in strijd met het standaard SOAP protocol).


3.2 .NET Remoting

In Hoofdstuk 2 is een globaal beeld geschetst van .NET Remoting. Er gebeuren nog veel meer interessante zaken in .NET Remoting, maar het voert te ver om dat in verder detail te beschrijven. We hebben nu genoeg informatie om de gemaakte keuzes bij GOne toe te lichten. Bij GOne wordt er gebruik gemaakt van .NET Remoting bij het directe contact tussen de clients onderling. Het doel hiervan is voornamelijk het transporteren van een file van de ene client naar de andere. Snelheid is hierbij natuurlijk het belangrijkste kwaliteitsattribuut. We hebben eerst zelf een remotable object gedefinieerd, dat overerft van MarshalByRefObject. Hiervoor is gekozen omdat het object toegang moet hebben tot het filesystem van de Server. Het object bevat een functie die een Filestream teruggeeft aan de Client (een Filestream is standaard remotable in .NET). Vervolgens kan de client deze Filestream gewoon uitlezen. Bij het uitlezen is het aantal bytes dat je per “read” aanroep leest van belang voor de performance van het systeem. Wanneer dit aantal te klein is, dan is de overhead per aanroep in verhouding te groot ten opzichte van de data. De file in één keer binnenhalen kan wel, maar dan kan er moeilijker status informatie worden gegeven aan de gebruiker. Ook het splitsen van de download en het geval van een afgebroken download hervatten zijn dan problematischer. Verder hebben we gekozen voor server-side activation en dan de Singleton variant. Dit omdat het niet noodzakelijk is om voor iedere client een eigen object te bewaren. Aangezien het object voor iedere client identiek is. Op deze manier bespaar je dus geheugenruimte op de Server, doordat er altijd maar één object actief is. Om levensduurproblemen te voorkomen, blijft dit object altijd bestaan. Dit is geen probleem, omdat er toch maar één object is. Omdat snelheid belangrijk is hebben we ervoor gekozen om de Binary – Formatter te gebruiken in combinatie met TCP. Dit is de snelste methode volgens de literatuur en dat hebben we zelf geverifieerd.


Alle .NET Remoting instellingen doen we in de code en niet via een configuratie file. Dit heeft als nadeel dat we de instellingen niet allemaal kunnen veranderen zonder op nieuw te compileren. Het heeft echter als voordeel dat alles dynamisch instelbaar is. Dit is nodig, doordat je dynamisch een server kiest om de file vanaf te downloaden. De aanroepen op het remote object worden voorlopig allemaal synchroon gedaan, dat houdt in dat de aanroeper zijn eigen proces blokt totdat hij respons krijgt van de Server. Dit kan eventueel een probleem gaan vormen met betrekking tot de performance. In dat geval moet de implementatie worden gewijzigd in een asynchroon systeem. Momenteel gebeurt alleen het downloaden van een file met behulp van threads. Dit omdat er op die manier meerdere downloads tegelijkertijd kunnen plaatsvinden en het hoofdprogramma niet blokkeert.


3.3 Koppeling C++, C++ .NET & C#

3.3.1 Verschillen C++ en C++ .NET De opzet van .NET is om verschillende programmeertalen met elkaar te kunnen laten praten. Vanzelfsprekend is dan natuurlijk dat een taal in .NET hetzelfde werkt als een diezelfde taal buiten het .NET framework. Maar omdat de taal in het .NET framework wel CLS compliant (zie hoofdstuk 2.3) dient te zijn, moeten een aantal zaken toch anders worden opgelost. Omdat we met WinAmp werken, zijn we min of meer gedwongen C++ te gebruiken voor het bouwen van de plugin. De .NET Remoting code is in C# geschreven en daardoor zullen we de C++-code van de plugin om moeten zetten naar C++ .NET code, willen we de plugin in het .NET framework met de .NET Remoting code kunnen laten werken. De grootste verschillen tussen deze twee ligt in de return values en het gebruik van pointers.

3.3.2 Aanroepen C# methoden in C++ Zolang de C++ code CLS-compliant is, is het geen enkel probleem om methoden of constructors aan te roepen uit C# code. In feite gaat het aanroepen van een C# methode in C++ op exact dezelfde manier als een C++ methode aanroepen in C++. Wat wel opvalt, is dat alle C# classes worden opgevat in C++ als pointers naar classes. Dit levert soms rare datatypes op, zoals String*.

3.3.3 Managed en Unmanaged Voor het schrijven van strings en andere typen die een ongedefinieerd aantal bytes nodig hebben, bestaat er in C/ C++ de functie malloc. Deze functie alloceert geheugen van een bepaalde grootte, waarnaar bytes toegeschreven kunnen worden. Nadat de gedeclareerde pointer niet meer nodig is, wordt het stukje geheugen weer vrijgegeven met free. Deze pointers worden unmanaged pointers genoemd. In C# zijn pointers weg geabstraheerd. Types van variabele lengtes worden onder water gedeclareerd zodat de gebruiker er niets van te zien krijgt. En dus ook het opruimen van deze pointers gebeurt onder water. Dit opruimen gebeurt met behulp van de garbage collector. Deze pointers worden managed pointers (ook wel bekend als __gc) genoemd. Beide type pointers kunnen worden gebruikt in het .NET framework, maar niet samen. Managed pointers worden gealloceerd op de common language runtime heap. Dit is een stuk geheugen dat speciaal wordt gebruikt door het .NET framework. Hierop kunnen variabelen


tussen de verschillende talen uitgewisseld worden. Unmanaged pointers hebben geen toegang tot dit stukje geheugen. Unmanaged pointers worden gealloceerd ergens anders in het geheugen en vallen buiten het bereik van de garbage collector. Variabelen die unmanaged gedeclareerd worden, kunnen niet gebruikt worden in andere programmeertalen. C# zou wel een unmanaged pointer kunnen inlezen, maar zou zelf niet deze pointer weer verwijderen, omdat C# er van uitgaat dat een garbage collector dat voor hem doet. Hierdoor kan het geheugen volstromen met ongebruikte pointers, en dat kan problemen opleveren. Daarom zijn managed pointers de enige pointers die CLS compliant zijn.


3.4 Windows Messaging in Winamp

Het programma Winamp kan geheel bestuurd worden door middel van windows messaging (namelijk de command messages). Zo kan er een programma geschreven worden dat het control gedeelte (play, pause, stop, etc.) van winamp geheel overneemt. Maar ook kunnen er commando’s worden verstuurd om bijvoorbeeld een .m3u file te genereren van de huidige playlist. Dit is een voordeel ten opzichte van andere mp3-spelers, waarbij dit vaak niet allemaal mogelijk is. Het versturen van zo’n message gaat tamelijk eenvoudig met de functie Sendmessage: SendMessage(hwnd_winamp, WM_COMMAND,command_name,0); Met hwnd_winamp wordt het window winamp bedoeld, zodat RUN (zie 2.4) weet naar welk window de message verstuurd dient te worden. WM_COMMAND geeft aan dat het soort bericht dat verstuurd wordt van het type “command message” is. Voor command_name kan het werkelijke bericht naar Winamp worden verstuurd, met eventueel nog een extra parameter (die in dit geval 0 is).


Hoofdstuk 4: Evaluatie van de gebruikte middleware in GOne

4.1 Java webservices Waarschijnlijk zal het implementeren van webservices met behulp van Visual Studio .NET en C# een stuk makkelijker verlopen dan met behulp van Java. We zijn ook op zoek gegaan naar een soort van Visual Studio .NET die met Java overweg kan. JBuilder (http://www.borland.com/jbuilder/ ): Deze ontwikkelomgeving was erg groot en was onder andere daardoor ook traag. Het was vrij lastig om hiermee een webservice te maken, omdat deze tool zoveel meer dingen ondersteunt. Na een middagje stoeien met JBuilder hebben we besloten deze tool te laten voor wat het was en op te zoeken naar een andere tool. Novell exteNd Workbench (http://www.novell.com/products/extend/): Workbench is een web application development tool die onder andere het ontwikkelen van een webservice ondersteunt. Deze tool is niet traag en je kunt stap voor stap een webservice maken met behulp van een wizard. Het probleem was hier alleen dat tijdens deze wizard we iedere keer tegen een probleem aanliepen en waar we geen oplossing voor konden vinden. Uiteindelijk hebben we een simpel voorbeeld, dat meegeleverd werd bij de Java Application Server, werkend gekregen. Toen dit eenmaal gelukt was, hebben we dit voorbeeld verder aangepast en uitgebreid. Dit kwam er op neer dat we alles in een gewone editor (TextPad) hebben gemaakt en alle aanroepen vanaf de commandline deden.

4.1.1 Server ontwikkeling Het ontwikkelen van de business logic van de serverside was niet erg complex maar wel secuur. Om er zeker van te zijn dat de server zo robuust mogelijk werd, moesten alle eventuele foute aanroepen opgevangen worden. Op deze manier kan de server correct reageren en eventueel een foutmelding terugsturen naar de client. Voorbeelden van foute aanroepen zijn: Nullpointers op de plaats van parameters, verkeerde typen en ‘verboden’ handelingen, zoals het opvragen van de playlist zonder aangemeld te zijn. Al deze checks zijn niet complex maar vergen even tijd om te controleren of inderdaad alle gevallen afgevangen worden. Bij het ontwerpen van de server bleek dat er een aantal basisfuncties waren (hulpfuncties) die door de echte functies van de interface aangeroepen worden. Mede hierdoor is het vrij eenvoudig om de server aan te passen indien nodig, want er staat weinig dubbele of overbodige code in.


4.1.2 Server Implementatie Om een webservice te kunnen draaien moet er in ieder geval een webserver werkzaam zijn. Wij hebben de standaard meegeleverde “Sun Java System Application Server Platform Edition 8 FCS” hiervoor gebruikt. Voor deze server zijn benodigdheden, namelijk de Java Runtime Environment en een geïnstalleerde versie van de J2SE (minimaal versie 1.4). Er zijn minimaal twee code files nodig om een webservice te maken.

1) Interface file, deze file beschrijft welke functies de webservice aanbiedt en met welke parameters deze moeten worden aangeroepen.

2) De implementatie file, hierin staat de zogenaamde business logica van de webservice. Deze twee vormen samen het EJB pakket. Het eerste dat dient te gebeuren is het compileren van de javasources files, dit kan direct met de ‘normale’ javac compiler. Bij het configureren van de server wordt gebruikt gemaakt van diverse xml bestandjes die elk een eigen onderdeel configureren. Het gaat te ver om deze hele procedure uit te leggen. Hiervoor verwijzen we naar de website van java, http://java.sun.com/. Een opmerking is hier echter wel op zijn plaats: het is zeker voor beginners niet eenvoudig om even zelf een simpele webservice te maken. De beste methode is om eerst naar enkele werkende voorbeelden te kijken die meegeleverd worden met de standaard pakketten.

4.1.3 Ant / asant Zoals gezegd zijn er minimaal twee java files nodig om een webservice te maken. De source code (met de businiss logica) en een interface file. Het is vanzelfsprekend niet mogelijk om deze direct op een java server te laten draaien. De code files moeten eerst nog gecompileerd worden door de EJB compiler die het server skeleton opbouwt. Naast het skeleton wordt ook de WSDL file gegenereerd. Samen met alle gecompileerde files wordt deze in een WAR (Web Archive) en vervolgens in een EAR (Enterprise Archive) gezet. Voor exacte details over beide archives, zie referentie 15. Tenslotte dient de EAR file op een server gezet (‘deploy’) te worden. Dit houdt in dat de server de webservice beschikbaar stelt via bijvoorbeeld Internet. Omdat alle bovenstaande handelingen op de commandline moeten gebeuren zijn er een aantal ondersteunende programma’s ontwikkeld, Ant en Asant. Ant is een acronym voor Another Neat Tool en is oorspronkelijk door een onafhankelijke programmeur gemaakt. Asant is daar weer een afgeleide van (“as Ant”). Ondertussen worden beiden al ondersteund door onder andere Sun en wordt het meegeleverd bij de pakketten benodigd voor het ontwikkelen van webservices. We hebben gekozen voor Asant in plaats van Ant, omdat bij Asant meer documentatie was meegeleverd. Hieronder zullen we alleen Asant behandelen, terwijl alles wat gezegd wordt eigenlijk ook voor Ant geldt. Asant werkt met behulp van xml-bestanden waarin alle mogelijke handelingen beschreven staan. Groot voordeel hiervan is dat aangegeven kan worden welke onderdelen afhankelijk


zijn van elkaar. Asant wordt aangeroepen met een handeling die uitgevoerd moet worden. Indien deze afhankelijk is van andere handelingen worden deze eerst uitgevoerd en zo verder. De werkwijze is vergelijkbaar met make onder unix, waarin afhankelijkheid ook is aan te geven. Asant biedt echter veel meer mogelijkheden. De bovenstaande handelingen konden dan ook in theorie met een commando worden uitgevoerd. De Asant tool zou in praktijk zeer gemakkelijk te hanteren moeten zijn. Het neemt al de benodigde tijd in beslag om met de build-file te kunnen werken. Zeker om vanuit niets een build-file te maken is niet erg gebruiksvriendelijk. Bovendien gebruikt Asant zoals gezegd een aantal configuratie bestanden (alle in xml) waarvan het nut en noodzaak niet direct duidelijk vermeld staan. Ook dit is voor beginnende ontwikkelaars niet handig. Een van de grootste hindernissen is de grote bug die er in Asant zit. Het gaat hierbij om het uitvoeren van java client code. Dit hadden wij in de beginfase nodig om de server te kunnen testen, onafhankelijk van de C# code. Het uitvoeren bleek in het geheel niet te werken met behulp van Asant. Na een work-around te hebben gevonden op de officiële java.sun.com site (deze work-around werd pas tijdens het project bekend, zie referentie 20) konden wij het een en ander wel naar behoren testen. De hoeveelheid configuratiebestanden en verschillende mogelijke aanroepen maken het geheel onoverzichtelijk. Zelfs het aanpassen van meegeleverde voorbeeld applicaties is geen triviale bezigheid. Onze webservice is een aangepaste en uitgebreide versie van een simpel voorbeeld meegeleverd door Sun. We hebben later geprobeerd zelf een webservice ‘from scratch’ te maken, wat inhield dat we zelf alle build-files moesten maken. Dit ging vrij moeizaam, maar uiteindelijk waren we dan toch zover om de EAR file te deployen op de server. Dit leverde echter een error op waar we geen raad mee wisten en ondanks dat we ons probleem op het java.sun.com forum hebben gezet (zie referentie 16), is er geen oplossing gekomen.

4.1.3 Deploytool Voor het deployen van EAR files is ook een aparte deploytool meegeleverd welke met een GUI werkt. Voordeel van deze tool is, dat direct te zien is welke services er op een server gedeployed zijn en dat het creëren van clientstubs ondersteund werd. De tool is echter puur een grafische schil om Ant en Asant heen wat ondermeer blijkt uit de foutmeldingen die gegeven worden bij bijvoorbeeld een compiler error. Deze bestond dan direct uit de stacktrace van de compiler die je ook getoond krijgt bij handmatig compileren.

4.1.5 Koppeling C# De EJB compiler genereert op basis van de interface file (deze moet aangemaakt worden) de eerder genoemde WSDL file. Dit is een XML file waarin alle methoden beschreven worden met typen en parameters op basis van SOAP. Voorbeelden van SOAP berichten in zogenaamde SOAP enveloppen zijn terug te vinden in Bijlage 5.


Een representatief deel van deze WSDL file is te zien in Bijlage 3. In dit voorbeeld wordt de methode Logon beschreven welke een client in staat stelt zich bij de server aan te melden. De verschillende onderdelen van een methode invocatie worden beschreven. In de Visual Studio kan een WSDL file geïmporteerd worden en direct worden gekoppeld aan een project (een Webreference). Door nu een instantie aan te maken van deze webreference zijn alle methoden van de webservice beschikbaar. De compiler draagt nu zelf zorg voor het genereren van de client-stub mede op basis van de WSDL file. De flexibiliteit van koppeling is lastiger te beschrijven. Er zijn een aantal gevallen te onderscheiden: § Er wordt functionaliteit toegevoegd aan de serverkant. Dit houdt in dat de

gegenereerde WSDL file uitgebreid wordt. Clientside is het alleen noodzakelijk aanpassingen te doen indien van de nieuwe functionaliteit gebruik moet worden gemaakt. Zo ja dan moet de WSDL file vernieuwd worden en kunnen de nieuwe functies direct aangeroepen worden. Als een client geen nieuwe functionaliteit nodig heeft op de server kan hij de ‘oude’ WSDL file blijven gebruiken.

§ Vervelender is het geval wanneer door gewijzigde vereisten bestaande functionaliteit aangepast moet worden. Dan moet de functionaliteit serverside worden aangepast, want de WSDL file moet opnieuw worden gegenereerd. Bovendien moeten alle aanroepen clientside worden aangepast.

§ In het geval er functionaliteit verdwijnt moeten in ieder geval alle aanroepen op de verwijderde functionaliteit clientside worden uitgeschakeld. Ook is aan te raden om clientside de nieuwe WSDL file te gebruiken.

Het maakt niet uit in welke taal of op welk platform er gewerkt wordt, systemen worden gekoppeld via SOAP, wel is het aan te raden ontwikkelomgevingen te gebruiken die WSDL files ondersteunen (zoals Visual Studio .NET). Hierdoor wordt de ontwikkelaar een hoop tijd bespaard, omdat de ontwikkelomgeving onder water zorg draagt voor het genereren van clientstubs en serverskeletons.


4.2 .NET Remoting In dit hoofdstuk kijken we terug op .NET Remoting en zullen we onze implementatie ervaringen behandelen en zullen we kijken naar de voor- en nadelen van .NET Remoting naar ons inzien. We zullen onze ervaringen met .NET Remoting behandelen aan de hand van gebruikersgemak, aanpasbaarheid, toepasbaarheid en snelheid.

4.2.1 Gebruikersgemak .NET Remoting is behoorlijk gebruiksvriendelijk. De documentatie is uitgebreid en er zijn veel voorbeelden te vinden. Het is allemaal transparant, als gebruiker hoef je niet te weten wat er onder water gebeurt om gebruik te kunnen maken van Remoting. Wanneer je iets afwijkt van de standaard voorbeeldjes, dan wordt het echter een stuk lastiger in gebruik. Wij zijn dit probleem veelvuldig tegengekomen. Omdat ons programma zowel als server als client fungeert gaf dit wat extra problemen, die niet in de MSDN worden voorgedaan. Hierin staan alleen maar recht-toe-recht-aan client-server voorbeelden. Ook het feit dat de instellingen van de verbinding dynamisch moet, gaf problemen. Dit kwam doordat veel uitleg zich baseert op het meegeven van de instellingen via een XML file. Het instellen in de code was een stuk gecompliceerder. Een ander probleem is dat wanneer het allemaal eenvoudig is en je niks van de exacte implementatie hoeft af te weten, je het risico loopt dat het wel werkt, maar niet precies dat doet wat we willen. Dit probleem zijn we tegengekomen bij het oversturen van de files. Het werkte, want de file werd overgestuurd van A naar B. Bij nadere inspectie bleek echter de upload en download bandbreedte gelijk te zijn. Dit kwam doordat er telkens een lege buffer van A naar B werd gestuurd en vervolgens werd deze buffer vol teruggestuurd van B naar A.

4.2.2 Aanpasbaarheid Met .NET Remoting is in principe alles wat je zou willen mogelijk. Het is opgebouwd uit meerdere abstractie lagen. De gebruiker kan de code op al deze niveau’s indien gewenst zelf overschrijven. Het nadeel van het overschrijven van diepe lagen is dat het gebruikersgemak ver te zoeken is. Een nadeel van .NET Remoting met de standaard instellingen is dat er geen faciliteiten worden geboden op het gebied van security. Dat is waarschijnlijk zo, omdat Microsoft niet verantwoordelijk wil zijn voor veiligheidsissues die hieruit voortkomen. Een probleem dat wij tegenkwamen is dat wanneer een remotable object wordt geregistreerd (als een soort server), dan kunnen we geen onderscheid meer maken wie er met het object communiceert. Diegene die het heeft geregistreerd willen we eigenlijk meer “rechten” geven dan gebruikers op geheel andere computers. Dit hadden we nodig wanneer we wilden kijken of een File inderdaad wordt geshared wanneer een andere gebruiker om de File vraagt. Dit bleek echter (te) lastig en daarom hebben we ervoor gekozen om ons hier niet verder in te verdiepen en het op te lossen door alleen naar de extensie van de te downloaden File te kijken.

4.2.3 Toepasbaarheid Doordat het zo algemeen is opgezet is .NET Remoting bijna overal voor te gebruiken, zolang het .NET Framework geïnstalleerd is. Het is alleen lang niet altijd aan te bevelen om er daadwerkelijk voor te kiezen.


Het gebruik van .NET Remoting bij GOne was deels een overkill. Vooral voor iets triviaals als het oversturen van een File, wat eigenlijk puur bytes oversturen is, is iets abstracts als Remoting eerder ingewikkeld dan handig. Wanneer we het niet in het kader van een middleware opdracht zouden doen hadden we hiervoor waarschijnlijk een low-level communicatie gebruikt. Achteraf gezien was een FTP connectie beter geweest, omdat de firewall dan minder problemen veroorzaakt. Wat wel een voordeel is van het gebruik van .NET Remoting in dit geval is dat het makkelijker uitbreidbaar is. Wanneer je de functionaliteit van het remote object uitbreidt, dan hoef je verder niks aan de code te veranderen.

4.2.4 Snelheid De snelheid van .NET Remoting is heel behoorlijk. Hij varieert nogal al na gelang de instellingen (zie Bijlage 6 voor een overzicht). De pakketgrootte hebben we na enig testwerk ingesteld op 50Kb per aanroep (zie Bijlage 7.1). Bij gebruik van TCP en Binary encoding is de snelheid het hoogst en de netwerk belasting het laagst (zie Bijlage 7.2 en 7.3). De overhead bij het SOAP protocol is bijna vijftig procent en verandert nagenoeg niet bij variabele bestandsgrootte. Dit is logisch te verklaren, want bij SOAP encoding is de overhead data in verhouding vrij groot. Dit is een standaard nadeel van het XML formaat. De performance van ons systeem met veel aangemelde gebruikers hebben we helaas niet kunnen testen. Het zou interessant zijn om te zien hoe de remotable objects reageren op veel requests per tijdseenheid.


4.3 CLS en .NET In dit hoofdstuk zal verder worden ingegaan hoe het koppelen van C# en C/C++ is verlopen in het .NET framework.

4.3.1 Globale statische klasse Sommige variabelen moeten niet locaal maar globaal worden gedefinieerd. Helaas is dit niet mogelijk in het .NET framework: de garbage collector kan deze globale variabelen niet opruimen, en dus zijn globale variabelen niet CLS compliant. Een oplossing hiervoor is het gebruik van een globale statische klasse. Hierin kunnen alle globale variabelen gedeclareerd worden, en doordat deze klasse wel CLS compliant is, heeft de compiler geen moeite om deze klasse te compileren. Dit levert echter een hele vreemde klasse op: static __gc class StaticConstants { public: static Winamp::Song * list [] = NULL; }; Maar de code is wel degelijk CLS compliant, en wordt dus geaccepteerd door het .NET framework.


4.4 GUI plugin De plugin moet dezelfde look & feel krijgen als Winamp zodat het een geïntegreerd geheel vormt. Omdat Winamp geen gebruik maakt van een normaal form, moet alles erg low-level opgelost worden: alles omtrent de pluginwindow moet zelf geregeld worden. Het is voor de gebruiker bijvoorbeeld prettig om een zo lang mogelijk listbox te zien met daarin de gedeelde nummers (afhankelijk van de grootte van het window). De volgende oplossing is geïmplementeerd: indien het window van de plugin verkleind of vergroot wordt, wordt er een event doorgegeven vanuit Winamp. Dit event wordt opgevangen, en aan de hand daarvan berekenen we voor het nieuwe window het nieuwe formaat en locatie. Zodoende kan exact worden uitgerekend op welke plaats en met welke grootte de listbox getekend moet worden. Het uitrekenen gaat op het niveau van pixels. Ditzelfde wordt gedaan voor de knoppen en de statusregel onder de listbox. Een van de zeer grote nadelen van deze methode is dat indien er zich wijzigingen voordoen in de GUI alles handmatig moet worden aangepast. Een knop verplaatsen houdt dus in dat andere knoppen waarschijnlijk ook verplaatst moeten worden en alle berekeningen dus nagelopen moeten worden. Ook is er geprobeerd de functionaliteit van de knop ‘send playlist’ automatisch in de plugin te verwerken. Dit zou inhouden dat wanneer de playlist in Winamp zelf verandert, de plugin dit event opvangt en automatisch de nieuwe playlist doorstuurt naar de server. Op het Winamp forum hebben we deze vraag gesteld (zie referentie 17), maar de event die verstuurd wordt bij een verandering van playlist bestaat pas sinds Winamp 5. Aangezien we GOne compatible wilden maken met zowel Winamp 2 als 5, hebben we deze functionaliteit weggelaten.


Hoofdstuk 5: Conclusies In hoofdstuk 4 hebben we de gebruikte middlewaretechnieken geëvalueerd. In dit hoofdstuk zullen we de gebruikte technieken onderling vergelijken en een aantal algemene conclusies trekken over middlewaretechnieken.

5.1 Gebruikersgemak en Tools Het ontwikkelen van de javawebservice qua java code gaat vrij gemakkelijk, zeker voor de ervaren java programmeur levert dit weinig problemen. Echter het werken met de tooling eromheen is een stuk problematischer. De (grafische) tools die wij geprobeerd hebben werkten allen niet erg intuïtief en daarom hebben we ook besloten de code maar in een text editor te schrijven en handmatig te compileren met Asant. Jammer genoeg was het vrij lastig om met Asant te werken, omdat het niet duidelijk is wat er nu precies allemaal gebeurd. Door de gebruikte tooling en bibliotheken hebben we het SOAP protocol op een hoog abstractieniveau geïmplementeerd, waardoor we extra moeite moesten doen om een SOAP bericht op te vangen. Het is praktisch dat de SOAP berichten gegenereerd worden, omdat dit de ontwikkelaar veel triviaal programmeerwerk scheelt. Als er een applicatie in .NET geschreven dient te worden, kan aan Visual Studio .NET niet ontkomen worden. Visual Studio .NET bevat de juiste compilers en is gekoppeld aan een aantal grote library’s. Het programmeren van C# code gaat dan ook erg eenvoudig. Een nadeel is misschien wel dat het allemaal wat te uitgebreid is, maar dat is slechts een luxe probleem. Een mooi voorbeeld van de simpelheid van Visual Studio .NET is het importeren van de WSDL file, dit gaat erg makkelijk en intuïtief. Het standaard .NET Remoting gebeuren werkt ook simpel in .NET, al is het soms moeilijk te doorgronden wat er nu echt precies gebeurd. Dit laatste moet je echter wel weten, wil je wat aanpassingen doorvoeren in standaard Remoting voorbeelden. Voor C++ is Visual Studio .NET iets minder gebruiksvriendelijk. Nog steeds zijn er veel voorbeelden te bekijken en ook de library is redelijk uitgebreid voor C++. Maar dit geldt voor een C++ .NET project. Om bestaande C++ code (wat veelal voor een Win32 applicatie is geschreven) te koppelen aan .NET is iets meer moeite nodig. C++ code maakt gebruik van unmanaged pointers, en dat mag niet als de code CLS compliant dient te zijn, zoals in hoofdstuk 3.3 wordt verteld. Om dit op te lossen ontstaan erg eigenaardige stukken code. Ook worden niet alle C# constructies begrepen door Win32 C++ code. Uiteindelijk is alles wel op de één of andere manier op te lossen, maar het zijn vaak de minder elegantere manieren. Echter, als er voor gekozen wordt om C++ - en C# code aan elkaar te koppelen zonder dat er gebruik wordt gemaakt van bestaande (Win32) code, dan gaat de koppeling een stuk gemakkelijker. In Winamp wordt gebruik gemaakt van een layout (een skin) die on-the-fly veranderd kan worden. Helaas is het voor het programmeren van plugins die ook gebruik willen maken van deze veranderende skin erg lastig. Alle code wat betreft dialog boxes en forms dient met de hand te worden geschreven, nadat er met behulp van de resource editor een scherm is gemaakt. Dit gaat dus lang niet zo gemakkelijk als bij het “klikken en slepen” in bijvoorbeeld C# projecten.


Het koppelen van plugins aan Winamp is redelijk eenvoudig, omdat het duidelijk is hoe je met Winamp moet communiceren. Het probleem zit echter bij het grafische gedeelte van de plugin, het kost veel tijd om dit mooi te maken. Het op deze wijze low level schrijven van de benodigde code is voor een keer wel leuk maar daarna is goede tooling gewenst. De goede tooling bij Java is ook nog wel eens een probleem. De (beginnende) ontwikkelaars moeten nog te veel hand werk verrichten voor het opstarten van een uiterst simpele javawebservice. Te veel energie en tijd gaat verloren bij het instellen van configuratie files en oplossen van onduidelijke compiler errors. De huidige ondersteunende tooling is nog niet genoeg ontwikkeld, het voorkomen van de ‘grote’ bug (zie 4.1.4) is hier een goed voorbeeld van. Dit in tegenstelling tot de tooling die beschikbaar is voor het .NET Framework, welke wel snel, intuïtief en simpel werkt. Nadeel is wel dat er kosten aan Microsoft tools verbonden zijn.

5.2 Documentatie Bij het .NET Framework is veel documentatie geschreven. Deze documentatie is online terug te vinden in de MSDN van Microsoft. Voor het koppelen van C# code aan C++ code en de code voor .NET Remoting is dus veel informatie beschikbaar. Bij Javawebservices is dit echter minder uitgebreid. Er zijn wel redelijk veel voorbeelden te vinden, maar als je tegen een bug of error aanloopt, wordt het een stuk moeilijker dit op te lossen. Alleen met het zoeken op java.sun.com kun je misschien een oplossing vinden. De documentatie bij Winamp is minimaal. Er is alleen een lege SDK beschikbaar, wat een code framework bevat voor alle soorten plugins voor Winamp. Hier zitten ook header files bij, waarin beschreven wordt hoe en wat je allemaal kunt aanroepen bij Winamp. Verder is er weinig informatie bekend voor ontwikkelaars van plugins, al is er wel een Winamp Forum waar vragen gesteld kunnen worden. Het schrijven van de plugin is ook niet eenvoudig, omdat het niet duidelijk is welke messages je kunt versturen. Je moet dit dus altijd opzoeken in de MSDN.

5.3 Snelheid en interoperabiliteit De gebruikte Java Application Server die de webservice bevat is erg traag met opstarten, maar wel stabiel als hij eenmaal draait. Het maken van de Javawebservice met behulp van Asant gaat ook niet erg snel, vooral het deployen van de webservice op de server duurt erg lang. De Javawebservice maakt gebruik van SOAP en dit zorgt ervoor dat probleemloos verschillende applicaties met elkaar kunnen communiceren over verschillende platformen. De snelheid van het .NET Remoting gebeuren is goed te noemen (zie Bijlage 6 voor verschillende overdrachtsprotocollen). Het downloaden van nummers gebeurt in verschillende threads, zodat niet het hele programma wacht totdat het nummer gedownload is. Het sturen van messages tussen Winamp en de plugin verloopt ook soepel en snel. Het voordeel van Java is dat het platformonafhankelijk is, dit in tegenstelling tot het .NET Framework (al is men bezig met een variant voor Unix/Linux) en Windows Messaging. Als je echter weet dat platformafhankelijkheid niet belangrijk is, kun je beter niet voor Java kiezen, omdat dit de snelheid niet ten goede komt.


5.4 Algemene conclusie We hebben algemene kennis opgedaan over verschillende middlewaretechnieken in hoofdstuk 2. In de casestudy komen verschillende middlewaretechnieken terug: webservices (in Java), .NET Remoting, koppeling C# en C++ code (CLS compliant) en Windows Messaging. Ook daar hebben we ons in de theorie verdiept en geprobeerd deze in de praktijk te brengen door middel van de casestudy. Het toepassen van middleware blijft lastig, omdat je vaak met bestaande softwarepakketten moet werken. De communicatie met deze pakketten verloopt meestal via, al dan niet goed gedocumenteerde, interfaces. Als programmeur heb je hierop geen invloed en indien er zich problemen voordoen zal er waarschijnlijk een adhoc oplossing gezocht moeten worden. Bovendien bestaat het risico dat koppelingen niet meer werken in de toekomst, vanwege softwareaanpassingen en veranderingen in de interface. Een goede interface met documentatie is cruciaal voor de implementatie van middlewaretechnieken. Afhankelijk van eisen die aan systemen gesteld worden moet een keuze gemaakt worden tussen de bestaande middlewaretechnieken en -architecturen.


BIJLAGEN

1. Werkverdeling Implementatie: Tom Evers:

§ Voor onderzoek winamp & messaging § .Net Remoting, verschillende protocollen § Interface (WSDL, java vs c#) in overleg met Sjors M § Configuratie scherm plugin § .Net aanroepen vanuit de plugin § Threads plugin § Windows messaging in plugin § Opvangen event playlist verandering in winamp § SOAP message opvangen § Overdrachtsprotocollen meten

Chris Jager:

§ Voor onderzoek winamp & messaging § Threads plugin § Playlist handling (parseren en sending / receiving) § Windows messaging in plugin § Geheugenbeheer plugin

Sjors Meekels:

§ Voor onderzoek winamp & messaging § Installatie java application server, met Tom de V § Server onder UNIX, met Tom de V § Java webservice (code files), met Tom de V § Interface (WSDL, java vs c#) in overleg met Tom E § Resizable maken plugin & look and feel winamp plugin § SOAP message opvangen § Overdrachtsprotocollen meten

Tom de Valk:

§ Voor onderzoek winamp & messaging § Installatie java application server, met Sjors M § Server onder UNIX, met Sjors M § Ontwikkelomgevingen voor java-webservices gezocht en getest § Java webservice (code files), met Sjors M § Threads plugin § Overdrachtsprotocollen meten § Installer Client software


Documentatie: Tom Evers:

§ Alles over .NET Remoting § Conclusie § Meetresultaten

Chris Jager:

§ Bijlage Nullsoft Winamp § Windows Messaging in Winamp § Koppeling C++, C++ .NET en C# .NET § Conclusie § Cls en .NET

Sjors Meekels:

§ Java webservice § Java / Jax-RPC / Soap § Evaluatie Java webservice § Bijlage file sharing systeem § Conclusie § Meetresultaten

Tom de Valk: § Java webservice § Java / Jax-RPC § Evaluatie Java webservice § Inleiding § De casestudy § Conclusie § Eindredactie § Meetresultaten


2. Filesharing-systemen Wij hebben een aantal praktijkvoorbeelden van filesharing-systemen nader bekeken en geanalyseerd wat de gebruikte architecturen hierbij zijn. Een van de manieren om de verschillende p2p netwerken onder te verdelen is naar de mate van centralisatie. Waarmee de mate afhankelijkheid van een of meerdere servers voor het opzetten van een p2p verbinding wordt bedoeld. Er zijn drie onderscheiden te maken:

• Volledig gedecentraliseerd, voorbeelden van deze implementatie zijn onder andere initiële versies van Gnutella en Freenet. Hierbij voeren alle knopen in het netwerk dezelfde taken uit, zowel de servertaken als de clienttaken. Nadeel van deze implementatie is de enorme overhead aan data die verzonden dient te worden om überhaupt op het netwerk te blijven. Bovendien leveren de zoekfuncties slechte resultaten, vaak is maar 10% van de gevonden bestanden daadwerkelijk te downloaden.

• Gedeeltelijk gecentraliseerd, voorbeelden zijn KaZaa, Morpheus en nieuwere versie

van Gnutella. In wezen is er dezelfde architectuur als bij volledige gedecentraliseerde systemen, maar dan met een uitbreiding. Enkele knopen in het netwerk fungeren als zogenaamde Supernodes. Hierop worden diverse taken uitgevoerd zoals het zoeken naar bestanden en het opnemen van nieuwe knopen in het netwerk. Een groot voordeel van deze opzet is het uitblijven van een enkele centrale server. Een dergelijke server vormt een groot risico in het netwerk, als deze server niet functioneert dan ligt het volledige netwerk plat, een single point of failure dus.

Het grote nadeel van Napster was dat het alleen draaide om mp3 files. Kazaa en andere netwerken kunnen alle soorten bestanden aan. Hierdoor is het mede steeds makkelijker om illegale software te bemachtigen.

• Hybride gedecentraliseerd, zoals Napster. De architectuur draait om een centrale server waar gebruikers zich bij dienen te melden. Hierop vinden ook de zoekoperaties plaats. Het uiteindelijke daadwerkelijke verzenden van bestanden gebeurd wel direct tussen twee gebruikers. Deze implementatie wordt ook wel peer- through-peer genoemd en door sommigen niet gezien als een volwaardige p2p implementatie. Een duidelijk risico factor is de centrale server, mede hierdoor gaat deze implementatie voorbij aan de pure p2p doelstelling. Bovendien wordt de performance slechter naarmate er steeds meer gebruikers zich aanmelden en queries op de server laten uitvoeren.

Napster is een van de eerste netwerken die de populariteit van het nieuwe medium enorm heeft gestimuleerd. Nadat Napster door juridische perikelen werd gedwongen de downloadmogelijkheden zeer te beperken nam het aantal gebruikers snel af en werden in korte tijd de opvolgers steeds populairder (KaZaa, Morpheus). In de architectuur van BitTorrent worden enkele nieuwe ideeën in de praktijk gebracht. Een gebruiker vindt zijn doel bestand door middel van een hyperlink op internet. Vervolgens wordt de relevante meta-informatie over het bestand via een server


(tracker) binnen gehaald. Tenslotte wordt de grootste dataoverdracht weer via p2p gedaan. Dat ook BitTorrent niet volledig veilig is schrijft Bram Cohen (auteur van BitTorrent) in zijn artikel "Security in p2p file distribution" (zie referentie 18).

Overzicht van het Gnutella netwerk in een graph


3. WSDL file extract <complexType name="ArrayOfNummerclass"> <complexContent> <restriction base="soap11-enc:Array"> <attribute ref="soap11-enc:arrayType" wsdl:arrayType="tns:Nummerclass[]"/> </restriction> </complexContent> </complexType> <complexType name="Nummerclass"> <sequence> <element name="artiest" type="string"/>

<element name="ip" type="string"/> <element name="locatie" type="string"/> <element name="titel" type="string"/>

</sequence> </complexType> <complexType name="Logonclass"> <sequence> <element name="ip" type="string"/>

<element name="naam" type="string"/> <element name="playlist" type="tns:ArrayOfNummerclass"/>

</sequence> </complexType> <message name="HelloIF_Logon">

<part name="Logonclass_1" type="ns2:Logonclass"/> </message> <message name="HelloIF_LogonResponse">

<part name="result" type="xsd:int"/> </message> <operation name="Logon" parameterOrder="Logonclass_1">

<input message="tns:HelloIF_Logon"/> <output message="tns:HelloIF_LogonResponse"/>

</operation> <operation name="Logon">

<soap:operation soapAction=""/> <input>

<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="encoded" namespace="http://hello.org/wsdl/HelloWorld"/>

</input> <output>

<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="encoded" namespace="http://hello.org/wsdl/HelloWorld"/>

</output> </operation>


4. Nullsoft’s Winamp In het begin van de jaren 90 werd door het Duitse innovatieve bedrijf Fraunhofer naast WAV een nieuw muziekformaat gelanceerd: MP32. Dit werd gedaan in opdracht van de Europese Unie. Het voordeel van MP3 boven WAV is dat een gemiddeld MP3-bestand wel tot 10 keer zo klein kan zijn als een WAV-bestand. Winamp, gecreëerd door Justin Frankel (programmeur, ook verantwoordelijk voor het implementeren van het Gnutella-netwerk), was in 1997 één van de eerste muziekspelers voor Windows die zowel MP1, MP2 als MP3 kon afspelen. De eerste versie baarde nog niet zoveel opzien, maar toen de tweede versie uitkwam werd het Internet steeds uitgebreider. Winamp 2 is één van het meest gedownload stukje software voor de PC. Het grote voordeel van Winamp was dat het, in tegenstelling tot Windows Mediaplayer, het een open source project was. Plugins konden tamelijk eenvoudig geschreven worden omdat de architectuur van het programma zich daar erg voor leent. Een erg bruikzame plugin was bijvoorbeeld de Disk Writer-plugin, die MP3 om kan zetten naar WAV, wat een erg handige functionaliteit was bij het branden van CD’s. De Disk Writer-plugin wordt overigens nog steeds als standaard bij de nieuwste versie van Winamp geleverd. Maar niet alleen was Winamp erg in trek bij programmeurs: ook designers konden hun ei erin kwijt. Winamp maakt(e) het namelijk mogelijk om verschillende skins te tonen, zodat de GUI er meteen heel anders uitziet. Inmiddels is Nullsoft na het experimentele Winamp 3 belandt bij deel 5. Deze is in twee versies te verkrijgen: de standaard versie en de pro versie. Voor de pro versie moet alleen wat geld worden neergelegd. Dit impliceert natuurlijk dat Winamp 5.0 geen open source project meer is. Een offspring van Winamp 3, de Wasabi-player, is dat wel. Nullsoft heeft echter wel rekening gehouden met programmeurs en “skinners”: de skins kunnen nog steeds gemaakt worden: dat gedeelte is wel “open source”, en Winamp 5 is geheel compatible met alle plugins van Winamp 2/3. Hierdoor is het nog steeds mogelijk om plugins voor Winamp te schrijven. General Purpose Plugin Voor Winamp zijn verschillende plugins te schrijven, die allen een andere functionaliteit hebben. Voor de plugins die niet voldoen aan één van deze functie-eigenschappen of voldoen aan meerdere, is er nog de categorie general purpose plugins (GPP). De door ons te schrijven plugin valt duidelijk in deze categorie. Een plugin voor winamp wordt over het algemeen als een dynamic linked library (dll) weggeschreven. Op het forum3 van Winamp zijn verschillende tutorials en lege GPP’s te downloaden. De meeste source code is geschreven in C++, maar er zijn ook enkele voorbeelden van Delphi en Basic te krijgen. Op het gebied van .NET is momenteel nog erg weinig te vinden, waarschijnlijk omdat het nog relatief nieuw is. Echter, C++ code zou geen problemen moeten opleveren in een .NET framework. We kunnen onze filesharingscode in de veel elegantere taal C# schrijven, de GUI voor de plugin in C++ laten staan, en zowel de C#- als de C++-code tegelijk als één dll compileren. Het .NET framework maakt dit mogelijk door de common language specification4 (CLS).


5. SOAP Messages Soap envelloppe Request van Client naar Server om zich aan het melden. <?xml version="1.0" encoding="utf-8" ?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://hello.org/wsdl/HelloWorld" xmlns:types="http://hello.org/wsdl/HelloWorld/encodedTypes" xmlns:xsi="http://www.w3.org/2001/XMLSchema -instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <tns:Logon> <Logonclass_1 href="#id1" /> </tns:Logon> <q1:Logonclass id="id1" xsi:type="q1:Logonclass" xmlns:q1="http://hello.org/types"> <ip xsi:type="xsd:string">131.174.125.39</ip> <naam xsi:type="xsd:string">Tom Evers</naam> <playlist href="#id2" /> </q1:Logonclass> <soapenc:Array id="id2" xmlns:q2="http://hello.org/types" soapenc:arrayType="q2:Nummerclass[4]"> <Item href="#id3" /> <Item href="#id4" /> </soapenc:Array> <q3:Nummerclass id="id3" xsi:type="q3:Nummerclass" xmlns:q3="http://hello.org/types"> <artiest xsi:type="xsd:string">Andere Hazes</artiest> <ip xsi:type="xsd:string">131.174.125.39</ip> <locatie xsi:type="xsd:string">D:\My Documents\My Music\Andre Hazes - Zij gelooft in mij.mp3</locatie> <titel xsi:type="xsd:string">Zij gelooft in mij</titel> </q3:Nummerclass> <q4:Nummerclass id="id4" xsi:type="q4:Nummerclass" xmlns:q4="http://hello.org/types"> <artiest xsi:type="xsd:string">Frans Bauer</artiest> <ip xsi:type="xsd:string">131.174.125.39</ip> <locatie xsi:type="xsd:string">D:\My Documents\My Music\45-22-a Frans Bauer - Eens Schijnt De Zon.mp3</locatie> <titel xsi:type="xsd:string">Eens Schijnt De Zon</titel> </q4:Nummerclass> </soap:Body> </soap:Envelope>


Soap envelloppe Response van de Server (int waarde geeft aan of de Logon succesvol was) <?xml version="1.0" encoding="UTF-8" ?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://hello.org/wsdl/HelloWorld" xmlns:ns1="http://hello.org/types" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<env:Body> <ns0:LogonResponse>

<result xsi:type="xsd:int">0</result> </ns0:LogonResponse> </env:Body> </env:Envelope> Request van de Client om de Playlist op te vragen (int waarde geeft aan of de Logon succesvol was) <?xml version="1.0" encoding="utf-8" ?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://hello.org/wsdl/HelloWorld" xmlns:types="http://hello.org/wsdl/HelloWorld/encodedTypes" xmlns:xsi="http://www.w3.org/2001/XMLSchema -instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <tns:GetPlayList>

<String_1 xsi:type="xsd:string">131.174.125.39</String_1> </tns:GetPlayList> </soap:Body> </soap:Envelope>


Response van de Server <?xml version="1.0" encoding="UTF-8" ?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://hello.org/wsdl/HelloWorld" xmlns:ns1="http://hello.org/types" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<env:Body> <ns0:GetPlayListResponse>

<result href="#ID1" /> </ns0:GetPlayListResponse>

<ns1:ArrayOfNummerclass id="ID1" xsi:type="enc:Array" enc:arrayType="ns1:Nummerclass[4]"> <item href="#ID2" /> <item href="#ID3" /> <item href="#ID4" /> </ns1:ArrayOfNummerclass> <ns1:Nummerclass id="ID2" xsi:type="ns1:Nummerclass"> <artiest xsi:type="xsd:string">Alice Cooper</artiest> <ip xsi:type="xsd:string">131.174.125.237</ip> <locatie xsi:type="xsd:string">D:\Muzieka\Alice Cooper - Poison.mp3</locatie> <titel xsi:type="xsd:string">Poison</titel> </ns1:Nummerclass> <ns1:Nummerclass id="ID3" xsi:type="ns1:Nummerclass"> <artiest xsi:type="xsd:string">Beasty Boys</artiest> <ip xsi:type="xsd:string">131.174.125.237</ip> <locatie xsi:type="xsd:string">D:\Muzieka\Beasty Boys_You Gotta Fight For Your Right To Party.mp3</locatie> <titel xsi:type="xsd:string">You Gotta Fight For Your Right</titel> </ns1:Nummerclass> <ns1:Nummerclass id="ID4" xsi:type="ns1:Nummerclass"> <artiest xsi:type="xsd:string">Carl Douglas</artiest> <ip xsi:type="xsd:string">131.174.125.237</ip> <locatie xsi:type="xsd:string">D:\Muzieka\Carl Douglas - Kong Fu Fighting.mp3</locatie> <titel xsi:type="xsd:string">Kong Fu Fighting</titel> </ns1:Nummerclass> </env:Body> </env:Envelope>


6. Meetresultaten SOAP http Bestand formaat (Mb) Pakketformaat (bytes) # sec # sec # sec gem gem kb/s eff gem kb/s tot vezonden data (Mb) verzonden #pakketen % overhead

3,77 10240 21,18 21,81 20,85 21,28 181,41 271,4 5,64 578 49,6 9,25 10240 54,41 53,75 50,65 52,94 178,93 266,9 13,8 1413 49,2 16,4 10240 92,46 89,81 87,92 90,06 186,46 279,0 24,54 2513 49,6

SOAP TCP Bestand formaat (Mb) Pakketformaat (bytes) # sec # sec # sec gem gem kb/s eff gem kb/s tot vezonden data (Mb) verzonden #pakketen % overhead

3,77 10240 18,21 17,1 18,07 17,79 216,96 321,1 5,58 571 48,0 9,25 10240 42,17 42,61 41,98 42,25 224,17 331,0 13,66 1399 47,7 16,4 10240 75,07 72,73 74,48 74,09 226,65 335,4 24,27 2485 48,0

Binary http Bestand formaat (Mb) Pakketformaat (bytes) # sec # sec # sec gem gem kb/s eff gem kb/s tot vezonden data (Mb) verzonden #pakketen % overhead

3,77 10240 14,85 13,35 13,77 13,99 275,95 297,9 4,07 417 8,0 9,25 10240 32,13 32,56 31,86 32,18 294,31 316,6 9,95 1019 7,6 16,4 10240 58,16 56,68 57,85 57,56 291,74 314,7 17,69 1811 7,9

Binary TCP Bestand formaat (Mb) Pakketformaat (bytes) # sec # sec # sec gem gem kb/s eff gem kb/s tot vezonden data (Mb) verzonden #pakketen % overhead

3,77 10240 11,32 10,54 10,64 10,83 356,35 380,0 4,02 412 6,6 9,25 10240 25,97 25,43 25,3 25,57 370,48 393,3 9,82 1006 6,2 16,4 10240 47,77 45,97 48,02 47,25 355,40 378,1 17,45 1787 6,4

3,77 10 4740 x x 4740,00 0,81 19,8 91,64 9609150 2330,8 3,77 100 483,6 466,6 x 475,06 8,13 27,2 12,6 132121 234,2 3,77 1024 55,02 54,2 55,3 54,84 70,40 86,3 4,62 4731 22,5 3,77 10240 11,32 10,54 10,64 10,83 356,35 380,0 4,02 412 6,6 3,77 20480 8,57 8,51 8,49 8,52 452,93 480,6 4,00 205 6,1 3,77 51200 7,26 7,05 7,17 7,16 539,17 576,4 4,03 83 6,9 3,77 102400 7,1 7,14 7,51 7,25 532,48 574,9 4,07 42 8,0 3,77 204800 6,77 7,07 6,88 6,91 558,95 633,1 4,27 22 13,3 3,77 1024000 8,03 9,47 7,85 8,45 456,86 615,6 5,08 5 34,7


7. Grafiek en tabellen bij meetresultaten

7.1 Overdrachtsnelheid van Binary Tcp

0,00100,00200,00300,00400,00500,00600,00700,00

10100

1024

10240

20480

51200

102400

20480

0

102400

0

Datapakketformaat (bytes)

Ove

rdra

chts

nelh

eid

Kb/

s

Effectieve overdracht

Totale overdracht

7.2 Overdrachtsnelheid verschillende configuraties

0,00

50,00

100,00

150,00

200,00

250,00

300,00

350,00

400,00

3,77 9,25 16,4

Bestandsformaat (Mb)

Effe

ctie

ve o

verd

rach

tsne

lhei

d K

b/s

SOAP HTTP

SOAP TCP

Binary HTTP

Binary TCP

7.3 Netwerk belasting verschillende configuraties

49,6 49,2 49,6

8,0 7,6 7,9

48,047,748,0

6,46,26,6

0,0

10,0

20,0

30,0

40,0

50,0

60,0

3,77 9,25 16,4

Bestandsformaat

Proc

entu

ele

Ove

rhea

d

SOAP HTTP

SOAP TCP

Binary HTTP

Binary TCP


8. Bronvermelding 1. http://en.wikipedia.org/wiki/MP3#History 2. http://en.wikipedia.org/wiki/Winamp 3. http://forums.winamp.com/ 4. http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/cpguide/html/cpconwhatiscommonlanguagespecification.asp 5. http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/cpref/html/cpref_start.asp 6. http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/cpguide/html/cpconpointers.asp 7. www.gnutella.com 8. www.gnutellanews.com 9. http://java.sun.com/blueprints/guidelines/designing_webservices/ 10. http://www.theserverside.com/articles/article.tss?l=MonsonHaefel-Column1 11. http://www.onjava.com/pub/a/onjava/2002/04/24/jax-rpc.html 12. http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/dnbda/html/bdadotnetarch14.asp 13. http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/vccore98/HTML/_core_user.2d.interface_objects_and_command_ids.asp 14. http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/winui/WinUI/WindowsUserInterface/Resources/Strings/StringReference/StringFunctions/stringcchprintf.asp

15. http://java.sun.com/j2ee/j2sdkee/techdocs/guides/ejb/html/Overview.fm.html 16. http://forum.java.sun.com/thread.jsp?forum=331&thread=517704&tstart=105&trange

=15 17. http://forums.winamp.com/showthread.php?s=&threadid=180487 18. http://opensores.thebunker.net/pub/mirrors/blackhat/presentations/bh-europe-03/bh-

europe-03-cohen.pdf 19. http://www.onjava.com/pub/a/onjava/2002/04/24/jax-rpc.html 20. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5005188 21. http://www.javapassion.com/webservices/JAX-RPC_speakernoted.pdf 22. http://msdn.microsoft.com/msdnmag/issues/02/10/NETRemoting/