Beheerplatform voor persoonlijke bestanden op een mobiel toestel

Transcriptie

1 Beheerplatform voor persoonlijke bestanden op een mobiel toestel Jan Van Boghout Promotoren: prof. dr. ir. Filip De Turck, dr. ir. Tim Wauters Begeleider: Frédéric Iterbeke Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar

2

3 Beheerplatform voor persoonlijke bestanden op een mobiel toestel Jan Van Boghout Promotoren: prof. dr. ir. Filip De Turck, dr. ir. Tim Wauters Begeleider: Frédéric Iterbeke Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar

4 Dankwoord Eerst en vooral wil ik mijn begeleiders Tim Wauters en Frédéric Iterbeke, alsook mijn promotor prof. Filip De Turck, bedanken voor hun hulp en begrip doorheen het jaar. Mijn professionele situatie zorgde voor de nodige uitdagingen wat de planning van deze masterproef betrof, maar dankzij de flexibiliteit die zij aan de dag legden is alles uiteindelijk op zijn pootjes terechtgekomen. Ook wil ik hen bedanken voor de kennis die ik heb opgedaan bij het schrijven van dit boek en de bijhorende software. Hiernaast wil ik ook iedereen bedanken die een stuk van dit boek heeft nagelezen of feedback gaf over WakaWaka. Tenslotte gaat er nog een grote dankbaarheid uit naar mijn vrienden die op menig zomerterras de kronieken van deze thesis hebben aanhoord. Jan Van Boghout, augustus 2009

5 Voorwoord Bij aanvang van deze masterproef deed het concept van PeCMan een beetje eigenaardig aan. Wat was het nut ervan, als diensten zoals Facebook een uitstekende ervaring aanbieden en zelfs een handige iphoneapplicatie meeleveren? Naarmate ik mij inwerkte kwam het unieke potentieel ervan echter uit te verf. Een platformonafhankelijke aanpak die toch gebruik kan maken van allerlei bestaande services is zeer aantrekkelijk, des te meer als er een kwaliteitsapplicatie bijhoort. De ontwikkeling van die toepassing was mijn uitdaging, en uiteindelijk ben ik tevreden over het resultaat. WakaWaka vormde een mooie oefening in het verbergen van netwerkoperaties voor een vlotte gebruikerservaring. De hinderpalen die onderweg opdoken hebben uiteindelijk een positief effect gehad, zij het als een verbetering in de software of als voorstel voor architecturale verbeteringen. Het uitwerken van WakaWaka heeft mij interessante inzichten opgeleverd, en ik hoop dat ik ermee heb bijgedragen aan de toekomst van PeCMan. Hoewel het systeem nog scherpe kantjes heeft, verdient het zeker te evolueren tot een echte dienst. Jan Van Boghout, augustus 2009

6 Toelating tot bruikleen De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef 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 masterproef. Jan Van Boghout, augustus 2009

7 Beheerplatform voor persoonlijke bestanden op een mobiel toestel Jan Van Boghout Promotoren: prof. dr. ir. Filip De Turck, dr. ir. Tim Wauters Begeleider: Frédéric Iterbeke Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar Samenvatting Deze masterproef onderzoekt de ontwikkeling van een client-applicatie, WakaWaka, die integreert met het gedistribueerde bestandssysteem PeCMan (Personal Content Management platform). Er wordt aangetoond dat gedistribueerde opslag van multimediabestanden praktisch haalbaar is en een aantal voordelen heeft t.o.v. gecentraliseerde diensten zoals Flickr, Facebook, e.d. Mobiele multimedia-applicaties hebben te maken met tal van struikelblokken, waarvoor in dit boek eventuele oplossingen aangereikt worden. De ontwikkeling van een uitgebreide client-applicatie onthulde structurele gebreken in de bestaande serverarchitectuur. Om hier in de toekomst oplossingen voor te kunnen bieden brengen we enkele voorstellen voor architecturale verbeteringen naar voren. Trefwoorden mobiel toestel, gedistribueerd opslagsysteem, multimedia, aggregatie, SIP

8 Personal content management platform on mobile devices Jan Van Boghout Supervisor(s): Filip De Turck, Tim Wauters, Frédéric Iterbeke Abstract This article investigates the challenges in writing a userfriendly mobile application that accesses a distributed virtual filesystem. Though peer-to-peer systems are traditionally used to exchange common files between desktop PCs, a distributed system can also power a personal multimedia management platform. We discuss the basic architecture of such a system, along with suggested architectural improvements. Keywords mobile devices, distributed storage, multimedia, aggregation, Session Initiation Protocol View WakaWaka Client Browse Transfer P2P File Transfers Storage Services I. INTRODUCTION INCREASINGLY, users switch to mobile devices for their daily multimedia needs. This development warrants a closer look at the current popular personal content ecosystems. One recurrent observation is the centralized and specialized nature of many multimedia services. Even though the back-end of such services is often based on load balancing and distributed storage systems, their front-ends are designed to support a certain level of user lock-in. Each service has its own passwords, comes with a unique user interface and often targets a specific kind of multimedia. This is a natural approach that ensures financial viability for these services, but it comes at a price: the fragmentation of users personal content. Considering how fast the social network landscape is changing, this problem merits a solid technological solution. A foundation for a platform solution was developed as PeC- Man 1, which stands for Personal Content Management platform. This system aims to be a service-agnostic solution for managing personal files. It accomplishes this by creating a virtual file system containing references to various storage locations. These storages range from popular sites like YouTube, Flickr and Facebook to a cell phone containing pictures of your road trip. Any device or service can be integrated into the peerto-peer network if it complies with the generic PeCMan APIs. Because the virtual file system effectively serves as a metadata layer, users can append additional information that can be twoway synchronized with specific services. This presents a unique opportunity for a service-agnostic multimedia aggregator. Most PeCMan efforts up to now have been focused on the distributed aspects of the server architecture. However, for a realistic evaluation of its potential there needs to be an accompanying mobile client application that moves beyond the status of technology preview. With this in mind, the iphone application WakaWaka was developed to study the advantages and pitfalls of integrating with the current PeCMan system. 1 PeCMan is a joint project between IBBT (Interdisciplinary Institute for Broadband Technology) and research groups at Ghent University (UGent), Gent, Belgium and Catholic University of Leuven, Belgium. Cocoa A. High Level File System SIPCore PJSIP File System Interaction Fig. 1. WakaWaka + PeCMan architecture II. ARCHITECTURE Virtual File Resolving SIP Proxy + PeCMan Service Virtual File Systems Currently, PeCMan operates as a SIP [1] service that deeply integrates with the SIP Proxy and Registrar. This allows it to take advantage of the account management that is implemented inside said Registrar. By using an open protocol like SIP, it s easy to set up a dedicated PeCMan installation for a domain. Clients access their virtual file system through SIP messages, requesting descriptions for the virtual file system and passing along updates. Each virtual file system contains a number of file references identified by a URI, which can then be resolved to actual storage locations on demand. Thanks to this structure, reorganizing multimedia and duplicating it on multiple volumes is a very cheap operation. Once a file location is resolved, it will be retrieved using a peer-to-peer connection. The sessions required to set this up are managed by SIP. Some storages can be dedicated multimedia services like Flickr, others might be personal devices. B. Client Considering the targeted server environment (figure 1), the main requirements for our client s architecture are as follows: SIP needs to be abstracted into protocol-agnostic concepts. For the actual implementation of the SIP protocol, we can use the third-party PJSIP library. File System management must account for latency and asyn-

