Beheerplatform voor persoonlijke bestanden op een mobiel toestel

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 2008-2009

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 2008-2009

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

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.


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.


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 2008-2009

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

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

P2P File Transfers

Storage Services

WakaWaka Client

View

Browse

I. I NTRODUCTION

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.

Virtual File Resolving

File System

I

NCREASINGLY , 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 PeCMan1 , 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.

Transfer

SIP Proxy + PeCMan Service

SIPCore

Cocoa

PJSIP Virtual File Systems

File System Interaction

Fig. 1. WakaWaka + PeCMan architecture

II. A RCHITECTURE A. High Level 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-

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.

FS Service

Notifier Virtual File Systems

Update Notifications SIP Signaling

SIP Proxy

File System Interaction HTTP Front-End(s)

FS Access

FS Access

Clients + Storage Services

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. P ROPOSED S ERVER A RCHITECTURE 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. P EER - TO -P EER 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. C ONCLUSIONS 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. R EFERENCES [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, Session Initiation Protocol, 2002 http://www.ietf.org/rfc/rfc3261.txt [2] J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Hypertext Transfer Protocol / HTTP 1.1, 1999 http://www.ietf.org/rfc/rfc2616.txt [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. 561-570, 2009. http://portal.acm.org/citation.cfm?id=1535069

INHOUDSOPGAVE

i

Inhoudsopgave Lijst van afkortingen

v

1 Situering

1

1.1

Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

PeCMan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.3

Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2 Onderzoek 2.1

2.2

2.3

4

Netwerkproblematiek bij mobiele toestellen . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.1

Netwerksnelheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.2

Beschikbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.1.3

Bereikbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.1.4

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

Studie van protocollen en technologieën . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.1

UDP / TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.2

SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.3

SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.2.4

XMPP / Jabber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.2.5

HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.2.6

XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.2.7

JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.2.8

Content Delivery Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

Architectuur van PeCMan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.3.1

Componenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.3.2

Interactie tussen client en server . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3 Ontwerp

26

3.1

Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.2

Architectuur van WakaWaka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

INHOUDSOPGAVE

3.3

3.4

ii

3.2.1

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.2.2

SIPCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

3.2.3

File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

3.2.4

WakaWaka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

Gebuikersinterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

3.3.1

Applicatie-icoon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

3.3.2

Schetsen van scenario’s

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

Architectuur van PeCMan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4 Implementatie

34

4.1

Ontwikkelingsomgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.2

SIPCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.2.1

Onderzoek

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.2.2

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.2.3

Genereren van de PJSIP-bibliotheek . . . . . . . . . . . . . . . . . . . . . . . . . .

38

4.2.4

Genereren van de SIPCore-bibliotheek . . . . . . . . . . . . . . . . . . . . . . . . .

39

4.2.5

Opmerkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

4.3.1

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4.3.2

Opmerkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

4.4.1

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

4.4.2

Opmerkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

Browse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.5.1

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.5.2

Opmerkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.6.1

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.6.2

Opmerkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

PeCMan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

4.3

4.4

4.5

4.6

4.7

5 Evaluatie

47

5.1

Testomgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.2

Prestatie-analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.2.1

Werkelijke en waargenomen prestaties . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.2.2

Opstartsnelheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

5.2.3

Inactiviteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.2.4

XML-verwerking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

INHOUDSOPGAVE

5.2.5

iii

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

Netwerk-analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

5.3.1

XML-uitwisseling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

5.3.2

Latentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

5.3.3

Datavolume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

5.4

Toetsen aan vooropgestelde doelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

5.5

Verder werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

5.5.1

Caching en persistentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

5.5.2

Uitgebreidere metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

5.5.3

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

5.3

Batterijduur

6 Voorstel PeCMan-architectuur 6.1

63

Hybride SIP / HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

6.1.1

Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

6.1.2

Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

6.1.3

Keuze van protocollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

6.1.4

Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

6.1.5

Interactie tussen client en server . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

6.1.6

Compressie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

6.1.7

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

6.2.1

Opvragen van metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

6.2.2

Bewerken van metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

6.2.3

Thumbnails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

6.3

Dynamische zoekopdrachten en bestandssystemen . . . . . . . . . . . . . . . . . . . . . . .

80

6.4

Notifications

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

6.4.1

Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

6.4.2

Push voor statusberichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

Peer-to-Peer: omzeilen van constante persoonlijke bereikbaarheid . . . . . . . . . . . . . .

82

6.5.1

Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

6.5.2

Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

6.5.3

Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

6.5.4

Beperken van Peer-to-Peer

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

6.5.5

Queue-and-Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

6.5.6

Queue-and-Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

6.5.7

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

6.2

6.5

7 Conclusie

89

INHOUDSOPGAVE

A Ontwikkelen voor de iPhone en iPod touch

iv

90

A.1 iPhone SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

A.2 iPhone Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

A.3 iPhone Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

A.4 Jailbreaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92

LIJST VAN AFKORTINGEN

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

v

LIJST VAN AFKORTINGEN

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

vi

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.

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.

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.

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.

2.1.1

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. Bijgevolg beperken we ons tot de gangbare netwerksnelheden die een dergelijk toestel kan ondervinden. Download (max) Upload (max) Download (praktijk) Upload (praktijk)

GPRS 56kbps 40kbps 10kbps 10kbps

EDGE 180 kbps 120 kbps 50 kbps 20 kbps

UMTS 384 kbps 64 kbps 200 kbps 40 kbps

HSDPA 7,2 Mbps 384 kbps 1 Mbps 200 kbps

WiFi + breedband 11 Mbps 1 Mbps 5 Mbps 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

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

20x 0,2x GPRS

1x

4x

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


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, 802.11b, 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 802.11g (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¨ ordineren 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.


2.1.2

7

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).

2.1.3

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.

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.

2.1.4

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 2.2.1

Studie van protocollen en technologie¨ en 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


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.

2.2.2

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


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.


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:[email protected] aan en worden meegegeven aan de eindgebruikers. Ze zijn echter niet bruikbaar om onmiddellijk een onderlinge verbinding op te zetten.


12

• Contact URI’s: deze zijn van de vorm sip:[email protected]:5060 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:[email protected];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.


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 voicemails, 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.

2.2.3

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-


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.

2.2.4

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 PeCMan 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.


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.

2.2.5

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.


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.

2.2.6

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 < element > < sub attribute =" value " > < example / > 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 () vaak ontbreekt.

2.2.7

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


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.

2.2.8

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.

2.3 Architectuur van PeCMan

2.3

18

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

2.3.1

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.


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¨ ordineert 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.


20

Clients Dit zijn uiteraard de PeCMan-clients van eindgebruikers, zoals WakaWaka. Alle clients gebruiken in principe dezelfde basisprotocollen voor communicatie met de PeCMan-proxy.

2.3.2

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 10.0.1.4:6060; rport ; branch = z 9 hG 4 b KP j A 98 F H rb S c d KlxaruF9AiawAidbcfYtUP Route : < sip :10.0.1.4:4000; lr > Max - Forwards : 70 From : < sip : user@thesis . test >; tag =6 A v H o r J e c d V W j X 0 L P I j b y Z F .62 H7u To : < sip : user@thesis . test > Call - ID : l 2 n K 0 l E P 9 4 V S X H j b J V d C 1 L K 0 E q N S . j2L CSeq : 48634 REGISTER Contact : < sip : user@10 .0.1.4: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.


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, sip:pecmanfilesystems:[email protected]:5060. 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, [email protected], geeft de subscriber aan, de gebruiker die zich inschrijft op het bestandssysteem. • De URI in de To-header, [email protected], 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 : pecma nfiles ystems : proxy@thesis . test :5060 SIP /2.0 Via : SIP /2.0/ UDP 10.0.1.4:6060; rport ; branch = z9 hG 4b KP jK INx T0 rW t S9vhvguHQ5nc5n0guz3ICra Max - Forwards : 70 From : sip : user@thesis . test ; tag = uPq - epIJNMFInHDFDAh - XPTPUVSZWcZG To : sip : fsowner@thesis . test Contact : < sip : user@10 .0.1.4:6060 >; device = simulator Call - ID : 6 n M 3 w g I H 1 m j o 2 u t c g z m t k n N e F z B J M f S q CSeq : 1157 SUBSCRIBE Route : < sip :10.0.1.4:4000; lr > Event : filesystem ; id =7 j p p U W I x h u 5 D K k J I 7 n N 5 3 x R z S Z D . - 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


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 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 PeCMan 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@10 .0.1.4:6060 SIP /2.0 Call - ID : GImP0SBwmmdwEeljW9iQos1Myn -0 tDTd CSeq : 2 NOTIFY From : < sip : fsowner@thesis . test >; tag =1073


23

To : < sip : user@thesis . test >; tag = uPq - epIJNMFInHDFDAh - XPTPUVSZWcZG Via : SIP /2.0/ UDP 10.0.1.4:4000; branch = z 9 h g 4 b k 6 1 f 2 e d d 2 6 8 b b 5 a 2 0 2 d c 2 a81d755e3cac Max - Forwards : 70 Event : filesystem ; id =7 j p p U W I x h u 5 D K k J I 7 n N 5 3 x R z S Z D . - 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 "/ > 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 10.0.1.4:6060; rport ; branch = z9hG4bKPjJjZ - e5hOKN5 2 KIVKVuCDUZ50 . fTN8s - c Route : < sip :10.0.1.4:4000; lr > Max - Forwards : 70 From : < sip : fsowner@thesis . test >; tag = GN . RQF9 - T M R R 7 f m 9 n j g h S T L F 9 J 6 7 6 BGs To : < sip : fsowner@thesis . test > Call - ID : U w 8 9 J X 5 w z O 2 C 3 P a c S V P U u u p b N K C 6 1 W a u 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 " > Bij het toevoegen zijn de volgende waarden van belang.


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 :10.0.1.4:4000; lr > Max - Forwards : 70 From : < sip : user@thesis . test >; tag =6 A v H o r J e c d V W j X 0 L P I j b y Z F .62 H7u To : < sip : fsowner@thesis . test > Via : SIP /2.0/ UDP 10.0.1.4:4000; branch = z 9 hG 4 b KP j A 98 F H rb S c d KlxaruF9AiawAidbcfYtUP Contact : < sip : user@10 .0.1.4:6060 >; device = phone CSeq : 1 INVITE Call - ID : 7 a M 8 w g I H 1 k b q 2 u t c g z m t k n N e F z B r 9 H d S 9 Content - Length : 145 < PeCMan action =" get " socket ="10.0.1.4:2561" > < file path =" Phone :// folder / File . txt " size ="31415" owner =" sip : fsowner@thesis . test "/ >

• Het action-attribuut specifieert opnieuw welke actie ondernomen wordt. We halen een bestand af, dus krijgt het de waarde “get”.


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.

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.

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 4.

3.2.1

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 FS Service

SIPCore

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.


3.2.2

28

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.

3.2.3

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.


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.

3.2.4

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

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 3.3.1

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.


3.3.2

31

Schetsen van scenario’s

Om v´ o´ or de implementatie een idee te krijgen van de mogelijke workflow van de gebruikersinterface werden een aantal eenvoudige schetsen gemaakt voor de belangrijkste taken van WakaWaka. De uiteindelijke gebruikersinterface is hier sterk op gebaseerd, al is ze tijdens de implementatie verder geëvolueerd.

Inloggen Om te verbinden met de PeCMan-server is een gebruikersnaam, wachtwoord en proxy-server nodig. Bij het opstarten wordt er een login-dialoog getoond die deze gegevens vraagt aan de gebruiker. Er kunnen verschillende proxies opgeslagen worden voor toekomstig gebruik.

WakaWaka WakaWaka

Choose Choose ProxyProxy

Connect Connect

[email protected] User User [email protected]

My Proxy My Proxy

Password Password required required

Some Other Some Proxy Other Proxy

Proxy Proxy localhost:4000 localhost:4000

add newadd proxy new proxy

KEYBOARD KEYBOARD

ConnectConnect

Doorbladeren van mappen en bekijken van bestanden De gebruiker kan het persoonlijke bestandssysteem doorbladeren alsof het een lokaal volume was. Bij het selecteren van een bestand wordt de inhoud ervan afgehaald en weergegeven. Bij het kiezen van de Info-knop (i) wordt een Inspector getoond die meer informatie en metadata bevat.


Files

32

Files Trip Road Edit Road Trip

Road Trip Edit

Road Trip Falls Road Trip Niagara Falls Niagara i i Niagara Falls

i

Road Trip

Niagara Falls

Awesome Picture 1.jpg Picture 1.jpg Awesome

name

Niagara Falls.jpg

Awesome Picture 2.jpg Picture 2.jpg Awesome

kind

JPEG image

size

400KB

View

Landscapes Landscapes Niagara Falls.jpg Niagara Falls.jpg 4 items

This file has not yet been downloaded to your device.

4 items Download

+

+

Transfers

List

ThumbnailsList

Share Transfers

Thumbnails

Share

ShareTransfers

Transfers

Share Transfers

Remove

Transfers

voor stijl download-knop, zie Remote app

Publiceren van een bestand Om een bestand te publiceren naar het virtuele bestandssysteem tonen we een dialoog die de naam opvraagt van het bestand, en waar het moet opgeslagen worden. De gebruiker kan een keuze maken tussen de verschillende opslagdiensten die de PeCMan-server toelaat. Tenslotte kan er ook nog extra metadata toegevoegd worden.

Cancel

Add File

Done

My File

Inside

Some Folder

Store File

on this device

Metadata

whatever

Bekijken van overdrachten Voor zowel up- als downloads is het handig om toch te kunnen doorwerken met de applicatie zonder te moeten wachten tot de overdracht volledig voltooid is. Daarom kan gebruik gemaakt worden van een gespecialiseerd Transfers-paneel, dat de vooruitgang van alle lopende overdrachten weergeeft.


33

Transfers

Done

Awesome Picture 1.jpg sending to [email protected]

Awesome Picture 1.jpg sending to [email protected]

Funny Cat.jpg downloading from [email protected]

3.4

Architectuur van PeCMan

De huidige architectuur van het PeCMan-serversysteem dat reeds eerder besproken werd (zie 2.3), vormt de basis voor de ontwikkeling van WakaWaka. Tijdens het uitwerken van deze masterproef kwamen problemen aan het licht die enkel opgelost kunnen worden door wijzigingen in de serverarchitectuur van PeCMan. We verwijzen hiervoor naar hoofdstuk 6, waar eventuele aanpassingen uitgebreid besproken worden.

IMPLEMENTATIE

34

Hoofdstuk 4

Implementatie Dit hoofdstuk bespreekt de architecturale ontwerpen die in hoofdstuk 3 naar voren gebracht werden in meer detail, alsook de eigenlijke implementatie ervan. Het vormt een wegwijzer voor de klassenstructuur van de verschillende subsystemen en dient hoofdzakelijk om de verantwoordelijkheid voor functionaliteit af te bakenen. Enkel de cruciale subsystemen en belangrijkste klassen worden afzonderlijk besproken. De minder relevante klassen worden weggelaten om de lezer niet te overstelpen met randinformatie. Voor meer informatie bij elke klasse en voor methode-specifieke documentatie verwijzen we naar de broncode van de applicatie op de meegeleverde CD-ROM.

4.1

Ontwikkelingsomgeving

Het uiteindelijk afgeleverde resultaat van deze masterproef is ontwikkeld voor de iPhone SDK 3.0, maar werd bij aanvang van de masterproef gebaseerd op de iPhone SDK 2.0. Waar mogelijk maakt de code gebruik van nieuwe API-verbeteringen in versie 3.0, die sinds de lente van 2009 in beta-vorm werd rondgestuurd naar ontwikkelaars. Als ontwikkelingsplatform werd een MacBook Pro Core 2 Duo gebruikt. Bij aanvang van de masterproef was het gebruikte besturingssysteem Mac OS X 10.5 Leopard, later werd overgeschakeld naar 10.6 Snow Leopard. Het gebruikte toestel was een iPhone 3G met een data-abonnement bij Proximus. Functionaliteitstests werden hoofdzakelijk uitgevoerd binnen een lokaal draadloos netwerk, maar ook over de 3G-verbinding en tussen verschillende netwerken. Meer details over het ontwikkelen voor de iPhone bevinden zich in appendix A.

4.2 SIPCore

4.2

35

SIPCore

SIPCore is de kernmodule in WakaWaka die instaat voor de implementatie van SIP (Session Initiation Protocol). Het wikkelt een gestroomlijnde Objective-C API rond de C-gebaseerde PJSIP-bibliotheek. Deze beperktere API bevordert de foutbestendigheid en zorgt ervoor dat de applicatie in de toekomst eenvoudig naar een andere bibliotheek kan overschakelen.

4.2.1

Onderzoek

Bij het ontwerp van SIPCore is meteen gekozen voor een vrij beschikbare bibliotheek. Een volledig eigen implementatie van het SIP-protocol draagt immers weinig bij aan de applicatie of aan de geest van de masterproef. De vereisten waren dus de volgende: geschreven in C, C++ of Objective-C; vrij beschikbaar en idealiter open source. We stippen de belangrijkste SIP-gerelateerde projecten hier aan.

PJSIP De PJSIP-bibliotheek is beschikbaar op pjsip.org. • Pro: werd platformonafhankelijk ontworpen; ondersteunt verschillende mobiele besturingssystemen inclusief Darwin op de iPhone. • Pro: wordt actief ontwikkeld en ligt aan de basis van meerdere iPhone VoIP projecten. De bibliotheek heeft zijn bruikbaarheid dus al in de praktijk bewezen. • Pro: bestaat uit verschillende abstractielagen, zodat onnodige aspecten (zoals VoIP codecs) niet noodzakelijk gebruikt moeten worden. • Pro: ondersteunt IPv6 naast IPv4, wat momenteel echter weinig relevant is aangezien iPhone OS dit niet aankan. Naar de toekomst toe is dit echter belangrijk. • Contra: wordt verdeeld onder het GNU General Public License (GPL) 2, zodat WakaWaka eveneens open source verdeeld moet worden. Dit is echter geen vereiste zolang de ontwikkeling intern verloopt, zoals dus het geval is voor deze masterproef.

Sofia-SIP De Sofia-SIP-bibliotheek is beschikbaar op sofia-sip.sourceforge.net. • Pro: ondersteunt verschillende besturingssystemen met een focus op Unix/Linux, inclusief Mac OS X.

4.2 SIPCore

36

• Pro: bevat geen eigen implementatie van VoIP-functionaliteit, zodat die ook niet uitgeschakeld moet worden. Sofia-SIP is een bibliotheek die zich specifiek op Session Initiation Protocol (SIP) toespitst en media-transport overlaat aan andere subsystemen. • Pro: wordt verdeeld onder het minder beperkende GNU Lesser General Public License (LGPL), wat in het kader van dit werk echter niet doorslaggevend is. • Pro: ondersteunt eveneens zowel IPv4 als IPv6. • Contra: wordt iets minder actief ontwikkeld, wat deels echter een gevolg is van het kleinere werkdomein.

minisip De minisip-bibliotheek is beschikbaar op minisip.org. Hoewel ze in principe geporteerd kan worden naar OS X, zijn er geen voordelen ten opzichte van PJSIP of Sofia-SIP die dat verantwoorden.

M5T SCE Mobility SDK Media5 adverteert een SIP-bibliotheek op www.media5corp.com/sce-mobility-sdk, die recent geporteerd werd naar de iPhone. Deze software is echter commercieel en hoofdzakelijk gericht op VoIPtoepassingen, gezien hun eigen softphone applicaties.

JAIN-SIP Voor Java-gebaseerde applicaties kan men gebruikmaken van het JAIN-SIP framework, beschikbaar op jain-sip.dev.java.net. Qua implementatie is dit niet relevant voor een iPhone applicatie aangezien die laatste geen Java Runtime aanbiedt, maar SIPCore is conceptueel wel gebaseerd op de structuur van JAIN-SIP.

Besluit Voor de doeleinden van deze masterproef is de PJSIP-bibliotheek het meest geschikt dankzij de bewezen werking op iPhone OS en regelmatige updates. Sofia-SIP is een zeer goed alternatief, maar het feit dat PJSIP reeds voor andere iPhone-applicaties gebruikt wordt was doorslaggevend. Qua architecturaal ontwerp is JAIN-SIP interessant; het ontwerp van SIPCore is licht gebaseerd op dit Java-subsysteem.

4.2 SIPCore

4.2.2

37

Overzicht

SIPCore is ontworpen zodat de onderliggende SIP-bibliotheek volledig afgescheiden wordt van de rest van de applicatie. Het vormt een object-georiënteerde laag die de communicatie met de PeCMan-diensten sterk vereenvoudigt dankzij bijkomende abstracties bovenop het SIP-protocol. De API bevat niets specifiek aan het PeCMan-systeem – men kan SIPCore in principe voor eender welke SIP-gebaseerde applicatie gebruiken zolang men enkel de de ge¨ımplementeerde functionaliteit vereist. Het is dus niet correct SIPCore als een complete Objective-C wrapper voor het SIP-protocol te beschouwen, aangezien het enkel abstracties aanbiedt voor delen van de specificatie. We bespreken kort de belangrijkste klassen.

SIPClient

De klasse SIPClient is het centrale aanspreekpunt in SIPCore. Ze staat in voor het centrale

beheer van één enkele SIP-account. Voor elke verschillende gebruiker moet in principe een afzonderlijk SIPClient-object aangemaakt worden, maar momenteel gaat de interne code uit van een singletoninstantie die globaal voor de applicatie geldt. Deze beperking is echter niet zichtbaar in het API-ontwerp, zodat de functionaliteit in de toekomst kan toegevoegd worden zonder de externe code te moeten bijwerken. In de eerste plaats verzorgt deze klasse de registratie van een gebruiker bij een SIP-registrar. Dit is immers de enige vereiste stap voor elke SIP-communicatie. De details van afzonderlijke REGISTER-berichten e.d. worden volledig verborgen. Verder is SIPClient een zogenaamde “factory” voor objecten die specifieke SIP-functionaliteit aanbieden zoals SIPSubscription. Deze objecten bevatten zeer beperkte implementaties die de feitelijke interactie met de onderliggende SIP-bibliotheek overlaten aan SIPClient, en hoofdzakelijk bestaan om op een praktische object-georiënteerde manier te kunnen werken met statuswijzigingen en foutboodschappen. Dit ontwerp heeft als gevolg dat SIPClient het overgrote deel van bibliotheek-afhankelijke code bevat en dus eventueel vervangen kan worden door een andere implementatie.

SIPSubscription

Een object van deze klasse beheert één enkele inschrijving op events van een SIP-

notifier zoals een andere gebruiker of een dienst. Het staat dus in voor het versturen en ontvangen van SUBSCRIBE- en NOTIFY-berichten. De eigenlijke implementatie van de SIP-berichten wordt intern overgelaten aan SIPClient, maar dit is niet extern zichtbaar. Via het SIPSubscriptionDelegate-protocol wordt een extern object op de hoogte gehouden van de toestand van de inschrijving. Typisch is dit ook de eigenaar van de SIPSubscription.

4.2 SIPCore

SIPPublication

38

SIPPublication-objecten vormen een wrapper voor PUBLISH-berichten en stellen dus

elk één publicatieverzoek voor. Via het SIPPublicationDelegate-protocol wordt een extern object op de hoogte gehouden van het succes van de publicatie, of van eventuele fouten.

SIPSession Voor het aanmaken en beheren van SIP-sessies worden SIPSession-objecten gebruikt. Deze klasse beheert INVITE- en BYE-berichten, hoewel de eigenlijke implementatie zich opnieuw grotendeels binnen SIPClient bevindt. Via SIPSessionDelegate kan een extern object dat de sessie aanvraagt op de hoogte gehouden worden van toestandswijzigingen van de sessie.

SIPMessage, SIPRequest, SIPResponse Deze klassen stellen respectievelijk een SIP-bericht, een SIP-verzoek en een SIP-antwoord voor. SIPRequest en SIPResponse zijn subklassen van SIPMessage. Dergelijke objecten zijn in feite enkel Objective-C wrappers rond de equivalente structuren in de onderliggende SIP-bibliotheek. Indien een extern object weet moet hebben van een specifiek SIP-bericht worden objecten van deze klassen meegegeven (o.a. bij ontvangen van een NOTIFY-bericht voor een inschrijving).

4.2.3

Genereren van de PJSIP-bibliotheek

Om PJSIP werkende te krijgen op de iPhone zijn enkele aanpassingen aan de oorspronkelijke code nodig. De instructies in dit onderdeel werden geschreven voor gebruik met iPhone OS 3.0 en Mac OS X 10.6 (Snow Leopard) als ontwikkelingsplatform, maar zijn waarschijnlijk met minimale aanpassingen bruikbaar voor toekomstige versies van iPhone OS en Mac OS X. Bij het afleveren van deze masterproef was de gebruikte versie van PJSIP versie 1.3. Deze werd vrijgegeven op 3 juli 2009, via de website van het project (www.pjsip.org). De aanpassingen hierin beschreven zijn dus ontwikkeld voor deze specifieke versie van de bibliotheek, en werken niet noodzakelijk op nieuwere (of oudere) versies. Aanpassingen De broncode is onveranderd gebleven. De volgende header- en buildscriptbestanden werden aangepast in de “pjproject”-map: • build/cc-gcc.mak: wijzigingen voor library generation op iPhone OS en Mac OS X • build/rules.mak: wijzigingen voor library generation op iPhone OS en Mac OS X • pjlib/include/pj: aanpassingen voor iPhone OS en Mac OS X; de detectie van besturingssysteem werkt soms onbetrouwbaar en de aangepaste bestanden zorgen ervoor dat de gegenereerde bibliotheek geschikt is voor Darwin.

4.3 File System

39

• pjmedia/build/Makefile: weghalen van pjmedia-test uit het buildscript om nutteloze fouten te voorkomen (SIPCore gebruikt geen pjmedia features) Compileren Zodra de nodige aanpassingen toegepast zijn, kunnen we overgaan tot het compileren van de code. Om eenvoudig voor de iPhone te compileren kunnen de shellscripts in pjproject-compile-scripts gebruikt worden. Voor gebruik met de iPhone simulator voert men compile-iphone-simulator.sh uit, voor het toestel zelf compile-iphone-device.sh. De script werden geschreven met de veronderstelling dat de aangemaakte executables terecht kunnen in respectievelijk pjproject-libs-simulator en pjproject-libs-device mappen. Na het uitvoeren van beide scripts hebben we zowel voor de i386- als de ARM-architectuur werkende executables en kunnen we overgaan tot het compileren van SIPCore zelf.

4.2.4

Genereren van de SIPCore-bibliotheek

Het genereren van SIPCore voor gebruik binnen een uiteindelijke client-applicatie zoals WakaWaka is eenvoudig. Zodra de stappen voor PJSIP doorlopen zijn is het enkel een kwestie van SIPCore.xcodeproj te openen in Xcode, het gepaste Target te kiezen en vervolgens Build te selecteren. De resulterende libSIPCore.a kan dan in de client-applicatie gebruikt worden.

4.2.5

Opmerkingen

De huidige implementatie van SIPCore vormt een mooie abstractielaag rond SIP, zoals het ontwerp voorschreef. Alles werkt naar behoren, op één probleem na. Bij uitvoering over 3G of GPRS heeft een iPhone standaard geen IP-adres toegewezen op de netwerkinterface naar het Wireless Wide Area Network (WWAN) toe. Netwerkoperaties op hoog niveau regelen automatisch het activeren van deze interface, maar omdat de gebruikte PJSIP-bibliotheek platformonafhankelijk probeert te werken bevinden de gebruikte netwerksystemen zich op de BSD-laag die geen automatische activering uitvoert. Een structurele oplossing zou een aanzienlijke architecturale aanpassing van PJSIP vereisen, een klus die niet haalbaar was binnen het tijdsbestek van deze masterproef. Als tijdelijke oplossing verstuurt SIPCore een HTTP-request naar http://example.com/ vóór het verbinden met een proxy. Dit activeert de WWAN-interface zodat er een geldig IP-adres beschikbaar is.

4.3

File System

Het File System-subsysteem vormt een abstractielaag voor virtuele bestandssystemen. Voor de eenvoud gebruiken we hierna de afkorting “FSS”. Het FSS verbergt latentie en netwerkactiviteit voor de rest van

4.3 File System

40

de applicatie, wat leidt tot een hogere betrouwbaarheid en een betere gebruikerservaring.

4.3.1

Overzicht

FSManager De klasse FSManager is het centrale aanspreekpunt voor het FSS. Dit object wordt aangemaakt met een SIPClient-object dat geconfigureerd werd met de details van de gebruiker. Een FSManager heeft standaard minstens één volume (van de klasse FSVolume): het persoonlijk volume voor de account. Bijkomende volumes van andere gebruikers en volumes voor dynamische zoekopdrachten kunnen via een URI geladen worden. Een FSManager-object staat in voor het algemeen beheer van zijn volumes.

FSVolume

Een dergelijk object is de representatie voor een virtueel bestandssysteem en kan vergeleken

worden met een mount point. Elk volume heeft een rootmap die gebruikt wordt als startpunt voor de subsystemen die een FSVolume aanspreken (o.a. het Browse-gedeelte). Intern werkt een volume via een bijhorende SIPSubscription, wat uiteraard een implementatiedetail is voor de bovenliggende lagen. Het FSVolume-object staat dus ook in voor de eigenlijke afhandeling van wijzigingen en verzoeken naar het bestandssysteem toe. De opengestelde API wordt echter gedefinieerd in de objecten die dadelijk besproken worden.

FSItem, FSFile, FSDirectory FSFile en FSDirectory stellen respectievelijk een bestand en een map op het virtueel bestandssysteem voor. Ze erven beide over van FSItem, een abstracte klasse waarvan geen rechtstreekse instanties bestaan, maar die gemeenschappelijke eigenschappen voorziet. De interactie met het bestandssysteem verloopt via deze klassen, een manier van werken die natuurlijk aanvoelt voor de andere subsystemen. Intern worden de operaties echter doorgegeven aan het FSVolume waartoe de objecten behoren. Naast de algemene FS-operaties ondersteunt FSFile ook het opvragen van willekeurige metadata en thumbnails. Wegens gebrek aan ondersteuning in de PeCMan-server wordt hier intern echter met gedeeltelijke dummy-code gewerkt. Naar de andere subsystemen toe is dit niet merkbaar, dus kan echte ondersteuning toegevoegd worden zonder iets te veranderen aan de externe API.

FSRequest

De klasse FSRequest is enerzijds een stuk van de API van het FSS, anderzijds een in-

tern gebruikte klasse. FSRequest-objecten beheren een aanvraag naar gegevens over een entiteit in het bestandssysteem. Het kan gaan om metadata, de werkelijke inhoud van bestanden, enz. Als externe subsystemen werkelijk nood hebben aan de statusinformatie van een request wordt het object aangeboden aan externe gebruikers. In andere gevallen, zoals bij het opvragen van metadata en thumbnails, kan er enkel aangegeven worden dat er in de achtergrond een request moet gebeuren. In plaats van dan expliciet de vooruitgang van een

4.4 View

41

request te volgen moeten externe objecten veranderingen in de gewenste gegevens observeren. Deze aanpak is nodig om zoveel mogelijk netwerk-gerelateerde concepten als implementatiedetail te beschouwen. In principe zou alles in termen van requests weergegeven kunnen worden, maar dan kunnen we uiteraard niet meer spreken van het weg abstraheren van latentie. Voor het werkelijke interne beheer van requests wordt een FSRequestQueue-object gebruikt. Deze queue verdeelt de uitvoering van requests in de achtergrond, zodat de UI nooit geblokkeerd wordt door het laden van gegevens. Requests communiceren tijdens hun uitvoering met hun delegate voor het meedelen van vooruitgang, eventuele fouten, enz.

4.3.2

Opmerkingen

Omdat de File System-laag instaat voor de eigenlijke interactie met de PeCMan-server ondervindt ze de meeste hinder van de prototype-kwaliteit van de File System-dienst. Het positieve punt is uiteraard dat de bovenliggende lagen hier geen last van ondervinden, een eigenschap die de bestaansreden van deze laag is. Om toch een aantal features naar voren te kunnen brengen voor een mooie demonstratie omzeilt het subsysteem de PeCMan-server voor bijvoorbeeld het laden van thumbnails en metadata. Hoewel deze code dus gedeeltelijk dummy is, maakt ze wel gebruik van het netwerk om een realistisch beeld te geven van de prestaties. Een thumbnail lokaal laden is uiteraard veel sneller dan een afbeelding over het netwerk binnenhalen. Ook voor de foutafhandeling zijn er hier en daar nog mogelijke gebreken. De FS Service waarmee gewerkt werd geeft bijvoorbeeld niet altijd de verwachte foutmeldingen mocht een bepaalde operatie falen. In sommige gevallen zal WakaWaka dus aannemen dat een operatie gelukt is, terwijl de server in feite een verkeerde statuscode teruggaf. Wat betreft de implementatie van FSRequests die gegevens afhalen (o.a. thumbnails en bestandsinhoud) werd in de huidige implementatie al gekozen voor HTTP, ter voorbereiding van de verbeteringen die in hoofdstuk 6 naar voren worden gebracht.

4.4

View

Onder het View-pakket groeperen we alle functionaliteit die instaat voor het weergeven van bestanden. Dit gebeurt op een modulaire manier, waardoor WakaWaka naar de toekomst toe eenvoudig uit te breiden is met ondersteuning voor nieuwe types bestanden. Dit gedeelte van de applicatie is iets minder afhankelijk van de File System-laag dan andere stukken, omdat het vooral verantwoordelijk is voor het interpreteren van de gegevens en minder voor het laden ervan.

4.4 View

4.4.1

42

Overzicht

WKViewerController

Deze klasse wordt gebruikt om een FSFile af te beelden in de applicatie, en

wordt door de Browse-component opgeroepen bij het selecteren van een bestand. Intern is dit een zeer algemene klasse die verschillende WKViewer-modules beheert. Op basis van de eigenschappen van het bestand wordt de gepaste WKViewer gekozen en geladen om het bestand af te beelden. WKViewerController voorziet een beperkte API voor WKViewers waardoor elke WKViewer enkel functionaliteit bevat die werkelijk nodig is voor het afbeelden van het bestandsformaat. Het laden van gegevens wordt geregeld door deze controller, hoewel de WKViewer ook de mogelijkheid krijgt om volledig zelf de gegevens op te vragen.

WKViewer

Een dergelijk object is een module voor WKViewerController die instaat voor het weerge-

ven van een categorie bestandstypes. Bij het laden van een bestand wordt aan elke WKViewer gevraagd hoe gepast hij is om een zekere FSFile te tonen. De module met de hoogste waarde wordt dan uiteindelijk gekozen. Een WKViewer-module kan werken op basis van afgehaalde gegevens, of met metadata zoals de URI beschikbaar via de FSFile. De versie van WakaWaka uit deze masterproef bevat 4 soorten WKViewers: • WKImageViewer geeft gewone afbeeldingen weer. • WKWebBrowser geeft webpagina’s weer en kan gebruikt worden om favoriete links te tonen. • WKDocumentViewer geeft gepagineerde documenten weer, zoals PDF-bestanden. • WKYouTubeViewer speelt YouTube-filmpjes af in de ingebouwde YouTube-speler.

WKInspector De File Inspector wordt ge¨ımplementeerd door de klasse WKInspector. Deze klasse geeft dus meer informatie over een gegeven FSFile, en kan opgeroepen worden door de WKViewerController. Als er metadata over het bestand beschikbaar is wordt die ook hier weergegeven.

4.4.2

Opmerkingen

WKYouTubeViewer, de viewer-klasse die instaat voor het weergeven van YouTube-filmpjes, werkt enkel op een echt toestel en niet in de iPhone Simulator. Dit is te wijten aan het feit dat er geen YouTubeapplicatie aanwezig is op de Simulator, een vereiste voor de bijhorende plug-in. Momenteel toont WakaWaka in de Simulator gewoon een scherm dat deze informatie meedeelt aan de gebruiker. WKImageViewer, de viewer-klasse die afbeeldingen toont, is momenteel heel beperkt en ondersteunt geen zoomen of verslepen van het weergegeven beeld. WKDocumentViewer ondersteunt enkel PDF-bestanden.

4.5 Browse

4.5

43

Browse

Het pakket klassen onder Browse laat de gebruiker toe te navigeren tussen verschillende virtuele volumes en mappen. De Browse-features zijn de meest cruciale van de applicatie, omdat de andere functionaliteit slechts kan aangeboden worden als gebruikers hun mappen en bestanden kunnen doorbladeren. Ook het beheer en de weergave van zoekopdrachten valt onder Browse.

4.5.1

Overzicht

WKOverviewController

Deze klasse bepaalt de basis-UI van WakaWaka, het eerste scherm na het

inloggen. Ze beheert de weergegeven FSVolumes, staat in voor het aanmaken van WKSearches, enz. Een aanzienlijk deel van de functionaliteit voor o.a. toevoegen van volumes wordt gedelegeerd naar andere hulpklassen.

WKBrowseController

Deze objecten staan in voor het weergeven en bewerken van een gegeven FS-

Directory. Dit houdt o.a. in: het ordenen en weergeven van mappen en bestanden, het on-demand laden van thumbnails, het aanmaken van nieuwe mappen, het verwijderen van bestanden, enz. Deze klasse ligt bovenop het File System-subsysteem, en maakt er uitgebreid gebruik van voor al zijn functionaliteit. Voor het weergeven van bestanden maakt een WKBrowseController gebruik van het View-pakket via WKViewerController. Wanneer de gebruiker een nieuw bestand wilt toevoegen wordt de nodige informatie meegegeven aan WKPublishController uit het Transfer-subsysteem.

WKSmartSearch

Dergelijke objecten zijn een wrapper rond een verzameling van volumes, waarbij de

inhoud wordt geaggregeerd tot één lijst resultaten. Dit is zeer nuttig om snel alle bestanden of mappen die voldoen aan een aantal criteria te vinden binnen de ingeschreven bestandssystemen. Standaard zit in WakaWaka een “Nearby”- en een “Images”-search, die metadata onderzoeken en respectievelijk nabije bestanden (via GPS) en enkel afbeeldingen filteren. WKSmartSearches zijn hoofdzakelijk ontwikkeld als voorbereiding op bijhorende serverondersteuning voor dynamische volumes. Een volume met zoekresultaten gecombineerd met een Smart Search in WakaWaka biedt zeer interessante mogelijkheden voor zoekopdrachten zoals “toon alle recente populaire YouTube-filmpjes met een panda in”. De server kan zich bezighouden met het aggregeren van informatie die voor veel gebruikers nuttig zijn, de client kan daarin verder filteren voor persoonlijk interessante multimedia. Omdat een Smart Search een FSDirectory genereert kunnen alle andere subsystemen zonder verdere aanpassing gebruikt worden. Navigeren door de resultaten, weergeven van bestanden, enz. werkt allemaal “out of the box”.

4.6 Transfer

4.5.2

44

Opmerkingen

WKSmartSearch werkt zoals verwacht, maar aangezien er geen dynamische volumes bestaan zijn ze enkel getest op gewone volumes waarop de gebruiker zich ingeschreven heeft. Verder moeten we opnieuw gebruik maken van de metadata die de File System-klassen ons aanbieden, gegevens die deels dummy zijn door gebrek aan serverondersteuning. Bovendien werkt locatiebepaling niet op de iPhone Simulator.

4.6

Transfer

Onder het Transfer-pakket vallen de klassen die instaan voor het uitwisselen van bestanden tussen het toestel en een virtueel bestandssysteem. Dit omvat het publiceren van bestanden naar een opslagdienst, maar ook het aanbieden van een peer-to-peer opslagdienst op het toestel. Hiernaast bevat dit subsysteem ook het beheer van de lopende bestandsoverdrachten.

4.6.1

Overzicht

WKPublishController

Deze klasse en de bijhorende hulpklassen staan in voor het publiceren van

bestanden naar een opslagdienst. Hiervoor worden eerst gegevens verstuurd naar een HTTP-opslagdienst en wordt vervolgens via de File System-laag een bestandsreferentie toegevoegd die verwijst naar deze gegevens.

WKP2PStorageService

WakaWaka instantieert van deze klasse maximum één object, dat instaat

voor de ingebouwde HTTP-server die een lokale opslagdienst aanbiedt. Deze opslag laat toe dat bestanden peer-to-peer uitgewisseld worden tussen toestellen van gebruikers.

WKTransfer, WKTransfersController

Objecten van de WKTransfer-klasse stellen een bestands-

overdracht voor. Dit kan zowel om een upload als een download gaan. Ze houden de huidige vooruitgang bij zodat die aan de gebruiker getoond kan worden. De globale WKTransfersController aggregeert deze transfers in een overzichtelijke lijst. Zo is het mogelijk om meerdere overdrachten tegelijkertijd uit te voeren, iets wat in mobiele applicaties dikwijls onmogelijk is.

4.6.2

Opmerkingen

Omwille van de enorm onpraktische werkwijze van de proof-of-concept Storage Service binnen het PeCManprototype werd besloten er geen gebruik te maken. In plaats daarvan is er binnen WakaWaka een peer-topeer storage-dienst ingebouwd (WKP2PStorageService) om bestanden tussen toestellen uit te wisselen. Deze service werkt over HTTP voor een betere betrouwbaarheid, en is dus een (zeer beperkt) prototype voor de verbeteringen zoals ze in hoofdstuk 6 beschreven staan.

4.7 PeCMan

4.7

45

PeCMan

De uiteindelijke versie van WakaWaka integreert met een PeCMan-server die licht is aangepast sinds de aanvang van de masterproef. Omdat de serversubsystemen die momenteel instaan voor de PeCManfunctionaliteit overwegend van proof-of-conceptkwaliteit zijn, is geopteerd voor het grotendeels behouden van de bestaande protocollen om een werkende demonstratie te kunnen afleveren. De File System Service heeft een grondige herstructurering en gedeeltelijke herimplementatie nodig om alle structurele gebreken te verhelpen. Omdat een kwaliteitsvolle herimplementatie van de serverzijde buiten het bestek van deze masterproef valt, werd in hoofdstuk 6 gekozen voor een theoretische benadering die gebaseerd is op de reële problemen die naar voren kwamen tijdens de implementatie van een volledige PeCMan-client. Tegelijkertijd twee kanten van een brug naar mekaar toe bouwen is af te raden, en is gedeeltelijk de oorzaak van de problemen met het huidige serversysteem. Aangezien er dus wel wijzigingen nodig waren om de basisfunctionaliteit van WakaWaka te doen werken, worden die hier kort gedocumenteerd. In tegenstelling tot bij de implementatie van WakaWaka ging hier geen uitgebreid ontwerp aan vooraf en werd evenmin veel rekening gehouden met de kwaliteit van de code. De volgende aanpassingen werden aangebracht: • De bestaande dienst had geen enkele ondersteuning voor het verwijderen van bestanden of mappen, wat enigszins problematisch was bij het schrijven van een nuttige client. Deze ondersteuning is toegevoegd aan de Java-code. Ook het aanmaken van mappen en bestanden is bijgewerkt om op een eenvoudige padgebaseerde manier te kunnen werken. • Voor SUBSCRIBE-berichten negeerde de implementatie parameters die toegevoegd werden bij de Event-header, terwijl ze volledig overgenomen moeten worden. Dit zorgde voor een probleem met de PJSIP-bibliotheek in WakaWaka die geen onderscheid meer kon maken tussen inschrijvingen. NOTIFY-berichten bevatten nu ook de extra identificatie die in de inschrijving meegegeven werd. • Bij wijzigingen aan het bestandssysteem via PUBLISH-berichten werd geen enkele client op de hoogte gebracht via een NOTIFY-bericht. Dit was opnieuw een fundamenteel gebrek dat min of meer opgelost is door de aangepaste code. Door de dooreengetrokken structuur van Proxy en File System Service blijven er echter nog gevallen bestaan waarin NOTIFY-berichten niet zoals verwacht verstuurd worden. De oorzaak hiervan kon voorlopig niet achterhaald worden. • De File System Service respecteert in sommige gevallen het sequentienummer binnen de SIP-dialoog niet (de waarde in de CSeq header). Binnen een dialoog moet een CSeq waarde steeds incrementeren bij elke bericht in een bepaalde richting. In sommige gevallen kreeg het sequentienummer echter terug een lagere waarde. Hiervoor is een tijdelijke oplossing toegevoegd die een globaal sequentienummer verhoogt en dat meegeeft als waarde voor de CSeq-header van NOTIFY-berichten.

4.7 PeCMan

46

• De ingebouwde Storage-dienst werd niet gebruikt voor WakaWaka omdat de integratie ermee te onbetrouwbaar en onvoorspelbaar is. Om toch bestanden te kunnen uitwisselen tussen twee clients werd de adresseringscode aangepast zodat gebruik gemaakt kan worden van de ingebouwde peerto-peer storage in WakaWaka.

EVALUATIE

47

Hoofdstuk 5

Evaluatie In dit hoofdstuk worden de uitgevoerde tests uiteengezet. Deze analyses gebeurden in het kader van de prestaties van de client. Hieronder verstaan we zowel de snelheid van uitvoering op het toestel als de netwerkprestaties bij veelvoorkomende taken in een typische PeCMan-workflow. Na de beschreven tests wordt nagegaan in hoeverre WakaWaka voldoet aan de vooropgestelde vereisten. We eindigen met een overzicht van eventueel verder werk dat nog kan gebeuren in de ge¨ımplementeerde subsystemen.

5.1

Testomgeving

Mobiel toestel Voor alle tests werd gewerkt met een iPhone 3G, waarop iPhone OS 3.0 ge¨ınstalleerd staat. Dit toestel beschikt over een processor van 412 MHz en 128 MB RAM-geheugen. Bij het meten van snelheid is werken met een echt toestel de enige optie, omdat de iPhone Simulator op een gewone Mac dezelfde code sneller uitvoert. De resultaten die verder worden voorgesteld zijn dus afhankelijk van het gebruikte toestel. Als WakaWaka bijvoorbeeld op een nieuwe iPhone 3G S uitgevoerd wordt, kan een snelheidswinst van minstens 30% verwacht worden dankzij de snellere processor (600 MHz) en dubbel zoveel geheugen (256 MB). De gebruikte iPhone 3G kan theoretisch tot 3,6Mbps HSDPA-download en 384kbps UMTS-upload aan. De netwerkomstandigheden dicteren echter de reële snelheid bij het testen over het 3G-netwerk.

Tools Om niet in herhaling te vallen in de volgende secties bespreken we hier kort de tools die gebruikt zijn voor het tunen en bestuderen van de prestatiekarakteristieken van WakaWaka.

5.2 Prestatie-analyse

Uitvoeringssnelheid

48

Voor het analyseren van de uitvoeringssnelheid was het belangrijkste hulpmiddel

Instruments. Deze toepassing zit standaard bij de iPhone Developer Tools, en bevat modules die allerhande informatie verzamelen over de uitvoering van de ontwikkelde applicatie. De belangrijkste hiervan is CPU Sampler, maar ook de geheugengerelateerde modules zijn nuttig om geheugengebruik te beperken. De CPU Sampler toont voor de code in het programma het percentage van de uitvoeringstijd die erin doorgebracht wordt. Andere modules dienen om geheugenlekken op te zoeken, het aantal aanwezige objecten te tonen, enz. Naast Instruments kwam het oude vertrouwde loggen naar de console altijd wel van pas. Om een eenvoudig tijdsverschil te meten is een aantal welgeplaatste logs voldoende en zeer nuttig. In het geval van Objective-C wordt in de code de functie NSLog() gebruikt. Handmatig uittesten blijft uiteraard van uiterst belang, want het gevoel van snelheid blijft een subjectieve aangelegenheid.

Netwerk

Voor het bestuderen van de netwerkinteractie tussen client en server werd hoofdzakelijk de

ingebouwde logging-capaciteit van de gekozen SIP-bibliotheek gebruikt. Anderzijds was ook Wireshark [17] een nuttig hulpmiddel om een uitgebreidere kijk te krijgen op de invloed van de SIP-berichten op het netwerk. Het loggen van berichten is zeer nuttig om de dialogen te kunnen volgen en te kijken welke gevolgen verschillende netwerkomstandigheden hebben op de gedragingen van het SIP-protocol. Wireshark werd vooral gebruikt om concrete metrieken te bepalen voor de netwerkperformantie.

5.2

Prestatie-analyse

Prestatie-onderzoek is voor zowat elk project een goed idee, maar voor voor mobiele toepassingen is het van uiterst belang. Mobiele platforms brengen immers tal van beperkingen met zich mee, zowel technische als door de gebruiker opgelegde. We moeten rekening houden met de beperkte rekenkracht van het toestel, de tragere netwerkomgeving, de batterijduur, het verbruik van bandbreedte, enz. Een trage gebruikerservaring zorgt bovendien voor veel frustratie. We bespreken in dit gedeelte de belangrijkste prestatiegerichte beslissingen die genomen werden tijdens de ontwikkeling van WakaWaka.

5.2.1

Werkelijke en waargenomen prestaties

Vooraleer we overgaan tot het bespreken van prestatie-analyses die WakaWaka sneller hebben gemaakt, moeten we het enorme belang van de menselijke waarneming benadrukken. Aangezien de PeCMan-client van deze masterproef gemaakt is voor een mobiel platform, is er slechts een beperkte rekenkracht. Voor sommige operaties is het dus onmogelijk ze nog te verbeteren eens een zeker minimum bereikt wordt. Hoewel het technisch onmogelijk kan zijn om een actie sneller te maken, is het wel mogelijk de menselijke waarneming te benutten om de actie sneller te doen lijken.


49

Wachttijden in computerinterfaces vormen een interessant onderzoeksonderwerp ([15], [16]) omdat manipuleren van de waarneming geen exacte wetenschap is zoals het meten van de uitvoeringstijd van een algoritme. De algemene consensus is dat een wachttijd niet lineair waargenomen wordt. Er is een drempelzone waaronder mensen een duurtijd als korter dan werkelijk ervaren, en waarboven de duurtijd langer lijkt dan echt het geval is. Wanneer dit juist gebeurt ligt hangt af van persoon tot persoon, van omstandigheden en tal van andere factoren die onze waarneming be¨ınvloeden. Onder de 1 à 2 seconden kunnen we echter aannemen dat het menselijk brein ons enig geduld verleent, nadien wordt de wachttijd als storend ervaren. De psychologische invloed van wachttijden is een universeel gegeven, maar men kan argumenteren dat het probleem groter is op een mobiel toestel dan op bijvoorbeeld een gewone PC. De gebruiker is namelijk actief bezig met het toestel, en door de beperkte schermgrootte is de huidige applicatie over het algemeen de enige die zichtbaar is. Deze intense focus zorgt ervoor dat eventuele wachttijden uitvergroot worden, waardoor zichtbare feedback bij een wachttijd cruciaal is. In zijn eenvoudigste vorm is dat bijvoorbeeld een balkje dat de expliciete vooruitgang toont. Hoewel dit bij langere wachttijden (5 s en langer) interessant kan zijn, is het voor een relatief korte wachttijd eerder storend. Een interessantere optie is het verbergen van de wachttijd door een visuele actie te verrichten vooraleer de resultaten te tonen. Dit concept wordt in het iPhone OS tot in het extreme toegepast, en is een grote factor in de aangename gebruikerservaring bij een goede iPhone-applicatie. Een goed voorbeeld is het openen van een applicatie. In plaats van het icoon te activeren en de applicatie te tonen nadat de code geladen is, zoomt de iPhone een tijdelijke opstartafbeelding in tijdens het laden. Ondertussen kan de applicatie initialiseren en wordt de resterende wachttijd beperkt. Dankzij de animatie is de menselijke waarnemingsdrempel effectief verschoven. Een geldige kritiek is dat animatie ook rekenkracht vereist, waardoor de eigenlijke activiteit langer zal duren dan strikt nodig is. Dit is een afweging die per geval moet gemaakt worden. Bij het opstarten van een applicatie is het bijvoorbeeld aantrekkelijker om 1 seconde lang een animatie te bekijken dan 0,75 s te wachten en plots de applicatie op het scherm te zien verschijnen. Dit is opnieuw te wijten (of te danken) aan de menselijke waarneming, die moeilijk een onderscheid kan maken tussen kleine tijdsintervallen. Gemiddeld kan animatie zeker een halve seconde meer speling geven aan een actie die anders onmiddellijk klaar zou moeten zijn.

5.2.2

Opstartsnelheid

De opstartsnelheid van een mobiele applicatie is één van de belangrijkste gebieden waar prestatie-analyse nodig is. De ervaring bij het opstarten is immers de eerste kennismaking met de software, en zoals gewoonlijk weegt de eerste indruk zwaar door. Daarom is er bij de prestatieverbeteringen van WakaWaka veel aandacht gegaan naar het optimaliseren van de opstarttijd.


50

In eerste instantie moest onderzocht worden welke activiteiten er plaatsvinden tijdens het openen van de applicatie. Voor er enige verbeteringen werden aangebracht zorgden de volgende operaties voor het merendeel van de rekentijd: • Laden van de applicatie-UI via een standaard NIB-bestand (bevat een definitie van de interface en wordt gegenereerd door de visuele ontwerptoepassing Interface Builder) • Aanmaken van allerhande controllers voor zowel de hoofd-UI als secundaire functies • Initialiseren van SIPCore en de onderliggende PJSIP-bibliotheek Uitgemiddeld over 10 metingen was de duurtijd van het oproepen van UIApplicationMain() tot het weergeven van het gebruikersvenster 0,974 s. Ongeveer 20% van de uitvoeringstijd zat in het laden van de UI vanuit een bestand, 35% in het laden van SIPCore en de overige 45% werd verdeeld over het aanmaken van de verschillende controllers. Het laden van de UI vanuit een bestand bleek onnodig, omdat de belangrijkste aspecten reeds volledig in code werden aangemaakt. Bovendien zorgde deze manier van laden ervoor dat een aantal controllers bij het opstarten werden aangemaakt die niet noodzakelijk waren. Zo werd bijvoorbeeld altijd een connectie-dialoog aangemaakt, terwijl die niet getoond wordt als de gebruikersgegevens van de vorige sessie nog opgeslagen zijn. Na het aanpassen van deze zaken werd de uitvoeringstijd gereduceerd tot gemiddeld 0,681 s. Na deze eerste ronde optimalisaties bestond het beheersbare gedeelte van het opstartproces nog uit de volgende taken: • Aanmaken van de hoofdcontrollers die de UI beheren • Initialiseren van SIPCore en de onderliggende PJSIP-bibliotheek Het maken van de UI-controllers is een absolute vereiste die geen aanzienlijke verbeteringen meer toelaat. Het laden van SIPCore daarentegen is in feite niet nodig tijdens het opstarten. Aangezien er voor de Opstarttijd

verbinding met de server aanwezig zal zijn, is het beter om de initialisatie van 0,974 Origineel toch een zekere latentie na 1e optimalisatie

0,681

de module dan te laten gebeuren. Uiteindelijk na 2e optimalisatie 0,368 zorgde deze eliminatie ervoor dat het opstartproces in gemiddeld 0,368 s kon voltooid worden. Spijtig genoeg was dit nog enigszins merkbaar bij het opstarten van de applicatie. 0,974 s 0,681 s 0,368 s

Figuur 5.1: Originele opstartsnelheid; na 1e optimalisatie; na 2e optimalisatie


51

Om de ervaring verder te verbeteren werd tenslotte een zogenaamde launch placeholder toegevoegd. Dit is een statische afbeelding (Default.png) binnen de applicatie die automatisch ingezoomd wordt bij het opstarten van de applicatie. De inhoud ervan is vrij te kiezen, maar in WakaWaka is gekozen voor een lege versie van de initiële UI. Een volledige schermafbeelding van de standaardinhoud zou een betere overgang vormen, maar dit wordt meestal vermeden omdat de gebruiker niet kan werken met de interface tot de placeholder weggehaald is. Een exacte replica van de UI maakt dat de gebruiker niet kan merken wanneer de overgang gebeurt.

5.2.3

Inactiviteit

Een belangrijke factor in het besparen van de batterij is het vermijden van continue operaties die uitvoeren terwijl de gebruiker niet actief werkt met de applicatie. Hieronder verstaan we vrijwel alle werk dat niet rechtstreeks ten gevolge van een gebruikersverzoek gebeurt. Na analyse van de “inactieve” uitvoering van WakaWaka werden de volgende processen bepaald als de hoofdoorzaak van rekenwerk: • Vernieuwen van de registratie door het sturen van REGISTER-berichten • Bevestigen van inschrijvingen door het sturen van periodieke SUBSCRIBE-berichten • Afhandelen van nieuwe SIP-events door de PJSIP-bibliotheek REGISTER- en SUBSCRIBE-berichten Deze twee processen zijn beide nodig, maar er moet een afweging gemaakt worden tussen prestaties en bewaren van de netwerkfuncties. We zouden bijvoorbeeld slechts om de 5 minuten een registratie kunnen bijwerken, maar als de netwerkconfiguratie verandert kan het dan tot 5 minuten duren vooraleer SIPcommunicatie terug normaal kan verlopen. Hetzelfde geldt voor het bijwerken van inschrijvingen op een bestandssysteem. We gebruiken standaard de volgende tijdsintervallen voor WakaWaka: • REGISTER om de 45 seconden: dit is iets korter dan de gewoonlijke 60 seconden, omdat de netwerkomstandigheden bij een mobiel toestel sneller kunnen veranderen. • SUBSCRIBE om de 90 seconden: dit is een langer interval omdat wijzigingen via NOTIFY binnenkomen en de berichten voor elke inschrijving afzonderlijk worden verstuurd, wat er in principe willekeurig veel kunnen zijn. Afhandelen van SIP-events De gebruikte SIP-bibliotheek werkt met een afzonderlijke draad die instaat voor het behandelen van nieuwe SIP-berichten en toestandswijzigingen. Dit gebeurt door het herhaald oproepen van pjsua handle events().


52

Standaard veroorzaakt de bibliotheek hierdoor zelfs zonder enige SIP-activiteit een gemiddeld CPUverbruik van 2 ` a 4%. Na inspectie van de broncode blijkt dat deze draad elke 10 milliseconden controleert of er nieuw werk moet gebeuren in het SIP-subsysteem. Dit gebeurt dus ongeveer 100 keer per seconde, meestal zonder dat er nieuwe events aanwezig zijn. Tijdsinterval 10 ms 20 ms 30 ms 40 ms 50 ms 100 ms

CPU-gebruik 1,2-3,9% 0,9-2,9% 0,9% afwisselend 0,9% en 0% meestal 0% en soms 0,9% meestal 0% en soms 0,9%

Tabel 5.1: Gedrag van het CPU-gebruik bij inactiviteit, afhankelijk van het gekozen polling interval Aangezien WakaWaka geen real-time communicatie vereist en ontworpen is om latentie te verbergen van de gebruiker, was het een goed idee om hier een prestatieverbetering te onderzoeken. Om een beter zicht op de situatie te krijgen werden intervals tot 100ms uitgetest. Grotere intervals kunnen best vermeden worden omdat ze de snelheid van SIP-communicatie potentieel te zwaar be¨ınvloeden. Een wachttijd van 100ms kan al snel zorgen voor een minimale waargenomen round-trip-time van 200ms. Voor WakaWaka is het interval daarom vastgelegd op 50ms, een goed compromis tussen reactietijd en CPU-verbruik.

5.2.4

XML-verwerking

De centrale functionaliteit van WakaWaka is het verwerken van virtuele bestandssystemen. Het spreekt dus vanzelf dat dit proces ook bekeken moet worden met snelheid in het achterhoofd. Het laden van een bestandssysteem kan opgedeeld worden in enkele discrete stappen: • Aanvragen van de SIP-subscription voor het bestandssysteem • Ontvangen van de XML-gegevens van de PeCMan-server • Verwerken van de ontvangen data en omzetten tot een interne representatie Aan de snelheid van de eerste twee punten is weinig te verbeteren zonder bijhorende aanpassingen aan de server, dus richten we ons hier op het interpreteren van XML en genereren van een interne voorstelling. Versnellen van de parser Het eerste objectief was het werkelijk meten en hopelijk versnellen van de parser-routines. Wegens een beperking van de huidige PeCMan-server zijn deze tests uitgevoerd met lokale XML-bestanden i.p.v. gegevens die effectief van de server kwamen. XML-bestanden groter dan 64KB worden namelijk gewoon


53

niet doorgestuurd door de server. Voor de resultaten is dit niet van belang, aangezien de prestaties voor gelijke XML-gegevens gelijk zijn onafhankelijk van de afkomst. De verschillende testcases zijn de volgende: • flat-files: Een test waarbij het XML-bestand een collectie van enkel bestanden bevat. Deze test werd uitgevoerd met 250, 500, 1000, 2000, 5000 en 10000 bestanden. • nested-dir: Een test waarbij de structuur bestaat uit een steeds diepere hiërarchie van mappen. Deze test werd uitgevoerd met een diepte van 250, 500 en 1000 mappen. Duizend mappen is voor een persoonlijk volume op een mobiel toestel een realistische bovengrens. Analyse van de uitvoering met Instruments toonde aan dat ongeveer 40% van de uitvoeringstijd doorgebracht werd in code van WakaWaka zelf. Het overige werk gebeurde in NSXMLParser, de ingebouwde klasse om XML te verwerken in de iPhone SDK. Inspectie van de originele code leverde een aantal interessante inzichten op. De uitvoeringstijd was verspreid over de gehele opbouw van de interne representatie, maar een aanzienlijk deel van het werk was eigenlijk slechts nodig zodra de bestanden of mappen in kwestie worden afgebeeld op het scherm. We konden dus duidelijk de techniek van “lazy loading” toepassen om een prestatieverbetering te bekomen. Bovendien werd de volgorde van een aantal controlepunten aangepast om rekening te houden met de waarschijnlijkheid dat er meer bestanden dan mappen op het volume voorkomen. Na het herwerken van de code en het weghalen van een aantal kleine stukken die dubbel werk veroorzaakten, werd toch een mooie prestatiewinst van om en bij de 40% bekomen voor de flat-files test. Bij de nested-dir test ligt het anders omdat de code daar al vrij goed georganiseerd was, en de wijzigingen in controlevolgorde nadelig zijn voor deze uitzonderlijke situatie. We gaan er immers van uit dat er vooral bestanden aanwezig zijn, terwijl in deze test enkel mappen voorkomen. Toch zorgen de andere optimalisaties ervoor dat we een heel kleine snelheidswinst boeken.

flat-files Duurtijd (s) Verbeterde duurtijd (s) Prestatiewinst nested-dir Duurtijd (s) Verbeterde duurtijd (s) Prestatiewinst

250 0,239 0,137 43% 250 0,240 0,236 2%

500 0,434 0,274 37% 500 0,486 0,463 5%

1000 0,852 0,544 36% 1000 0,961 0,923 4%

2000 1,805 1,075 40% 2000 – – –

5000 4,233 2,700 36% 5000 – – –

10000 8,408 5,402 36% 10000 – – –

Tabel 5.2: Resultaten van snelheidsmetingen voor de XML-verwerking van een bestandssysteem


54

8,408 s

4,233 s

1,805 s 0,239 s

250 files

0,434 s

0,852 s

500 files

1000 files

2000 files

5000 files

10000 files

Figuur 5.2: Resultaten van de flat-files-test voor en na optimalisatie Beperken van het geparste materiaal Hoewel de prestaties van de XML-parser zelf verbeterd kunnen worden, blijft het een feit dat de duurtijd verhoogt naarmate de inhoud van het bestandssysteem groeit. De enige optie naast het versnellen van het werk is minder werk uitvoeren. Dit kan gebeuren op twee manieren. • Momenteel stuurt de PeCMan-server steeds het volledige bestandssysteem door. Mits toevoeging van de nodige serverprotocollen zou een client slechts een gedeelte van het bestandssysteem kunnen opvragen. Terwijl de gebruiker navigeert doorheen de hiërarchie kunnen dan bijkomende stukken geladen worden. • Een truc die door een aantal iPhone-applicaties wordt toegepast is het gebruik van een “Load More”knop onderaan lijsten die potentieel zeer lang kunnen worden. In principe zou het mogelijk moeten zijn om een gedeelte van de XML-definities nog niet om te zetten naar een interne voorstelling tot er expliciet naar gevraagd wordt. Het probleem is echter dat deze aanpak goed werkt voor lijsten die gesorteerd zijn van nieuw naar oud, maar niet praktisch is wanneer we werken met ongesorteerde of alfabetisch geordende gegevens zoals bij WakaWaka. De beste optie is in dit geval de eerste, omdat dan ook de hoeveelheid netwerkverkeer beperkt wordt. Deze functionaliteit wordt momenteel echter niet aangeboden in de server, maar wordt besproken in hoofdstuk 6.

5.2.5

Batterijduur

Er werden geen specifieke tests uitgevoerd om het batterijverbruik van WakaWaka te meten. Hiervoor zijn enkele redenen: • De effectieve batterijduur kan enorm fluctueren door andere processen die het toestel naast de actieve gebruikersapplicatie uitvoert, wat een correcte meting zwaar bemoeilijkt.

5.3 Netwerk-analyse

55

• Verschillende toestellen die het iPhone OS gebruiken (iPhone, iPhone 3G, iPhone 3G S, iPod touch) hebben allemaal andere batterijkarakteristieken, en een meting op één type geeft dus weinig algemene informatie. • Het is nuttiger om de relatieve snelheidsverbeteringen zoals in de vorige secties te documenteren, omdat dit een correct beeld geeft voor eender welk toestel waar de applicatie op kan werken. • Een meting waarbij WakaWaka actief is tot de batterij afloopt is weinig realistisch. Eindgebruikers zullen typisch korte sessies houden om hun multimedia te beheren of te bekijken, en dan de applicatie terug afsluiten.

5.3

Netwerk-analyse

5.3.1

XML-uitwisseling

Het belangrijkste netwerkverkeer bij PeCMan is de uitwisseling van bestandssystemen via de XMLvoorstelling. De server die gebruikt werd bij het ontwikkelen van WakaWaka stuurt deze gegevens mee in de verstuurde SIP-berichten. Enkele eenvoudige tests tonen al snel aan dat deze aanpak onbruikbaar wordt in realistische gebruiksscenario’s. Het versturen van XML-data werd getest met zowel UDP- als TCP-transport. Beide gevallen hebben hun eigen problemen. Als test werd een XML-bestandssysteem van 100KB aangemaakt voor één van de gebruikers die geregistreerd staan bij de server. Vervolgens wordt er gewoon ingelogd met WakaWaka.

UDP De bevindingen bij UDP als transport zijn als volgt: • SIP berichten boven +/- 64KB veroorzaken een exceptie in de Java SIP-stack van de server. Grote bestandssystemen worden dus niet verstuurd. • SIP berichten die groter zijn dan 1500 bytes kunnen niet langer betrouwbaar gebruikt worden over UDP wegens fragmentatie en pakketverlies.

TCP Dankzij de ingebouwde foutafhandeling en hersamenstelling van TCP kan de server willekeurig grote berichten sturen. De PJSIP-bibliotheek heeft echter een beperkte buffergrootte voor binnenkomende berichten, waardoor de applicatie niet kan omgaan met onbeperkt grote berichten. Het is dus onmogelijk om een onbeperkte hoeveelheid gegevens te ontvangen in één bericht.

5.3 Netwerk-analyse

56

Conclusie Beide types transport hebben problemen met zelfs relatief kleine bestandssystemen. Een actieve gebruiker komt al snel aan 1000 bestanden, waarmee we reeds over de toegestane limiet zitten. Bijgevolg is de huidige aanpak van volledige XML-beschrijvingen mee te sturen onbetrouwbaar. WakaWaka is ontworpen om de manier van bestandssystemen ophalen af te schermen van de rest van de applicatie. Dit laat toe de client eenvoudig over te schakelen naar een nieuw serversysteem zoals beschreven in hoofdstuk 6.

5.3.2

Latentie

WakaWaka verbergt latentie waar mogelijk, maar het is toch nuttig te onderzoeken in welke mate latentie voorkomt bij interactie met de PeCMan-server. Alle metingen gebeurden op een echt toestel (zie 5.1). Voor deze test werd de normale inlogprocedure van WakaWaka herhaaldelijk uitgevoerd en werd het tijdsverschil gemeten tussen het sturen van een SIP-bericht en het ontvangen van een antwoord. Dit tijdsinterval bevat de volgende componenten: • De Round-Trip Time (RTT) van het gebruikte netwerk. Deze kan zwaar fluctueren naarmate de netwerkomstandigheden veranderen. In de beschreven tests is het aantal netwerkknopen dat de RTT be¨ınvloedt beperkt omdat zowel client als server zich binnen België bevinden. Dit aspect van de totale duurtijd is overwegend voor het resultaat. • De duurtijd voor het versturen en ontvangen van de berichten over het netwerk. We meten dus niet de RTT van het netwerk in de traditionele zin. • De verwerkingstijd van het bericht bij de server. We kunnen aannemen dat deze verwaarloosbaar is t.o.v. de RTT, aangezien de testserver geen groot volume berichten moet afhandelen. • Eventuele retransmissies van het bericht of het antwoord. Dit zal zich manifesteren als een aanzienlijke verlenging van de totale duurtijd. Herverzenden kan gebeuren ten gevolge van timeouts of werkelijk pakketverlies. De hoeveelheid pakketverlies (die de nood aan retransmissies bepaalt) is zeer afhankelijk van de signaalsterkte voor de verbinding. De metingen betreffen alle SIP-berichten die het toestel verlaten tijdens de inlogprocedure. Dat zijn enkel REGISTER- en SUBSCRIBE-berichten. Naast die metingen werd ook de tijd onderzocht tussen het sturen van een SUBSCRIBE-bericht en het ontvangen van de bijhorende NOTIFY. Deze berichtenstromen zijn immers de belangrijkste voor de werking van de client. De tests werden uitgevoerd in een stedelijke omgeving waarbij het toestel op dezelfde fysieke locatie bleef, dus we kunnen ervan uitgaan dat de RTT en het pakketverlies tot een realistisch minimum beperkt waren. De waarden zijn gemiddelden van een test die loopt over een sessie van 15 minuten.

5.3 Netwerk-analyse

57

4,02 s

Register-OK

3,395 s

Subscribe-Notify

1,716 s

0,239 s

0,309 s

WiFi / UDP

WiFi / UDP WiFi / TCP 3G / UDP 3G / TCP GPRS / UDP GPRS / TCP

0,561 s

0,973 s

0,992 s

1,058 s

1,741 s

1,103 s

0,334 s

WiFi / TCP

3G / UDP

Register-OK (gem.) 0,239 s 0,561 s 0,973 s 1,058 s 1,716 s 3,395 s

3G / TCP

Min 0,231 s 0,312 s 0,426 s 0,368 s 0,654 s 0,919 s

GPRS / UDP

Max 0,411 s 3,132 s 2,006 s 3,254 s 4,853 s 5,463 s

GPRS / TCP

Subscribe-Notify (gem.) 0,309 s 0,334 s 0,992 s 1,103 s 1,741 s 4,020 s

Tabel 5.3: Duurtijden voor het volledig afhandelen van één SIP-bericht Bij deze resultaten kan men enkele aantekeningen maken: • Tegen de verwachtingen in is UDP niet altijd sneller dan bij TCP: de minimale duurtijd bij 3G is langer. De maximale afhandelingstijd is wel korter, een resultaat dat hoogstwaarschijnlijk stemt uit het feit dat PJSIP bij UDP-transport onmiddellijk 4 gedupliceerde REGISTER-berichten verstuurt als preventie voor pakketverlies-gerelateerde vertraging. Zelfs als er enkele verloren gaan zullen de anderen de server bereiken voor er met TCP een retransmissie kan plaatsvinden. • Bij gebruik van GPRS is UDP wel merkbaar sneller, wat doet vermoeden dat UDP een betere keuze wordt naarmate de verbinding trager en onbetrouwbaarder wordt. Bij 3G en WiFi wordt het verschil soms praktisch verwaarloosbaar, hoewel UDP over het algemeen een licht betere prestatie vertoont. • Het tijdsinterval tussen het versturen van een SUBSCRIBE en het ontvangen van een NOTIFY is slechts een beetje langer dan die voor een register. Dit bevestigt het vermoeden dat de RTT van de verbinding de belangrijkste factor is. • Het resultaat voor TCP over WiFi vertoont een lichte abnormaliteit: de gemiddelde waarde voor Subscribe-Notify ligt lager dan die voor Register-OK. Deels kan dit te wijten zijn aan de frequentie waarmee zowel de server als de client berichten verwerken, anderzijds zitten er bij Register-OK ook meer uitschieters die het gemiddelde naar boven halen. We kunnen stellen dat de gegevens het vermoeden bevestigen dat UDP meer geschikt is voor de SIPcommunicatie. Op enkele uitzonderingen na is UDP sneller dan TCP. Latentie is echter niet de enige zorg bij een mobiele client, en zoals de volgende sectie aan zal tonen is er sprake van een trade-off.

5.3 Netwerk-analyse

5.3.3

58

Datavolume

De in het vorige punt uiteengezette tests werden uitgevoerd met het controleren van latentie in gedachte. Het is voor een mobiele client echter ook belangrijk om te kijken hoeveel dataverkeer er plaatsvindt, aangezien dit gefactureerd wordt of meetelt voor een datalimiet. Bijgevolg tonen we nu de hoeveelheid gegevens die op een kwartier inactiviteit van WakaWaka veroorzaakt werden. De vermelde waarden zijn afkomstig van de teller op de iPhone voor data uitgewisseld over het mobiele netwerk. Aangezien de iPhone dergelijke gegevens niet meedeelt voor WiFi en omdat een WiFi-verbinding meestal quasi ongelimiteerd is (in verhouding tot mobiele verbindingen), behandelen we hier enkel 3G en GPRS. 3G / UDP 3G / TCP GPRS / UDP GPRS / TCP

Download 50 kB 41 kB 87 kB 44 kB

Upload 9 kB 9 kB 12 kB 13 kB

Totaal 59 kB 50 kB 99 kB 57 kB

Tabel 5.4: Uitgewisseld datavolume bij 15 minuten inactiviteit Hoewel de gegevens waarschijnlijk intern afgerond worden en mogelijk niet volledig betrouwbaar zijn, geven ze toch een nuttige indicatie waaruit we een aantal besluiten kunnen trekken. • UDP zorgt voor meer dataverkeer, in het geval van GPRS zelfs een verdubbeling van de hoeveelheid downstream gegevens. Dit is vooral te wijten aan het dubbel verzenden van gegevens om preventief om te springen met pakketverlies en vertragingen. • Over TCP is de hoeveelheid gegevens bij 3G en GPRS zeer gelijkaardig, wat te verwachten is omdat TCP enkel retransmissies regelt als er vrij zeker een pakket verloren is gegaan. • TCP heeft iets meer overhead per pakket t.o.v. UDP, maar compenseert dit ruim door minder pakketten te versturen. • Voor 15 minuten niets doen zijn de bekomen gegevenshoeveelheden eigenlijk relatief groot. Er is dus zeker nog ruimte voor aanpassen van de parameters en voor serveroptimalisaties. Na deze resultaten lijkt TCP op vlak van dataverkeer duidelijk een betere keuze. Samen met de vaststelling uit het vorige punt dat wat latentie betreft het verschil met UDP niet opzienbarend is, kunnen we ons duidelijk afvragen of UDP wel de geschikte keuze is voor communicatie met de PeCMan-server. Latentie kan tenslotte verborgen worden door de gebruikersinterface, maar het dataverkeer komt onverbiddelijk terecht op een factuur. Uiteindelijk is voor WakaWaka het standaardtransport op UDP ingesteld, omdat het dataverkeer in belangrijke mate veroorzaakt wordt door een prototype-server die niet geoptimaliseerd is en in feite meer gegevens dan strikt nodig doorstuurt.

5.4 Toetsen aan vooropgestelde doelen

5.4

59

Toetsen aan vooropgestelde doelen

In dit onderdeel wordt nagegaan in welke mate WakaWaka voldoet aan de vooropgestelde doelstellingen. Vormt het een goede demonstratie van PeCMan zoals de bedoeling was?

Effici¨ ent omspringen met beperkingen Tijdens de ontwikkeling werden tal van optimalisaties toegevoegd, en er werden uitgebreide tests uitgevoerd om eventuele prestatieproblemen te detecteren. Het is zeker en vast mogelijk om WakaWaka nog verder te versnellen, maar als eerste versie zorgen de huidige prestaties zeker voor een bruikbare ervaring. Met de netwerkperformantie ligt het anders omdat het verbeteringspotentieel hier beperkt wordt door de serverzijde van PeCMan. De bekomen resultaten voor de netwerktests zijn niet bijzonder indrukwekkend, maar spijtig genoeg zijn er fundamentele serveraanpassingen nodig voor een aanzienlijke prestatiewinst (zie hoofdstuk 6).

Verbergen van netwerkoperaties Het File System-subsysteem gaat praktisch overal uit van een succesvolle uitvoering van serveroperaties waardoor de gebruikersinterface een tijdelijke representatie gebruikt die hoogstwaarschijnlijk snel bevestigd zal worden. Indien er toch een fout optreedt wordt dat aan de gebruiker meegedeeld. Omdat de tijd tussen het uitvoeren van de operatie en de bevestiging kort genoeg is, kan de gebruiker meestal niet snel genoeg een nieuwe actie ondernemen zodat die problemen ondervindt door tijdelijke resultaten van een onbevestigde operatie. Dit verbergen van latentie verhoogt de gebruiksvriendelijkheid aanzienlijk. Bij sommige acties is het onmogelijk gebleken om de netwerkaspecten te verbergen. Een voorbeeld is het laden van de werkelijke inhoud van een bestand. Omdat hiervoor gewacht moet worden tot de gegevens volledig aangekomen zijn is gekozen voor het weergeven van de huidige vooruitgang.

Aantrekkelijke gebruikersinterface De gebruikersinterface van WakaWaka ziet er mooi afgewerkt uit dankzij het volgen van de iPhone designrichtlijnen. Er werd een passend icoon gemaakt voor de applicatie met een knipoog naar Pac-Man om het persoonlijk karakter te verhogen. Ook binnen de applicatie werd tijd gestoken in het verfijnen van grafische details. Naast de grafische aspecten wordt de gebruiksvriendelijkheid ook bepaald door de workflow. WakaWaka poogt om alle belangrijke acties overzichtelijk te tonen, en slaagt daar vrij goed in gegeven de beperkte ruimte die beschikbaar is op een mobiel toestel.

5.5 Verder werk

60

Toegevoegde waarde Naast een goede ervaring voor de basisfunctionaliteit voegt WakaWaka ook de mogelijkheid toe om zich in te schrijven op andere gebruikersvolumes, en om zoekopdrachten te verrichten op de bekeken bestandssystemen. Dit laat zeer handige filters toe zoals de “Nearby”-zoekopdracht, maar momenteel is het nut van deze functies beperkt wegens een gebrek aan ondersteuning voor dynamische volumes die zoekresultaten genereren in de PeCMan-server.

Bruikbaar over alle netwerkverbindingen WakaWaka is getest over GPRS, 3G en WiFi. De applicatie werkt volledig, maar bij de mobiele verbindingen zijn er heel af en toe problemen bij de initiële verbinding. Dit probleem wordt veroorzaakt door het feit dat de gebruikte SIP-bibliotheek op een zeer laag niveau opereert en de iPhone niet automatisch een netwerkverbinding opent in dat geval. De SIP-abstractielaag in WakaWaka heeft hiervoor een ingebouwde oplossing, maar in zeldzame gevallen werkt die niet als verwacht. Dit probleem is echter niet eenvoudig sluitend op te lossen, aangezien er een grote architecturale aanpassing nodig zou zijn in de PJSIP-bibliotheek.

5.5

Verder werk

In dit stuk wordt een overzicht gegeven van waar WakaWaka nog tweaks en verbeteringen kan gebruiken. Ook introduceren we enkele grotere uitbreidingen die later toegevoegd zouden kunnen worden. We behandelen hier enkel aanpassingen voor de client-applicatie. De serverzijde van PeCMan komt overvloedig aan bod in hoofdstuk 6.

5.5.1

Caching en persistentie

Momenteel wordt er binnen WakaWaka slechts beperkt aan caching gedaan voor o.a. thumbnails. Naast het cachen van dergelijke metadata kan het ook nuttig zijn om recent bekeken bestanden volledig lokaal bij te houden. Dit vermijdt het constant aanspreken van het netwerk telkens men een bestand wilt openen. Op vlak van persistentie is de applicatie beperkt tot het bijhouden van de gebruikersgegevens. De bestandssystemen waarop men zich inschrijft worden niet gepersisteerd bij het aflsuiten van het programma. De algoritmen die bestandssystemen bijwerken zijn ontworpen om bestaande gegevens zoveel mogelijk te hergebruiken, waardoor het laden van een cache een nuttige tijdelijke weergave zou aanbieden vooraleer de laatste nieuwe informatie geladen is. Dergelijke persistentie bewijst zijn nut meer als er sprake is van

5.5 Verder werk

61

een aanzienlijke latentie waardoor de gebruiker kan merken dat het bestandssysteem nog niet geladen werd. Tijdens de ontwikkeling was dit echter nooit het geval.

5.5.2

Uitgebreidere metadata

Het weergeven en beheren van metadata is momenteel eerder beperkt. Aangezien de serverzijde hiervoor geen enkele ondersteuning biedt, gebruikt de applicatie op sommige plaatsen tijdelijke code om toch de aanwezigheid van metadata te simuleren. Een goed voorbeeld is het weergeven van thumbnails. Zodra er een structurele oplossing aanwezig is in de PeCMan-server, zal WakaWaka aangepast moeten worden om hiervan gebruik te maken. Deze aanpassingen blijven echter binnen het File System subsysteem, wat de zaak toch wel vergemakkelijkt. Het beheer van metadata voor bestanden past best binnen de File Inspector, aangezien daar plaats is voor een willekeurig aantal bijkomende velden. Zo zou er bijvoorbeeld beheer van tags kunnen toegevoegd worden, toevoegen van locatie-informatie, enz.

5.5.3

Security

Het huidige prototype van de PeCMan-server en bijgevolg ook WakaWaka houden zich praktisch niet bezig met beveiliging van de communicatie of vertrouwelijkheid van gegevens. Er zijn verschillende securityaspecten van het systeem die onder de loep moeten genomen worden om PeCMan als vrij beschikbaar systeem te kunnen gebruiken. Encryptie van SIP-berichten De SIP-communicatie van WakaWaka met de PeCMan-server kan in principe verstuurd worden over SSL, zodat de inhoud enkel in versleutelde vorm onderschept kan worden. In het afgeleverde prototype van deze masterproef is dit echter niet het geval, omwille van verschillende redenen: • Zelfs al is de communicatie versleuteld, momenteel vereist de SIP-proxy geen paswoord of andere identificatie om zich te registreren. Bijgevolg kan eender welke client zich sowieso aanmelden onder een willekeurige account. • De iPhone SDK maakt de OpenSSL-bibliotheek van het systeem niet openbaar, zodat voor SSLondersteuning een eigen gecompileerde versie van OpenSSL aan de applicatie moet toegevoegd worden. Dit is niet bijzonder complex, maar vergroot de geheugenconsumptie van de applicatie momenteel zonder nut. • Encryptie van de SIP-communicatie vereist iets meer rekenkracht, hoewel dit nauwelijks merkbaar zou zijn gezien het beperkte volume van verzonden SIP-berichten.

5.5 Verder werk

62

Er zijn geen technische hindernissen om encryptie aan te schakelen, maar door het gebrek aan authentificatie in de proxy heeft het geen toegevoegde waarde. Bij gebruik van de applicatie is al dan niet aanwezige encryptie bovendien onmerkbaar. Zolang het PeCMan-systeem niet gebruikt wordt met informatie die effectief beschermd moet blijven heeft het weinig zin van de communicatie over SSL te laten verlopen.

Toegangsrechten voor PeCMan-bestandssystemen De ondersteuning voor toegangsrechten is op serverniveau zeer rudimentair, en WakaWaka houdt dus weinig rekening met het instellen of uitlezen ervan. Voor een productiesysteem moet men natuurlijk wel in detail kunnen bepalen wie toegang krijgt tot welke bestanden. Qua gebruikersinterface kan dit best ingepast worden in de workflow van het publiceren enerzijds en in de File Inspector anderzijds.

VOORSTEL PECMAN-ARCHITECTUUR

63

Hoofdstuk 6

Voorstel PeCMan-architectuur Zoals aangegeven in vorige hoofdstukken vereisen enkele verbeteringen in WakaWaka bijhorende structurele server-ondersteuning in het PeCMan-systeem. Dit gedeelte bespreekt uitgebreid wat er aan de serverzijde kan toegevoegd en aangepast worden om uiteindelijk een betere gebruikerservaring aan te bieden. Het voorgestelde ontwerp past de bestaande architectuur aan om o.a. een grotere betrouwbaarheid en prestatieverbeteringen te bekomen. Deze masterproef beperkt zich tot een uitgewerkt ontwerp van een dergelijke serverarchitectuur, enerzijds omdat een theoretische benadering ervoor zorgt dat het doel van de architectuur de eerste zorg blijft, en anderzijds omdat de werkelijke implementatie ervan buiten het bestek van de opdracht valt.

6.1

Hybride SIP / HTTP

De huidige serverarchitectuur heeft een aantal fundamentele problemen die opgelost moeten worden. In dit gedeelte stellen we een bijgewerkt ontwerp voor dat sterk lijkt op het bestaande, maar andere technologieën gebruikt die geschikter zijn voor de uitgevoerde taken.

6.1.1

Probleemstelling

Alle communicatie met PeCMan verloopt in het bestaande model over SIP. Die keuze werd vooral gemaakt omwille van de eenvoudigere implementatie, maar ze zorgt voor een aantal problemen die het gehele systeem met een handicap opzadelen. • Zowel UDP- als TCP-transport ondervinden problemen bij willekeurig grote bestandssystemen. SIP werd niet ontwikkeld voor gegevenstransfers, het is een signaliseringsprotocol.

6.1 Hybride SIP / HTTP

64

• SIP is onhandig om veelvuldige on-demand aanvragen te doen. In principe kan het laden van miniaturen bijvoorbeeld geregeld worden via INVITE-berichten, maar dit zal traag en foutgevoelig zijn. • Op vlak van encryptie en beveiliging laten standaardimplementaties van SIP veel te wensen over, een eigenschap die in het tegenwoordige netwerklandschap moeilijk te verdedigen is. • Informatie die aangeboden wordt door een PeCMan-bestandssysteem kan ook nuttig zijn voor andere diensten. Aangezien SIP enkel populair is voor specifieke toepassingen (meestal VoIP), vormt het gebruik ervan als basisprotocol een struikelblok voor integratie met andere diensten. In de omgekeerde richting werkt geen enkele opslagdienst met SIP, waardoor de vertaling van PeCManoperaties naar externe diensten toe nodeloos ingewikkeld gemaakt wordt. • Naast de technische problemen met SIP als protocol voor het gehele systeem werden sommige operaties ook geforceerd om te passen binnen SIP-berichten. Het meest opvallende voorbeeld is het gebruik van PUBLISH voor het beheer van mappen en bestanden. Dit bericht werd in de eerste plaats ontworpen om toestandswijzigingen te communiceren, niet om een persistente voorstelling elders bij te werken.

6.1.2

Vereisten

Nu we een beter zicht hebben op de zwakheden van SIP binnen PeCMan, kunnen we bepalen aan welke eigenschappen een verbeterde architectuur moet voldoen. Om de tekst niet te overladen met dubbele termen spreken we hierna over PFS wanneer we het hebben over de specifieke PeCMan-dienst die instaat voor het beheren van bestandssystemen. • PFS moet voor zijn basisfunctionaliteit onafhankelijk zijn van SIP als signaliseringsprotocol. Het moet zich dus gedragen als een afzonderlijke dienst. • Operaties naar PFS toe die persistentie van gegevens veroorzaken, moeten afgehandeld worden op een betrouwbare en beveiligde manier. Hieronder valt onder meer het toevoegen en verwijderen van mappen en bestanden. • PFS moet kunnen werken met bestandssystemen van onbeperkte grootte. • Integratie met andere diensten moet relatief eenvoudig zijn om de adoptie van PeCMan te bevorderen. De keuze van protocollen heeft hier dus een grote invloed op.


6.1.3

65

Keuze van protocollen

Vooraleer we overgaan tot een beschrijving van de aangepaste architectuur, bespreken we kort de keuze van protocollen. We kunnen de basisfunctionaliteit van het PeCMan-systeem uiteentrekken in twee grote categorieën: • Interactie met het virtuele bestandssysteem en bestandsuitwisseling. Het gaat hier om gegevens die exact moeten overgezet worden op een betrouwbare manier. • Signalering en sessiebeheer voor gebruikers. Dit soort communicatie is vrij vergevingsgezind voor fouten en gemiste berichten. Deze onderverdeling maakt duidelijk dat er compleet verschillende vereisten nodig zijn voor sommige delen van het PeCMan-systeem. Bijgevolg wordt dan ook voorgesteld om de architectuur te herzien met een afzonderlijk basisprotocol voor beide categorieën. Zo’n opsplitsing zorgt er alvast voor dat het systeem voldoet aan het criterium van onafhankelijkheid.

Signalering en sessiebeheer De bestaande architectuur gebruikt reeds SIP, een protocol dat uiterst geschikt is voor deze taak. Men kan dus de huidige SIP-infrastructuur behouden. Anderzijds kan een architecturale aanpassing een goed moment zijn om alternatieven te onderzoeken. We spreken ons in deze masterproef niet uit over de meest geschikte keuze van signaleringsprotocol, maar verwijzen voor meer informatie over het belangrijkste alternatief, XMPP, naar 2.2.4 (pagina 14).

Interactie met het virtuele bestandssysteem en bestandsuitwisseling Het protocol is hier cruciaal, omdat de keuze bepaalt in welke mate de eerder vermelde problemen uit de weg geruimd worden. We brengen HTTP naar voor als sterke kandidaat. • Als één van de basisprotocollen waarop het internet zoals wij het kennen gebouwd is, kan het rekenen op veel expertise. HTTP wordt ook ondersteund door zowat elke API die netwerkfunctionaliteit bevat. Dit vergemakkelijkt het ontwikkelen van PeCMan-clients, en zorgt ervoor dat de serverinfrastructuur gebruik kan maken van alle kennis die opgedaan werd door decennia HTTP-gebruik. • Omdat HTTP zo onmisbaar is, kent het een ongeëvenaarde ondersteuning bij firewalls en routers. Gedistribueerde diensten met andere protocols ondervinden dikwijls last van NAT en andere routerproblemen, iets waar HTTP over poort 80 quasi immuun voor is.


66

• Beveiliging van verkeer over HTTP is eenvoudig met HTTPS. Dankzij de populariteit van HTTP is de ondersteuning voor beveiligd HTTP-verkeer opnieuw bijzonder goed. • Ondanks oorspronkelijk ontwikkeld te zijn voor het navigeren tussen webpagina’s, heeft HTTP door de jaren heen zijn extreme flexibiliteit bewezen. Dit uit zich o.a. in de hoge schaalbaarheid die bereikt kan worden in populaire diensten. • HTTP wordt dagelijks gebruikt om gigabytes aan informatie te verzenden, en kan dus zeker gebruikt worden om bestandssystemen van willekeurige grootte uit te wisselen. • Dankzij het actief gebruik van HTTP zijn er zeer nuttige uitbreidingen die de netwerkprestaties kunnen verhogen, zoals compressie en persistente verbindingen. • Zowat elke opslagdienst of sociaal netwerk werkt via HTTP omdat ze in essentie gebaseerd zijn op hun websites. Naarmate mobiele clients aan populariteit winnen vermindert het belang van de website, maar blijft HTTP wel steeds het gebruikte protocol. Dit maakt het eenvoudiger om binnen het PeCMan-systeem een vertaling uit te voeren naar een specifieke opslagdienst. • Anderzijds vergemakkelijkt HTTP integratie met PeCMan vanuit andere diensten. HTTP-toegang maakt het bijvoorbeeld stukken haalbaarder om een website aan te bieden die communiceert met het gedistribueerde bestandssysteem.

6.1.4

Architectuur

Nu bepaald werd dat zowel SIP als HTTP in de architectuur aanwezig moeten zijn, kan de vorige architectuur aangepast worden om deze opsplitsing weer te geven. We beperken ons hier tot een vrij hoog niveau, omdat de specifieke details weinig bijdragen aan het begrijpen van de interactie met een PeCMan-client als WakaWaka. De volgende sectie bespreekt hoe een client de verschillende systemen in deze nieuwe architectuur aanspreekt, maar eerst geven we een kort overzicht van de componenten in figuur 6.1: • De FS Service is nu een afgeschermde component die de SIP-proxy en -registrar gebruikt voor co¨ ordinatie. Eventueel kan er een ander protocol zoals XMPP gekozen worden als alternatief voor SIP. Beide kunnen in principe ondersteund worden. • De Notifier-component is een algemeen subsysteem dat instaat voor het propageren van wijzigingen aan bestandssystemen naar gebruikers toe. Momenteel gebeurt dit enkel via SIP-NOTIFY, maar dankzij de algemeenheid van de component kan bijvoorbeeld ondersteuning voor Apple Push Notifications toegevoegd worden (zie 6.4.2). • De FS Access-componenten zijn één of meerdere HTTP front-ends voor de FS Service. Ze vormen een fa¸cade naar de werkelijke bestandssystemen. Men kan dus meerdere access-modules voorzien


67

om de netwerkbelasting te verlichten. Het feit dat een bestandssysteem niet is gebonden aan een specifieke FS Access-component verhoogt de schaalbaarheid aanzienlijk. Deze architectuur specifieert niet hoe de Access-componenten communiceren met de achterliggende FS Service: dit is wat de clients betreft een implementatiedetail aangezien zij enkel toegang zoeken tot de HTTP- en SIP-front-ends. • Onderling communiceren clients en storage services nog steeds peer-to-peer, maar nu wordt HTTP gebruikt als protocol i.p.v. SIP. Opslag op een mobiel toestel geeft aanleiding tot de aanwezigheid van een kleine ingebouwde HTTP-server in de clients, waardoor de meeste clients ook onder de categorie opslagdiensten vallen.

FS Service

Notifier virtuele bestandssystemen

Melden van FS updates SIP Access

Wijzigingen aan bestandssystemen HTTP front-end(s)

SIP Proxy

FS Access

Registratie, FS updates

FS Access

Lezen en wijzigen bestandssysteem

Clients + Storage Services

Figuur 6.1: Aangepaste PeCMan-architectuur met afzonderlijke SIP- en HTTP-componenten. De centrale File System Service is nu afgeschermd van clients en opslagdiensten.


6.1.5

68

Interactie tussen client en server

HTTP als communicatieprotocol met de PeCMan-dienst zorgt voor een hogere betrouwbaarheid en aantrekkelijke uitbreidingsmogelijkheden, maar ook de XML-communicatie tussen client en server moet onder de loep genomen worden om hier optimaal gebruik van te maken. We bekijken een aantal scenario’s en stellen een gestroomlijnde XML-syntax voor.

Inloggen en opvragen van een HTTP-aanspreekpunt Vooraleer men iets kan doen binnen PeCMan moet men uiteraard inloggen. Hiervoor wordt de volgende interactie voorgesteld: 1. Client (C) registreert zich via SIP (of een equivalent protocol) bij een SIP-server (S; in de praktijk combinatie van proxy en registrar) zoals in de bestaande architectuur. Het beheer van de gebruikerstoestand en eventueel verschillende toestellen verloopt hetzelfde. 2. Zodra C bevestiging krijgt van de registratie bij S vraagt via een SUBSCRIBE-bericht naar de PeCMan-dienst (PFS) een bestandssysteem aan. Dit gebeurt opnieuw op dezelfde manier als in het bestaande systeem. 3. C krijgt een 200 OK-antwoord, vervolgens een NOTIFY-bericht. Dit bericht bevat echter geen XML-voorstelling van het bestandssysteem meer, maar een XML-beschrijving zoals in fragment 6.1. Deze structuur beschrijft welke HTTP-server aangesproken moet worden voor aanvragen i.v.m. het bestandssysteem. Merk op dat deze server verschillend kan zijn voor elke afzonderlijke inschrijving, een vereiste gezien het gedistribueerde aspect van PeCMan. Een woordje uitleg bij de structuur: • Het url-element beschrijft een HTTP of HTTPS URL waarnaar verzoeken voor dit bestandssysteem moeten gaan, m.a.w. het HTTP-aanspreekpunt (PFS-HTTP). De expires-parameter bepaalt hoe lang dit aanspreekpunt geldig is voor het aangevraagde bestandssysteem. Eventueel kunnen er meerdere url-elementen zijn om een keuze van server toe te laten. • Het api-element bevat de ondersteunde interactiemethoden voor de gegeven URL. Dit is van belang voor toekomstige uitbreidingen van PeCMan en kan gebruikt worden om te beslissen dat de client geen verbinding kan maken met dit specifiek volume. • Het credentials-element beschrijft op welke manier C zich moet identificeren bij het PFS-HTTP en wordt hierna in meer detail besproken (fragment 6.2). • Het optionele last-modified-attribuut geeft een unieke token aan die de huidige toestand van het bestandssysteem voorstelt. Telkens er een wijziging gebeurt zal de token veranderen. Het nut hiervan zal duidelijk worden bij het opvragen van een bestandssysteem (zie verder).


69

4. C inspecteert het fs-access element en houdt de informatie over PFS-HTTP intern bij. Via dit aanspreekpunt gebeuren de acties die in de volgende secties worden besproken. 5. Zoals gewoonlijk kan C nu periodiek een nieuw NOTIFY-bericht ontvangen. Deze nieuwe berichten kunnen een ander fs-access element specifieren. In dat geval moeten alle toekomstige verzoeken via het nieuwe PFS-HTTP verlopen.

Fragment 6.1: XML-beschrijving van het HTTP communicatiepunt < url expires ="3600" > http :// example . com / pecman / entry - point pecman -1.0 < credentials > ...

Credentials Vooraleer verder te gaan met andere scenario’s moet het credentials-element verduidelijkt worden omdat het cruciaal is voor elke communicatie met een nieuwe server of peer. Het probleem is als volgt: de PeCMan-client (C) beschikt enkel over zijn globale gebruikersnaam en wachtwoord. Omwille van allerlei redenen (decentralisatie, bescherming van gebruikersgegevens) heeft een HTTP-aanspreekpunt (PFSHTTP) mogelijk geen toegang tot die informatie. Omdat C toch moet communiceren met PFS-HTTP over een beveiligd kanaal moet er dus bijkomende informatie gegeven worden. Men kan verschillende manieren bedenken om dit element in te vullen. We beschrijven er drie die nuttig zouden kunnen zijn. Fragment 6.2 toont een eenvoudige instructie voor HTTP-authentificatie met een gebruikersnaam en wachtwoord. Fragment 6.3 zou kunnen aangeven dat elk verzoek aan PFS-HTTP een credentials-element moet bevatten dat identiek aan hetgene in de instructie is. Het is ook mogelijk dat het PFS-HTTP wel kennis heeft van alle gebruikersinformatie. De credentials kunnen dan dezelfde zijn als voor het globale PeCMan-systeem, wat kan weergegeven worden zoals in fragment 6.4. Fragment 6.2: Instructie voor een gebruikersnaam en wachtwoord < credentials > < type > http - auth < user > PFS - HTTP - user < password > password


70

Fragment 6.3: Instructie voor een te dupliceren credentials-element < credentials > < type > clone < some - token >1234567890

Fragment 6.4: Instructie voor gebruik van de standaard login-informatie < credentials > < type > http - auth - default

Interactie met het HTTP-aanspreekpunt Om de interactie met een verkregen HTTP-aanspreekpunt (PFS-HTTP) niet telkens te moeten detailleren in de volgende scenario’s wordt hier de algemene werking weergegeven. Aanvragen naar het PFS-HTTP verlopen als volgt: 1. De client (C) kiest een actie waarmee een zekere XML-beschrijving overeenkomt. Deze XMLbeschrijving komt overeen met een gedeelte van de server API. 2. C stuurt nu een HTTP POST-bericht naar het PFS-HTTP met als message body de relevante XML-gegevens. 3. Indien nodig authentificeert C bij PFS-HTTP zoals voorgeschreven werd door het credentialselement bij inschrijving. 4. PFS-HTTP stuurt nu een antwoord naar C met in de message body een XML-definitie die een antwoord vormt op de aanvraag. De syntax van dit antwoord is opnieuw afhankelijk van de specifieke API.

Opvragen van een bestandssysteem Om de inhoud van een bestandssysteem te verkrijgen stuurt de client C naar het PFS-HTTP een XMLverzoek van de volgende vorm: < list path ="/ subdir /" / > < list path ="/ lolcats / new /" depth ="2" if - modified =" token " / > < list path ="/ epic / fail /" if - modified =" token " / >


71

Het root-element geeft aan dat het gaat om een aanvraag voor informatie en zal voor alle aanvragen gebruikt worden die enkel gegevens opvragen. Het list-element codeert één instructie voor het opvragen van de inhoud van een map: • Het path-attribuut is verplicht en geeft aan voor welke map de inhoud moet opgevraagd worden. De waarde “/” betekent de PeCMan-root (het gehele bestandssysteem), submappen worden door een forward slash gescheiden. • Het optionele depth-attribuut geeft aan tot welke diepte de resultaten teruggegeven moeten worden. De waarde 0 geeft geen inhoud terug, wat soms nuttig kan zijn om de status van een map te bepalen. Een waarde van 1 geeft dus enkel de rechtstreekse inhoud van de map terug. Als depth negatief is of ontbreekt, wordt de volledige recursieve inhoud teruggegeven. • Het optionele if-modified-attribuut laat toe om een unieke token mee te geven waarmee het PFSHTTP kan nagaan of de inhoud van de map sindsdien is aangepast. De waarde van dit attribuut is afkomstig van een eerdere listing, zoals verder besproken wordt. Ook de waarde van depth moet gerespecteerd worden bij deze instructie. Merk op dat deze waarde dient om te controleren of een lokale cache gebruikt kan worden. Men kan meerdere list-instructies toevoegen om tegelijkertijd verschillende mappen op te vragen. Dankzij deze syntax is het dus niet nodig om telkens het gehele bestandssysteem af te halen als enkel een submap nodig is. Na het ontvangen van het verzoek antwoordt het PFS-HTTP in de volgende vorm: < listing path ="/ subdir /" depth =" -1" status ="200" > < dir name =" Directory " owner =" user@example . com " permissions ="777" > < file name =" Image . jpg " src =" service :// locator " size ="100" / > < dir name =" Private directory " / > < listing path ="/ epic / fail /" depth =" -1" status ="404" / > < listing path ="/ lolcats / new /" depth ="2" status ="304" / > Een fs-response-element bevat optioneel een last-modified-attribuut (net als fs-access voordien) dat de huidige toestand van het globale bestandssysteem aangeeft. De waarde ervan kan in een toekomstige list-instructie gebruikt worden voor het if-modified-attribuut.


72

Voor elke list-instructie uit het verzoek is er nu een listing-element, niet noodzakelijk in dezelfde volgorde. Een listing-element is als volgt gestructureerd: • De path- en depth-attributen zijn verplicht en komen normaalgezien overeen met de aangevraagde waarden. Mocht dit wegens een fout toch niet het geval zijn is dit af te leiden uit de teruggegeven waarde. • Het status-attribuut bevat een code die aangeeft wat de toestand van de aangevraagde map is. Hier worden HTTP-statuscodes gebruikt, maar dit kan ook een andere syntax zijn. In ieder geval moeten minstens de volgende waarden bestaan: – 200: de map bestaat en de inhoud kan teruggevonden worden in het listing-element. – 304: de map bestaat, en de inhoud ervan is identiek aan toen de “last-modified”-waarde van het bestandssysteem gelijk was aan de aangevraagde token. Deze code wordt enkel teruggegeven als de bijhorende list-instructie een if-modified-attribuut had, en als het bestandssysteem voldoende historiek heeft bijgehouden om hier zeker van te zijn. De inhoud wordt niet meegegeven, aangezien de client zijn lokale cache kan behouden. – 403: de map bestaat, maar de aanvrager heeft er geen toegang toe. – 404: de map kon niet gevonden worden en de inhoud is dus niet teruggegeven. • Indien de statuscode 200 is bevat het listing-element file- en dir-elementen die het bestandssysteem tot op de gewenste diepte voorstellen. – Zowel dir- als file-elementen hebben een naam, eigenaar en bevoegdheden. Het verplichte name-attribuut bevat de naam, het optionele owner en permissions specifieren de eigenaar (een PeCMan-gebruikersnaam) en bevoegdheden (in octaal formaat). Indien owner of permissions niet gedefinieerd zijn wordt respectievelijk de aanvrager van het bestandssysteem en 700 verondersteld. – Het dir-element kan andere dir-elementen en file-elementen bevatten. – Het file-element is een bestandsreferentie, en bevat een bijkomend src-attribuut met een URI die naar de werkelijke inhoud verwijst. Deze URI is niet noodzakelijk interpreteerbaar door de client, maar kan gebruikt worden om verwijzingen naar dezelfde inhoud te identificeren. Om de inhoud van een bestand op te halen zal deze src-waarde meegegeven worden (zie verder). Het optionele size-attribuut vormt een indicatie voor de grootte van het bestand in bytes. Opvragen van bestanden Voor het opvragen van bestanden sturen we opnieuw een aanvraag naar het PFS-HTTP, van de volgende vorm:


73

< get src =" service :// locator " / > Dankzij het gebruik van het fs-request-element kan een dergelijk verzoek gebeuren samen met andere operaties zoals de list-instructie. Het antwoord voor de get-instructie is van de vorm: < location src =" service :// locator " status ="200" > < url expires ="3600" > http :// example . com /1234567890. data < credentials > ... Het location-element geeft aan op welke HTTP-server we de inhoud kunnen afhalen. • Het src-attribuut wordt overgenomen van de aanvraag en dient om te onderscheiden tussen verschillende resultaten. • Het status-attribuut lijkt sterk op dat bij listings, en is dus opnieuw 200 als de locatie van het bestand gedefinieerd is. • De url- en credentials-elementen gedragen zich net als in het scenario voor inschrijven op een bestandssysteem (zie eerder). De client kan op basis van deze informatie een eenvoudige HTTPdownload starten. Toevoegen en verwijderen van mappen, bestandsverwijzingen Ook het aanpassen van het bestandssysteem gebeurt via het PFS-HTTP. We werken nu met een nieuw root-element dat enkel gebruikt wordt voor wijzigingen, fs-modify. < delete path ="/ subdir /" / > Het atomic-attribuut bepaalt of de wijzigingen als één geheel beschouwd moeten worden. Indien de waarde true is moet het PFS ervoor zorgen dat ofwel de hele aanvraag lukte, ofwel geen enkel onderdeel.


74

Bij true moeten de wijzigingen ook sequentieel uitgevoerd worden. Dit is belangrijk om de integriteit van het virtuele bestandssysteem te bewaren. De toegelaten elementen zijn de volgende: • Het delete-element verwijdert een map of bestand. In het geval van een map wordt de volledige inhoud mee verwijderd. • Het add-dir-element voegt een map toe en maakt indien nodig de tussenliggende hiërarchie aan. Een diepe mapstructuur aanmaken kan dus met één instructie. • Het add-file-element voegt een bestandsreferentie toe. – Het path-attribuut bepaalt het uiteindelijke pad van het bestand. De naam wordt hieruit afgeleid, en de tussenliggende maphiërarchie wordt aangemaakt indien nodig. – Het src-attribuut definieert een URI die verwijst naar de inhoud van het bestand. Deze URI wordt normaalgezien verkregen via een opslagdienst. – Het optionele size-attribuut is de verwachte grootte van het bestand in bytes. Dit kan weggelaten als de grootte niet bekend is. • Het optionele permissions-attribuut bij add-dir en add-file bepaalt de bevoegdheden voor de map of het bestand. Als de permissions weggelaten worden neemt het PFS 700 aan als standaardwaarde. Na het uitvoeren van de aangevraagde operaties stuurt het PFS-HTTP een antwoord terug. Elke instructie in de aanvraag zorgt in het antwoord voor een equivalent element met een path- en status-attribuut. Als de statuscode van elk element gelijk is kan het root-element optioneel eveneens een statuscode bevatten. Dit kan nuttig zijn om niet alle statuscodes afzonderlijk te moeten inspecteren. < delete path ="/ subdir /" status ="200" / >

Aanvragen van een opslagdienst Het laatste stuk basisfunctionaliteit dat de PeCMan-server moet voorzien is het selecteren en aanspreken van opslagvoorzieningen. Eerst en vooral moet men de beschikbare diensten kunnen opvragen, een taak die geen complexe syntax vereist: < list - services / >


75

Het PFS-HTTP kan nu controleren welke diensten er beschikbaar zijn voor de gebruiker in kwestie, en stuurt een antwoord terug met de resultaten: < services > < service expires ="3600" > < name lang =" en " > YouTube < description > The video sharing site http :// youtube . example . com / do < credentials > ... < accepts > video / mpeg , video / mp4 < service expires ="3600" > < name > File Storage http :// storage . example . com / do < credentials > ... Het services-element bevat een willekeurig aantal service-elementen (een leeg element is mogelijk). Elke service wordt als volgt beschreven: • Het name-element bevat de naam van de dienst, optioneel met een lang-attribuut dat de taal van dit element aangeeft. Er kunnen dus meerdere name-elementen zijn. • Het optionele description-element bevat een uitgebreidere omschrijving van de dienst en kan ook een lang-attribuut bevatten. • De url- en credentials-elementen specifiëren opnieuw een HTTP-aanspreekpunt voor de publicatieAPI (zie volgende punt). Het publiceren naar een dienst zal niet meer via het PFS-HTTP verlopen. • Het optionele accepts-element bevat een lijst met MIME-types die aangeven welke types bestanden de service aanvaardt. Indien dit attribuut niet aanwezig is kan men uitgaan van een typeonafhankelijke dienst, hoewel bij het effectief uploaden het bestand nog geweigerd kan worden. • Het optionele expires-attribuut bevat de geldigheidsduur waarin de client ervan kan uitgaan dat de service nog beschikbaar is. Publiceren naar een opslagdienst Via het PFS-HTTP werd de lijst met beschikbare services opgevraagd en weet de client van een aantal contactpunten die via HTTP bereikt kunnen worden. Het conceptueel publiceren van een bestand bestaat


76

nu uit twee stappen: • Werkelijk uploaden van de gegevens naar een opslagdienst • Monteren van een bestandsreferentie aan het bestandssysteem Het aanmaken van een bestandsverwijzing werd eerder reeds besproken, en vereist enkel een URI die bekomen zal worden bij het uitvoeren van de eerste stap. Aangezien we nu niet enkel een XML-verzoek moeten doen maar ook willekeurige gegevens publiceren maken we gebruik van een HTTP POST met multipart/form-data naar het aanspreekpunt van de dienst. Deze manier van werken wordt gebruikt voor het uploaden van gegevens vanop websites, maar is even geschikt voor onze doeleinden. Een dergelijk POST-bericht werkt in feite met meerdere velden die willekeurige gegevens kunnen bevatten. Voor een PeCMan-dienst definiëren we twee velden: instructions en data. Het data-veld zal gebruikt worden om de inhoud van het bestand te uploaden, het instructions-veld bevat een XML-definitie die met UTF-8 geëncodeerd wordt. Voor de precieze werking van multipart/form-data verwijzen we naar [18]. De XML-definitie bevat de coördinatie voor het uploaden van de gegevens, geen al te zware taak aangezien de dienst enkel instaat voor gegevensopslag. < publish - request > < file id =" identifier " field =" data " name =" Movie . mp4 " type =" video / mp4 " / > Het id-attribuut is verplicht en dient om eventueel verschillende bestanden van mekaar te onderscheiden. Het field-attribuut geeft aan onder welk veld in de gegevens voor het bestand zich bevinden. Standaard is dat dus “data”. Het optionele name-attribuut geeft een naam aan de gegevens, maar de dienst is niet verplicht daar iets mee te doen. Het type-attribuut definieert het MIME-type van de opgeladen gegevens. Binnen het file-element kunnen eventueel dienst-specifieke elementen toegevoegd worden, zodat de dienst beschikt over bijkomende metadata. De dienst verwerkt de gegevens, en stuurt een HTTP-antwoord terug waarvan de statuscode gebruikt wordt om de toestand van de upload te bepalen. Als de client een 200 OK-antwoord verkrijgt bevat de message body een XML-structuur als volgt: < publish - response > < file id =" identifier " src =" service :// locator " / > Voor elk bestand dat met succes naar de dienst gepubliceerd werd bevat het root-element een file-element met een id- en src-attribuut. De waarde voor id komt overeen met die van de verstuurde aanvraag en dient dus om zeker te zijn bij welk bestand het resultaat hoort. Het src-attribuut bevat een URI die bruikbaar


77

is om een bestandsreferentie aan te maken bij het PFS-HTTP. De dienst moet hiervoor uiteraard enig overleg met PeCMan gepleegd hebben, anders kunnen willekeurige URI’s moeilijk herkend worden.

6.1.6

Compressie

Bij werken met mobiele toestellen kunnen we te maken hebben met trage netwerkverbindingen, en het is dus van belang de uitgewisselde hoeveelheid gegevens te minimaliseren. Aangezien XML bekend staat als een leesbaar maar soms vrij gewichtig formaat, kan de XML-uitwisseling tussen client en server minder dan optimaal zijn. Eén optie is het optimaliseren van de XML-representatie zodat ze minder karakters inneemt, maar dit is geen goede zaak voor de leesbaarheid van het protocol. Een betere keuze is het comprimeren van communicatie, iets dat zeer eenvoudig is dankzij het gebruik van HTTP. We kunnen gebruik maken van standaard HTTP-compressie, zoals beschreven in [8]. Via de “content-coding”-header kan aangegeven worden dat de inhoud gecomprimeerd werd. Veel HTTP-implementaties ondersteunen bovendien compressie “out of the box”, waardoor een PeCMan-client vrijwel geen extra werk moet verrichten. Om een idee te geven van het nut van HTTP-compressie vergelijken we de bestandsgrootte van een aantal PeCMan-bestandssystemen voor en na compressie. Hiervoor werden XML-beschrijvingen met 100, 500, 1000, 5000 en 10000 unieke bestandsnamen gegenereerd. De winst door compressie varieert tussen 70% en 75%, een mooi meegenomen verbetering die makkelijk te bereiken is met HTTP. Grootte voor compressie

1.069KB

Grootte na compressie

534KB

261KB

11KB

6.1.7

3KB

53KB

131KB

106KB 14KB

27KB

Conclusie

Na deze uitgebreide uiteenzetting kan besloten worden dat PeCMan met de voorgestelde aanpassingen een betrouwbaarder platform wordt dat bovendien makkelijker integreerbaar en uitbreidbaar is zonder de unieke gedistribueerde aspecten op te offeren. Er werd een volledige referentie opgesteld die de ontwikkeling van een nieuwe XML-API aanzienlijk kan

6.2 Metadata

78

vereenvoudigen. De werkelijke implementatie van het voorgestelde serversysteem zou uiteraard nog heel wat voeten in de aarde hebben, maar er zijn onbetwistbare voordelen aan verbonden.

6.2

Metadata

Eén aspect dat in het voorgaande voorstel niet aan bod is gekomen is dat van metadata. Tegenwoordig is de metadata van persoonlijke bestanden bijna even belangrijk als de gegevens zelf. Waar is deze foto getrokken? Wie was er aanwezig op dat feestje? Het zijn allemaal vragen die metadata kan beantwoorden, en het is dus belangrijk dat PeCMan hiervoor voorzieningen aanbiedt. Aangezien een virtueel bestandssysteem in feite al metadata op zich vormt, lijkt het gepast dat het PFS-HTTP, aangebracht in het vorige stuk, zich ook bezighoudt met beheer van metadata. Dankzij de XML-gebaseerde communicatie is metadata-ondersteuning eenvoudig in te passen.

6.2.1

Opvragen van metadata

Het opvragen van metadata hoort thuis bij het opvragen van andere gegevens over het bestandssysteem, en moet dus toegevoegd worden in een fs-request-element. We stellen de volgende syntax voor: < list - metadata path ="/ path / to / Movie . mp4 " / > Als antwoord kan dan de volgende structuur gebruikt worden: < metadata path ="/ path / to / Movie . mp4 " status ="200" > < tag name =" pecman - thumbnail " type =" url " > http :// thumbnails . example . com /123567890. jpg < tag name =" youtube - comments " > < tag name ="1" type =" comment " >... Voor de bespreking van de path- en status-attributen verwijzen we naar de listing-elementen in het vorige deel. Het metadata-element vereist wat meer uitleg: • Het bevat een willekeurig aantal tag-elementen die elk één stuk metadata voorstellen. • Een tag-element heeft ofwel een name-attribuut, ofwel een type-attribuut, ofwel beide. Zodra het een waarde specifieert voor het type-attribuut wordt verondersteld dat de inhoud ervan vastgelegd

6.2 Metadata

79

is volgens de specificatie van dat bepaalde type. Enkel tag-elementen die een name-waarde bevatten zijn adresseerbaar, wat impliceert dat alle tags op het hoogste niveau een waarde voor name moeten bevatten. • Tag-elementen kunnen ook op hun beurt nieuwe tag-elementen bevatten, wat een vorm van gemeenschappelijke datatypes toelaat. Opnieuw geldt dat elementen met een type-attribuut moeten voldoen aan de vorm van dat type. De specifieke behandeling van mogelijke types is niet meer van belang voor nodige aanpassingen aan PeCMan, dus dit laten we over als oefening voor de lezer.

6.2.2

Bewerken van metadata

De representatie van metadata zoals hiervoor aangebracht laat een hiërarchische adressering toe van metadata, een belangrijke eigenschap voor het aanpassen van deze gegevens. Het zou immers onpraktisch zijn als een client steeds op de hoogte moet zijn van alle mogelijke metadata-waarden. Voor het bewerken van metadata stellen we enkele instructies voor die toegevoegd worden aan een fs-modify element zoals dat eerder beschreven werd. < delete - metadata path ="/ path / to / Movie . mp4 " tag =" youtube - comments /1" / > < person firstname =" Alice " / > < person firstname =" Bob " / > We stellen twee nieuwe elementen voor: • Het delete-metadata-element verwijdert een hiërarchisch pad naar een tag. Deze aanpak laat toe om bijvoorbeeld één stuk commentaar te verwijderen zonder alle comments te moeten overschrijven. Dit voorkomt problemen wanneer twee clients tegelijkertijd metadata aanpassen. • Het add-metadata-element voegt de volledige inhoud van het element toe als waarde voor het metadatapad dat in het tag-attribuut gedefinieerd wordt. Indien er al een waarde bestond wordt die overschreven. Na het verwerken van de metadata-aanpassingen bevat het fs-modification-element in het antwoord de volgende elementen, volledig analoog aan wijzigingen van het bestandssysteem zelf:

6.3 Dynamische zoekopdrachten en bestandssystemen

80

< delete delete - metadata path ="/ path / to / Movie . mp4 " tag =" youtube - comments /1" status ="200" / >

6.2.3

Thumbnails

Een zeer specifieke vorm van metadata is het toevoegen van thumbnails. Omdat ze zo nuttig zijn is het belangrijk te onderzoeken of de voorgestelde metadatastructuur ze kan ondersteunen. Uit het voorbeeld in 6.2.1 blijkt duidelijk dat het antwoord positief is. We kunnen thumbnails hetzelfde aanpakken als de andere HTTP-subsystemen: elke thumbnail definieert zijn eigen HTTP-aanspreekpunt dat de afbeelding bijhoudt. Idealiter zorgt de PeCMan-server zelf voor het genereren van thumbnails, en wordt de bijhorende metadata automatisch toegevoegd.

6.3

Dynamische zoekopdrachten en bestandssystemen

Een zeer aantrekkelijke mogelijkheid van virtuele bestandssystemen is het aggregeren van informatie. Omdat de inhoud van een virtuele listing verspreid mag zijn over heel het internet, is een PeCManvolume uiterst geschikt om bijvoorbeeld een up-to-date lijst van populaire YouTube- en Vimeo-filmpjes voor te stellen. Dit type volumes kan volledig zonder feedback van de client voorzien worden, maar een nog krachtigere toepassing zou toelaten dat de client parameters meegeeft bij het inschrijven op een volume. Dit zou een waaier van mogelijkheden toelaten die, gecombineerd met Smart Searches in WakaWaka, van PeCMan een ultieme multimedia-aggregator maken. Dynamische volumes vereisen slechts een zeer beperkte aanpassing op vlak van client-server communicatie. Het harde werk van efficiënt aggregeren wordt immers binnen de server verricht. We stellen voor dynamische bestandssystemen een zeer eenvoudige syntax voor die meegegeven wordt als message body van het SUBSCRIBE-bericht bij een inschrijving: < param name =" search " value =" cute panda " / > Het fs-subscribe element zou een willekeurig aantal param-elementen kunnen bevatten die de resultaten van de inschrijving be¨ınvloeden. Er moet wel over gewaakt worden dat het aantal parameters en de lengte van waarden beperkt blijft, aangezien deze berichten over SIP getransporteerd worden, niet over HTTP.

6.4 Notifications

6.4

81

Notifications

De architectuur die voorgesteld werd bevat een Notifier-component, die in principe toelaat om wijzigingen in het bestandssysteem en andere nuttige waarschuwingen naar de gebruiker te sturen via andere wegen dan SIP NOTIFY-berichten. We bespreken in dit gedeelte het concept van “push” en de mogelijke toepassing ervan binnen PeCMan.

6.4.1

Push

Inleiding Het begrip “push” is momenteel een vrij modieuze term en wordt gebruikt om te contrasteren tegen de “pull”-techniek. Die laatste, ook “polling” genoemd, is samen te vatten als het periodiek opvragen van gegevens om te reageren op toestandswijzigingen, waarbij onder toestand eender welk soort gegevenstoestand kan verstaan worden: nieuwe e-mails, beschikbare downloads, enz. De grote zwakte van die werkwijze zit vervat in het woord “periodiek”. Men moet een geschikt interval bepalen en vraagt dikwijls gegevens op zonder enige indicatie dat er iets gewijzigd is. Nutteloos werk leveren is uiteraard suboptimaal, des te meer wanneer toestandswijzigingen op onvoorspelbare tijdstippen plaatsvinden. Toepassingen zoals instant messaging maken reeds lang gebruik van de “push”-metafoor: ze duwen immers telkens nieuwe berichten naar de gebruiker. Door de opmars van mobiele toestellen die zuinig moeten omspringen met batterij en netwerkactiviteit nam het nadeel van traditionele “pull”-toepassingen zoals e-mail grotere proporties aan, en men probeert tegenwoordig steeds meer via “push”-technologieën te werken. De achilleshiel van “push” is de nood aan bijkomende interactie tussen server en client. Terwijl bij een “pull” de client eenvoudigweg de server moet aanspreken om informatie te bekomen, is het bij “push” nodig om de server op de hoogte te houden telkens de IP-locatie of bereikbaarheid van de client verandert. De server moet informatie over zijn clients bijhouden, en de client moet voldoende regelmatig de server bijwerken. Er is dus sprake van een misverstand als men onmiddellijk aanneemt dat “push” een batterijbesparende maatregel is. In de eerste plaats is het een dienst aan de gebruiker, die ten allen tijde over de laatste informatie beschikt. De boekhouding die nodig is om de server te kunnen laten “pushen” heeft echter wel een kost, die vermeden kan worden als continu bijgewerkte gegevens geen vereiste zijn. In het kader van dit werk zijn er twee grote toepassingen van “push” mogelijk. Enerzijds is er “push” als uitbreiding van de P2P-serverarchitectuur van PeCMan, anderzijds kan men het als informatief hulpmiddel gebruiken. Beide uitgangspunten worden verder in detail besproken.

6.5 Peer-to-Peer: omzeilen van constante persoonlijke bereikbaarheid

6.4.2

82

Push voor statusberichten

Er zijn tal van toestandswijzigingen die voorkomen in het PeCMan systeem: publiceren of aanpassen van bestanden in een virtueel bestandssysteem, nieuwe resultaten voor zoekopdrachten, aanvragen van lokaal opgeslagen gegevens, enz. Elk van deze aspecten kan in principe gecommuniceerd worden aan de eindgebruiker met berichten die naar het toestel in kwestie worden gestuurd. Wanneer WakaWaka actief is op het toestel is de manier waarop statusberichten ontvangen worden volledig vrij. De meeste toestandswijzigingen worden dan meegedeeld via SIP SUBSCRIBE- en NOTIFYberichten, aangezien de gebruiker aangemeld is bij de SIP-registrar. Als de applicatie echter niet openstaat, is er op het iPhone-platform geen enkele manier om in de achtergrond een eigen verbinding met de server open te houden. De enige mogelijkheid om toch nog berichten tot bij de eindgebruiker te krijgen zijn Apple Push Notifications. Conceptueel zijn ze zeer eenvoudig, en in principe kan men ondersteuning ervoor inbouwen in de PeCMan-server. Voor meer informatie, zie de Apple Push Notification Service Programming Guide [19]. Nodige aanpassingen De wijzigingen die nodig zijn voor dergelijke functionaliteit zijn vrij goed in te passen in de huidige PeCMan-architectuur, aangezien de SIP-workflow reeds met gelijkaardige concepten werkt via NOTIFY berichten wanneer een aanpassing gebeurt. In plaats van een NOTIFY-bericht te genereren kan er een Push Notification gestuurd worden indien de gebruiker in kwestie niet aangemeld is. In de PeCMan-server kan een Notifier-component ge¨ımplementeerd worden die op een intelligente manier statuswijzigingen doorgeeft aan de gebruiker. Door te werken met generieke Notifications kan de aanwezigheid van Apple Push Notifications geabstraheerd worden van de rest van de PeCMan-subsystemen, en heeft men de mogelijkheid om later andere manieren van waarschuwingen toe te voegen.

6.5

6.5.1

Peer-to-Peer: omzeilen van constante persoonlijke bereikbaarheid Probleemstelling

Onbereikbare mobiele toestellen zijn een gegeven waarmee rekening gehouden moet worden, zoals eerder besproken werd (2.1). In traditionele client-server architecturen is dit slechts een beperkt probleem, aangezien gebruikers meestal geen gebruik proberen te maken van het netwerk als ze weten dat er geen verbinding aanwezig is. In het geval van PeCMan is er echter sprake van een gedistribueerd systeem waarbij elk eindpunt in principe als een opslagplaats kan dienen. Voor het ophalen van een bestand moet een dergelijk eindpunt


83

dus bereikbaar zijn voor de aanvrager. We kunnen de opslagplaatsen opdelen in twee grote categorieën: traditionele services en toestellen van eindgebruikers. Voor services kunnen we in principe uitgaan van een theoretische bereikbaarheid van 100%. Dergelijke systemen zijn immers ontworpen om ten allen tijde beschikbaar te zijn voor gebruikers ervan. Bij toestellen van eindgebruikers daarentegen kunnen we dit zeker niet veronderstellen. Zelfs al heeft een toestel een permanente IP-verbinding, dan nog is het grotendeels onbeschikbaar omdat de WakaWaka-applicatie slechts een bereikbare opslagplaats vormt als ze geactiveerd werd door de gebruiker. Een robuust PeCMan-ecosysteem moet dus de onbereikbaarheid van eindpunten kunnen overbruggen. Bovendien moet dit zo transparant mogelijk gebeuren voor de eindgebruiker, teneinde eventuele frustratie te voorkomen. In de volgende secties wordt de haalbaarheid van enkele mogelijkheden getoetst.

6.5.2

Vereisten

Vooraleer we overgaan tot een bepreking van mogelijke technieken is het belangrijk af te bakenen welke eigenschappen een aanvaardbare oplossing moet bezitten. Anders zoeken we in het donker en kunnen we verschillende opties moeilijk naast mekaar leggen. • Het systeem mag niet vereisen dat elke client-applicatie ten allen tijde actief is. De basiswerking moet gegarandeerd worden onafhankelijk van de bereikbaarheid van bepaalde gebruikers of toestellen. We moeten m.a.w. met de situatie van onbereikbaarheid omgaan in plaats van ze weg te wensen. • Het systeem moet eindgebruikers zo weinig mogelijk storen om bestandsoverdrachten te verzorgen. Als er toch ongevraagde communicatie moet plaatsvinden, moet er een mogelijkheid zijn om dit uit te schakelen. • Het systeem moet efficiënt omspringen met de beperkingen van bepaalde toestellen. In het geval van een mobiele client wilt dit zeggen dat er zo weinig mogelijk dataverkeer gegenereerd wordt, en de batterij optimaal benut wordt. Voor always-on diensten mag dan weer rijkelijk gebruik gemaakt worden van de mogelijkheden ervan. Anders gezegd moet het systeem waar nodig zelf meer werk verrichten als dit minder werk voor de eindgebruikers inhoudt. Dit is een vrij vage richtlijn omdat het vermijden van dubbel werk (voor het eindgebruikerstoestel) op verschillende niveaus en in variërende mate aanwezig kan zijn. • Het systeem moet ervoor zorgen dat “prestaties” geleverd door een eindgebruiker hoofdzakelijk gebeuren in functie van de gebruiker zelf. Dit omvat o.a. opofferen van batterijduur, versturen van gegevens over het mobiel netwerk, enz. Verzoeken aan een mobiel toestel moeten enig voordeel hebben voor de gebruiker. Zoniet wordt de stimulans om het systeem te blijven gebruiken in gevaar


84

gebracht. Deze regel slaat vooral op het verrichten van onnuttig werk, maar is nog slechter afgelijnd dan de vorige omdat de mate van het“voordeel” een zeer subjectieve aangelegenheid kan zijn en soms niet voorspeld kan worden.

6.5.3

Push

Een terugkerende vraag bij het onderzoeken van PeCMan op mobiele toestellen is hoe men de aanwezige multimediabestanden permanent toegankelijk kan houden, en dan liefst op een energiezuinige manier. Als mogelijke oplossing wordt een “push” mechanisme aangereikt, wat neerkomt op het activeren van de PeCMan-client op het toestel zodra er een verzoek voor een bestand binnenkomt. Op sommige mobiele platformen kan men dit via SMS of een speciale permanente SIP-verbinding regelen. Er zijn echter enkele tegenargumenten voor deze denkwijze: • De permanente bereikbaarheid van mobiele clients is momenteel slechts een natte droom, en het is dus gevaarlijk om de architectuur van het systeem op een dergelijke onrealistische veronderstelling te baseren. Zelfs met een perfect functioneel push-mechanisme kan het toestel onbereikbaar zijn om tal van redenen, uitgebreid besproken in het hoofdstuk Netwerkproblematiek bij mobiele toestellen (2.1). • Hoe efficiënt het push-mechanisme ook is, het zal steeds energie verbruiken. De batterijduur wordt dus gecompromitteerd. Ook wordt er steeds bandbreedte verbruikt, die over lange tijd kosten voor de gebruiker kunnen doen oplopen. • De permanente beschikbaarheid bij een push-mechanisme wordt in feite opgelegd door de noden van andere gebruikers, in plaats van de noden van de gebruiker van het toestel. Zij willen immers toegang tot het multimediabestand van de gebruiker. Dit heeft als gevolg dat de nadelen qua batterijduur en netwerkactiviteit moeilijk te verantwoorden zijn. • Op zich geen tegenargument voor het push-concept, maar wel een technisch struikelblok: push op de iPhone is beperkt tot kleine berichten, geluiden en badges. Men kan bijvoorbeeld niet automatisch een applicatie openen bij het ontvangen van een push notification. Nadenken over een push-mechanisme legt dus een fundamentele zwakheid bloot, inherent aan gedistribueerde opslag op mobiele toestellen. Push lost hier in essentie niets aan op, en kan best vermeden worden voor dit specifieke probleem. Een betere oplossing kan omschreven worden als “queue-and-forward”, en wordt hierna besproken. Merk op dat die aanpak een optionele push-component bevat die op de iPhone kan werken.


6.5.4

85

Beperken van Peer-to-Peer

Een andere optie voor het omzeilen van bereikbaarheid is het omhelzen van een meer traditioneel clientserver model. Hoewel dit technisch gezien een veel minder aantrekkelijke uitdaging is, is het wel een bewezen techniek die een optimale bereikbaarheid kan garanderen. Het probleem van onbereikbaarheid is inherent aan de gedistribueerde aanpak van PeCMan. Eerst en vooral moet benadrukt worden dat aan deze eigenschap niets moet verminderd worden, aangezien de consolidatie van verschillende opslagplaatsen net de aantrekkingskracht van het systeem is. Wat wel een realistische optie is, is het verwijderen van mobiele toestellen als servers. Dergelijke eindpunten zijn onvermijdelijk tijdelijk, wat in rechtstreekse tegenstrijd is met het concept van een server. Peer-to-peer bestandsoverdrachten worden hoofdzakelijk gebruikt bij systemen zoals BitTorrent. Dergelijke toepassingen maken duidelijk dat er niets mis is met het basisconcept. Wat echter fundamenteel verschilt in onze besproken problematiek is het soort bestanden dat gedeeld wordt. Bij het overgrote deel van P2P-toepassingen haalt iedereen dezelfde bestanden af, wat toelaat om het werk te verdelen en zo de centrale server minder te overbelasten. Bij persoonlijke gegevens zorgt de nood aan privacy er echter voor dat zeer weinig intergeconnecteerde eindpunten een kopie bezitten van de gegevens. Bij weinig peers reduceert P2P zich in feite tot traditionele client-server, maar dan met een server die geen garantie voor constante beschikbaarheid kan bieden. De grootste tegenargumenten tegen een P2P-vermindering is de afhankelijkheid van specifieke services, en het werk dat verricht moet worden om bestanden op de service te zetten vooraleer ook maar iemand interesse vertoont in het gepubliceerde materiaal. De eerste kwestie is eenvoudig op te lossen door een eigen PeCMan storage-service toe te laten op een vaste PC of iets dergelijks, zolang het toestel in kwestie een voldoende hoge graad van beschikbaarheid heeft. Het tweede punt is fundamenteel correct, maar moet afgewogen worden tegen het alternatief. Enerzijds is kan een andere gebruiker een bestand verzoeken en het peer-to-peer verkrijgen via het toestel van de eigenaar (voor zover dat beschikbaar is). Het toestel van de eigenaar verricht dan pas het zware werk om een bestand te delen, en enkel als er effectief een aanvraag voor komt. Anderzijds kan de gebruiker het bestand onmiddellijk publiceren naar de service, waardoor toekomstige aanvragen onafhankelijk van het mobiel toestel kunnen afgehandeld worden. Dit is een nadeel als niemand ooit een aanvraag doet naar die gegevens, waarbij men zich dan de vraag kan stellen waarom de gebruiker ze eigenlijk heeft gepubliceerd. Beperken van “echte” peer-to-peer (tussen twee eindgebruikers) voor individuele bestandsoverdrachten is niet in tegenstrijd met de basisprincipes van het PeCMan-systeem. Het blijft als een platformonafhankelijke lijm dienen tussen heterogene diensten. Door individuele overdrachten via de traditionele client-server aanpak te verrichten kan men het beste van beide werelden bekomen.


6.5.5

86

Queue-and-Forward

In deze sectie wordt een nieuwe aanpak besproken die vanaf hier “queue-and-forward” genoemd wordt. Bij nader toezicht zal blijken dat dit een hybride aanpak is die P2P probeert te verzoenen met centrale services. De observatie die het centrale uitgangspunt van queue-and-forward vormt is de volgende. Indien iemand een bijzonder populair bestand op zijn mobiel toestel heeft staan, is het bijkomende (subjectieve) voordeel van een upload naar een andere gebruiker bijzonder klein na de allereerste keer. De eigenaar offert immers gebruikerstijd, batterijduur en netwerkactiviteit op bij elke overdracht van een bestand. Queue-andforward is ontworpen om die opoffering te herleiden tot een eenmalige vereiste. Tegelijkertijd zal blijken dat het onbereikbaarheidsprobleem zo op een quasi optimale manier omzeild wordt, gegeven de beperking dat een bestand zich oorspronkelijk enkel en alleen op het mobiel toestel van de eindgebruiker bevindt. Merk op dat queue-and-forward (zoals eender welke andere oplossing) enkel nuttig is wanneer een aangevraagd bestand zich bevindt op een toestel dat geen quasi-permanente bereikbaarheid kan garanderen. Dit geldt voor zowat elk toestel van een eindgebruiker, maar zeker en vast voor mobiele toestellen. Services daarentegen kunnen op elk ogenblik antwoorden op een aanvraag en hebben dus geen nood aan deze werkwijze. Concept Conceptueel is queue-and-forward een zeer eenvoudige oplossing. We introduceren een nieuwe component in de PeCMan serverarchitectuur, de Queue-and-Forward Manager (QFM). Alle aanvragen voor bestanden, alsook wijzigingen in beschikbaarheid van gebruikers en diensten worden langs de QFM gestuurd. We veronderstellen nu dat het PeCMan-systeem net ge¨ınitialiseerd werd, en er nog nooit aanvragen zijn binnengekomen. Er komt nu een verzoek van eindpunt A binnen voor een bestand X dat zich bevindt op eindpunt B. Queue-and-forward werkt nu als volgt: • Meld aan A dat het bestand X momenteel onbeschikbaar is, en dat het in de wachtlijn is geplaatst. De client kan dan later een nieuwe aanvraag doen. • Indien eindpunt B momenteel beschikbaar is: – Vraag het gewenste bestand aan bij B en zet een overdracht op tussen B en een Queue-andForward Storage (QFS) component. Dit gebeurt in plaats van een onmiddellijke overdracht van B naar A. De QFM onderhoudt het verband tussen het virtuele PeCMan-bestand en de tijdelijke kopie die nu aanwezig is in de QFS. – Eens het bestand correct overgezet is naar de QFS kan optioneel een mededeling naar A gestuurd worden die aangeeft dat een bestand uit de wachtlijn nu beschikbaar is. Als dit niet


87

gebeurt of als A niet langer beschikbaar is, zal A bij de volgende keer opstarten van de client opnieuw een aanvraag doen voor het bestand X. • Indien B niet beschikbaar is: – De QFM plaatst nu de aanvraag voor X in een interne wachtlijn, en voert de aanvraag uit zodra B opnieuw beschikbaar is. Vervolgens laten we wat tijd verlopen zodat de QFS zeker een kopie van het bestand X bevat. Indien B oorspronkelijk niet beschikbaar was wachten we dus tot B zich aangemeld heeft en de overdracht van B naar QFS voltooit. We gaan nu verder met het “forward”-gedeelte van deze techniek. Op een gegeven moment is A opnieuw beschikbaar, en gebeurt het volgende. • A vraagt opnieuw het bestand X aan bij B. Dit verloopt zoals gewoonlijk via de QFM. • De QFM merkt nu dat er een kopie van X aanwezig is in de QFS. Dit gebeurt onafhankelijk van de beschikbaarheid van B. In plaats van een overdracht op te zetten van B naar A wordt er nu een overdracht tussen de QFS en A ingesteld. • A heeft nu een kopie van X verkregen van B, met de QFS als tussenpersoon. Het grote voordeel van queue-and-forward is dus dat het om kan gaan met niet-overlappende beschikbaarheidsintervals van eindpunten. Een nadeel is dat in het standaard scenario er een wachttijd bestaat wanneer zowel A en B beschikbaar zijn, maar de kopie van X eerst via de QFS moet verstuurd worden. Tegelijkertijd naar A en QFS sturen is geen goed idee, aangezien er dan dubbel zoveel netwerkverkeer gegenereerd wordt. Een betere oplossing zou zijn onmiddellijk partiële data door te sturen van QFS naar A, terwijl B nog gegevens aan het sturen is naar B. Dit vereist een iets geavanceerdere structuur maar zorgt er wel voor dat queue-and-forward bijna volledig onmerkbaar is voor de eindgebruiker, wat uiteindelijk toch het doel is.

Push Hoewel push niet fundamenteel gebruikt kan worden als oplossing voor onbereikbaarheid, is het wel bijzonder nuttig als hulpmiddel voor queue-and-forward. De aanwezigheid van een wachtlijn impliceert dat aanvragen een zekere tijd moeten wachten. Er zijn twee redenen voor wachttijd: • Het interval tussen de aanvraag vanuit A en de beschikbaarheid van B • Het interval tussen het voltooien van de gegevensoverdracht van B naar QFS en de beschikbaarheid van A


88

Beide intervallen bepalen hoe lang A moet wachten op bestand X. In het eerste geval kunnen we Push Notifications gebruiken om B ervan op de hoogte te brengen dat iemand een bestand heeft aangevraagd dat zich op het mobiele toestel bevindt. Dit zou echter optioneel moeten zijn, aangezien het B stoort voor een actie die geen groot voordeel verschaft. Het tweede geval is echter wel voordelig voor A, aangezien die normaalgezien zo snel mogelijk een aangevraagd bestand wil verkrijgen. Zodra bestand X beschikbaar is op de QFS kan dat bij A gemeld worden, opnieuw via een Push Notification.

Nodige aanpassingen Aan de kant van de client zijn praktisch geen aanpassingen nodig om queue-and-forward te ondersteunen. Omdat WakaWaka reeds met een download queue werkt naar de gebruiker toe is het al klaar voor queueand-forward. In de architectuur van de server(s) is een nieuwe component nodig die voor alle queue-and-forward co¨ ordinatie zorgt. Deze component moet dus kunnen aangesproken worden bij binnenkomende bestandsaanvragen, en wordt geconsulteerd voor de te gebruiken locatie van bestanden. Bovendien moet het subsysteem op de hoogte zijn van alle services en types eindpunten, opdat er een onderscheid gemaakt kan worden tussen eindpunten die geen queue-and-forward vereisen, en anderen waar dit wel voordelig bij is. Voor de eigenlijke opslag van tijdelijke bestanden kan een bestaande dienst zoals Amazon Simple Storage Service (S3) gebruikt worden. Dit zorgt ervoor dat enkel de wachtlijn- en onderhandelingsfunctionaliteit binnen PeCMan moet gebeuren. De massale gedistribueerde opslag kan uit handen gegeven worden.

6.5.6

Queue-and-Transfer

Queue-and-transfer is een mogelijke variant op queue-and-forward waarbij de verplaatsing naar een always-on service permanent is. In plaats van een tijdelijke kopie te onderhouden, zal nu bij de eerste aanvraag het bestand verplaatst worden van het mobiel toestel naar een opslagserver en wordt deze wijziging ook expliciet aangepast in het PeCMan-bestandssysteem.

6.5.7

Conclusie

Zolang het mogelijk is bestanden op een gebruikerstoestel op te slaan kunnen we besluiten dat het bereikbaarheidsprobleem niet opgelost, maar wel zo goed mogelijk vermeden kan worden. Queue-andforward of queue-and-transfer laten de gebruiker toe lokaal bestanden op te slaan, en toch zoveel mogelijk gebruik te maken van de constante bereikbaarheid van een service. De trade-off is hier uiteraard dat voor queue-and-forward bijkomende infrastructuur nodig is die op een schaalbare manier moet werken.

CONCLUSIE

89

Hoofdstuk 7

Conclusie De ontwikkeling van WakaWaka heeft aangetoond dat het mogelijk is een gebruiksvriendelijke ervaring te bouwen rond PeCMan die zeker niet hoeft onder te doen voor volledig gecentraliseerde multimediadiensten. Het implementatiegedeelte van deze masterproef leverde reeds een bruikbare applicatie op die werkelijk nuttige functionaliteit aanbiedt. Hoewel beperkingen op het mobiele toestel en het netwerk dikwijls als handicap worden beschouwd, verhogen ze met wat creatief denken de robuustheid van de oplossing. Proactief omspringen met het virtuele bestandssysteem maakt dat eindgebruikers meestal geen vertraging ondervinden van de netwerkgebaseerde workflow, iets wat niet gezegd kan worden voor veel andere netwerkopslagsystemen. Gebrek aan rekenkracht zorgt voor een nood aan optimalisatie die uiteindelijk positieve resultaten oplevert. Naast de lessen die getrokken zijn over het ontwikkelen van een PeCMan-client, werd ook veel inzicht verworven in het verbeteren van de PeCMan-servers. WakaWaka werkt goed gegeven de huidige serverarchitectuur, maar moet intern soms eigenaardige omwegen maken door een gebrek aan de serverondersteuning. Dit boek kan gebruikt worden als referentie voor verder onderzoek naar eventuele toekomstige uitbreidingen op PeCMan-dienstniveau. Dankzij de abstractie binnen WakaWaka kunnen de serverprotocollen aanzienlijk wijzigen zonder al te veel nodig werk om de applicatie functioneel te houden. Een belangrijke sterkte van PeCMan is het aggregeren van heterogene diensten.

Momenteel is de

metadata-ondersteuning op serverniveau nog vrij gebrekkig, maar met Smart Searches kan men zoekresultaten van diverse diensten weergeven in één virtueel volume. Zodra er een zoekdienst wordt aangeboden binnen het PeCMan-systeem zijn de mogelijkheden eindeloos. Tenslotte moet nog aangestipt worden dat het maken van een mooie UI nooit verloren werk is. Er is veel aandacht naar de gebruikersinterface gegaan, waardoor mensen die voor het eerst met WakaWaka in contact komen sneller met het concept weg zijn. Aangezien eindgebruikers een dienst succesvol kunnen maken of compleet kunnen negeren, is een aantrekkelijke client-applicatie een onbetwistbaar pluspunt om nieuwe gebruikers naar PeCMan te lokken.

ONTWIKKELEN VOOR DE IPHONE EN IPOD TOUCH

90

Bijlage A

Ontwikkelen voor de iPhone en iPod touch Voor deze masterproef was het iPhone-platform een vanzelfsprekende keuze gezien de superieure gebruikerservaring en mogelijkheden ten opzichte van andere mobiele platforms. Elke roos heeft echter een doorn, en bij iPhone-ontwikkeling is dit duidelijk het zwaar afgeschermde installatieproces op de hardware. Een stuk iPhone-software testen op de meegeleverde iPhone Simulator is eenvoudig, maar om diezelfde applicatie op een toestel te krijgen moet men eerst toestemming van Apple krijgen. Dit onderdeel dient hoofdzakelijk als handleiding voor het uittesten van WakaWaka, maar is uiteraard algemeen toepasbaar voor andere iPhone-applicaties.

A.1

iPhone SDK

Eerst en vooral moet elke aspirant-iPhone-ontwikkelaar zich gratis als “Registered iPhone Developer” registreren via de site http://developer.apple.com/iphone/. Dit proces is vanzelfsprekend en na het inloggen met de aangemaakte account krijgt men toegang tot de Software Development Kit (SDK). Deze software vereist een Mac. Na het installeren van de SDK hebt u toegang tot Xcode en Interface Builder in /Developer/Applications. Xcode is de standaard Mac Integrated Development Environment (IDE) en staat in voor het compileren, installeren, uitvoeren en debuggen van iPhone-applicaties op de Simulator of op een toestel. Interface Builder is de GUI-builder waarmee de interface van uw applicatie samengesteld wordt.

A.2

iPhone Simulator

Nu u de benodigde tools hebt, wilt u de iPhone-applicatie in actie zien. Hier duikt het eerste probleem op: de software-gebaseerde Simulator die Apple meelevert met de iPhone SDK is enorm nuttig voor snel

A.3 iPhone Device

91

testen, maar is uiteraard niet volledig representatief voor het uitvoeren op een werkelijk toestel. Omdat installeren op een iPhone of iPod touch echter heel wat voeten in de aarde heeft, wordt dit afzonderlijk besproken in de volgende sectie. Installatie en uitvoering op de iPhone Simulator is eenvoudig en vereist geen verdere voorbereiding. Men opent het Xcode-project voor de gewenste applicatie; in het geval van WakaWaka is dit dus WakaWaka.xcodeproj. In de knoppenbalk van Xcode vindt u vervolgens een “Overview” menu, waaronder men kan selecteren tussen iPhone Simulator en iPhone Device. In dit geval kiezen we Simulator. Vervolgens selecteren we Build and Run onder het Build menu, wat de applicatie compileert en automatisch opent in de software-Simulator. In deze simulator kan men zowat alle basisfunctionaliteit van een applicatie testen, maar er zijn toch enkele tekortkomingen. Multi-touch wordt niet ondersteund, er is geen toegang tot een camera, de simulator gebruikt een andere hardware architectuur (het is geen emulator) en de snelheid is niet bijster representatief voor een echte iPhone. Bovendien is het moeilijk om het gevoel bij een gebruikersinterface af te leiden van een simulator op een computerscherm. Het is dus van uiterst belang om effectief ook op een toestel te testen.

A.3

iPhone Device

Eens de voorbereidingen getroffen zijn, is testen op een iPhone of iPod touch even gestroomlijnd als werken via de Simulator. Men kiest onder “Overview” gewoonweg voor Device, en verder is de werkwijze indentiek. Vooraleer dit mogelijk is vereist Apple echter een hoop rompslomp en papierwerk. Eerst en vooral is vanaf nu een betaalde inschrijving tot het iPhone Developer Program (developer. apple.com/iphone/program/)nodig. Normaalgezien is het Standard Program voor US$99 jaarlijks voldoende, als men interne distributie wenst kiest men voor het Enterprise Program aan US$299 per jaar. Om zich in te schrijven dient men Apple allerlei identificatie toe te sturen, en vervolgens te wachten tot ze zich geroepen voelen om uw status als iPhone Developer goed te keuren. Dit kan in sommige gevallen een tijdje duren. Na goedkeuring krijgt u via uw account toegang tot het iPhone Developer Program Portal. Hier moet eerst en vooral uw iPhone of iPod touch als ontwikkelingstoestel geregistreerd worden. Nadien moet u een digitaal ondertekend certificaat en een zogenaamd “provisioning profile” afhalen. Dit moet in Xcode geconfigureerd worden voor het iPhone-project dat u wenst te testen. Gelukkig biedt het Portal enkele nuttige assistentiefuncties aan die deze werkwijze verduidelijken. Eens alle benodigde certificaten en profielen zijn geconfigureerd zou u in staat moeten zijn om het project effectief op een toestel te installeren en te testen. Merk wel op dat dit enkel geldt voor de toestellen die

A.4 Jailbreaking

92

als “development devices” geregistreerd staan, iemand met een willekeurige iPhone kan de applicatie niet zomaar installeren. Het is ook niet mogelijk om met de certificaten en profielen voor ontwikkeling de applicatie op de App Store te krijgen. Hiervoor moet opnieuw een afzonderlijke configuratie gebeuren, maar die is weinig relevant in het kader van deze masterproef aangezien het een interne ontwikkeling betreft. Ontwikkelen voor de iPhone is een vrij vlotte ervaring, maar om op dat punt te geraken moet men door een zee van Digital Rights Management (DRM) zwemmen. Men kan zich de vraag stellen of dit een productieve aanpak is, maar momenteel is het slikken wat Apple opdient.

A.4

Jailbreaking

Voor de volledigheid bespreken we ook het concept van “jailbreaking”. Dit is het omzeilen van de beperkingen die Apple oplegt door de besturingssoftware van de iPhone te kraken. Verwar een jailbreak niet met een SIM-unlock, wat de interactie met de hardware zodanig be¨ınvloedt dat iPhones in landen met een exclusieve GSM-operator toch gebruikt kunnen worden op andere netwerken. Een jailbreak dient hoofdzakelijk om software te installeren die Apple niet zou toelaten op de App Store. Vanuit een puur ontwikkelingsstandpunt biedt jailbreaking echter weinig voordelen na de initiële configuratie. Hoewel die laatste ontweken kan worden, is de integratie met Xcode en andere tools minder goed, wat de productiviteit toch wel naar beneden kan halen. Voor een project als WakaWaka is jailbreaking dus weinig nuttig, tenzij om de applicatie relatief eenvoudig op andermans iPod touch of iPhone te krijgen zonder ze expliciet als ontwikkelaars aan te duiden in de bijhorende certificaten.

BIBLIOGRAFIE

93

Bibliografie [1] J. Postel, User Datagram Protocol, 1980 http://www.ietf.org/rfc/rfc768.txt [2] J. Postel, Transmission Control Protocol, 1981 http://www.ietf.org/rfc/rfc793.txt [3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, Session Initiation Protocol, 2002 http://www.ietf.org/rfc/rfc3261.txt [4] A. B. Roach, Session Initiation Protocol (SIP)-Specific Event Notification, 2002 http://www.ietf.org/rfc/rfc3265.txt [5] J. Rosenberg, A Presence Event Package for the Session Initiation Protocol (SIP), 2004 http://www.ietf.org/rfc/rfc3856.txt [6] A. Niemi, Session Initiation Protocol (SIP) Extension for Event State Publication, 2004 http://www.ietf.org/rfc/rfc3903.txt [7] M. Handley, V. Jacobson, Session Description Protocol, 1998 http://www.ietf.org/rfc/rfc2327.txt [8] J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Hypertext Transfer Protocol / HTTP 1.1, 1999 http://www.ietf.org/rfc/rfc2616.txt [9] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, Fran¸cois Yergeau, Extensible Markup Language (XML) 1.0 (Fifth Edition), 2008 http://www.w3.org/TR/2008/REC-xml-20081126/ [10] P. Saint-Andre, Extensible Messaging and Presence Protocol (XMPP): Core, 2004 http://www.ietf.org/rfc/rfc3920.txt [11] D. Crockford, JavaScript Object Notation (JSON), 2006 http://www.ietf.org/rfc/rfc4627.txt

BIBLIOGRAFIE

94

[12] Ecma International, ECMAScript Language Specification, 2009 http://www.ecma-international.org/publications/files/drafts/tc39-2009-025.pdf [13] F. Iterbeke en S. Melis, Een peer-to-peer gebaseerde Presence Service voor Multimedia Toepassingen, masterproef Universiteit Gent, 2006, [14] M. De Muynck, Personal Content Management voor mobiele toestellen, masterproef Hogeschool Gent, 2008 [15] E. Wang, User’s Delay Perception and Tolerance in Human-Computer Interaction, Human Factors and Ergonomics Society Annual Meeting Proceedings, Baltimore, US, Computer Systems, pp. 651655(5), 2002. http://www.ingentaconnect.com/content/hfes/hfproc/2002/00000046/00000005/art00011 [16] 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. 561-570, 2009. http://portal.acm.org/citation.cfm?id=1535069 [17] Wireshark Foundation, Wireshark network protocol analyzer http://www.wireshark.org/ [18] L. Masinter, Returning Values from Forms: multipart/form-data, 1998 http://www.ietf.org/rfc/rfc2388.txt [19] Apple Inc., Apple Push Notification Service Programming Guide http://developer.apple.com/iphone/library/documentation/NetworkingInternet/ Conceptual/RemoteNotificationsPG/Introduction/Introduction.html

Beheerplatform voor persoonlijke bestanden op een mobiel toestel

Recommend Documents