9 Notifier FS Service Virtual File Systems HTTP facilitates integration with other systems. As HTTP often implies a fully centralized server approach, it must be stressed that the revised architectural design doesn t sacrifice any of the existing system s distributed characteristics. Every service or device still serves as a distributed peer, but peers now communicate over a much more reliable protocol. SIP Signaling SIP Proxy Update Notifications HTTP Front-End(s) FS Access Clients + Storage Services File System Interaction FS Access Fig. 2. Revised PeCMan architecture with separated signaling and file system management. SIP is still used for account management and updates, HTTP is used for the client/storage front-end. chronous operation internally, as opposed to exposing it to higher layers of abstraction. This is crucial in creating a pseudolocal browsing experience on the mobile device. [3] Browsing functionality must take advantage of available metadata to provide smart searches. Viewing documents needs to happen in a modular fashion to select the appropriate viewer for a particular distributed resource. For example, YouTube movies open in a dedicated player. Transferring files can happen in both directions: users can retrieve files from storage locations, or the device can become a micro-storage itself in the peer-to-peer environment. III. PROPOSED SERVER ARCHITECTURE The experience of writing a full-featured client application led to a deeper understanding of structural weaknesses in the existing architecture, as well as new insights into how these negative points can be eliminated. While the unmodified PeCMan architecture manages the entire virtual file system traffic using SIP, we propose a separation of signaling and file system operations, as illustrated in figure 2. For user management, peer-to-peer session initiation and notification functionality, the existing SIP layer can be reused. Managing the virtual file system must be done using a more suitable network protocol like HTTP [2]. Besides being completely reliable for arbitrarily large file system exchanges it is a logical choice because of its widespread use, excellent firewall support, compression extensions and more. Since most third-party multimedia services are web-based, an implementation based on IV. PEER-TO-PEER AND AVAILABILITY One major disadvantage of peer-to-peer file exchange is its dependence on simultaneously connected devices. To transfer a document from A to B, both peers need to be online to arrange a session. In a traditional context where users actively send multimedia to others, this doesn t pose a problem. However, the fundamental design of the distributed storage environment implies that even end user devices can be micro-servers that passively await requests for stored multimedia. As such, peer A requesting a document located on peer B has to account for the possibility of B being unavailable. If both A and B are transient devices it s perfectly possible that they are never online at the same time, making a theoretically available resource thoroughly unavailable for a subset of users. To work around this limitation, we introduce a technique called Queue-and-Forward that makes use of an always-on middleman service (QFS). When user A requests a resource from an offline user B, A will notify the QFS that said resource was added to its queue. If B comes online after A went offline, the QFS will detect this and request B s resource in A s name. The transfer succeeds, after which B can go offline once again. As soon as A contacts the QFS to query the status of its queue, the newly available resource will be transferred to A. One important aspect of Queue-and-Forward is that it has no effect on the virtual file system references. This results in the forwarding process having to be repeated every time participating peers aren t simultaneously available. A variant of this technique is Queue-and-Transfer: when a resource located on a transient storage is requested when it s unavailable, the QFS again queues the request but moves it to an always-on storage service permanently once it becomes available. When that happens, the change is reflected in the virtual file system. V. CONCLUSIONS After the necessary architectural improvements and functional refinements, a service-agnostic distributed storage platform becomes an attractive option for its technological capabilities as well as the added value for end users. It is in fact possible to hide the complexities of distributed storage in a well-designed mobile application. REFERENCES [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, Session Initiation Protocol, [2] J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Hypertext Transfer Protocol / HTTP 1.1, [3] A. J. Szameitat, J. Rummel, D. P. Szameitat, A. Sterr, Behavioral and emotional consequences of brief delays in human-computer interaction, International Journal of Human-Computer Studies, Volume 67, Issue 7, pp ,

10 INHOUDSOPGAVE i Inhoudsopgave Lijst van afkortingen v 1 Situering Probleemstelling PeCMan Doelstelling Onderzoek Netwerkproblematiek bij mobiele toestellen Netwerksnelheid Beschikbaarheid Bereikbaarheid Conclusie Studie van protocollen en technologieën UDP / TCP SIP SDP XMPP / Jabber HTTP XML JSON Content Delivery Networks Architectuur van PeCMan Componenten Interactie tussen client en server Ontwerp Vereisten Architectuur van WakaWaka

11 INHOUDSOPGAVE ii Overzicht SIPCore File System WakaWaka Gebuikersinterface Applicatie-icoon Schetsen van scenario s Architectuur van PeCMan Implementatie Ontwikkelingsomgeving SIPCore Onderzoek Overzicht Genereren van de PJSIP-bibliotheek Genereren van de SIPCore-bibliotheek Opmerkingen File System Overzicht Opmerkingen View Overzicht Opmerkingen Browse Overzicht Opmerkingen Transfer Overzicht Opmerkingen PeCMan Evaluatie Testomgeving Prestatie-analyse Werkelijke en waargenomen prestaties Opstartsnelheid Inactiviteit XML-verwerking

12 INHOUDSOPGAVE iii Batterijduur Netwerk-analyse XML-uitwisseling Latentie Datavolume Toetsen aan vooropgestelde doelen Verder werk Caching en persistentie Uitgebreidere metadata Security Voorstel PeCMan-architectuur Hybride SIP / HTTP Probleemstelling Vereisten Keuze van protocollen Architectuur Interactie tussen client en server Compressie Conclusie Metadata Opvragen van metadata Bewerken van metadata Thumbnails Dynamische zoekopdrachten en bestandssystemen Notifications Push Push voor statusberichten Peer-to-Peer: omzeilen van constante persoonlijke bereikbaarheid Probleemstelling Vereisten Push Beperken van Peer-to-Peer Queue-and-Forward Queue-and-Transfer Conclusie Conclusie 89

13 INHOUDSOPGAVE iv A Ontwikkelen voor de iphone en ipod touch 90 A.1 iphone SDK A.2 iphone Simulator A.3 iphone Device A.4 Jailbreaking

14 LIJST VAN AFKORTINGEN v Lijst van afkortingen API Application Programming Interface APN Apple Push Notifications DNS Domain Name System DRM Digital Rights Management EDGE Enhanced Data Rates for GSM Evolution GPL GNU General Public License GPRS General Packet Radio Service GUI Graphical User Interface HSDPA High-Speed Downlink Packet Access HSPA High-Speed Packet Access HSUPA High-Speed Uplink Packet Access HTTP HyperText Transfer Protocol IDE Integrated Development Environment IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 IP Internet Protocol ISP Internet Service Provider LGPL GNU Lesser General Public License LZW Lempel Ziv Welch (algoritme) MTU Maximum Transmission Unit

15 LIJST VAN AFKORTINGEN vi NAT Network Address Translation P2P Peer to Peer RTT Round-Trip Time S3 Simple Storage Service SDK Software Development Kit SDP Session Description Protocol SIP Session Initiation Protocol SSL Secure Sockets Layer TCP Transmission Control Protocol TLS Transport Layer Security UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol UMTS Universal Mobile Telecommunications System URI Uniform Resource Identifier VoIP Voice over IP WWAN Wireless Wide Area Network

16 SITUERING 1 Hoofdstuk 1 Situering 1.1 Probleemstelling Steeds vaker delen mensen persoonlijke gegevens over het Internet: foto s, zelfgemaakte filmpjes, opgenomen muziekfragmenten, favoriete links, enz. De opmars van krachtigere mobiele toestellen zoals de iphone versterkt deze trend alleen maar, wat blijkt uit het succes van diensten als Facebook, YouTube, Vimeo en Flickr. Bestaande diensten bieden echter een zwaar gecentraliseerde ervaring aan die de multimedia van gebruikers in bezit neemt en zo een kunstmatige afhankelijkheid creëert. Bovendien zijn deze sites meestal beperkt in het type gegevens dat ze aanvaarden en hebben ze allemaal een volledig eigen manier van werken. Eindgebruikers moeten dus steeds afzonderlijke stappen ondernemen om al hun materiaal te kunnen bekijken en beheren. Om zulke beperkingen te overkomen en persoonlijke bestanden op een schaalbare en service-onafhankelijke manier te delen werd een aangepaste Peer-to-Peer architectuur ontwikkeld: PeCMan (Personal Content Management). Aangezien een groeiend deel van alle persoonlijke multimedia aangemaakt en gepubliceerd wordt op een mobiel toestel zoals een smartphone, is een gedistribueerd opslagsysteem als PeCMan technisch gezien een zeer aantrekkelijke optie. Voor dagdagelijkse gebruikers is het echter minstens even belangrijk dat ze hun foto s, filmpjes, enz. via een mooie en gebruiksvriendelijke applicatie kunnen delen met de wereld. 1.2 PeCMan PeCMan staat voor Personal Content Management Platform. Het is een project dat verloopt in samenwerking met IBBT en de groepen IBCN en MMLab aan de Universiteit Gent, alsook CUO en Distrinet aan de Katholieke Universiteit Leuven.

17 1.3 Doelstelling 2 In zijn basisvorm bestaat het platform uit een gedistribueerde verzameling van virtuele bestandssystemen, waarvan de werkelijke inhoud verspreid is over het internet. PeCMan verzorgt dus een virtuele laag die persoonlijke gegevens aggregeert tot één conceptueel bestandssysteem, onafhankelijk van de externe services waar de gegevens bewaard worden. In zijn uitgebreidere vorm integreert de centrale PeCMan-functionaliteit ook met externe diensten zoals YouTube en Flickr, om zo een gemeenschappelijke werkwijze aan te bieden voor publicatie en beheer van multimedia. De gebruiker wordt op die manier minder afhankelijk van specifieke diensten, wat de portabiliteit van gegevens aanzienlijk verbetert. Dankzij het virtuele bestandssysteem ligt er in principe geen beperking op het type bestanden die op een PeCMan-volume bijgehouden kunnen worden. Deze aanpak is dus zeer toekomstbestendig, een belangrijke eigenschap gezien het snel veranderende landschap o.a. op vlak van sociale netwerken. Communicatie tussen PeCMan-gebruikers verloopt via SIP, een netwerkprotocol dat populair is voor Voice over IP (VoIP) en instant messaging-toepassingen. De PeCMan-server waarmee gewerkt wordt voor deze masterproef bevat een beperkt prototype van een opslagdienst waarop bestanden gepubliceerd kunnen worden. Voor een uitgebreider overzicht van de architectuur en de werking van PeCMan wordt graag verwezen naar punt 2.3 in dit boek. 1.3 Doelstelling Het doel van deze masterproef is aan te tonen dat het PeCMan-concept bruikbaar is in realistische mobiele scenario s. Hiervoor wordt een iphone-applicatie ontwikkeld die aantoont dat gedistribueerde bestandsopslag een haalbare optie is in de echte wereld. Deze toepassing heet WakaWaka, een kleine knipoog naar het spelletje Pac-Man. Om aan te tonen dat het PeCMan-systeem succesvol kan gebruikt worden via een modern mobiel toestel moet WakaWaka aan enkele voorwaarden voldoen: Er moet efficiënt omgesprongen worden met het netwerk en met de beperkingen van het toestel. Hier gaat het over batterijduur, benodigd dataverkeer, e.d. Waar mogelijk moet de vertraging inherent aan netwerkopslag verborgen worden van de eindgebruiker. Men mag niet overstelpt worden door bezig met... -boodschappen of nutteloze foutmeldingen. De gebruikersinterface moet aantrekkelijk en overzichtelijk zijn. Om WakaWaka te gebruiken moet geen voorkennis nodig zijn buiten een algemene comfortabele houding tegenover technologie. De belangrijkste taken moeten eenvoudig uit te voeren zijn, zonder technische aspecten op te dringen aan de gebruiker.

18 1.3 Doelstelling 3 Naast de basisfunctionaliteit moet er ook sprake zijn van toegevoegde waarde voor de gebruiker. Dergelijke bijkomende functionaliteit moet indien mogelijk de unieke eigenschappen van het PeCMan-platform benutten. Alle functionaliteit moet bruikbaar zijn over alle netwerkverbindingen die beschikbaar zijn op het toestel. Het is dus niet aanvaardbaar om enkel via WiFi te werken. Uiteindelijk hebben de opgesomde eigenschappen tot doel een demonstratie te ondersteunen die interesse opwekt in het PeCMan-ecosysteem. Het resultaat moet bijgevolg een afgewerkte indruk geven.

19 ONDERZOEK 4 Hoofdstuk 2 Onderzoek 2.1 Netwerkproblematiek bij mobiele toestellen Een stuk software op een mobiel toestel leeft in een volledig andere netwerkomgeving dan een doordeweekse PC met een vaste breedbandverbinding. Om een goede ervaring voor de eindgebruiker te garanderen moeten we rekening houden met de beperkingen en eigenaardigheden van deze mobiele habitat. Dit gedeelte bespreekt een aantal struikelblokken waarmee elke mobiele applicatie met netwerkconnectiviteit moet omgaan Netwerksnelheid Tot op heden bezit slechts een klein deel van de verkochte mobiele toestellen draadloos internet via WiFi of 3G (UMTS of HSDPA). Meestal is er helemaal geen sprake van internet-toegang, of slechts via een primitieve browser over GPRS. Deze toestellen kunnen echter bezwaarlijk multimedia-ready genoemd worden, en we vermelden ze verder dus niet meer. In dit boek bespreken we een applicatie voor de iphone en ipod touch, die qua netwerk-ondersteuning representatief zijn voor de nieuwe generatie multimedia-toestellen. gangbare netwerksnelheden die een dergelijk toestel kan ondervinden. Bijgevolg beperken we ons tot de GPRS EDGE UMTS HSDPA WiFi + breedband Download (max) 56kbps 180 kbps 384 kbps 7,2 Mbps 11 Mbps Upload (max) 40kbps 120 kbps 64 kbps 384 kbps 1 Mbps Download (praktijk) 10kbps 50 kbps 200 kbps 1 Mbps 5 Mbps Upload (praktijk) 10kbps 20 kbps 40 kbps 200 kbps 0,5 Mbps Tabel 2.1: Gangbare draadloze netwerkverbindingen en hun snelheid Theoretische netwerksnelheden zijn dikwijls weinig representatief door ruisvorming en signaalverzwakking bij draadloze technologieën. Voor de prestaties van de verbinding in de praktijk neemt men vaak best

20 2.1 Netwerkproblematiek bij mobiele toestellen 5 ongeveer de helft van de theoretische maximumsnelheid als realistisch maximum. Het is echter hoofdzakelijk van belang het grote relatieve verschil tussen de types verbindingen waar te nemen. Een mobiel toestel kan op korte tijd overschakelen naar een verbinding die enorm veel sneller of trager is dan de vorige. 100x 0,2x 1x 4x 20x GPRS EDGE UMTS HSDPA WiFi Figuur 2.1: Relatieve downloadsnelheden (in een realistische omgeving) Gebrek aan connectiviteit De meest problematische netwerkverbinding is de afwezige verbinding. De gebruiker koos ervoor geen mobiel-internetabonnement te nemen, er is geen WiFi-hotspot in de buurt, de netwerkopties zijn uitgeschakeld om batterij te besparen,... Er bestaan talloze redenen voor een gebrek aan connectiviteit op een mobiel toestel. Het resultaat is altijd hetzelfde: een download- en uploadsnelheid van 0 bit/s. Bovendien kan dit dikwijls voorkomen tijdens de uitvoering van een applicatie. Deze problematiek wordt besproken in Bereikbaarheid (2.1.3). GPRS/EDGE GPRS was de eerste wijdverspreide technologie die IP-toegang toeliet over het GSM-netwerk. Ze is ondertussen al achterhaald en dus bijzonder traag (56 KB/s downstream, 40 KB/s upstream). In afwachting van 3G-infrastructuur kozen sommige operatoren ervoor hun bestaande GPRS-netwerk te upgraden naar het zogenaamde EDGE. Dit was een efficiëntieverbetering t.o.v. GPRS die geen volledig nieuwe GSM-apparatuur vereiste. In België is GPRS zowat overal beschikbaar, maar EDGE wordt slechts door enkele operatoren ondersteund en is zelfs volledig afwezig bij Proximus. Waar EDGE actief is op de GSM-mast kan men downstream 180 KB/s en upstream 120 KB/s bereiken. De iphone die gebruikt werd voor de tests in dit thesiswerk maakte gebruik van een abonnement bij Proximus, waardoor EDGE nooit beschikbaar was. Op papier kan men met GPRS gestaag maar zeker surfen, maar in de praktijk is de latentie en effectieve snelheid zo abominabel dat van real-time activiteit en vlotte file exchange geen sprake kan zijn. Bij het

21 2.1 Netwerkproblematiek bij mobiele toestellen 6 gebruiken van een GPRS-verbinding moeten we ons dus beperken tot eenvoudige status-uitwisseling en uitwisselen van multimedia liefst achterwege laten. UMTS/HSPA (3G) De zogenaamde derde-generatienetwerken vereisten nieuwe infrastructuur en nieuwe licenties van de overheid voor het bijhorende draadloos spectrum, waardoor sommige operatoren besloten de kat nog even uit de boom te kijken. Proximus heeft al een vrij uitgebouwd 3G-netwerk, waardoor we in de meeste stedelijke gebieden kunnen testen met sneller 3G-internet. UMTS was de eerste iteratie van de 3G-netwerken, terwijl tegenwoordig HSDPA aan 7,2 Mbps gangbaar is. De upstream-snelheden liggen in verhouding veel lager dan de downstream-snelheden, hoewel die verbeteren als HSUPA (typisch 2 Mbps upstream) actief is. Merk op dat de bereikbare snelheid over het 3G-netwerk ook afhankelijk is van de hardware in het mobiel toestel. Zo ondersteunt de iphone 3G slechts tot 3,6 Mbps HSDPA. Hoewel we opnieuw ver van de theoretische resultaten verwijderd blijven, is 3G in gebruik zeer aanvaardbaar voor een mobiel toestel. Hoewel men soms last kan hebben van latentie op de verbinding, is de gemiddelde snelheid voldoende bruikbaar voor het ontvangen en versturen van multimedia. WiFi In het geval van WiFi is de snelheid vooral beperkt door de achterliggende vaste verbinding, en dan hoofdzakelijk wat upstream-verkeer betreft. De eerste iteratie van de WiFi standaard, b, ondersteunt een theoretische maximum transmissiesnelheid van 11 Mbps. In de praktijk is dit wel minder, maar aangezien de meeste WiFi-routers momenteel al overschakelen op g (54 Mbps) wordt de snelheid toch vooral bepaald door de kabelverbinding. Over het algemeen kunnen we in een typisch gebruikersscenario wel rekenen op 5 Mbps downstream en 1 Mbps upstream. Voor draadloze verbindingen over WiFi kunnen we dus besluiten dat multimediabestanden delen totaal geen probleem is. Veel PC s gebruiken dezelfde WiFi-verbindingen, en we zullen dus eerder beperkt worden door de rekenkracht van het toestel dan door de netwerksnelheid. Latentie Naast de doorvoersnelheid is bij GSM-verbindingen ook de latentie een factor die zich kan laten voelen. Vooral bij het coördineren van de applicatie, waarbij typisch kleine berichten over het netwerk worden gestuurd, kan dit een probleem zijn. Aangezien we in deze masterproef er echter niet naar streven om een real-time applicatie te ontwikkelen zal de latentie in verhouding weinig ongemak veroorzaken. Voor het doorsturen van multimedia is de doorvoersnelheid van groter belang.

22 2.1 Netwerkproblematiek bij mobiele toestellen Beschikbaarheid Een tweede veronderstelling die niet langer geldt in het mobiele landschap is die van constante bereikbaarheid bij het gebruiken van een applicatie die het netwerk aanspreekt. Terwijl we verontwaardigd naar de Internet Service Provider (ISP) bellen als een vaste internetverbinding het opgeeft, is een wegvallende verbinding dagelijkse kost bij mobiel internet. WiFi Hoewel een WiFi-verbinding kwaliteitsvol is, kan ze zeer eenvoudig wegvallen van het ene moment op het andere. Dit kan gebeuren omwille van allerlei redenen, zowel extern als door een actie van de gebruiker: De gebruiker schakelt WiFi uit om batterij te besparen. Door het mobiel toestel fysiek te verplaatsen gaat het buiten bereik van het basisstation. De gebruikstermijn bij een betaalde hotspot is verstreken, waardoor nieuwe verbindingen geweigerd worden. GSM In tegenstelling tot WiFi is internet over het GSM-netwerk zo goed als overal beschikbaar. Toch kunnen we helemaal niet spreken van complete beschikbaarheid, omwille van omstandigheden zoals de volgende: Bij het overschakelen van één GSM-cel naar een andere kan het mobiel internet tijdelijk verbroken worden. Dit gebeurt regelmatig op de trein, in de auto, enz. Hoewel de gebruiker van een mobiele applicatie vaak binnen dezelfde cel blijft, kunnen we daar niet altijd op rekenen. Het type verbinding kan veranderen door overbelasting van de mast, veranderen van cel of aanpassingen door de gebruiker. Het overschakelen van 3G naar GPRS kan bijvoorbeeld problematisch zijn als er een overdracht bezig was die de bandbreedte van 3G vereiste. De verbinding kan volledig wegvallen door de internet-instellingen aan te passen of eenvoudigweg door zich buiten bereik van een GSM-mast te bevinden (bijvoorbeeld als de trein door een tunnel rijdt) Bereikbaarheid Het concept van bereikbaarheid sluit nauw aan bij beschikbaarheid, maar brengt enkele nieuwe subtiele problemen aan het licht. Hoewel er een goede internetverbinding beschikbaar kan zijn, is het mobiel toestel niet noodzakelijk bereikbaar voor de applicatie in kwestie.

23 2.2 Studie van protocollen en technologieën 8 Aangezien alle IP-verkeer gebaseerd is op communicatie tussen IP-adressen is het van cruciaal belang dat het huidige IP-adres van een mobiel toestel ten allen tijde gekend is. Door de fenomenen besproken onder Beschikbaarheid komt het regelmatig voor dat we een ander IP-adres toegekend krijgen. Voor uitgaande communicatie is dat geen probleem, maar voor binnenkomende berichten is het wel degelijk een struikelblok. Bij een IP-adreswijziging is een mobiel toestel tijdelijk onbereikbaar tot alle partijen waarmee gecommuniceerd wordt op de hoogte zijn gebracht van de nieuwe adressering. Protocollen zoals SIP zijn ontworpen om dergelijke wijzigingen op te vangen, maar hoe vaak er ook updates gestuurd worden over het huidige IP-adres zal er steeds een interval zijn waarin andere partijen verouderde informatie hebben over het toestel. Gedurende die periode is men effectief onbereikbaar. Tenslotte moeten we nog vermelden dat een onbeschikbare verbinding uiteraard ook aanleiding geeft tot een onbereikbaar toestel. Dit gebeurt bijna steeds zonder enige vorm van waarschuwing, waardoor de communicatiepartners vaak zelf moeten besluiten dat een ander toestel onbereikbaar is geworden Conclusie De problematiek uit de vorige secties kan samengebracht worden onder één begrip: continuïteit van de netwerkverbinding. Vaste breedbandtoegang zorgt voor een quasi-permanente verbinding op desktop PC s, maar een mobiel toestel moet overleven in een enorm discontinue omgeving. De nood aan het opvangen van deze discontinuïteiten is groot, want het is de enige manier om een vlotte en ononderbroken ervaring te bieden aan gebruikers van mobiele applicaties. Naarmate men technologische vooruitgang boekt zullen sommige van de besproken situaties verdwijnen, maar 100% bereikbaarheid is voorlopig nog toekomstmuziek. Zuinig omspringen met de batterij is een belangrijke reden voor het voortbestaan van deze problematiek. Een gewaarschuwd man is er twee waard, dus een goede kennis van de pijnpunten van mobiele netwerken is cruciaal om ons te wapenen tegen netwerkproblemen. 2.2 Studie van protocollen en technologieën UDP / TCP De netwerkprotocollen die verder in dit onderdeel besproken worden bevinden zich stuk voor stuk op de applicatielaag van het netwerk, maar het is belangrijk om aan te stippen dat de keuze in de transportlaag, voor zover er een keuze is, eveneens een grote invloed heeft. UDP, of User Datagram Protocol [1], is in feite niet meer dan een beperkte wrapper rond het standaard IP-protocol op de netwerklaag. Het stuurt een pakket van A naar B zonder enige garantie voor het

24 2.2 Studie van protocollen en technologieën 9 afleveren ervan en zonder terughoudendheid te vertonen bij netwerkcongestie. Bovendien garandeert UDP geen volgorde van ontvangst of hersamenstelling van gefragmenteerde pakketten. Dit gebrek aan betrouwbaarheid heeft echter één aanzienlijk voordeel: pakketten kunnen sneller tussen eindpunten reizen. TCP, of Transmission Control Protocol [2], is de tegenhanger van UDP die als hoofddoel heeft betrouwbaarheid aan te bieden bovenop de onbetrouwbare IP-laag. Dit transportprotocol bevestigt de ontvangst van pakketten, garandeert dat de ontvangen volgorde gelijk is aan de verstuurde volgorde en past zich aan als het netwerk overbelast is om zo pakketverlies te verminderen. TCP neemt het ook op zich om gegevens van de applicatielaag te fragmenteren en bij ontvangst opnieuw samen te stellen in de juiste volgorde. Deze bijkomende eigenschappen kunnen echter zorgen voor een grotere latentie dan bij UDP. In de praktijk zullen we enkel voor SIP de keuze hebben tussen UDP of TCP, aangezien alle andere gebruikte protocollen ontworpen zijn bovenop TCP-transport. SIP (hierna besproken) biedt deze mogelijkheid aan omdat het als signaleringsprotocol de betrouwbaarheid van TCP in mindere mate nodig heeft dan een protocol dat bestemd is voor bestandsoverdrachten. PeCMan gebruikt SIP voor de regelende communicatie tussen peers. Aangezien we voor dit soort berichten meestal kleine pakketten versturen die vooral snel moeten aankomen bij de ontvanger, is het vermoedelijk beter om voor UDP te kiezen. SIP zorgt immers zelf voor wederzijdse bevestiging van ontvangst, regelt het opnieuw verzenden van verloren gegane berichten, enz. Het voegt dus de nodige betrouwbaarheid toe op applicatieniveau, ondanks het gebrek aan afleveringsgaranties bij UDP-transport. De andere soorten communicatie binnen PeCMan werken meestal met grotere blokken gegevens. Ze vereisen een voorspelbare en betrouwbare overdracht en kunnen dus gebruikmaken van de flow control van TCP om problemen met veranderende netwerkomstandigheden te voorkomen. Hieronder valt onder meer het overzetten van bestanden tussen eindgebruikers. Voor dit soort transacties moeten we duidelijk werken met het robuustere TCP, wat over het algemeen vanzelf zal gebeuren als we gebruik maken van standaardprotocollen die voor bestandsoverdracht werden ontworpen SIP Inleiding Het centrale protocol binnen de huidige PeCMan-architectuur is SIP, of Session Initiation Protocol [3]. Zoals de naam doet vermoeden is het hoofddoel ervan verschillende IP-eindpunten met mekaar te doen communiceren zodat ze een onderlinge sessie kunnen opzetten. SIP wordt zeer dikwijls gebruikt als basis voor internettelefonietoepassingen, maar kan dienen voor eender welk systeem dat gebruikers moet verbinden zonder dat beiden van het begin af aan mekaars IP-locatie kennen. PeCMan valt duidelijk onder deze noemer, en maakt gebruik van SIP als basisprotocol om de

25 2.2 Studie van protocollen en technologieën 10 diverse diensten en eindgebruikers met mekaar in contact te brengen via hun SIP-accounts op de centrale PeCMan-server. Naast de basisfunctionaliteit voor adressering en opzetten van sessies bestaan er ook uitbreidingen op SIP die het mogelijk maken om toestandswijzigingen tussen gebruikers uit te wisselen. Deze extensies laten toe een veel nuttiger netwerk te bouwen op basis van SIP. Netwerk Een typisch SIP-netwerk bestaat uit de volgende logische componenten, die vaak geïmplementeerd zijn op dezelfde fysieke locatie: User Agents: de eindgebruikers (dit kunnen ook diensten zijn) binnen het netwerk die onderling willen communiceren via SIP. In het geval van PeCMan vallen hieronder de clients, zoals degene die ontwikkeld werd voor deze masterproef, en de services die instaan voor opslag van bestanden en beheer van bestandssystemen. Registrar: deze servercomponent ontvangt REGISTER-berichten (zie verder) en slaat de IP-locatie van user agents op in de zogenaamde location service, wat typisch een interne databank is. Dit gebeurt voor het domein waarvoor de registrar verantwoordelijk is. Proxies: proxy servers zorgen voor het ontvangen en verzenden van berichten tussen clients en registrars als de clients niet rechtstreeks op de hoogte zijn van de IP-locatie van de registrar. Meestal dient een proxy server dus voor de routering van berichten, maar ze kan ook gebruikt worden om sommige verzoeken te weigeren of te wijzigen. Redirect servers: dit zijn een specifieke user agents die enkel dienen om een SIP-verzoek voor een gegeven gebruiker te verwijzen naar een stel alternatieven. Transacties, berichten en dialogen SIP heeft een meerlagig ontwerp, waarbij de eigenlijke functionaliteit (het versturen van berichten) zich bevindt bovenop een transactielaag. Deze laag ligt bovenop de transportlaag (waar typisch via UDP gewerkt wordt) en zorgt voor het versturen van SIP-berichten en antwoorden op binnenkomende verzoeken. Er wordt een eigen vorm van retransmissies en timeouts voorzien, wat met enige verbeelding kan gezien worden als een beperkte vorm van TCP-functionaliteit. Onder een transactie verstaat SIP de uitwisseling tussen een User Agent Client (UAC) en een User Agent Server (UAS) van een request en alle bijhorende responses. Een dergelijke response mag echter niet verward worden met een request in de andere richting, wat ons tot bij het concept van dialogen brengt.

26 2.2 Studie van protocollen en technologieën 11 Een SIP-dialoog stelt een (tijdelijke) persistente verbinding voor tussen twee user agents en vormt een unieke context waarin SIP-berichten moeten geïnterpreteerd worden. Elke dialoog heeft een unieke identificatiecode die in de Call-ID-header wordt bijgehouden. Binnen de dialoog wordt een sequentienummer (in de CSeq-header) aan elk bericht toegekend om de correcte volgorde tussen berichten te kunnen afleiden. Het formaat van SIP-berichten is qua vorm zeer gelijkaardig aan HTTP [8]. Ook de numerieke codes die in antwoorden op SIP-requests kunnen gegeven worden, zijn gebaseerd op de HTTP-specificatie (ze overlappen, maar zijn niet volledig hetzelfde). Eén bericht kan, in tegenstelling tot bij HTTP, beantwoord worden met meerdere responses. Er zijn 6 categorieën van antwoordcodes. Provisional 1xx: dit zijn de voorlopige antwoordcodes. Bij een dergelijk antwoord kan later nog een 1xx of een definitief antwoord van een ander type verwacht worden. Deze codes worden gebruikt als de aanvraag enige tijd in beslag neemt. Successful 2xx: deze categorie bevat in feite enkel de code 200, die aangeeft dat de aanvraag met succes afgehandeld werd. Redirection 3xx: dergelijke antwoorden worden gegeven als het verzoek niet onmiddellijk afgehandeld kan worden, maar naar (een) andere SIP-entiteit(en) verwezen moet worden om het te kunnen verwerken. Code 301 geeft bijvoorbeeld aan dat de gebruiker van een SIP-adres permanent overgeschakeld is naar een ander adres. Request Failure 4xx: deze codes geven aan dat de originele aanvraag niet kan afgehandeld worden bij de aangesproken server. Bij een dergelijk antwoord moet de verzender ofwel een aangepast bericht sturen, ofwel hetzelfde bericht versturen naar een andere server. Server Failure 5xx: een antwoord van deze categorie betekent dat de aanvraag niet noodzakelijk verkeerd is, maar dat de server een fout tegenkwam waardoor het verzoek niet kon afgehandeld worden. Global Failures 6xx: deze categorie wordt gebruikt wanneer het bericht de bestemmeling effectief heeft bereikt, maar daar werd afgewezen. Adressering en registratie (REGISTER) Een SIP-entiteit wordt over het algemeen voorgesteld door een Uniform Resource Identifier (URI). Er zijn enkele verschillende types URI die dikwijls voorkomen bij de communicatie. Publieke URI s voor gebruikers: deze nemen de vorm sip:user@example.com aan en worden meegegeven aan de eindgebruikers. Ze zijn echter niet bruikbaar om onmiddellijk een onderlinge verbinding op te zetten.

27 2.2 Studie van protocollen en technologieën 12 Contact URI s: deze zijn van de vorm en duiden een werkelijke locatie aan die (eventueel via een DNS-opzoeking) rechtstreeks kan gebruikt worden voor het opzetten van een verbinding, zonder tussenkomst van een andere SIP-component. Het host-gedeelte kan een IP-adres of een opzoekbare domeinnaam zijn. De poort specifieert waar de User Agent Server openstaat voor communicatie. Server URI s: dit zijn eenvoudige aanduidingen van de IP-locatie van een SIP-servercomponent. Een voorbeeld is sip:pecman-proxy.ugent.be. Het is nuttig op te merken dat SIP-URI s bijkomende parameters ondersteunen als volgt: sip:user@example.com;device=iphone;param=value Deze notatie wordt binnen PeCMan gebruikt om onderscheid te maken tussen verschillende toestellen van dezelfde gebruiker. De vraag is nu uiteraard hoe een user agent de contact-uri kan verkrijgen voor een publieke URI. Hier komen de registrar en de proxy in het plaatje. Eerst en vooral zal een client bij het opstarten zijn registrar contacteren. Dit gebeurt typisch via de proxy, die steeds op de hoogte is van ofwel een gepaste registrar voor het domein ofwel van een andere proxy die de registrar kan bereiken. De client stuurt een REGISTER-bericht naar de registrar met de huidige IP-locatie van de gebruiker in kwestie. De server slaat deze gegevens op in de location service, waar vervolgens het verband tussen publieke en locatie-uri gekend is. Een andere gebruiker kan nu via een proxy te weten komen waar hij of zij een bepaalde publieke URI kan contacteren. Deze informatie kan uit de location service opgevraagd worden. Zodra beide user agents mekaar kunnen contacteren kunnen ze ook een rechtstreekse sessie opzetten. Beheer van sessies (INVITE, ACK, BYE) Eens gebruikers zich aangemeld hebben bij de registrar kunnen alle user agents de contactadressen van andere gebruikers bekomen, waarmee er een peer-to-peer sessie kan opgezet worden. Merk op dat dit opnieuw een conceptuele dialoog is, en geen verbinding in de transportlaag zoals bij TCP. Een SIP-sessie wordt tot stand gebracht m.b.v. een INVITE-bericht. Hiermee wordt een dialoog aangemaakt. Zoals bij andere SIP-berichten ontvangt de aanvrager vervolgens een variabel aantal 1xx-responses (of geen) vooraleer een definitief antwoord te krijgen. Bij een niet-2xx antwoord zal de aanvrager moeten kijken wat er kan foutgegaan zijn. Bij een 200 OK-antwoord vindt er nog een extra stap plaats die niet voorkomt bij andere berichten, namelijk het versturen van een ACK-bericht als bevestiging. Dit noemt men de 3-way handshake, een concept dat ook bij TCP gebruikt wordt.

28 2.2 Studie van protocollen en technologieën 13 Om de dialoog uiteindelijk af te sluiten wordt er een BYE-bericht verzonden. Dit verzoek kan door beide deelnemers in de sessie verstuurd worden. Publiceren en detecteren van toestandswijzigingen (SUBSCRIBE, NOTIFY, PUBLISH) SIP in zijn basisvorm dient enkel om sessies op te zetten tussen verschillende gebruikers. Omdat het protocol ook gebruikt wordt voor o.a. instant messaging is het nuttig de toestand van sommige eindgebruikers te kunnen meedelen aan andere gebruikers, bijvoorbeeld om te weten of iemand online is. Om dergelijke toepassingen toe te laten ontwikkelde men voor het SIP-protocol enkele extensies ([4], [6]). Eerst en vooral is er het pakket voor Event Notification [4] dat ontworpen werd om eenvoudige gebeurtenissen mee te delen aan geïnteresseerde partijen. Zo zou men bijvoorbeeld kunnen aangeven dat één bepaald toestel momenteel het actieve toestel is, wat van belang kan zijn voor andere clients die willen communiceren met de gebruiker [5]. Andere mogelijkheden zijn o.a. het eerder vermelde instant messaging, het aantal nieuwe voic s, enz. Het uitwisselen van deze informatie gebeurt via SUBSCRIBE- en NOTIFY-berichten. Enerzijds is er de subscriber, die zich expliciet inschrijft voor een bepaald stuk informatie bij een gebruiker of service. Zodra de gegevenstoestand in kwestie wijzigt zal de notifier een NOTIFY-bericht verzenden naar elke subscriber. Naast de uitbreiding voor event subscriptions is het bij sommige soorten informatie ook nodig om vanaf een User Agent te kunnen meedelen dat de toestand gewijzigd is. Teneinde dit toe te laten introduceerde men een PUBLISH-bericht [6]. Dit is een zeer eenvoudig bericht omdat het slechts een eenmalige communicatie is en dus geen SIP-dialoog vereist. Het bericht specifieert de nieuwe toestand van het meegegeven event package, waarna de notifier op basis van die nieuwe informatie zoals gewoonlijk de nodige NOTIFY-berichten kan rondsturen. In PeCMan worden SIP Events gebruikt als basis voor het virtuele bestandssysteem. Alle wijzigingen worden via NOTIFY-berichten meegedeeld aan de clients die zich ingeschreven hebben. Om nieuwe bestanden en mappen op het bestandssysteem te zetten wordt gewerkt via een PUBLISH-bericht SDP SDP, of Session Description Protocol, wordt dikwijls gebruikt in combinatie met SIP in internettelefonietoepassingen. Derhalve is het een goed idee om te evalueren of het protocol een nuttige rol kan spelen binnen PeCMan. Bij nadere inspectie van [7] blijkt echter dat een SDP-onderhandeling specifiek ontworpen is voor real-time streaming media, terwijl we voor PeCMan willekeurige soorten bestanden verzenden tussen de verschil-

29 2.2 Studie van protocollen en technologieën 14 lende peers. Voor internettelefonie wisselt men continue audiostromen uit, waarvoor SDP ontworpen is met specificaties voor bandbreedte, tijdsinformatie, enz. In principe zouden we het protocol kunnen misbruiken om een generieke bestandsoverdracht op te zetten voor PeCMan, maar dit heeft weinig nut aangezien dat ook mogelijk is met enkel SIP-berichten. We besluiten dus dat SDP geen plaats heeft in de basisarchitectuur van PeCMan XMPP / Jabber XMPP, of Extensible Messaging and Presence Protocol [10], is een gestandaardiseerd protocol dat zijn oorsprong vindt in de Jabber instant messaging service. In tegenstelling tot SIP is het dus ontwikkeld met instant messaging in gedachte en niet als toevoeging achteraf. Een prominente gebruiker van XMPP is Google Talk. XMPP en SIP kunnen gebruikt worden voor gelijkaardige doeleinden en men kan zich dus terecht afvragen of XMPP een geschiktere keuze zou zijn voor PeCMan. De keuze tussen SIP en XMPP is er één die van tal van factoren afhangt. We sommen enkele belangrijke verschillen op die een dergelijke beslissing kunnen beïnvloeden. SIP is ontworpen om via UDP-transport te werken terwijl XMPP-implementaties enkel TCPtransport gebruiken. Enerzijds kunnen SIP-berichten dus sneller verstuurd worden, anderzijds is XMPP betrouwbaarder en gedraagt het zich beter bij netwerkoverbelasting. XMPP gebruikt XML streams die conceptueel enigszins lijken op dialogen bij SIP, maar een TCPconnectie openhouden tot de stream afgesloten wordt. SIP daarentegen gebruikt afzonderlijke transacties. Aangezien XMPP ontwikkeld werd op basis van een instant messaging-protocol, zou het eenvoudiger moeten zijn om dergelijke functionaliteit toe te voegen dan wanneer men SIP gebruikt. XMPP-berichten worden voorgesteld in XML, wat zowel een voordeel als een nadeel kan zijn. Aan de ene kant is dit een leesbaar en handig formaat, aan de andere kant is het moeilijker om volledig eigen gegevens in te bedden. XMPP biedt een optie aan om HTTP als transport te gebruiken via zogenaamde HTTP Binding, waarbij een HTTP connectie wordt gebruikt om de XML-stream uit te wisselen. Dit zorgt voor enige overhead, maar heeft wel als voordeel dat het door praktisch elke firewall kan. De UDP-pakketten van SIP kunnen problemen ondervinden bij het tegenkomen van een firewall. Terwijl de meeste beschikbare SIP-implementaties gebruikt worden voor internettelefonie, worden XMPP-implementaties veelal ingezet voor overdracht van tekstuele gegevens. Aangezien PeC- Man hoofdzakelijk werkt met structurele gegevens en zich niet bezighoudt met het uitwisselen van multimedia-sessies, kan men argumenteren dat XMPP een meer gepast protocol is.

30 2.2 Studie van protocollen en technologieën 15 Security was duidelijk een belangrijke overweging bij het opstellen van de XMPP-standaard. Hoewel SIP ook beveiligd kan worden via Transport Layer Security (TLS), behandelt de XMPP-specificatie authentificatie en beveiliging in veel meer detail. Uiteindelijk is een overwegende factor dat het bestaande PeCMan-systeem reeds een SIP-implementatie bevat. Een eventuele overgang naar XMPP moet gestaafd worden door voldoende bijkomende voordelen, zoals het toevoegen van instant messaging HTTP HTTP, of HyperText Transfer Protocol [8], wordt niet gebruikt in de originele PeCMan-architectuur, maar komt later in hoofdstuk 6 aan bod. Dit protocol is waarschijnlijk het bekendste netwerkprotocol van tegenwoordig, aangezien het de basis vormt van het World Wide Web dat we dagelijks gebruiken. Technisch gezien is HTTP zeer eenvoudig, een eigenschap die het een fundamenteel protocol heeft gemaakt. Over TCP wordt een HTTP-bericht gestuurd naar een HTTP-server die standaard op poort 80 luistert. Dit bericht bevat net zoals SIP naast een aantal headers ook een message body dat willekeurige gegevens kan bevatten. Het bericht begint met een request-line die aangeeft welke HTTP-methode gebruikt wordt. GET: de meest gebruikte methode die in het geval van een succesvolle afhandeling (200 OK) in de message body van het antwoord de gegevens meestuurt die overeenkomen met de URI in de originele aanvraag. POST: de tweede methode die praktisch overal op het WWW ondersteund wordt. Hierbij wordt in de message body van de aanvraag een willekeurig blok gegevens meegegeven, wat in de server vervolgens geïnterpreteerd wordt in functie van de aangesproken URI. Deze methode wordt gebruikt wanneer een client een aanzienlijke hoeveelheid gegevens naar de server moet versturen, bijvoorbeeld wanneer men een bijlage toevoegt op een webmail-dienst. PUT, DELETE: deze methodes geven aan dat de gegevens horend bij de URI in het verzoek vervangen moeten worden door de gegevens in de message body (bij PUT), of verwijderd moeten worden (bij DELETE). OPTIONS, HEAD, TRACE: minder gebruikte methodes die respectievelijk de mogelijkheden van een server opvragen, enkel de headers van een equivalent GET-antwoord terugsturen (dus zonder message body), en het volledige HTTP-bericht in de message body terugsturen voor diagnostische doeleinden.

31 2.2 Studie van protocollen en technologieën 16 De antwoorden op een HTTP-aanvraag bevatten net zoals SIP numerieke codes die aangeven of er een fout is opgetreden. De categorieën zijn nu 1xx, 2xx, 3xx, 4xx en 5xx, met een gelijkaardige semantiek. De gelijkenis is niet toevallig, het SIP-formaat werd geïnspireerd door HTTP XML XML, of Extensible Markup Language [9], is een presentatieformaat met een zeer specifieke syntax die geen enkele semantiek toekent. Omdat XML zich niet bezighoudt met betekenis maar enkel met het weergeven van gestructureerde gegevens, is het zeer populair als formaat voor opslag en uitwisseling van tekstuele data. De syntax is gebaseerd op de tag-structuur van HTML. Dit maakt XML-documenten zeer leesbaar voor mensen en toch makkelijk verwerkbaar voor computers. Deze notatie veroorzaakt soms wel een ietwat overmatige hoeveelheid tekst voor zelfs vrij eenvoudige structuren. Fragment 2.1: Een voorbeeld van een welgevormde XML-structuur <? xml version ="1.0" encoding =" UTF -8"? > <element > <sub attribute =" value "> < example /> </sub > </ element > De eigenlijke elementnamen zijn vrij te kiezen en worden optioneel vastgelegd in een XML-schema. De syntax van XML is strikt maar laat toch een enorme flexibiliteit toe. In PeCMan wordt het als presentatieformaat voor alle communicatie met het bestandssysteem gebruikt. Zeer veel systemen (inclusief de huidige implementatie van PeCMan) gebruiken geen strikt geldige vorm van XML omdat de XML-proloog (<?xml...?>) vaak ontbreekt JSON JSON, of JavaScript Object Notation [11], is een presentatieformaat dat zijn opmars is beginnen maken met de opkomst van geavanceerdere web-applicaties die dynamisch de server aanspreken via JavaScript (ECMAScript [12]). Zeer dikwijls wordt daarvoor nog steeds XML als presentatieformaat gebruikt, maar het parsen van XML-gegevens heeft twee grote nadelen. Ten eerste is het omzetten naar traditionele objecten een vervelende klus, ten tweede kan het verwerken van grote XML-bestanden enige tijd in beslag nemen. Om deze redenen maakt men steeds meer gebruik van JSON. Zoals de naam doet vermoeden is het formaat rechtstreeks gebaseerd op de schrijfwijze van arrays, maps, strings en getallen in de JavaScriptprogrammeertaal. Het is echter volledig onafhankelijk van de taal en kan in tal van omgevingen gebruikt

32 2.2 Studie van protocollen en technologieën 17 worden. Voor webapplicaties heeft de JavaScript-basis grote performantievoordelen, en het vereist minder programmeerwerk. Ook buiten webapplicaties vindt JSON echter ingang, omdat het een zeer eenvoudig formaat is dat minder onnodige duplicatie bevat dan XML, en makkelijk interpreteerbaar is aangezien zowat elke programmeertaal een efficiënte implementatie aanbiedt van de gebruikte basisstructuren. Fragment 2.2: Een voorbeeld van een JSON-structuur { } " element ": [ { " type ": " sub ", " attribute ": " value " } ] JSON is dus nog steeds goed leesbaar voor mensen, hoewel het iets minder gestructureerd kan overkomen dan XML. Over het algemeen vormt JSON een mooiere structuur als de structuur veel lijkt op key / value maps. XML geeft dan weer beter hiërarchische structuur weer. De keuze tussen de twee is dus zwaar afhankelijk van de toepassing Content Delivery Networks Tenslotte bespreken we nog kort het concept van Content Delivery Networks (of Content Distribution Networks), niet omwille van een specifieke technologie maar eerder omdat ze een mooie illustratie vormen van geografische distributie zonder dit bloot te stellen aan de client. CDN s bieden een centraal aanspreekpunt aan voor het afhalen van bepaalde resources, maar in de onderliggende communicatie wordt gekozen voor de meest gepaste werkelijke server die de aanvraag moet afhandelen. Dit gebeurt echter zonder bijkomende interactie met de client, waardoor betere schaalbaarheid niet ten koste gaat van de eenvoud voor de client. Deze aanpak staat in contrast met peer-to-peer protocollen zoals BitTorrent, waarbij elke client expliciet op de hoogte is van elke peer met een stuk data. Beide aanpakken hebben hun toepassingen, maar bij het aanbieden van een dienst aan een groot aantal eindgebruikers is het dikwijls van groot belang de complexiteit te verbergen om zo de betrouwbaarheid van de gehele dienst te verhogen. Een goed voorbeeld is de Amazon Simple Storage Service (S3), die een massaal gedistribueerd opslagsysteem aanbiedt, maar toch een eenvoudig HTTP-gebaseerd communicatieprotocol gebruikt met een centraal aanspreekpunt. Hieruit kunnen we een belangrijke les trekken: gedistribueerde systemen worden veel nuttiger zodra het gedistribueerde aspect geen bijkomende interactie met de eindgebruiker vereist.

33 2.3 Architectuur van PeCMan Architectuur van PeCMan We bespreken de architectuur van de PeCMan-server in deze masterproef tot op het subsysteemniveau, aangezien men met een volledig gedetailleerde klassenstructuur weinig nieuw inzicht verwerft in de interactie tussen client en server. Voor meer details over de implementatie van de SIP-server en voor een behandeling van de bestaande PeCMan-architectuur tot op klasseniveau verwijzen we naar [13] en [14]. Eerst en vooral volgt er een overzicht van de aanwezige componenten in het bestaande systeem, dan gaan we over tot een bespreking van hoe een client communiceert met de server in een aantal veelvoorkomende scenario s. Clients Storage Services P2P bestandsoverdracht Bestandsreferenties opzoeken Interactie met bestandssysteem SIP Proxy + FS Service virtuele bestandssystemen Componenten SIP Proxy, SIP Registrar Deze subsystemen zijn implementaties van de standaard SIP-entiteiten zoals ze eerder beschreven werden. De proxy is het aanspreekpunt voor praktisch alle verkeer binnen PeCMan, en verwijst aanmeldende gebruikers naar de registrar. Deze componenten werden oorspronkelijk ontwikkeld in het kader van [13], en ze werden dus niet specifiek voor PeCMan ontworpen. Dit is echter niet nodig, aangezien SIPcommunicatie willekeurige gegevens kan meedragen.

34 2.3 Architectuur van PeCMan 19 Presentity Manager Dit is een subsysteem dat geïmplementeerd werd als een onderdeel van de SIP Proxy. Het staat in voor het beheer van Event-informatie, wat neerkomt op het behandelen van SUBSCRIBE-, NOTIFY- en PUBLISH-verkeer van en naar de proxy. Deze component kan werken met willekeurige soorten Event Packages, een term die in de SIP-specificatie [5] geïntroduceerd werd om een onderscheid te kunnen maken tussen soorten toestandswijzigingen. Voor PeCMan-communicatie wordt het filesystem event package gereserveerd. De Presentity Manager zorgt ervoor dat alle ingeschreven user agents een NOTIFY-bericht ontvangen wanneer het bestandssysteem waarop ze zijn ingeschreven verandert. File System Service Conceptueel is dit een dienst die geregistreerd is bij de centrale PeCMan SIP-registrar en -proxy. Het is het subsysteem dat werkelijk instaat voor het beheer van virtuele bestandssystemen. Dat omvat het verwerken van wijzigingen zoals aangemaakte mappen en bestanden, het wegschrijven naar XML als persistente voorstelling, controleren van toegangsrechten, enz. Hoe deze interactie juist verloopt wordt verder beschreven (zie 2.3.2). Momenteel is deze service geïmplementeerd als een intern subsysteem van de proxy, waardoor we dus niet echt kunnen spreken van een volledig afgescheiden dienst. Bij de interactie met de client is dit niet merkbaar, dus dit implementatiedetail heeft weinig effect op de applicatie ontwikkeld voor deze masterproef. Storage Service Het Storage-subsysteem is een proof-of-concept van een PeCMan-dienst waarop een eindgebruiker bestanden kan opslaan. Merk op dat het hier dus gaat om de effectieve opslag van gegevens en niet om het virtueel linken van een bestand. Dit laatste is het domein van de File System Service. Storage-diensten in PeCMan bieden gedistribueerde opslagcapaciteit aan terwijl de File System Service het bestandssysteem coördineert en verwijst naar de specifieke services voor de gegevensinhoud. In het systeem waar deze masterproef zich op baseert is dit enkel een testversie, maar in een latere fase kan PeCMan in principe allerlei diensten zoals YouTube, Facebook en Flickr ondersteunen. Het is zelfs mogelijk om een mobiel toestel in te stellen als opslagdienst. Net zoals de File System Service sluit de huidige implementatie van de Storage zeer nauw aan bij de SIP-proxy, en zijn ze dus enkel conceptueel afgescheiden subsystemen. Opnieuw heeft dit weinig invloed op de communicatie naar de client toe.

35 2.3 Architectuur van PeCMan 20 Clients Dit zijn uiteraard de PeCMan-clients van eindgebruikers, zoals WakaWaka. principe dezelfde basisprotocollen voor communicatie met de PeCMan-proxy. Alle clients gebruiken in Interactie tussen client en server In dit gedeelte bespreken we de berichten die tussen een PeCMan-client en de PeCMan-servers uitgewisseld worden. Voor de eenvoud beschouwen we de serverzijde hier als één discrete server waarmee gecommuniceerd wordt. In het bestaande systeem sturen client en server alles over SIP, met een zelfgedefinieerd XML-formaat om de operaties te beschrijven. Inloggen en uitloggen Het in- en uitlogproces bij PeCMan is identiek aan dat van andere SIP-oplossingen. Om in te loggen stuurt de client een REGISTER-bericht naar de server met een tijdsinterval dat aangeeft hoe lang de meegegeven informatie geldig is. Binnen dat interval moet de client een nieuw dergelijk bericht sturen, of de server zal er van uitgaan dat de client niet langer beschikbaar is. De registratie is gelukt zodra de client een 200 OK-antwoord ontvangt van de server. Fragment 2.3: REGISTER-bericht bij inloggen REGISTER sip : thesis. test SIP /2.0 Via : SIP /2.0/ UDP :6060; rport ; branch = z9hg4bkpja98fhrbscd KlxaruF9AiawAidbcfYtUP Route : <sip : :4000; lr > Max - Forwards : 70 From : <sip : user@thesis.test >; tag =6 AvHorJecdVWjX0LPIjbyZF.62 H7u To: <sip : user@thesis.test > Call -ID: l2nk0lep94vsxhjbjvdc1lk0eqns. j2l CSeq : REGISTER Contact : <sip : user@ :6060 >; device = phone Expires : 60 Content - Length : 0 Om uit te loggen wordt dezelfde REGISTER-methode gebruikt, maar met een waarde 0 voor de Expiresheader. Deze waarde wordt door de server geïnterpreteerd als het afsluiten van de registratie. Merk de parameter device=phone op bij het contactadres. Deze parameter wordt in de server gebruikt om onderscheid te maken tussen toestellen van dezelfde gebruiker.

36 2.3 Architectuur van PeCMan 21 Opvragen van een bestandssysteem Voor het opvragen van een bestandssysteem stuurt de client een SUBSCRIBE-bericht naar de server om zich in te schrijven voor wijzigingen. De belangrijkste componenten van dit bericht zijn de volgende: De target URI in de request line, Dit is het publieke adres van de File System Service. Alle verzoeken voor het werken met bestandssystemen gaan naar deze service. De URI in de From-header, geeft de subscriber aan, de gebruiker die zich inschrijft op het bestandssysteem. De URI in de To-header, geeft aan op welk bestandssysteem men zich inschrijft. Wanneer men zich inschrijft voor het persoonlijk bestandssysteem zijn de waarden voor From en To gelijk. De Event-header beschrijft het type gebeurtenissen waarop men zich wenst in te schrijven: filesystem. Er wordt ook een unieke identifier meegegeven die gebruikt wordt om op de client de inschrijving terug te vinden. Deze parameter wordt identiek teruggestuurd in antwoorden. De Accept-header deelt mee wat voor type er verwacht wordt voor de message body van terugkomende NOTIFY-berichten. Dit is weergegeven in een MIME-type formaat, in het geval van PeCMan wordt application/filesystem+xml gebruikt. Fragment 2.4: SUBSCRIBE-bericht voor het aanvragen van een bestandssysteem SUBSCRIBE sip : pecmanfilesystems : proxy@thesis. test :5060 SIP /2.0 Via : SIP /2.0/ UDP :6060; rport ; branch = z9hg4bkpjkinxt0rwt S9vhvguHQ5nc5n0guz3ICra Max - Forwards : 70 From : sip : user@thesis. test ; tag =upq - epijnmfinhdfdah - XPTPUVSZWcZG To: sip : fsowner@thesis. test Contact : <sip : user@ :6060 >; device = simulator Call -ID: 6 nm3wgih1mjo2utcgzmtknnefzbjmfsq CSeq : 1157 SUBSCRIBE Route : <sip : :4000; lr > Event : filesystem ;id =7 jppuwixhu5dkkji7nn53xrzszd.- hg9 Expires : 60 Accept : application / filesystem + xml Allow - Events : presence, refer, filesystem Content - Length : 0 Op dit bericht stuurt de server vervolgens een antwoord. Dit kan een foutcode zijn als de inschrijving gefaald is en er dus geen verdere berichten meer verwacht moeten worden. Als de inschrijving wel lukt

37 2.3 Architectuur van PeCMan 22 stuurt de server een 200 OK-antwoord terug. In dat geval kan de client minstens één NOTIFY-bericht verwachten voor de inschrijving, en eventueel nog bijkomende berichten nadien als het bestandssysteem aangepast wordt. De belangrijkste elementen van dergelijke NOTIFY-berichten (zie fragment 2.5) zijn de volgende: De From- en To-header, die nu het omgekeerde zijn van het bijhorende SUBSCRIBE-bericht. Merk op dat de File System Service niet meer vermeld wordt in het bericht. De Subscription-State-header heeft een waarde van active, pending of terminated. Bij een actieve inschrijving is alles in orde en zit in de message body de informatie horend bij de inschrijving. De message body bevat nu gegevens van het type application/filesystem+xml. Dit is een formaat eigen aan PeCMan, en beschrijft een virtueel bestandssysteem. Het heeft altijd <PeCMan> rootelement, waarin een geneste hiërarchie van mappen en bestanden staat. Mappen worden gedefinieerd m.b.v. het dir-element, bestanden door een file-element. In de huidige implementatie hebben beide structuren dezelfde attributen. Het name-attribuut bevat de naam van het bestand of de map. Het path-attribuut definieert een URI waarop de inhoud van het bestand gevonden kan worden. Het schema geeft aan op welke service het zich bevindt, het resourcegedeelte vormt een identificatie voor die specifieke dienst. In het voorbeeld bevindt het bestand zich op de Storage Service. Hoewel mappen ook een path-attribuut bevatten wordt dit in de praktijk nergens voor gebruikt en staat het dikwijls op blanco of null. Het size-attribuut bevat de grootte van de inhoud van het bestand in bytes. Aangezien PeC- Man enkel een virtueel bestandssysteem is kan het niet zelf de grootte van een bestand uitzoeken en wordt dit als metadata meegegeven bij publicatie. De waarde hiervan moet dus soms met een korrel zout genomen worden. Het owner-attribuut geeft aan welke SIP-gebruiker de eigenaar is van het bestand. Dit laat bijvoorbeeld toe een bestand van iemand anders op je eigen bestandssysteem te plaatsen met enkel een virtuele aanpassing, zonder dat er een bestandsoverdracht aan te pas komt. Hiervoor moeten beide gebruikers dan wel rechten op het bestand hebben. Fragment 2.5: NOTIFY-bericht bij het ontvangen van een bestandssysteem NOTIFY sip : user@ :6060 SIP /2.0 Call - ID: GImP0SBwmmdwEeljW9iQos1Myn -0 tdtd CSeq : 2 NOTIFY From : <sip : fsowner@thesis.test >; tag =1073

38 2.3 Architectuur van PeCMan 23 To: <sip : user@thesis.test >; tag =upq - epijnmfinhdfdah - XPTPUVSZWcZG Via : SIP /2.0/ UDP :4000; branch = z9hg4bk61f2edd268bb5a202dc 2 a81d755e3cac Max - Forwards : 70 Event : filesystem ;id =7 jppuwixhu5dkkji7nn53xrzszd.- hg9 Content - Type : application / filesystem + xml Subscription - State : Active Content - Length : 217 <PeCMan > < dir name =" Directory " path ="" size ="0" owner =" sip : fsowner@thesis. test "> <file name =" File. txt " path =" storage :// File. txt " size =" 1234" owner =" sip : fsowner@thesis. test "/ > </dir > </ PeCMan > Deze NOTIFY-berichten blijven verstuurd worden tot de client de inschrijving beëindigt door een SUBSCRIBEbericht te sturen (binnen dezelfde dialoog) met waarde 0 voor de Expires-header. Deze techniek is volledig analoog aan in- en uitloggen. Bestanden en mappen toevoegen aan een bestandssysteem Om een map of bestand toe te voegen aan het virtuele bestandssysteem wordt gebruikgemaakt van de PUBLISH-methode in SIP. Een dergelijk bericht ziet eruit als in fragment 2.6. Fragment 2.6: PUBLISH-bericht voor het toevoegen van een map PUBLISH sip : fsowner@thesis. test :6060 SIP /2.0 Via : SIP /2.0/ UDP :6060; rport ; branch = z9hg4bkpjjjz - e5hokn5 2 KIVKVuCDUZ50. ftn8s -c Route : <sip : :4000; lr > Max - Forwards : 70 From : <sip : fsowner@thesis.test >; tag =GN.RQF9 - TMRR7fm9njghSTLF9J67 6 BGs To: <sip : fsowner@thesis.test > Call -ID: Uw89JX5wzO2C3PacSVPUuupbNKC61Wau CSeq : 4341 PUBLISH Event : filesystem Content - Type : application / filesystem + xml Content - Length : 110 <PeCMan action =" add " basepath =" PeCMan :" > <dir name =" Name " path =" null " size ="0" owner =" null "></dir > </ PeCMan > Bij het toevoegen zijn de volgende waarden van belang.

39 2.3 Architectuur van PeCMan 24 Het action-attribuut deelt mee aan de server welke operatie er uitgevoerd moet worden. In het originele systeem is er enkel een add en een get functie. Het basepath-attribuut bepaalt in welke contextmap de wijzigingen moeten gebeuren. De waarde PeCMan: betekent dat de map op het hoogste niveau moet aangemaakt worden. Het name-attribuut bepaalt de naam van de map. De andere attributen hebben weinig nut, aangezien ze automatisch afgeleid zullen worden binnen de server. Het toevoegen van een file gebeurt met een gelijkaardige syntax die overeenkomt met die van afgehaalde bestandssystemen. De syntax voor wijzigingen op het bestandssysteem is veranderd tijdens de implementatie van deze masterproef, omdat het oorspronkelijke XML-protocol niet toeliet iets te verwijderen. Wanneer de PeCMan-server de gewenste aanpassingen heeft uitgevoerd, wordt er zoals gewoonlijk een 200 OK-antwoord verstuurd. Opvragen van een bestand Voor het ophalen van de inhoud voor een virtueel bestand moet een peer-to-peer verbinding aangelegd worden tussen de client en een andere client, of tussen de client en een service. In ieder geval is er een sessie nodig, waarvoor SIP ontworpen is. De sessie wordt opgezet via een INVITE-bericht. In het originele server-ontwerp gebeurt dit via een bericht zoals fragment 2.7. Fragment 2.7: INVITE-bericht voor het aanvragen van een bestand INVITE sip : fsowner@thesis. test SIP /2.0 Route : <sip : :4000; lr > Max - Forwards : 70 From : <sip : user@thesis.test >; tag =6 AvHorJecdVWjX0LPIjbyZF.62 H7u To: <sip : fsowner@thesis.test > Via : SIP /2.0/ UDP :4000; branch = z9hg4bkpja98fhrbscd KlxaruF9AiawAidbcfYtUP Contact : <sip : user@ :6060 >; device = phone CSeq : 1 INVITE Call -ID: 7 am8wgih1kbq2utcgzmtknnefzbr9hds9 Content - Length : 145 <PeCMan action =" get " socket =" :2561" > <file path =" Phone :// folder / File. txt " size ="31415" owner =" sip : fsowner@thesis. test "/ > </ PeCMan > Het action-attribuut specifieert opnieuw welke actie ondernomen wordt. We halen een bestand af, dus krijgt het de waarde get.

40 2.3 Architectuur van PeCMan 25 Het socket-attribuut wordt door de proof-of-concept server gebruikt om de inhoud van een bestand uiteindelijk te sturen naar het meegegeven IP-adres op de vermelde poort. Dit is echter geen haalbare werkwijze in een realistisch scenario. Het file-element met bijhorende attributen wijst opnieuw aan over welk bestand het gaat. De size-parameter is van weinig belang aangezien de client niet over sluitende informatie beschikt. Na de 3-way handshake zal de sessie opgezet worden en stuurt de service of client die het bestand bevat de inhoud naar de meegegeven socket. Zodra die overdracht voltooid is, kan de aanvrager de sessie afsluiten. Deze aanpak werd echter niet gebruikt bij de implementatie van WakaWaka, omdat het de rollen van client en server omdraait en zo problemen veroorzaakt met o.a. foutafhandeling en het interpreteren van timeouts.

41 ONTWERP 26 Hoofdstuk 3 Ontwerp Vooraleer van start te gaan met de implementatie van WakaWaka moest er een duidelijk ontwerp zijn voor de opbouw van de applicatie. Op basis van de informatie uit het vorige hoofdstuk kon een clientarchitectuur vastgelegd worden die integreert met de PeCMan-servers. Deze architectuur en de keuzes die eraan vooraf gingen wordt in dit hoofdstuk toegelicht. Eerst en vooral bespreken we de eigenschappen waaraan de bekomen architectuur moet voldoen, vervolgens komt de ontworpen basisarchitectuur aan bod en tenslotte wordt het visueel ontwerp van de gebruikersinterface beschreven. 3.1 Vereisten Elk goed ontwerp begint met een grondige definitie van de gewenste eigenschappen voor het systeem. Om de resultaten te behalen zoals ze naar voor werden gebracht in de doelstellingen van deze masterproef, bepaalden we de volgende technische vereisten: De architectuur moet in meerdere lagen opgebouwd worden. Hogere lagen moeten steeds algemenere abstracties aanbieden om de interactie te vereenvoudigen. De applicatie mag zich niet bezighouden met het handmatig versturen van SIP-berichten. Er moet dus een subsysteem aanwezig zijn dat SIP abstraheert op een objectgeoriënteerde manier. Het beheer van virtuele bestandssystemen moet zich op een afzonderlijke laag bevinden. De API die deze laag aanbiedt aan bovenliggende lagen moet protocol-onafhankelijk zijn. Er mag dus geen SIP-specifieke werkwijze zichtbaar zijn voor de rest van de applicatie. Het uitvoeren van operaties op een bestandssysteem moet onmiddellijk een effect hebben op de representatie in het model. Latentie moet m.a.w. verborgen worden d.m.v. tijdelijke objecten.

42 3.2 Architectuur van WakaWaka 27 Zowel de laag die instaat voor het bestandssysteem als de UI-laag moeten ondersteuning voor metadata (met miniaturen als specifiek geval) voorzien. Het weergeven van bestanden moet gebeuren via een modulaire aanpak waarmee eenvoudig nieuwe types documenten ondersteund kunnen worden. 3.2 Architectuur van WakaWaka We bekijken in dit hoofdstuk de architectuur van WakaWaka slechts tot op het subsysteem-niveau. Voor een meer gedetailleerde bespreking van individuele klassen en opdeling van functionaliteit in deze subsystemen verwijzen we naar hoofdstuk Overzicht Uit de vereisten (3.1) werd een basisarchitectuur afgeleid die kan voldoen aan de gewenste eigenschappen. De nood aan abstractie dicteert een architectuur met minstens drie afzonderlijke lagen: SIPfunctionaliteit, beheer van bestandssystemen en het deel van de applicatie dat voor gebruikersinteractie instaat. Dat laatste is vrij omvangrijk en kan dus nog eens opgedeeld worden in een aantal belangrijke componenten. We bekomen zo een architecturale opbouw als volgt: WakaWaka View + Controller View Browse Transfer Storage Services File System Model SIPCore FS Service Cocoa SIP Library In Model-View-Controller-termen kunnen we de combinatie van de twee onderste abstractielagen beschouwen als het model van de gehele applicatie, terwijl de bovenste laag instaat voor de views en controllers. In de volgende secties wordt besproken welke functionaliteit de verschillende subsystemen aanbieden.

43 3.2 Architectuur van WakaWaka SIPCore SIPCore is de abstractielaag die instaat voor het verwerken van SIP-berichten. Voor de doeleinden van WakaWaka moest de volgende SIP-functionaliteit ondersteund worden: Registratie bij de server met ondersteuning voor een proxy (REGISTER) Inschrijvingen op events en ontvangen van updates (SUBSCRIBE/NOTIFY) Publicatie van events (PUBLISH) Aanmaken en beheren van sessies (INVITE/BYE) Het doel van dit subsysteem is het abstraheren van SIP. De aangeboden API is dus onafhankelijk van PeCMan en de protocollen voor uitwisseling van bestandssystemen. SIPCore biedt abstracties aan voor elke type SIP-interactie, zodat bovenliggende systemen geen eigen beheer van SIP-dialogen e.d. moeten uitvoeren. Er worden afzonderlijke objecten aangeboden voor inschrijvingen, publicaties, enz. Voor de basisafhandeling van het SIP-protocol wordt een bestaande SIP-bibliotheek gebruikt. Een volledig eigen implementatie zou te tijdrovend zijn en weinig bijdragen aan de resultaten File System De File System-component staat in voor de abstractie van de PeCMan-protocollen. Hierbij wordt gebruik gemaakt van het onderliggende SIPCore voor de SIP-communicatie. Alle communicatie met bestandssystemen verloopt via deze abstractielaag, wat garandeert dat de applicatie onafhankelijk is van specifieke protocolversies van PeCMan. Deze strikte afscheiding zorgt ervoor dat de bovenliggende systemen nooit moeten veranderen, zelfs bij een fundamentele wijziging van de PeCMan-protocollen. De API die dit subsysteem aan hogere lagen aanbiedt is volledig objectgeoriënteerd. Virtuele bestandssystemen, mappen en bestanden vormen de basistypes van de API, en zijn de enige manier van interactie met een bestandssysteem. Deze objecten bevatten alle functionaliteit aangeboden door PeCMan: Aanmaken van mappen en bestanden Verwijderen van mappen en bestanden Afhalen van de inhoud van bestanden Om latentie te kunnen verbergen moet de API een onmiddellijke wijziging in het model doorvoeren bij elke operatie. De werkelijke acties gebeuren echter asynchroon, waardoor fouten pas achteraf gemeld worden.

44 3.2 Architectuur van WakaWaka 29 De modelobjecten moeten in staat zijn om om te gaan met tijdelijke toestanden van het model. Waar mogelijk wordt het bestaan van netwerkoperaties niet weergegeven in de API, maar enkel geïmpliceerd als asynchrone toestandswijzigingen. Ook het beheer van eventuele caches wordt volledig binnen de File System-laag geregeld, zodat een virtueel bestandssysteem werkelijk een volledige abstractie is voor de rest van de applicatie WakaWaka De bovenste laag functionaliteit in de architectuur staat voor de volledige resterende functionaliteit binnen WakaWaka, en is dus zeer uitgebreid. Omdat we hier echter op het niveau van de gebruikersinterface zitten is het niet meer mogelijk om een volledig afgescheiden laag toe te voegen. Er bevinden zich echter wel enkele grote blokken functionaliteit die grotendeels afzonderlijk van mekaar werken: View: het weergeven van bestanden waarnaar verwezen wordt op het virtuele bestandssysteem Browse: het rondbladeren in het virtuele bestandssysteem, beheren van mappen, e.d. Transfer: het publiceren en delen van bestanden tussen gebruikers en diensten Naast deze rudimentaire opsplitsing zijn er uiteraard nog andere componenten die niet op een afzonderlijk ontwerp gebaseerd werden. Voorbeelden zijn de inlogweergave en ondersteuning voor zoekopdrachten. View Het View-subsysteem gebruikt een modulaire aanpak om verschillende bestandstypes weer te geven. Deze component bevat views en controllers die werken op basis van de types aangeboden in het File System-pakket. De verantwoordelijkheid van deze component beperkt zich tot het weergeven van inhoud en informatie over één bestand. Daarnaast is er ook een informatie-paneel aanwezig dat metadata en algemene informatie over het bestand toont. De overwegende eigenschap die bewaard moet worden is hier uitbreidbaarheid. Het is immers cruciaal dat in de toekomst ondersteuning voor nieuwe bestandstypes kan toegevoegd worden. Browse De Browse-functionaliteit zorgt in de eerste plaats voor het doorbladeren van virtuele volumes en mappen. Deze component wordt dus rechtstreeks boven het File System-pakket geplaatst en vormt de visuele lijm tussen het FS-model en de View-functionaliteit. Navigeren door virtuele mappen moet aangenaam

45 3.3 Gebuikersinterface 30 zijn, met thumbnails die op aanvraag geladen worden. In het Browse-pakket vinden we ook de zoekvoorzieningen die filteren van bestandssystemen mogelijk maakt. Het belangrijkste doel van Browse-klassen is het verbergen van latentie zodat de gebruiker een virtueel bestandssysteem als lokaal ervaart. Het grootste deel van het werk wordt daarvoor geleverd door het File System, maar het doorbladeren moet optimaal gebruik maken van de aangeboden mogelijkheden. Transfer Onder de Transfer-functionaliteit valt het publiceren van bestanden naar PeCMan en het weergeven van de vooruitgang ervan. Het moet mogelijk zijn om meerdere overdrachten tegelijkertijd uit te voeren en die in een centraal overzicht te beheren. Deze overdrachten kunnen afkomstig zijn van de hele applicatie, waardoor de functionaliteit dus voldoende algemeen moet zijn voor allerlei soorten transfers. Voor het publiceren van bestanden moet de gebruiker een keuze kunnen maken uit verschillende diensten om bestanden op te slaan. De infrastructuur moet gereed zijn om een willekeurig aantal diensten te kunnen gebruiken. Tenslotte bevat het Transfer-systeem ook een component die het mogelijk maakt om lokaal bestanden op te slaan die door andere toestellen opgevraagd kunnen worden. Dit gedeelte zal dus een kleine interne server vereisen om gegevens op aanvraag te versturen naar andere gebruikers. 3.3 Gebuikersinterface Applicatie-icoon Elke zichzelf respecterende iphone-applicatie heeft een aantrekkelijk icoon om zich te differentiëren. Voor WakaWaka werd het volgende icoon ontworpen: De achtergrond is een fragment van een doolhof, symbool voor het zoeken en vinden van interessante nieuwe multimedia via PeCMan. Op de voorgrond staat een happende wolk, geïnspireerd door het figuurtje Pac-Man waarvan ook de naam WakaWaka afkomstig is. Een wolk is een populair symbool voor netwerkfunctionaliteit sinds het inburgeren van de term the cloud voor diensten op afstand. Het feit dat WakaWaka stukjes van die cloud consumeert maakt het happende figuurtje des te meer passend.