Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. LAGASSE
Streamen van applicaties naar resource-beperkte toestellen door
Dieter GOVAERTS
Promotor: prof. dr. ir. F. GIELEN Co-promotor: prof. dr. ir. F. DE TURCK Scriptiebegeleider: lic. R. HENS Afstudeerwerk ingediend tot het behalen van de graad van burgerlijk ingenieur in de computerwetenschappen
Academiejaar 2006–2007
Toelating tot bruikleen
De auteur geeft de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en delen van het afstudeerwerk te kopi¨eren 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 dit afstudeerwerk.
Dieter GOVAERTS, 4 juni 2007
Dankwoord Het einde van mijn studieloopbaan is bijna bereikt. De kroon wordt nu op het werk gezet met dit afstudeerwerk waarvan de realisatie niet mogelijk geweest zou zijn zonder de hulp en ondersteuning van vele andere mensen. Uiteraard ben ik allen hiervoor erg dankbaar. In de eerste plaats wil ik mijn promotor prof. dr. ir. F. Gielen bedanken, omdat hij mij de kans gegeven heeft om dit afstudeerwerk te realiseren. Daarnaast wil ik hem ook danken voor de vele inzichten die hij mij verschaft heeft tijdens zijn boeiende lessen. Ik wens ook mijn co-promotor prof. dr. ir. F. De Turck te bedanken voor de interesse die hij toonde in mijn scriptie. Vervolgens wil ik ook mijn begeleider Raf Hens bedanken voor zijn ondersteuning, geduld en kritische blik. Ik wens hem veel succes bij de verderzetting van zijn doctoraat. Verder wil ik zeker ook mijn vriendin Cynthia bedanken voor de steun en toeverlaat die zij voor mij geweest is tijdens het maken van deze scriptie, voor de liefde en de inspiratie. Mijn dank gaat verder ook nog uit naar al mijn familie en vrienden die mij steun boden tijdens het afgelopen jaar. In het bijzonder wil ik natuurlijk mijn ouders bedanken omdat ze mij de mogelijkheid gegeven hebben deze studies aan te vatten en voor de voortdurende motivatie om verder te zetten.
Streamen van applicaties naar resource-beperkte toestellen door Dieter GOVAERTS Afstudeerwerk ingediend tot het behalen van de graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2006–2007 Promotor: prof. dr. ir. F. GIELEN Co-promotor: prof. dr. ir. F. DE TURCK Scriptiebegeleider: lic. R. HENS Universiteit Gent Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. LAGASSE
Samenvatting In deze thesis wordt een systeem besproken dat applicaties kan streamen naar resource-beperkte toestellen. Deze toestellen krijgen steeds meer mogelijkheden zoals draadloze internettoegang en het uitvoeren van grotere en complexere applicaties. De beschikbare interne opslag blijft echter een belangrijke kost waardoor de ontwikkelaars van deze toestellen het geheugen liefst zo klein mogelijk houden. Het beschreven systeem kan hierin een alternatief bieden voor grote geheugens door applicaties op een transparante wijze te streamen naar deze resource-beperkte toestellen. Hierbij wordt netwerk transfervolume ingeruild voor een lager gebruik aan lokale opslag door de applicaties. Om dit te bekomen worden de applicaties op het resource-beperkte toestel gevirtualiseerd. Dit betekent dat het voor het besturingssysteem lijkt alsof de applicaties aanwezig zijn op het toestel. Het besturingssysteem kan deze applicaties dan ook net als elke normale applicatie opstarten, maar de inhoud van de applicatiebestanden zal pas gestreamd worden wanneer deze effectief nodig is voor de uitvoering van de applicatie. Deze techniek wordt gecombineerd met een datacache waarin de gestreamde delen van een applicatie tijdelijk opgeslagen worden. Deze datacache gebruikt een deel van de lokale opslag maar is beperkt in grootte. De datacache wordt beheerd door het systeem en heeft als doel om niet steeds dezelfde applicatiedelen opnieuw te moeten streamen. Door het systeem krijgt de gebruiker dus de beschikking over een theoretisch oneindig grote collectie van applicaties die hij steeds kan gebruiken, ongeacht de beschikbare lokale opslag op zijn toestel.
Uit de testresultaten blijkt dat de uitvoeringstijd van een gestreamde applicatie sterk kan toenemen. Dit is met name vooral merkbaar bij bandbreedtes van enkele honderden Kbps en lager. Bij bandbreedtes van enkele Mbps blijft de uitvoeringstijd echter vaak binnen aanvaardbare grenzen. Het compileren van een java-bestand met een gestreamde Java Development Kit (JDK) heeft bijvoorbeeld een uitvoeringstijd van 256 s in een netwerk met een bandbreedte van 384 Kbps en 35 s in een netwerk met een bandbreedte van 4 Mbps. Hierbij wordt ongeveer 12 MiB van de 170 MiB grote JDK gestreamd. Er wordt dus een grote besparing bekomen in zowel gebruikte lokale opslag als in gebruik van netwerk transfervolume daar er maar 7% van de totale applicatie effectief gestreamd wordt. Trefwoorden: streamen, resource-beperkt, applicatiebezorging, caching
Streaming of applications to resource-constrained devices Dieter Govaerts Supervisor(s): Frank Gielen, Filip De Turck Abstract—This article describes the architecture and implementation of a system for streaming applications to resource-constrained devices. These devices gain ever more possibilities such as wireless internet access and execution of larger and more complex applications. Yet local storage capacity remains an issue due to its high implementation costs. The described system can provide an alternative for a larger local storage by transparently streaming applications to the device, thus exchanging network transfers for a lower usage of local storage by the applications. Keywords— streaming, resource-constrained, application delivery, caching
I. I NTRODUCTION
M
ANY users have access to mobile devices such as a mobile phone, MP3-player, PDA or a portable game computer. The possibilities of these devices ever expand with faster wireless internet access and faster computing speeds. The internal storage capacity remains yet an important factor in the cost of these devices. Therefore, developers of these devices want to keep the internal storage capacity as low as possible without jeopardizing user-friendliness. Users on the contrary desire as much local storage as possible. Their aim is to have full control over how many and which applications they keep and never want to be forced to choose between two applications because both can’t fit in the local storage. The ideal case for them is when there isn’t any correlation between the internal storage capacity of their device and the applications they can have at their disposal. When a user decides to use a new application on his device, he wants it up and running as fast as possible. He doesn’t want to be bothered with downloading and installing the new application. In the ideal case, he wants to select the new application and start using it immediately without any considerable delay. II. A PPLICATION STREAMING The system described in this article will provide an elegant solution to these issues. The system will stream applications to the device of the user in a transparant way for both, end user and application developer. Activating an application will result in a virtual installation of the application. Which means that the application will be installed as with a regular installation (creation of configuration files, execution of installation scripts, . . . ) but its files will only show up virtually with no content downloaded yet. When the newly activated application starts executing, the content of the application files will be streamed automatically, but only the parts needed. The main objectives of the system for resource-constrained devices are: • Lower usage of local storage • Faster initial application start
• •
Reduced network transfervolume Extensive application collection III. D ESIGN
Several problems arose during the design of the system. The most prominent of these will be discussed in the following subsections. A. File virtualization A main function of the system is to virtualize the application files on the device of the user. This is vital to the workings of the system since the application files must be accessible even when in reality none or only some of their parts (see section IIIC) are available in the local storage. Two viable options that can address this problem have been identified: a virtual machine and a virtual filesystem. The first option is to virtualize files by means of a virtual machine. When a user starts a streamed application, the virtual machine is started up first which will execute the application on its virtual processor. Doing so, the virtual machine gets full control over the origin of the application code. If available it loads the application code from local storage, otherwise it streams the code from the server. This is an easy solution for end users but it comes with a high price. Executing applications in a virtual machine consumes a lot of resources (computation and memory) which are not abundantly available on the target devices. Translating applications for the virtual machine is also very costly, requires a lot of expertise and is processor dependant. Moreover, virtualization is only available within the virtual machine and is not system wide. A better candidate is found in using a virtual filesystem, inserted as a device driver in the operating system. Since the device driver is logically placed behind the operating system kernel, its virtual files become system wide available. As such, the streamed applications can be loaded and executed by the operating system kernel as if they were regular applications. A virtual filesystem is, compared to a virtual machine, rather straightforward in development, it uses a lot less resources when executed and can be made processor independent. B. Data caching Since streaming application parts can be slow, it’s important to introduce some form of caching. Therefore the system will manage a size limited data cache on the local storage of the device. It can hold a fixed number of application parts and is shared between all applications. The strategy to manage this cache should be chosen carefully. There is no point in flushing the whole cache for an application that will be executed only
once. From the users perspective it will be better to keep the more frequently used application parts in the data cache. C. Granularity of streamed application parts Streaming the whole application every time it’s required, will waste a lot of resources, because applications are often packaged with other files that aren’t needed every time. Even the executable file can contain large parts that will rarely be needed. Think of word processors with lots of functionality of which the user only uses a small amount. For that reason, application files are divided up in smaller chunks of equal size. These smaller chunks will be streamed to the client when required. It turns out that the best size for these chunks is chosen equal to the page size, used by the operating system on the client device. D. Random execution As opposed to streaming audio or video, applications can not be streamed as a linear sequence of frames. Parts of an application are executed in an arbitrary sequence which is hard to predict. As a consequence, application parts will only be streamed reactively as a response to a request made by a client. This will introduce extra delay in the execution of the application when a part has to be streamed to the client. IV. A RCHITECTURE Figure 1 shows a general overview of the Application Streaming System.
Streamed Applications
User
Administrator
Operating System Kernel
Page Loader
Application Manager
Collection Manager
Streaming Client
Streaming Server
Global Filesystem Caching Filesystem
Normal Filesystem
Application Storage
Client
Server
Fig. 1. General overview of the Application Streaming System. Grey blocks belong to the described system.
be handled by the Page Loader which depends on the Global Filesystem to provide the necessary data. The Caching Filesystem module will either read the requested data from its data cache on a Normal Filesystem or send a request for the needed data to the Server using the Streaming Client module. The Streaming Client is able to handle connections with multiple Servers simultaneously and can send multiple requests to a Server without waiting for the response (asynchronous requests). The Streaming Server module receives the requests from the Clients and answers them by using the information in the Application Storage module. The Streaming Server module is able to handle multiple request in parallel from different Clients or from the same Client. The Application Storage module stores all content of the application files and meta information on the applications in the collection. The meta information is used to provide Users with an overview of the available applications in the collection through the Application Manager. An Administrator can use the Collection Manager module to add new applications or new versions of an application to the Application Storage. V. T EST RESULTS We have performed a series of tests by executing a collection of applications when streamed with the system. During the tests, the execution time of the application and the amount of application data effectively transmitted were measured. The tests were performed with two virtual computers with a virtual local network in between. The bandwidth of the local network was set to 4 Mbps, 384 Kbps and 128 Kbps. The results showed that streaming applications can have a high impact on execution times. This was largely due to the limited bandwidth of the network compared to local storage. This is especially noticeable with a network bandwidth of 128 Kbps where execution could take as much as 20 minutes whereas the same application executed from local storage took only 2 seconds. With a network bandwidth of 4 Mbps the execution times remained within acceptable limits. The execution of the same application with a network bandwidth of 4 Mbps took only 52 seconds. Streamed application data ranged from 98% to 23% for application with a sole solid executable-file through 7% for applications with lots of extra files. This shows the true potential of streaming applications since only the application data effectively needed by the user are streamed. As such, great savings can be achieved in both used local storage and used network transfer volume. VI. C ONCLUSION
A User can activate new applications on his system with the Application Manager module. This module will execute the virtual installation provided by the Server by adding the application files to the Caching Filesystem module. This will generally take less then a second to execute. The application files are now system wide available. Starting a Streamed Application doesn’t require any special actions and will be handled by the Operating System Kernel as with any regular application. Loading the application will
The described Application Streaming System is able to provide users of resource-constrained devices with an extensive application collection which uses only a comparatively small amount of local storage. The system is easy to use and transparent for both end user and application developer. The system is designed to run on resource-constrained devices.
Inhoudsopgave 1 Inleiding
1
1.1
Probleemschets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Centrale vragen van deze thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3.1
Hoe kan een systeem voor het streamen van applicaties gebouwd worden?
5
1.3.2
Wat zijn de praktische problemen bij het streamen van applicaties? . . . .
6
1.3.3
Is het praktisch haalbaar om applicaties te streamen? . . . . . . . . . . .
8
1.3.4
Bijkomende vragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
Software over een netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.4.1
Remote execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.4.2
Local delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
Verwant werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.5.1
Het Zero Install systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.5.2
AppStream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Overzicht van deze thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.4
1.5
1.6
2 Specificatie
15
2.1
Informele beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.2
Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3
Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3 Architectuur 3.1
33
Het Application Streaming System . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.1.1
Het globale systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.1.2
Het StreamingClient subsysteem . . . . . . . . . . . . . . . . . . . . . . .
36
vii
INHOUDSOPGAVE
3.1.3 3.2
3.3
viii
Het StreamingServer subsysteem . . . . . . . . . . . . . . . . . . . . . . .
37
Het StreamingClient subsysteem . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.2.1
De module CachingFilesystem
. . . . . . . . . . . . . . . . . . . . . . . .
39
3.2.2
De module Locator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.2.3
De module ClApplicationStreamer . . . . . . . . . . . . . . . . . . . . . .
45
3.2.4
De module ApplicationManager . . . . . . . . . . . . . . . . . . . . . . . .
47
3.2.5
De module UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
Het StreamingServer subsysteem . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.3.1
De module SvApplicationStreamer . . . . . . . . . . . . . . . . . . . . . .
48
3.3.2
De module Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.3.3
De module CollectionManager . . . . . . . . . . . . . . . . . . . . . . . .
51
3.3.4
De module UserManager . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.3.5
De module UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4 Ontwerpkeuzes 4.1
4.2
4.3
4.4
53
Virtualisatie van bestanden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.1.1
Speciale streamingbibliotheek . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.1.2
Virtuele machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.1.3
Virtueel bestandssysteem . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
Bestandsbeheer in het virtuele bestandssysteem . . . . . . . . . . . . . . . . . . .
56
4.2.1
Beheer van de bestandsinhoud . . . . . . . . . . . . . . . . . . . . . . . .
57
4.2.2
Beheer van de directorystructuur . . . . . . . . . . . . . . . . . . . . . . .
61
Beheer van de datacache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.3.1
Keuzestrategie¨en . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.3.2
Updatestrategie¨en . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
Granulariteit van streamen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.4.1
Streamen per applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
4.4.2
Streamen per bestand . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
4.4.3
Streamen per vast blok . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.4.4
Streamen per variabel blok . . . . . . . . . . . . . . . . . . . . . . . . . .
70
INHOUDSOPGAVE
5 Resultaten en verder onderzoek 5.1
5.2
ix
72
Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
5.1.1
Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
5.1.2
Testprogramma’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
5.1.3
Gestreamde hoeveelheid . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
5.1.4
Uitvoeringstijd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
5.1.5
Latentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
Verder onderzoek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.2.1
Gespecialiseerd cachebeheer . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.2.2
Proactief streamen van applicaties . . . . . . . . . . . . . . . . . . . . . .
78
5.2.3
Gebruikersprofielen toevoegen . . . . . . . . . . . . . . . . . . . . . . . . .
79
5.2.4
Gebruiksmodel opstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
6 Conclusie
81
Lijst van afkortingen ADSL Asymmetric Digital Subscriber Line APT Advanced Packaging Tool ATP Application Transfer Protocol B byte Bash Bourne-again shell CGI Common Gateway Interface EDGE Enhanced Data rates for GSM Evolution FAT File Allocation Table FTP File Transfer Protocol GNU GNU’s Not Unix GPRS General Packet Radio Service GSM Global System for Mobile Communications GUI Graphical user interface HTML HyperText Markup Language HTTP HyperText Transfer Protocol I/O Input/Output inode indexnode IP Internet Protocol ISDN Integrated Services Digital Network IT Information technology J2EE Java 2 Enterprise Edition KiB kibibyte, kilo binary byte (= 1024 bytes)
x
LIJST VAN AFKORTINGEN
Kbps kilobit per seconde (= 1000 bits per seconde) LAME LAME Ain’t an MP3 Encoder LRU Least Recently Used MiB mebibyte, mega binary byte (= 1024 KiB) Mbps megabit per seconde (= 1000 Kbps) MMX (handelsmerk van Intel zonder duidelijke betekenis) MP3 MPEG-1 Layer 3 MPEG Moving Picture Experts Group MS Microsoft PC Personal computer PDA Personal Digital Assistant PseudoLRU Pseudo Least Recently Used RPC Remote Procedure Call TCP Transmission Control Protocol UI User interface UMTS Universal Mobile Telephone System URI Uniform Resource Identifier URL Uniform Resource Locator Wi-Fi Wireless Fidelity XDR eXternal Data Representation
xi
Hoofdstuk 1
Inleiding Vroeger werd software bijna uitsluitend gedistribueerd via fysieke media zoals diskettes of cdrom’s. Door de populariteit van het internet in het laatste decennium wordt software steeds vaker via deze elektronische snelweg gedistribueerd. Elektronische distributie heeft immers een aantal voordelen ten opzichte van distributie op fysieke media. Zo vervalt de kost voor het aanmaken van de media en het verdelen van de media via de winkels, bovendien kan de software meteen wereldwijd aangeboden worden waardoor veel meer potenti¨ele klanten bereikbaar zijn. Tegelijkertijd wordt de tijd die verloopt tussen het afwerken van de software en het bereiken van de klant met de software heel wat korter. In de loop der tijden zijn daarom al heel wat manieren bedacht en ge¨ımplementeerd om functionaliteit op de meest uiteenlopende wijzen bij de gebruiker te krijgen. Al deze methodes kunnen ingedeeld worden in twee groepen. Aan de ene kant zijn er de manieren die gebruikmaken van remote execution waarbij de applicatie uitgevoerd wordt op een server waarvan de gebruiker de resultaten dan op zijn toestel te zien krijgt. Aan de andere kant zijn er de manieren die gebruikmaken van local delivery waarbij de applicatie getransporteerd wordt naar het toestel van de gebruiker waarna deze hierop uitgevoerd wordt. Een verdere bespreking van deze twee methodes met hun voor- en nadelen wordt gegeven in sectie 1.4. In deze thesis wordt een werkwijze besproken waarbij de applicaties gestreamd worden naar het toestel van de gebruiker. Deze methodiek hoort dan ook thuis in de groep van local delivery. Met deze manier van werken zal getracht worden een aantal problemen en tekortkomingen van de bestaande werkwijzen, die optreden bij resource-beperkte toestellen, te verhelpen.
1
1.1 Probleemschets
1.1
2
Probleemschets
Draagbare toestellen zijn tegenwoordig niet meer weg te denken uit het dagelijkse leven. Iedereen heeft wel de beschikking over een GSM, MP3-speler, PDA of mobiele spelcomputer. Deze toestellen krijgen ook steeds meer mogelijkheden zoals draadloze internettoegang (bijvoorbeeld door middel van GPRS, UMTS of Wi-Fi) en het uitvoeren van complexe applicaties. De beschikbare interne opslag blijft echter wel een belangrijke factor in de kost van deze toestellen. Ontwikkelaars van deze toestellen doen er dan ook alles aan om de interne opslag zo klein mogelijk te houden zonder de gebruiksvriendelijkheid van het toestel in gedrang te brengen. Dezelfde trade-off tussen geheugen en kost bestaat ook in de dedicated hardware zoals bijvoorbeeld set-top boxen voor digitale televisie en breedbandrouters en -modems. Ook bij deze toestellen trachten de ontwikkelaars een zo groot mogelijke functionaliteit te cre¨eren in een zo klein mogelijk geheugen. Gebruikers van hun kant wensen echter net zo veel mogelijk lokale opslag. Zij willen te allen tijde zelf kunnen beslissen hoeveel en welke applicaties zij op hun toestel ter beschikking hebben. Zij willen met andere woorden niet gedwongen worden om te kiezen tussen twee applicaties omdat er voor beide tezamen onvoldoende lokale opslag ter beschikking is op hun toestel. In het ideale geval wil de gebruiker dat er geen verband bestaat tussen de lokaal beschikbare opslag en de applicaties die beschikbaar zijn op zijn toestel. Wanneer de gebruiker een nieuwe applicatie aan zijn toestel wil toevoegen, kan er heel wat tijd verlopen tussen het moment waarop de gebruiker de nieuwe applicatie selecteert 1 , bijvoorbeeld op een website, en het moment waarop hij de applicatie effectief kan gebruiken. Dit heeft twee oorzaken. In de eerste plaats moet de applicatie gedownload worden naar zijn toestel alvorens de applicatie opgestart en gebruikt kan worden. Ten tweede moet er in vele gevallen een installatieprocedure doorlopen worden die een aantal noodzakelijke veranderingen doorvoert op het systeem van de gebruiker. In sommige gevallen vereist deze installatieprocedure ook nog een interactie van de gebruiker. In het ideale geval wil de gebruiker echter dat de nieuwe applicatie meteen na de selectie wordt uitgevoerd en bij voorkeur zonder installatieprocedure. Door de eenvoud waarmee applicaties op het internet gepubliceerd kunnen worden, zullen nieuwe versies van een applicatie ook veel sneller en frequenter beschikbaar gemaakt worden 1
Selectie van een applicatie geeft het moment aan waarop de gebruiker beslist een nieuwe applicatie te willen
gebruiken door middel van een handeling.
1.2 Doelstellingen
3
voor de gebruikers. Gebruikers wensen zich echter niet bezig te houden met het onderhouden van hun applicaties met nieuwe versies. In vele gevallen wil een gebruiker steeds automatisch gebruikmaken van de meest recente versie van zijn applicaties.
1.2
Doelstellingen
In deze thesis zal een Application Streaming System ontworpen worden dat een oplossing moet bieden voor de eerder besproken problematiek door, op een voor de gebruiker en applicatieontwikkelaar transparante wijze, applicaties naar het toestel van de gebruiker te streamen. Streaming technologie wordt al langer gebruikt voor het bezorgen en weergeven van audio en video zodat de gebruiker niet moet wachten tot het volledige databestand gedownload is. Door dit principe nu ook toe te passen op applicatiebezorging, dient een applicatie niet eerst volledig te worden gedownload alvorens deze gebruikt kan worden. Een activatie 2 van de applicatie, zoals de configuratie in het systeem, is in dit geval al voldoende om de applicatie te kunnen opstarten en de uitvoering te laten beginnen. Op basis van de behoeften van de gebruiker wordt de rest van de applicatie dan tijdens de uitvoering van de applicatie naar het toestel van de gebruiker gestreamd. Doordat een applicatie niet volledig, of zelfs helemaal niet, aanwezig moet zijn op het toestel van de gebruiker, terwijl het besturingssysteem hiervan niet op de hoogte is, moet het streamen van een applicatie gepaard gaan met een virtualisatie van de applicatiebestanden. Het besturingssysteem moet met andere woorden de “illusie” krijgen dat alle applicatiebestanden volledig op het toestel aanwezig zijn. Door applicaties op deze manier te streamen naar het toestel van de gebruiker, wordt getracht met de volgende aspecten een verbetering te brengen ten opzichte van de bestaande applicatie distributie methodes (voor een bespreking van deze bestanden methodes, zie sectie 1.4).
Minder gebruik van de lokale opslag: doordat enkel de gebruikte delen van een applicatie aanwezig moeten zijn op het toestel van de gebruiker zal er meer plaats vrijkomen voor de opslag van andere data. 2
Een activatie van een applicatie is hetzelfde als een installatie maar er worden geen bestanden van de applicatie
in de lokale opslag geplaatst. Het omvat onder andere het aanmaken van een configuratiebestand, het uitvoeren van een installatiescript, e.a.
1.3 Centrale vragen van deze thesis
4
De applicatie kan sneller opgestart worden: doordat de applicatie niet fysiek aanwezig moet zijn op het toestel van de gebruiker, kan de applicatie opgestart worden zodra een minimale hoeveelheid van de applicatiecode gestreamd werd. Op deze manier kan de tijd die nodig is om de applicatie te downloaden naar het toestel van de gebruiker verdeeld worden over de uitvoering van de applicatie zelf. De gebruiker zal dus niet moeten wachten tot de volledige applicatie naar zijn toestel gedownload werd maar zal de applicatie, meteen na de in verhouding korte activatie, kunnen opstarten. Verminderd netwerk transfervolume: door enkel de onderdelen van een applicatie te streamen die effectief gebruikt worden door de gebruiker, moet vaak maar een deel van de volledige applicatie gestreamd worden. Zeker bij uitgebreidere applicaties zal de gebruiker immers zelden de volledige functionaliteit van een applicatie gebruiken. Uitgebreidere applicatiecollectie: er kan de gebruiker een meer uitgebreide applicatiecollectie ter beschikking gesteld worden zonder dat de applicaties ook effectief aanwezig moeten zijn op zijn toestel. De afwezigheid van een zelden gebruikte applicatie op het toestel zal geen belemmering meer vormen voor de productiviteit van de gebruiker. Bij het gebruik van de applicatie zullen immers automatisch de benodigde delen van de applicatie naar het toestel van de gebruiker gestreamd worden. Automatisch selectief onderhoud: onderhoud van applicaties dient niet manueel en/of collectief te gebeuren maar kan automatisch net voor het opstarten van de applicatie gebeuren en op precies dezelfde manier waarop een applicatie voor het eerst gestart wordt. Dit vermijdt bovendien onderhoud van applicaties die niet langer in gebruik zijn. Met deze aspecten wordt getracht een aantal tekortkomingen van de huidige methodes inzake applicatiedistributie en -onderhoud te verbeteren om alzo de gebruikerservaring verder te optimaliseren.
1.3
Centrale vragen van deze thesis
Het Application Streaming System zal, op een voor de gebruiker en applicatieontwikkelaar transparante wijze, de mogelijkheid bieden om applicaties lokaal uit te voeren zonder dat deze daarvoor permanent en/of volledig in de lokale opslag van het toestel aanwezig moeten zijn. De meest centrale vragen als voornaamste drijfkrachten achter deze thesis zijn:
1.3 Centrale vragen van deze thesis
5
1. Hoe kan een systeem voor het streamen van applicaties gebouwd worden? 2. Wat zijn de praktische problemen bij het streamen van applicaties? 3. Is het praktisch haalbaar om applicaties te streamen? Hieronder hernemen we deze centrale vragen met enkele bijkomende subvragen die ze opwerpen en worden mogelijke antwoorden geformuleerd.
1.3.1
Hoe kan een systeem voor het streamen van applicaties gebouwd worden?
Bij het streamen van applicaties moeten de applicatiebestanden niet permanent aanwezig zijn op het toestel van de gebruiker. Dit vereist uiteraard speciale technieken die deze werkwijze kunnen ondersteunen. In de volgende secties worden belangrijke subvragen behandeld die een belangrijke rol spelen bij het ontwikkelen van het Application Streaming System.
Hoe kunnen applicatiebestanden gevirtualiseerd worden? Een voorname functie van het Application Streaming System, is het virtualiseren van de applicatiebestanden. Dit is noodzakelijk omdat, onder andere door het besturingssysteem, de applicatiebestanden wel steeds aanspreekbaar moeten zijn, terwijl ze in werkelijkheid niet of maar gedeeltelijk aanwezig zijn in de lokale opslag. De bestanden zullen immers pas naar het toestel van de gebruiker gestreamd worden op het moment dat hun inhoud ook effectief nodig is voor de uitvoering van de applicatie. Er moet dus een techniek gebruikt worden die het besturingssysteem, op het toestel van de gebruiker, “voorliegt” dat de bestanden steeds aanwezig zijn in de lokale opslag en op de achtergrond de bestanden pas streamt wanneer hun inhoud nodig is. In deze thesis werd gebruikgemaakt van een virtueel bestandssysteem waaraan bestanden met eigenschappen zoals bestandsnaam, pad, permissies en grootte kunnen toegevoegd worden maar zonder hun inhoud. Wanneer het besturingssysteem een applicatie uit het virtuele bestandssysteem wil starten, zal het een lees-aanvraag (Eng. read-request) doen bij het virtuele bestandssysteem voor de inhoud van een bepaald deel van een bestand. Het virtuele bestandssysteem kijkt dan of de gevraagde inhoud uit de lokale opslag opgehaald kan worden of via het netwerk gestreamd moet worden. In hoofdstuk 4 wordt het gebruikte virtuele bestandssysteem
1.3 Centrale vragen van deze thesis
6
verder besproken samen met andere alternatieven voor de virtualisering van de applicatiebestanden.
Hoe gestreamde bestanden lokaal cachen? Wanneer de bestanden in het virtuele bestandssysteem steeds opnieuw gestreamd moeten worden telkens hun inhoud nodig is, zal dit een zeer oneffici¨ent gebruik van resources, meer bepaald de netwerkverbinding, betekenen. Bestanden, of delen van bestanden, die gestreamd worden naar het toestel van de gebruiker, worden dan ook best bewaard in de lokale opslag van het toestel om ze in de toekomst niet opnieuw te moeten streamen. In het geval van resource-beperkte toestellen is de lokale opslag van het toestel vaak relatief klein en kunnen dan ook niet alle gestreamde bestanden eeuwig bewaard blijven. Bovendien zal de gebruiker van het toestel niet al zijn lokale opslag willen besteden aan het cachen van bestanden en de lokale opslag liever gebruiken om persoonlijke data op te slaan. Op een gegeven moment zal de plaats die ingenomen wordt door de bewaarde gestreamde bestanden dan ook gerecycleerd moeten worden. Om de gestreamde applicatiebestanden zo optimaal mogelijk te beheren, werd in het virtuele bestandssysteem, zoals hierboven beschreven, een gespecialiseerde datacache voor dit doel ondergebracht. De opbouw van de datacache wordt besproken in sectie 4.3.
1.3.2
Wat zijn de praktische problemen bij het streamen van applicaties?
Streamen van applicaties naar resource-beperkte toestellen betreft een optimalisatievraagstuk waarbij er een afweging moet gemaakt worden tussen een aantal factoren zoals gebruik van netwerk transfervolume, gebruik van lokale opslag, vlotte gebruikerservaring, eventueel de levensduur van de batterij, e.a. De volgende secties geven een overzicht van een aantal belangrijke vragen die de keuzes bij deze afwegingen be¨ınvloeden.
Welke gegranuleerdheid moet gebruikt worden om applicaties te streamen? Om applicaties te kunnen streamen moet eerst een eenheid gekozen worden waarin elke applicatie opgedeeld zal worden. De eenheid is een deel van de applicatie dat als verder ondeelbaar wordt beschouwd en dat individueel naar het toestel van de gebruiker gestreamd kan worden. Alvorens een applicatie gestreamd kan worden moet deze dan ook eerst opgedeeld worden in eenheden.
1.3 Centrale vragen van deze thesis
7
Er bestaat een aantal mogelijkheden om deze eenheid te kiezen waarbij de ene al meer voordelen biedt dan de andere. De mogelijkheid die in deze thesis gekozen wordt bestaat erin de bestanden van de applicatie op te delen in kleinere blokken van telkens dezelfde grootte. In sectie 4.4 wordt besproken wat de ideale grootte van zo’n blok is als ook welke alternatieven er bestaan.
Welke evictie-strategie moet worden toegepast in de datacache? Zoals in sectie 1.3.1 beschreven werd, zal er in het virtuele bestandssysteem een datacache ingebouwd worden die de gestreamde applicatiedelen in de lokale opslag van het toestel opslaat voor eventueel later gebruik. Deze datacache is echter in grootte begrensd door de beperkte lokale opslagmogelijkheden van het toestel. Daarom wordt een evictie-strategie gebruikt om gegevens uit de datacache te verwijderen wanneer deze vol zit en er nieuwe gegevens aan toegevoegd moeten worden. De gekozen strategie zal echter een belangrijke invloed hebben op de prestaties van het Application Streaming System. Een goede keuze hier is dan ook een absolute must. De prestaties van de strategie op zich zijn niet het enige beoordelingscriterium. Ook de hoeveelheid metagegevens die verzameld moeten worden, en bij gevolg ook bewaard moeten worden in de lokale opslag, speelt een rol bij de keuze. Een uitgebreide studie van de verschillende mogelijkheden voor de evictie-strategie was in het kader van deze thesis niet mogelijk. In deze thesis werd gekozen voor de Pseudo-least-recentlyused (PseudoLRU) strategie die relatief goede prestaties oplevert met een beperkte hoeveelheid metagegevens. Een bespreking van de gekozen strategie en andere mogelijkheden wordt gegeven in sectie 4.3.
Hoe kan de grilligheid in de uitvoering van een applicatie worden opvangen? In tegenstelling tot bijvoorbeeld het streamen van audio en video staat de volgorde waarin de data gestreamd moeten worden bij applicaties niet vast. Audio- en video-data worden immers altijd lineair van het begin tot het einde afgespeeld, tenzij de gebruiker expliciet vraagt om vanaf een bepaald moment te beginnen afspelen. Bij applicaties ligt dit volledig anders. Delen van een applicatie, de functies, worden in een bijna willekeurige volgorde uitgevoerd. Het best kan dit vergeleken worden met een video-film die in een willekeurig aantal deeltjes geknipt wordt van
1.3 Centrale vragen van deze thesis
8
verschillende lengte, waarna de deeltjes in een willekeurige volgorde afgespeeld worden. Hierbij kunnen bepaalde deeltjes zelfs vaker dan ´e´en keer afgespeeld worden en andere deeltjes helemaal nooit. Om deze reden is het zeer moeilijk te weten welk deel van een applicatie als volgende uitgevoerd zal worden. Daarom zal in deze thesis een reactief model gevolgd worden waarbij een deel van de applicatie pas gestreamd wordt op het moment dat geweten is dat het effectief nodig is voor de uitvoering van de applicatie. Dit zal echter leiden tot een extra vertraging in de applicatie waardoor een proactief model betere resultaten kan behalen. Dit valt echter buiten het bereik van deze thesis maar zal kort besproken worden in sectie 5.2.2.
1.3.3
Is het praktisch haalbaar om applicaties te streamen?
Met andere woorden, kan een Application Streaming System ontwikkeld worden dat aanvaardbaar is voor de gebruikers? Hoewel het systeem er op gericht is om de wachttijden voor de gebruiker te verminderen en zijn lokale opslag effici¨enter te gebruiken, zal een vertraging steeds voelbaar blijven wanneer de applicatie gestreamd wordt tijdens de uitvoering ervan. De vraag is of deze vertraging voldoende klein kan gemaakt worden zodat de gebruiker er bijna niets van merkt of zodat de gebruiker deze vertraging zal kunnen aanvaarden. Uit de resultaten van deze thesis zal blijken dat het haalbaar is om applicaties te streamen. Met het huidige prototype van het Application Streaming System dat in het kader van deze thesis ontwikkeld werd, wegen de voordelen van een dergelijk systeem echter nog niet op tegen de nadelen. Het opstarten van een applicatie voor de eerste maal kan enorm traag zijn wat de gebruiker soms kan doen twijfelen of er nog iets zal gebeuren. Dit zou in de toekomst voor een deel verholpen kunnen worden door een proactief streaming-model te volgen. Ook de strategie van de datacache is nog verre van optimaal te noemen en is zeker een punt dat verbeterd moet worden in een definitief systeem. Maar het streamen van applicaties is zeker haalbaar en een valabele optie voor het distribueren van applicaties in de toekomst.
1.3.4
Bijkomende vragen
In deze sectie wordt een vraag besproken die belangrijk is voor het Application Streaming System maar niet onderzocht werd wegens te uitgebreid en te complex om te behandelen binnen het tijdsbestek van deze thesis.
1.4 Software over een netwerk
9
Wat gebeurt er bij het wegvallen van de netwerkverbinding? Doordat het systeem er net op gericht is minder lokale opslag te gebruiken ten koste van netwerk transfervolume, blijft een netwerkverbinding met de server een vereiste voor de correcte werking van de applicaties. Wanneer de netwerkverbinding wegvalt tijdens de uitvoering van een applicatie zal dit onherroepelijk leiden tot een fout in de applicatie wanneer de uitvoering een applicatiedeel nodig heeft dat nog niet in de datacache aanwezig is. Dit is niet anders dan bij het streamen van audio of video waarbij het verbreken van de verbinding ook zal leiden tot het abrupt stoppen van de weergave. Echter bij het streamen van applicaties kan dit meer ernstige gevolgen hebben zoals bijvoorbeeld dataverlies. Voor de gebruiker is dit uiteraard onaanvaardbaar maar de enige remedie op dit moment, degene die ook toegepast wordt in deze thesis, is dat de gebruiker zelf proactief het systeem opdraagt een applicatie volledig te cachen v´ o´ or het verbreken van de verbinding. Hierdoor verliest de gebruiker natuurlijk de voordelen die gepaard gaan met gestreamde applicaties. Een alternatief kan misschien gevonden worden in een grondige analyse van de applicatie alvorens het streamen, waarbij voor elk deel van een applicatie een graceful degradation wordt voorzien voor het geval dat een deel niet gestreamd kan worden zonder een fout in de applicatie te veroorzaken. Zulke technieken vallen echter buiten het bestek van deze thesis en zullen dan ook niet verder besproken worden.
1.4
Software over een netwerk
Voor het aanbieden van applicaties via een netwerk bestaan er twee methodes, remote execution en local delivery. In de volgende paragrafen zullen beide methodes nader toegelicht worden.
1.4.1
Remote execution
Bij remote execution wordt de applicatie geladen en uitgevoerd op een server en wordt enkel de presentatielaag ge¨exporteerd naar de client. Een goede werking van de applicatie is dan ook sterk afhankelijk van de beschikbaarheid van de server. De gebruiker kan op een interactieve manier de applicatie op de server gebruiken. De invoer van de gebruiker wordt hiervoor aan de clientzijde opgevangen en doorgezonden naar de server die de invoer verwerkt en een resultaat terugstuurt naar de client.
1.4 Software over een netwerk
10
Een vaak gebruikte vorm voor de presentatielaag zijn dynamisch gegenereerde webpagina’s waarop eenvoudige UI-componenten kunnen geplaatst worden en die met een standaard webbrowser zoals Firefox kunnen bekeken worden. Getuigen hiervan zijn het grote aantal applicatieservers voor de J2EE en .NET platformen. Deze applicatieservers maken nog steeds gebruik van de CGI-standaard3 en zijn eigenlijk een sterke doorontwikkeling van de bijhorende scripts en applicaties. Het zijn applicatieplatformen die de applicatieontwikkelaar van een aantal basisvereisten ontlast, zoals bijvoorbeeld het traceren van gebruikersessies. Daarnaast bieden ze een aantal krachtige hulpmiddelen zoals eenvoudige programmeertalen voor het genereren van web-pagina’s en vereenvoudigde persistentie van data. Een nadeel van deze vorm is dat de presentatiemogelijkheden beperkt blijven tot deze van een standaard webbrowser. Dit kan echter ook als hun grootste kracht gezien worden daar de applicaties op elke webbrowser op elk besturingssysteem kunnen gebruikt worden. Een systeem met meer uitgebreide presentatiemogelijkheden bestaat uit het installeren van specifieke clientsoftware op de gebruikerscomputer, dewelke dan gebruikt wordt voor het cre¨eren van applicatievensters in MS Windows stijl. Deze vensters kunnen dan weer gebruikt worden voor het weergeven van de presentatielaag van de applicaties die uitgevoerd worden op de server. Hierbij worden bijna geen beperkingen opgelegd aangaande de presentatiemogelijkheden, met uitzondering van complexe animaties zoals bijvoorbeeld videobeelden. Vaak worden ook lokale hulpbronnen, zoals opslag en printers, van de gebruikerscomputer ge¨exporteerd naar de applicatie op de server. Hierdoor krijgt de gebruiker de illusie van een lokaal ge¨ınstalleerde en uitgevoerde applicatie. Nadeel bij deze techniek is de vertraagde reactie op gebruikersinvoer die hierbij vaak als storend wordt ervaren. Deze vertraging geldt uiteraard ook bij de applicatieservers, maar de gebruiker aanvaardt deze vertraging als normaal en niet storend bij het bekijken van webpagina’s.
1.4.2
Local delivery
De andere methode is local delivery waarbij de applicatie op de gebruikerscomputer wordt geladen en uitgevoerd. Na een eerste keer downloaden kan de applicatie dan ook werken zonder beroep te moeten doen op een server voor de uitvoering. Hierbij is de gebruiker in grote mate zelf verantwoordelijk voor het installeren en onderhouden van de applicatie, dit in tegen3
Met de CGI-standaard kan er informatie van de client naar de server gezonden worden, ingebed in de HTTP-
aanvraag of gecodeerd in de URL van de webpagina.
1.4 Software over een netwerk
11
stelling tot remote execution waarbij veel van deze taken door de systeembeheerder van de server overgenomen worden. Het meest eenvoudige voorbeeld van deze methode is het downloaden van het installatiearchief van een applicatie door de gebruiker met behulp van bijvoorbeeld een webbrowser of een FTP-client. De gebruiker dient vervolgens handmatig de installatie te starten en te sturen. In dit geval is er dus een grote gebruikersinteractie nodig alvorens de applicatie klaar is voor gebruik. Hierbij zijn voor de gebruiker het downloaden van het installatiearchief, de installatie en het uitvoeren van de applicatie gescheiden processen. Een meer ge¨ıntegreerde techniek zijn de package management systemen die in de Linuxwereld vaak gebruikt worden zoals bijvoorbeeld APT (Advanced Packaging Tool) voor Debian GNU/Linux. Omdat een groot deel van de applicaties voor Linux als open-source project beschikbaar is, wordt veel van de installatiearchieven van deze applicaties in een vrij te gebruiken centraal package management systeem ondergebracht. Met de juiste tools kan dan op eenvoudige wijze de lijst met beschikbare applicaties worden opgevraagd en applicaties ge¨ınstalleerd, ge¨ updatet en verwijderd worden. Hierbij wordt telkens rekening gehouden met de onderlinge afhankelijkheden tussen de applicaties. Bij deze methode wordt het downloaden en installeren van een applicatie samengevoegd tot ´e´en enkel proces en worden het onderhoud en het verwijderen van een applicatie sterk vereenvoudigd voor de gebruiker. Bovendien krijgt de gebruiker steeds een mooi overzicht van de beschikbare software. Een andere techniek wordt gebruikt door bijvoorbeeld Java Applets. Hiervoor moet de gebruiker eerst een zogenaamde virtuele machine installeren, waarna meestal kleine applicaties in de context van een webbrowser kunnen worden uitgevoerd. De applicatie wordt hierbij als onderdeel van bijvoorbeeld een webpagina gedownload en meteen uitgevoerd. Een installatie van de applicatie is niet nodig omdat deze vaak gebruikt wordt als wegwerpapplicatie die bij het verlaten van de webpagina niet langer nodig is. Onderhoud van de applicatie door de gebruiker is ook niet nodig daar bij elk bezoek aan de webpagina de meest recente versie opnieuw wordt gedownload. Java Applets vormen dus als het ware een hybride oplossing tussen remote execution en local delivery omdat ze wel afhankelijk zijn van een server voor het laden van de applicatie maar niet voor de uitvoering ervan. Doordat de applicatie in een virtuele omgeving draait hoeft de gebruiker zich ook minder zorgen te maken over de herkomst van de applicatie. Door verder te bouwen op het succes van de Java Applets heeft Sun dan later Java Web
1.5 Verwant werk
12
Start ontwikkeld. Door het Java Web Start platform kunnen applicaties, net zoals Java Applets, eenvoudig vanuit een webbrowser worden gestart met dat verschil dat een Java Web Start applicatie een eigen venster heeft in plaats van in een webpagina te worden weergegeven. Bovendien wordt de applicatie net v´o´or het uitvoeren volledig gedownload en lokaal op de computer van de gebruiker gecachet. Vanuit deze lokale cache kan de applicatie dan later opnieuw gestart worden zonder gebruik te moeten maken van de oorspronkelijke server zodat de applicatie ook zonder een netwerkverbinding gebruikt kan worden. Is het netwerk wel beschikbaar, dan wordt bij het starten van de applicatie automatisch gecontroleerd of er een nieuwere versie beschikbaar is die dan ook meteen gedownload wordt en de oude versie in de cache zal vervangen.
1.5
Verwant werk
Er werd reeds eerder onderzoek gedaan en er werden reeds eerder systemen ontwikkeld die dezelfde of gelijkaardige doelstellingen hebben als deze thesis (zie sectie 1.2). In deze sectie zullen een aantal van deze systemen besproken worden, alsook hun verhouding tot het systeem dat in deze thesis ontwikkeld wordt.
1.5.1
Het Zero Install systeem
Het Zero Install systeem werd ontwikkeld door Thomas Leonard [Leo] en is erop gericht om, zoals de naam al zegt, applicaties te kunnen gebruiken zonder ze te moeten installeren. De voornaamste doelstellingen zijn: Iedereen kan een applicatie installeren: iedereen en niet enkel een administrator kan een nieuwe applicatie installeren. Een applicatie kan eenvoudigweg uitgevoerd worden door het opgeven van een URL. De applicatie wordt dan automatisch gedownload samen met zijn afhankelijkheden in een individuele of gemeenschappelijke cache. Iedereen kan een applicatie distribueren: het systeem is niet gebaseerd op een centraal beheerde package repository. Iedereen kan een applicatie distribueren via zijn eigen website. Er is geen toestemming van een centrale autoriteit nodig om een applicatie via het systeem te distribueren.
1.5 Verwant werk
13
Je kan een applicatie uitvoeren of ze nu ge¨ınstalleerd is of niet: wanneer een applicatie uitgevoerd wordt die nog niet ge¨ınstalleerd werd op het toestel, dan zal het systeem de applicatie automatisch downloaden, installeren en uitvoeren. Veiligheid: er werd een groot aantal veiligheidsmaatregelen in het systeem ingebouwd zoals bijvoorbeeld het signeren van de packages om tussenkomst van derden te voorkomen. Het Zero Install systeem vertoont vanuit het standpunt van de gebruiker sterke overeenkomsten met het Application Streaming System. De eerste drie doelstellingen worden immers ook bereikt met het Application Streaming System van deze thesis en de vierde is ook steeds mogelijk. Voor de derde doelstelling moet bij het Zero Install systeem wel reeds enige informatie over de applicatie beschikbaar zijn op het toestel van de gebruiker om een niet ge¨ınstalleerde applicatie te kunnen starten. Bij het Application Streaming System is dit echter niet het geval en is dit enkel afhankelijk van de beschikbaarheid van de server. Achter de schermen gaat het Zero Install systeem ook helemaal anders te werk. Een belangrijk onderscheid met het Application Streaming System is dat een applicatie steeds volledig gedownload wordt en niet enkel de delen die nodig zijn voor de uitvoering van de applicatie. Het systeem vertoont dan ook sterke overeenkomsten met Java Web Start maar dan niet enkel voor Java applicaties.
1.5.2
AppStream
Het AppStream [app] systeem kan op een gelijkaardige manier als het Application Streaming System uit deze thesis, applicaties streamen naar een computer van de gebruiker. Het uitgangspunt hier is echter het vereenvoudigen van de IT-administratie bij grote bedrijven. De doelstellingen zijn dan ook dynamisch licentiebeheer, versneld applicatiedeployment en vereenvoudigde PC-administratie. Achter de schermen werkt AppStream ook door het opdelen van de bestanden in kleinere delen van een vaste grootte die dan gestreamd kunnen worden naar de computer van de gebruiker. Voor de virtualisering van de bestanden wordt hierbij ook gebruikgemaakt van een virtueel bestandssysteem. Een punt van verschil met het systeem uit deze thesis is echter dat AppStream een gecentraliseerd systeem is. Alle applicaties zijn afkomstig vanuit ´e´en enkele bron.
1.6 Overzicht van deze thesis
1.6
14
Overzicht van deze thesis
In hoofdstuk 2 zullen de specificaties opgesteld worden voor het systeem. Er zal begonnen worden met een informele beschrijving aan de hand waarvan dan een aantal use case voor het systeem uitgewerkt worden. Op basis van deze specificatie zal dan in hoofdstuk 3 een architectuur voor het systeem opgesteld worden. Vervolgens zal in hoofdstuk 4 ingegaan worden op een aantal keuzes die gemaakt werden tijdens het ontwerpen van het systeem en zullen ook de argumenten voor deze keuzes gepresenteerd worden. Hoofdstuk 5 beschrijft een aantal testen die uitgevoerd werden met het systeem en bespreekt de resultaten die daaruit voortkwamen. In het tweede deel van hoofdstuk 5 zullen een aantal uitbreidingen en verdere onderzoeksdomeinen worden voorgesteld. Tot slot zal in hoofdstuk 6 een algemeen besluit geformuleerd worden waarin de belangrijkste resultaten van deze scriptie nog eens opgesomd worden.
Hoofdstuk 2
Specificatie In dit hoofdstuk wordt de specificatie van het Application Streaming System – onderwerp van deze thesis – besproken. In eerste instantie worden de informele vereisten van het systeem beschreven. Deze vereisten worden dan vertaald in meer formele use cases dewelke dan de basis zullen vormen voor het opstellen van de architectuur in hoofdstuk 3.
2.1
Informele beschrijving
Het Application Streaming System is een systeem dat applicaties aanbiedt aan zijn eindgebruikers via een netwerk zonder dat deze manueel gedownload moeten worden of een door de gebruiker begeleide installatie moeten ondergaan. Delen van een applicatiebestand worden pas naar het toestel van de gebruiker gestreamd op het moment dat de functionaliteit die in deze delen vervat zit, effectief nodig is voor de uitvoering van de applicatie. Hierdoor wordt de tijd die nodig is om een applicatie van de server op te halen en te starten, sterk gereduceerd en krijgt de gebruiker het gevoel dat de applicatie reeds op het lokale systeem aanwezig was. Het Application Streaming System zoals net beschreven, is bruikbaar voor het streamen van applicaties naar bijvoorbeeld desktopsystemen. Wil men deze techniek ook toepassen op resource-beperkte toestellen, dan moet er rekening gehouden worden met de specifieke beperkingen van deze toestellen. Het Application Streaming System zal daarom in de eerste plaats rekening houden met de, in vele gevallen, kleinere lokale opslag voor applicaties in deze toestellen. Het Application Streaming System zal deze toestellen in staat stellen meer of grotere applicaties uit te voeren dan de lokale opslag hen toelaat. De client zal een deel van de beschikbare lokale
15
2.1 Informele beschrijving
16
Client A Server 1
Client B
Netwerk Server 2
Client C
Figuur 2.1: Clients kunnen applicaties streamen van verscheidene servers en servers kunnen applicaties streamen naar meerdere clients
opslag beheren zodat deze plaats optimaal gebruikt wordt voor het opslaan van de applicaties. Bij het beheer van deze lokale opslag zal rekening gehouden worden met het gebruikspatroon van de gebruiker en zullen die delen van de applicaties bewaard worden die het meest nuttig kunnen zijn in de toekomst. Het systeem zal bestaan uit streamingservers en streamingclients die verbonden zijn via een netwerk. Zoals weergegeven in figuur 2.1 kan een server zijn applicaties tegelijk naar meerdere clients streamen en kan elke client tegelijk applicaties van meerdere servers streamen. De servers zullen op twee manieren geconfigureerd kunnen worden. Ofwel is de server publiekelijk toegankelijk en kan iedereen de applicaties anoniem gebruiken, ofwel vereist de server een authenticatie van de gebruiker alvorens men de applicaties kan gebruiken. De client zal de mogelijkheid hebben om te configureren welke servers gebruikt moeten worden en met welke authenticatiegegevens dit moet gebeuren. De gebruiker zou te allen tijde de indruk moeten krijgen dat de applicaties die beschikbaar worden gesteld door de server ook steeds beschikbaar zijn op zijn toestel. Dit geldt zelfs indien de applicatie nooit eerder gebruikt werd of indien de gebruiker nooit heeft aangegeven deze applicatie te willen gebruiken. Het voor de eerste keer starten van een applicatie zou dan ook geen andere handelingen mogen vereisen, zoals bijvoorbeeld het activeren van de applicatie in de lijst van beschikbare applicaties, ten opzichte van het starten van de applicatie na de eerste keer. Wanneer er een nieuwe versie van een applicatie beschikbaar komt in de applicatiecollectie,
2.2 Vereisten
17
dan kan de gebruiker er voor kiezen om bij de volgende start van de applicatie automatisch de nieuwste versie te gebruiken. De oude versie van de applicatie zal dan automatisch van de client verwijderd worden en de nieuwe versie zal worden uitgevoerd als betrof het hier een nieuwe applicatie. De server zou de data steeds zodanig moeten aanleveren aan de client, zodat de gebruiker het gevoel krijgt dat de applicatie lokaal opgeslagen is. Dit betekent concreet dat de uitvoering van een applicatie steeds zo snel mogelijk moet starten wanneer een gebruiker laat blijken een applicatie te willen gebruiken. Wanneer een applicatie gestreamd wordt, zullen dus eerst de delen van de applicatie gestreamd worden die noodzakelijk zijn om de applicatie verder uit te voeren. Deze noodzakelijke delen zouden dan gevolgd kunnen worden door delen van de applicatie die, volgens predictieve modellen, nodig kunnen zijn voor de uitvoering. De client zal de netwerkverbinding met de server steeds zo goed mogelijk onderhouden ten einde een continue service te kunnen waarborgen. Wanneer een verbinding verbroken wordt, zal de client op eigen initiatief, dus zonder tussenkomst van de gebruiker, de verbinding met de server proberen te herstellen. Bij een korte onderbreking van de verbinding zou de gebruiker hiervan niets mogen merken. Applicaties zouden dus zonder onderbreking moeten verder werken, ook al werd er tijdens de onderbreking een aanvraag gedaan voor het streamen van een nieuw deel van de applicatie. Bij het herstellen van de verbinding zal de aanvraag dan ook meteen herhaald worden. Enkel wanneer een server gedurende een lange tijd onbereikbaar blijft zal de gebruiker hiervan in kennis gesteld worden en kan de applicatie afgebroken worden.
2.2
Vereisten
In deze sectie zullen de voornaamste vereisten van het Application Streaming System opgesomd worden. De lijst is zeker niet bedoeld om de vereisten tot in detail te defini¨eren maar zou voldoende informatie moeten bevatten om er de use cases en architectuur op te funderen. De woorden ‘zal’ en ‘zou’ hebben een speciale en precieze betekenis in de context van vereisten. Een zal vereiste moet worden nagekomen. Indien een onderdeel dat een zal vereiste implementeert zich niet in het finale systeem bevindt, dan voldoet het systeem niet aan zijn vereisten. Een zou vereiste impliceert dat de vereiste niet kritiek is voor de correcte werking van het systeem volgens de vereisten, maar deze vereiste is wel wenselijk.
2.2 Vereisten
18
R1. Het Application Streaming System zal een systeem zijn dat een applicatiecollectie aanbiedt aan zijn gebruikers. R2. De gebruiker zal een willekeurig aantal applicatiecollecties tegelijk kunnen gebruiken. R3. Op geen enkel moment zal de correcte werking van een applicatie afhangen van de applicatiedelen die al dan niet lokaal beschikbaar zijn op het toestel van de gebruiker. Meer concreet komt dit neer op de vereiste dat een applicatie ook kan uitgevoerd worden wanneer maar een deel of zelfs niets van de applicatie lokaal beschikbaar is. R4. De beschikbaarheid of uitvoerbaarheid van een applicatie voor een client zal in geen enkel geval afhangen van de beschikbare hoeveelheid lokale opslag. Meer concreet komt dit neer op de vereiste dat de uitvoering van een applicatie niet kan geweigerd worden op basis van onvoldoende lokale opslag. R5. De lokale opslag van de applicatiedelen op de client zal beheerd worden op basis van het gebruikspatroon van de applicaties door de gebruiker. R6. Om een applicatie uit de collectie te gebruiken zal de gebruiker de applicatie niet eerst manueel moeten downloaden of installeren. R7. De gebruiker zou geen specifieke actie moeten uitvoeren om een applicatie voor een eerste maal te gebruiken. Deze speciale actie zal in geen geval meer bedragen dan het selecteren van de applicatie uit een lijst van beschikbare applicaties. R8. Het gebruik van applicaties via het Application Streaming System zal transparant zijn voor de gebruiker. Voor de gebruiker zal er dus geen fundamenteel verschil bestaan tussen een normale lokale applicatie of een applicatie die via het Application Streaming System gestreamd wordt. R9. Het aanbieden van een applicatie via het Application Streaming System zal geen speciale aanpak van de applicatieontwikkelaar vereisen om de applicatie geschikt te maken voor het streamen. R10. Elke applicatie die uitvoerbaar is op het toestel van de gebruiker zou ook geschikt moeten zijn om via het Application Streaming System uitgevoerd te worden. R11. Om applicaties te kunnen streamen zal de gebruiker eenmalig de Application Streaming System-client op zijn toestel moeten installeren. De installatie zou geen speciale technische kennis mogen vereisen.
2.2 Vereisten
19
R12. De configuratie van het Application Streaming System op de client zal eenvoudig zijn en geen speciale technische kennis van de gebruiker vereisen. R13. De client zal automatisch verbinding maken met de streamingservers die nodig zijn voor de uitvoering van een applicatie. R14. Wanneer een verbinding onverwachts verbroken wordt zal de client zo snel mogelijk en automatisch de verbinding trachten te herstellen. Aanvragen voor de server worden meteen opnieuw verstuurd. Bij korte onderbrekingen zal dit geen gevolgen hebben voor de correcte werking van de applicaties. R15. De gebruiker zal de mogelijkheid hebben een applicatie volledig in de lokale opslag op te slaan en aldus onafhankelijk te worden van de server. Deze actie kan geweigerd worden op basis van onvoldoende lokaal beschikbare opslag op de client. R16. De gebruiker zou de garantie moeten krijgen dat de applicatie die gestreamd wordt, steeds afkomstig is van de door de gebruiker geselecteerde applicatiecollectie. R17. De gebruikerservaring van een gestreamde applicatie uit de applicatiecollectie zou zo dicht mogelijk bij deze van een niet-gestreamde applicatie moeten liggen. R18. Een Application Streaming System server zal geconfigureerd kunnen worden om gebruikers anoniem toegang te verlenen tot de applicatiecollectie en/of toegang te verlenen op basis van een authenticatie. R19. Een applicatie zal op de server kunnen toegevoegd worden tot de applicatiecollectie als een directory waarin alle bestanden van de applicatie staan. R20. Een applicatie zal op de server kunnen toegevoegd worden tot de applicatiecollectie onder de vorm van een tar-archief waarin de bestanden van de applicatie zijn opgeslagen. R21. Een applicatie zou op de server kunnen toegevoegd worden tot de applicatiecollectie onder de vorm van een Debian-package. Bij de eerste activering van de applicatie op de client zal dan het bijhorende installatiescript uitgevoerd worden. R22. De server zal van de applicaties een gebruiksprofiel opstellen en op basis daarvan anticiperende acties ondernemen. R23. Wanneer een nieuwe versie van een applicatie in de applicatiecollectie beschikbaar komt, zal dit zo snel mogelijk meegedeeld worden aan de clients. Deze nieuwe versie kan dan, gebaseerd op de voorkeuren van de gebruiker, gestart worden wanneer de gebruiker de applicatie de volgende keer opstart.
2.3 Use cases
20
Application Streaming System Applicatiecollectie toevoegen
Identiteit controleren <
>
… met anonieme toegang
Gebruiker toevoegen
… met identiteitscontrole
Gebruikers legitimatiedatabank
Gebruiker verwijderen Gebruiker
Nieuwe applicatie selecteren
Applicatiecollectie verwijderen
Applicatie lokaal opslaan Applicatie uitvoeren
Nieuwe applicatieversie toevoegen
Tar-archive toevoegen
Debian-package toevoegen
Applicatie toevoegen
Applicatie verwijderen
<<extend>> Besturingssysteem
Nieuw commando uitvoeren
Administrator
Figuur 2.2: Use case diagram voor het Application Streaming System
ID
Naam
Prim. actoren
Prioriteit
Complexiteit
1
Applicatiecollectie toevoegen
Gebruiker
Hoog
Laag
2
Nieuwe applicatie selecteren
Gebruiker
Hoog
Normaal
3
Applicatie uitvoeren
Besturingssysteem
Hoog
Hoog
4
Nieuw commando uitvoeren
Besturingssysteem
Laag
Hoogste
5
Applicatie lokaal opslaan
Gebruiker
Normaal
Hoog
6
Applicatie toevoegen
Administrator
Hoog
Laag
7
Nieuwe applicatieversie toevoegen
Administrator
Hoog
Normaal
Tabel 2.1: Overzicht van de uitgewerkte use cases voor het Application Streaming System
2.3
Use cases
In figuur 2.2 wordt een use case diagram weergegeven voor het Application Streaming System. Het geeft een overzicht van de voornaamste use cases en de actoren die kunnen interageren met het systeem. In tabel 2.1 wordt een overzicht gegeven van de uitgewerkte use cases.
2.3 Use cases
21
De actor Gebruiker is de eindgebruiker van het Application Streaming System. Zijn uiteindelijke doel is om op een zo eenvoudig mogelijke manier en zonder te veel restricties, zoals beperkte lokale opslag, een collectie van applicaties te kunnen gebruiken op zijn resource-beperkt toestel. De actor Administrator is de beheerder van het systeem en is verantwoordelijk voor het aanbieden van de applicaties aan de gebruiker. Zijn doel is dan ook het beheer van de applicatiecollectie en de gebruikers op de server. Een derde actor is het Besturingssysteem. Dit is een representatie van het besturingssysteem op het toestel van de gebruiker. Het doel van deze actor is het starten en uitvoeren van de applicaties voor de gebruiker. De use cases voor het Besturingssysteem (Applicatie uitvoeren en Nieuw commando uitvoeren) worden niet geassocieerd met de Gebruiker omdat deze niet rechtstreeks door de Gebruiker geactiveerd worden. De Gebruiker zal immers het besturingssysteem (dat niet tot het Application Streaming System behoort) vragen een applicatie te starten, wat op zijn beurt het systeem zal aanspreken voor de uitvoering van de applicatie. De laatste actor is de Gebruikers legitimatiedatabank. Deze actor zal enkel een passieve rol spelen en het systeem bijstaan bij het verifi¨eren van de identiteit van de gebruikers. In figuur 2.2 wordt een use case cursief weergegeven (Applicatiecollectie toevoegen). Dit is een abstracte use case. Een abstracte use case kan niet op zichzelf ge¨ınitieerd worden, maar is enkel zinvol wanneer het gebruikt wordt om functionaliteit te beschrijven die gemeenschappelijk is tussen andere use cases. De andere use cases zijn dan concrete use cases die wel ge¨ınitieerd kunnen worden tot een specifiek scenario. Deze semantiek van abstracte use cases werd overgenomen van El-Attar [EA] en Firesmith [Fir]. De rest van deze sectie zal bestaan uit het uitwerken van de belangrijkste use cases. De use cases die in figuur 2.2 in het grijs worden weergegeven zullen dan ook niet verder uitgewerkt worden.
2.3 Use cases
22
use case 1: Applicatiecollectie toevoegen Beschrijving
De gebruiker wil een nieuwe applicatiecollectie toevoegen aan zijn configuratie op de client zodat hij de applicaties uit de collectie kan gebruiken. De applicaties uit de collectie moeten evenwel nog geactiveerd worden (zie use case 2 en use case 4).
Prioriteit/Complexiteit
Hoog/Laag
Gerelateerde vereisten
R1, R2, R12, R18
Precondities
De client software is reeds ge¨ınstalleerd op het toestel van de gebruiker en de gebruiker beschikt over een URI die de applicatiecollectie identificeert.
Postcondities bij succes
De configuratie van de client is aangepast en de gebruiker kan de applicaties uit de applicatiecollectie gebruiken.
Postcondities bij faling
De configuratie van de client blijft ongewijzigd en er wordt een melding gegeven met de reden voor het falen.
Primaire actoren
Gebruiker
Secundaire actoren
Geen
Trigger
De gebruiker vraagt de client om een nieuwe applicatiecollectie toe te voegen aan zijn configuratie.
Aanverwante use cases
(Applicatiecollectie toevoegen met anonieme toegang) (Applicatiecollectie toevoegen met identiteitscontrole)
2.3 Use cases
23
Hoofdscenario
1. De gebruiker vraagt de client een nieuwe applicatiecollectie toe te voegen aan de configuratie. 2. De gebruiker vult de URI van de collectie in en geeft de gewenste toegangsmethode op. 3. De gebruiker bevestigt de gegevens. 4. De client contacteert de server. 5. De toegangsmethode op de server wordt gecontroleerd. 6. De applicatiecollectie wordt toegevoegd aan de configuratie van de client. 7. De lijst van applicaties in collectie wordt opgevraagd van de server en lokaal bewaard voor later gebruik. [succes]
Variaties
4a. Op de opgegeven URI kan geen server gecontacteerd worden. 4a.1. De applicatiecollectie wordt niet toegevoegd aan de configuratie van de client. Er wordt een melding gegeven dat de server niet gecontacteerd kon worden. [faling] 5a. De geselecteerde toegangsmethode is niet toegestaan op de geselecteerde server. 5a.1. De applicatiecollectie wordt niet toegevoegd aan de configuratie van de client. Er wordt een melding gegeven dat de geselecteerde toegangsmethode niet aanvaard werd op de server. [faling]
use case 2: Nieuwe applicatie selecteren Beschrijving
De gebruiker wil op zijn client een nieuwe applicatie gebruiken. Hij maakt daartoe aan het systeem zijn keuze bekend door in de lijst van beschikbare applicaties, de nieuwe applicatie te selecteren. Het systeem zal hierop de nieuwe applicatie activeren op de client waardoor de gebruiker vanaf dat moment de applicatie, net als een lokaal beschikbare applicatie, kan uitvoeren.
Prioriteit/Complexiteit
Hoog/Normaal
Gerelateerde vereisten
R1, R6, R7, R8, R12
2.3 Use cases
24
Precondities
De client software is reeds ge¨ınstalleerd op het toestel van de gebruiker. De gebruiker heeft reeds eerder een applicatiecollectie toegevoegd aan zijn configuratie (zie use case 1).
Postcondities bij succes
De nieuwe applicatie is geactiveerd op het toestel van de gebruiker en is klaar om gebruikt te worden.
Postcondities bij faling
De nieuwe applicatie is niet geactiveerd en de configuratie van de client blijft ongewijzigd. Er wordt een melding gegeven met de reden voor het falen.
Primaire actoren
Gebruiker
Secundaire actoren
Geen
Trigger
De gebruiker selecteert een nieuwe applicatie uit de lijst van beschikbare applicaties.
Aanverwante use cases Hoofdscenario
use case 4: Nieuw commando uitvoeren 1. De gebruiker selecteert op de client een nieuwe applicatie uit de lijst van beschikbare applicaties. 2. De gebruiker geeft het commando deze applicatie te activeren op zijn systeem. 3. De client contacteert de server en vraagt een lijst op van beschikbare versies van de geselecteerde applicatie. 4. De gebruiker selecteert de gewenste versie van de applicatie. 5. De client contacteert de server en vraagt een activeringspakket op voor de geselecteerde applicatie en versie. 6. De applicatie wordt geactiveerd op de client door uitvoering van het activeringspakket. 7. De applicatie is geactiveerd op het toestel en is klaar voor gebruik. [succes]
2.3 Use cases
Variaties
25
3a. De gebruiker geeft aan geen specifieke versie te willen kiezen. 3a.1. De client contacteert de server en vraagt een activeringspakket voor de geselecteerde applicatie. 3a.2. De server selecteert zelf een geschikte versie voor de client en verstuurt daarvan het activeringspakket. 3a.3. [ga naar 6] 3b. De client kan geen verbinding maken met de server van de geselecteerde applicatie. 3b.1. Na een aantal keer opnieuw te proberen, breekt de client zijn pogingen om de server te bereiken af met een melding van de fout. [faling]
use case 3: Applicatie uitvoeren Beschrijving
Wanneer de gebruiker een applicatie start geeft hij deze opdracht aan het besturingssysteem. Het besturingssysteem ontvangt deze aanvraag voor het uitvoeren van de applicatie en gaat op zoek naar het bijhorende applicatiebestand. Wanneer het hierbij gaat om een applicatie die via het Application Streaming System gestreamd wordt, zal het besturingssysteem het systeem aanspreken voor het inladen van de applicatie. De applicatie wordt geladen en uitgevoerd op het systeem van de gebruiker.
Prioriteit/Complexiteit
Hoog/Hoog
Gerelateerde vereisten
R1, R3, R4, R8, R13, R17, (R7)
Precondities
De applicatie werd reeds eerder door de gebruiker geselecteerd en geactiveerd op zijn toestel. De client software moet ook reeds gestart zijn op het toestel van de gebruiker.
Postcondities bij succes
De applicatie is gestart en de uitvoering kan beginnen.
Postcondities bij faling
De applicatie start niet. Eventueel wordt een melding gegeven van de reden.
Primaire actoren
Besturingssysteem
Secundaire actoren
Geen
2.3 Use cases
26
Trigger
De gebruiker start een applicatie op zijn toestel.
Aanverwante use cases
use case 4: Nieuw commando uitvoeren
Hoofdscenario
0. extension point::Nieuw commando uitvoeren 1. Het besturingssysteem contacteert het systeem voor het inladen van een applicatie. 2. Het systeem bepaalt welke applicatie gestart wordt. 3. Het systeem checkt of er een verbinding is met de server van de applicatie. 4. Het systeem beantwoordt de aanvraag van het besturingssysteem voor het inladen van de applicatie. [succes]
Variaties
3a. Er kan geen connectie gemaakt worden met de server van de applicatie en de applicatie werd niet lokaal opgeslagen. 3a.1. De uitvoering van de applicatie wordt niet gestart. [faling] 3b. Er kan geen connectie gemaakt worden met de server van de applicatie maar de applicatie werd wel lokaal opgeslagen. 3b.1. [ga naar 4]
use case 4: Nieuw commando uitvoeren Extends
use case 3: Applicatie uitvoeren
Beschrijving
Wanneer de gebruiker een nieuw commando ingeeft in de shell, zal het systeem trachten te achterhalen welke applicatie de gebruiker probeert uit te voeren. Het systeem zal dan zelf de geschikte applicatie proberen te activeren op het toestel van de gebruiker om alzo een uitvoering van de applicatie mogelijk te maken zonder dat de gebruiker de applicatie eerst moet selecteren uit de lijst van beschikbare applicaties (use case 2). Deze case kan ook worden toegepast wanneer een nieuw commando voorkomt in een shell-script.
Prioriteit/Complexiteit
Laag/Hoogste
Gerelateerde vereisten
R1, R6, R7, R8, R13, R17
2.3 Use cases
27
Precondities
De gebruiker moet reeds eerder een applicatiecollectie toegevoegd hebben aan zijn configuratie. De client software moet ook reeds gestart zijn op het toestel van de gebruiker en het systeem moet opgenomen zijn in de PATH-instelling van de shell.
Postcondities bij succes
De applicatie wordt door het systeem zonder tussenkomst van de gebruiker geactiveerd en de uitvoering van de applicatie kan gestart worden.
Postcondities bij faling
De configuratie van de client blijft ongewijzigd en er wordt geen melding (tenzij eventueel door de shell) gegeven voor het falen.
Primaire actoren
Besturingssysteem
Secundaire actoren
Geen
Trigger
De gebruiker start een onbekend commando via de shell
Aanverwante use cases
use case 2: Nieuwe applicatie selecteren use case 3: Applicatie uitvoeren
Hoofdscenario
1. De shell contacteert het systeem met de vraag voor een applicatie die overeenkomt met het door de gebruiker opgegeven commando. 2. Het systeem zoekt in de collecties van de gebruiker naar applicaties die overeenkomen met het opgegeven commando. 3. Het systeem activeert de gevonden applicatie op de client. 4. Het systeem antwoordt bevestigend op de vraag van de shell. 5. [ga verder met use case 3]
Variaties
3a. Er worden geen applicaties gevonden in de applicatiecollectie die overeenkomen met het commando dat door de gebruiker werd opgegeven. 3a.1. De configuratie van de client blijft ongewijzigd. [faling]
2.3 Use cases
28
use case 5: Applicatie lokaal opslaan Beschrijving
Wanneer de gebruiker voorziet dat hij niet langer een connectie met de server van een applicatie kan behouden, maar deze applicatie toch op zijn client wil blijven gebruiken, dan kan de gebruiker er voor kiezen om de volledige applicatie lokaal op te slaan op zijn client en alzo onafhankelijk te worden van de server. Deze omschakeling moet op een voor de gebruiker transparante wijze mogelijk zijn.
Prioriteit/Complexiteit
Normaal/Hoog
Gerelateerde vereisten
R6, R8, R15
Precondities
De gebruiker moet reeds eerder een applicatiecollectie toegevoegd hebben aan zijn configuratie.
Postcondities bij succes
De geselecteerde applicatie werd volledig van de server gedownload en lokaal op de client bewaard. De applicatie kan nu onafhankelijk van de beschikbaarheid van de server uitgevoerd worden.
Postcondities bij faling
De geselecteerde applicatie werd niet lokaal opgeslagen. Het uitvoeren van de applicatie is nog steeds afhankelijk van de beschikbaarheid van de server. Er wordt een melding gegeven met de reden voor het falen.
Primaire actoren
Gebruiker
Secundaire actoren
Geen
Trigger
De gebruiker selecteert een applicatie uit de lijst van beschikbare applicaties voor lokaal opslaan.
2.3 Use cases
Hoofdscenario
29
1. De gebruiker selecteert een applicatie uit de lijst van beschikbare applicaties. 2. De gebruiker geeft het commando deze applicatie lokaal op te slaan. 3. Het systeem controleert of de applicatie reeds geactiveerd werd op het toestel van de gebruiker. 4. Het systeem controleert of er voldoende lokaal beschikbare vrije opslag is om de applicatie in op te slaan. 5. Het systeem downloadt de volledige applicatie van de server en bewaart deze in de lokale opslag. 6. De applicatie werd lokaal opgeslagen en kan onafhankelijk van de server gebruikt worden. [succes]
Variaties
3a. De applicatie is nog niet geactiveerd op het toestel van de gebruiker. 3a.1. De applicatie wordt geactiveerd volgens use case 2. 3a.2. [ga naar 4] 4a. Er is onvoldoende lokale opslag beschikbaar om de volledige applicatie op te slaan. 4a.1. De applicatie wordt niet lokaal opgeslagen en de uitvoering van de applicatie blijft afhankelijk van de beschikbaarheid van de server. Er wordt melding gemaakt van het tekort aan lokale opslag. [faling]
2.3 Use cases
30
use case 6: Applicatie toevoegen Beschrijving
De administrator wil een nieuwe applicatie toevoegen aan de collectie van een server. De applicatie is vanaf dan beschikbaar in de databank van de server. Opmerking: de applicatie is beschikbaar in de databank van de server om er nieuwe versies aan toe te voegen. Voor de gebruikers van de collectie is de applicatie nog niet beschikbaar omdat deze nog geen versies bevat. Zie use case 7 om versies toe te voegen aan een applicatie.
Prioriteit/Complexiteit
Hoog/Laag
Gerelateerde vereisten
R1
Precondities
De administrator is aangemeld op de streamingserver.
Postcondities bij succes
De nieuwe applicatie is toegevoegd aan de databank van de server.
Postcondities bij faling
De nieuwe applicatie werd niet toegevoegd aan de databank van de server. Er wordt een melding gegeven met de reden voor het falen.
Primaire actoren
Administrator
Secundaire actoren
Geen
Trigger
De administrator vraagt aan de streamingserver om een nieuwe applicatie toe te voegen aan de collectie.
Aanverwante use cases Hoofdscenario
use case 7: Nieuwe applicatieversie toevoegen 1. De administrator vraagt de server om een nieuwe applicatie toe te voegen aan de applicatiecollectie. 2. De administrator vult gegevens zoals de naam van de applicatie, een korte samenvatting en een beschrijving in. 3. De administrator bevestigt de gegevens. 4. Het systeem voegt een nieuwe applicatie met de opgegeven naam toe aan zijn databank. 5. Het systeem geeft het identificatienummer van de nieuwe applicatie weer. [succes]
2.3 Use cases
Variaties
31
4a. De opgegeven naam van de applicatie bestaat reeds in de databank. 4a.1. De applicatie wordt niet toegevoegd aan de databank. Er wordt een melding gegeven dat er reeds een applicatie met deze naam bestaat. [faling]
use case 7: Nieuwe applicatieversie toevoegen Beschrijving
De administrator wil een nieuwe versie toevoegen aan een applicatie in de collectie op de server. De versie wordt door de server ge¨ımporteerd in zijn databank. De versie is vanaf dan beschikbaar voor de gebruikers van de applicatiecollectie om geactiveerd te worden.
Prioriteit/Complexiteit
Hoog/Normaal
Gerelateerde vereisten
R1, R19, R20, R21
Precondities
De administrator is aangemeld op de streamingserver. De applicatie waaraan de versie wordt toegevoegd, bestaat reeds in de databank van de server. De bestanden van de nieuwe versie zijn beschikbaar op de lokale opslag van de server.
Postcondities bij succes
De nieuwe versie is toegevoegd aan de applicatie en kan door de gebruikers van de collectie geactiveerd worden.
Postcondities bij faling
De nieuwe versie werd niet toegevoegd aan de applicatie. Er wordt een melding gegeven met de reden voor het falen.
Primaire actoren
Administrator
Secundaire actoren
Geen
Trigger
De administrator vraagt aan de server om een nieuwe versie aan een applicatie in de collectie toe te voegen.
Aanverwante use cases
use case 6: Applicatie toevoegen (Nieuwe applicatieversie als Tar-archive toevoegen) (Nieuwe applicatieversie als Debian-package toevoegen)
2.3 Use cases
Hoofdscenario
32
1. De administrator vraagt de server om een nieuwe versie toe te voegen aan de applicatiecollectie. 2. De administrator kiest de applicatie waaraan hij een nieuwe versie wil toevoegen en bevestigt zijn keuze. 3. De administrator vult gegevens zoals de versieaanduiding in. 4. De administrator bevestigt de gegevens. 5. De administrator specificeert de locatie waar de bestanden van de versie gevonden kunnen worden. 6. Het systeem voegt een nieuwe versie met de opgegeven versieaanduiding toe aan zijn databank. 7. Het systeem importeert de bestanden van de versie in zijn databank. 8. Het systeem geeft het identificatienummer van de nieuwe versie weer. [succes]
Variaties
2a. De administrator geeft een applicatie op die niet bestaat in de databank van de server. 2a.1. Het toevoegen van een nieuwe versie wordt afgebroken. Er wordt een melding gegeven dat de opgegeven applicatie niet bestaat in de databank. [faling] 6a. De opgegeven versieaanduiding bestaat reeds in de databank. 6a.1. De versie wordt niet toegevoegd aan de databank. Er wordt een melding gegeven dat er reeds een versie met deze versieaanduiding bestaat. [faling]
Hoofdstuk 3
Architectuur In dit hoofdstuk zal er een overzicht gegeven worden van de architectuur van het Application Streaming System. Hierbij wordt gebruikgemaakt van verschillende architecturale perspectieven om de verschillende aspecten van het systeem te belichten. De bedoeling is om de meest significante architecturale beslissingen vast te leggen en kenbaar te maken. Om de architectuur zo accuraat mogelijk te beschrijven werd gebruikgemaakt van het “4+1” View Model zoals beschreven door Kruchten [Kru95]. In figuur 3.1 wordt dit model schematisch weergegeven. Logical View
Development View Use Case View
Process View
Physical View
Figuur 3.1: Het “4+1” view model [Kru95]
Het “4+1” model splitst een architectuur in een aantal views of perspectieven die elk een specifiek aspect van de architectuur vastleggen. Het model bestaat uit de volgende perspectieven: Logisch perspectief: met dit perspectief worden de abstracte beschrijvingen van de systeemonderdelen vastgelegd. Het modelleert uit welke onderdelen een systeem is opgebouwd en
33
3.1 Het Application Streaming System
34
hoe deze met elkaar interageren. Proces perspectief: dit perspectief behandelt de verschillende processen in het systeem. Het beschrijft precies wat er in het systeem moet gebeuren. Ontwikkel perspectief: dit perspectief schetst hoe de delen van het systeem zijn georganiseerd in modules en componenten. Fysiek perspectief: met dit perspectief wordt beschreven hoe de softwareonderdelen van het systeem worden gealloceerd op de hardware-processing en -communicatie entiteiten. Use cases: deze beschrijven de functionaliteit van het systeem, bekeken vanuit het perspectief van de buitenwereld. Dit perspectief is nodig om weer te geven wat het systeem verondersteld wordt te doen en dient ter ondersteuning van de andere vier perspectieven. De use cases werden reeds uitvoerig besproken in sectie 2.3. In dit hoofdstuk zullen dan ook de overige vier perspectieven aan bod komen.
3.1
Het Application Streaming System
In figuur 3.2 wordt een globaal informeel overzicht gegeven van de opbouw van het Application Streaming System en hoe het ingepast wordt in het systeem van de gebruiker. Deze figuur kan niet duidelijk ingepast worden in ´e´en van de vier perspectieven van Kruchten maar geeft wel een duidelijk inzicht in de belangrijkste componenten van de architectuur. De componenten die deel uitmaken van het Application Streaming System worden in het grijs weergegeven. Rechts bovenaan staat de gebruiker. Deze maakt gebruik van een applicatiemanager om de applicaties die hij wil streamen te beheren. Eens de gebruiker applicaties geselecteerd heeft om te streamen kunnen deze net als elke andere applicatie gebruikt worden. Er is dus geen tussenkomst van de applicatiemanager nodig om een applicatie op te starten. Wanneer een gestreamde applicatie gestart wordt, zal deze, net als elke andere normale applicatie, ingeladen worden door de besturingssysteem kernel. De kernel zal het uitvoerbare bestand hiervoor opdelen in geheugenpagina’s van telkens dezelfde grootte. Deze pagina’s worden dan later door de paginalader in het geheugen ingeladen.
3.1 Het Application Streaming System
Gestreamde Applicaties
35
Gebruiker
Administrator
Besturingssysteem Kernel
Paginalader
Applicatie Manager
Collectie Manager
Client Applicatie Streamer
Server Applicatie Streamer
Bestandssysteem Caching Filesystem
Normaal Filesystem
Applicatie Opslag
Client
Server
Figuur 3.2: Globaal informeel overzicht van de Application Streaming System architectuur
Wanneer een dergelijk geheugenpagina ingeladen moet worden, maakt de paginalader gebruik van het bestandssysteem om de inhoud van het uitvoerbare bestand te lezen. Het bestandssysteem is samengesteld uit verschillende drivers waaronder het caching filesystem van het Application Streaming System en de normale filesystem drivers voor de lokale opslag. Wanneer het uitvoerbare bestand zich in het caching filesystem bevindt, kan de inhoud op twee manieren bekomen worden. Ofwel bevindt de inhoud zich in de cache in de lokale opslag en dan maakt het caching filesystem op zijn beurt opnieuw gebruik van het bestandssysteem om de inhoud op te halen. Ofwel bevindt de inhoud zich niet in deze cache en dan wordt de inhoud via de client applicatie streamer vanop de server opgehaald via het netwerk. Op de server zal de server applicatie streamer de inhoud van een bestand opvragen uit de applicatie opslag. Een administrator kan nieuwe applicaties en nieuwe applicatieversie aan de collectie toevoegen met behulp van de collectiemanager.
3.1.1
Het globale systeem
Het Application Streaming System is opgebouwd uit twee subsystemen die samen het clientserver patroon vormen. Dit patroon werd gekozen om een scheiding van belangen te bekomen
3.1 Het Application Streaming System
Filesystem
<<subsystem>> StreamingClient
36
ApplicationSource ApplicationSource
<<subsystem>> StreamingServer
Figuur 3.3: Client-server patroon toegepast op het Application Streaming System, weergegeven vanuit een ontwikkel perspectief
tussen de functionaliteit die instaat voor het beheren van de gestreamde applicaties op het toestel van de gebruiker en het beheer van de applicaties in een collectie. De client en de server krijgen respectievelijk StreamingClient en StreamingServer als naam. In figuur 3.3 wordt een component diagram weergegeven van deze opsplitsing. Hierin wordt weergegeven dat de StreamingClient en StreamingServer onderling communiceren via de ApplicationSource interface (zie sectie 3.1.3). Verder zal de StreamingClient de Filesystem interface (zie sectie 3.1.2) aanbieden aan zijn omgeving.
3.1.2
Het StreamingClient subsysteem
De StreamingClient is het subsysteem dat op het toestel van de gebruiker wordt uitgevoerd. Het zal hier verantwoordelijk zijn voor het opzetten en onderhouden van de connecties met de StreamingServers, voor het presenteren van de aangeboden applicatiecollecties op de StreamingServers aan de gebruiker, voor het activeren van nieuwe applicaties op het toestel van de gebruiker en voor het het beheer van de geactiveerde applicaties. Een StreamingClient zal hierbij tegelijk van meerdere StreamingServers applicaties kunnen streamen. In tweede instantie zal de StreamingClient ook een virtualisatie van de bestanden in de geactiveerde applicaties moeten ondersteunen ten aanzien van het besturingssysteem en moet het deze gevirtualiseerde bestanden kunnen afbeelden op de juiste bestanden op de juiste StreamingServer.
De Filesystem interface De Filesystem interface is de interface naar het besturingssysteem toe die de virtualisatie van bestanden mogelijk maakt. De StreamingClient zal met deze interface in het besturingssysteem geplugd worden zodat het besturingssysteem via deze weg de bestanden van de gestreamde applicaties kan benaderen. Na activatie van een applicatie is de inhoud van de bestanden immers nog niet fysiek aanwezig op het toestel van de gebruiker. Deze interface zorgt dan ook voor
3.1 Het Application Streaming System
37
de nodige abstractie opdat de gebruiker de bestanden wel via de geijkte weg, zijnde het bestandssysteem, zou kunnen benaderen en gebruiken zonder gewaar te worden dat de bestanden eigenlijk niet lokaal op zijn toestel aanwezig zijn. De keuze om de bestandsvirtualisatie als een bestandssysteem te realiseren zal onderbouwd worden in sectie 4.1.
3.1.3
Het StreamingServer subsysteem
Het StreamingServer subsysteem is verantwoordelijk voor het aanbieden van een collectie van applicaties aan de StreamingClients. Een administrator kan een nieuwe applicatie of een nieuwe versie van een applicatie toevoegen aan de collectie. Een StreamingServer kan door de StreamingClients bevraagd worden over de applicaties die aangeboden worden in de collectie. Wanneer de gebruiker op de StreamingClient een applicatie activeert, zal de StreamingClient bij de StreamingServer een activatiepakket opvragen zodat de applicatie op het toestel van de gebruiker kan ge¨ınitialiseerd worden. Dit pakket zal onder andere een beschrijving bevatten van de bestanden die tot de applicatie behoren maar zal nog geen inhoud van deze bestanden bevatten. Wanneer later de inhoud van een bestand nodig is op het toestel van de gebruiker – de gebruiker start bijvoorbeeld de applicatie of opent een lees-mij-bestand – dan zal de StreamingClient de StreamingServer verzoeken de nodige delen van het bestand door te sturen.
De ApplicationSource interface en het Application Transfer Protocol De ApplicationSource interface verzorgt de communicatie tussen de StreamingClient en de StreamingServer. De interface is een abstractie van het onderliggende Application Transfer Protocol (ATP) dat gebaseerd is op XDR-records en zowel pull-transfers door de StreamingClient als push-transfers door de StreamingServer mogelijk maakt. De interface is non-blocking zodat de StreamingClient meerdere aanvragen tegelijk kan sturen naar de StreamingServer zonder het antwoord van een vorige aanvraag te moeten afwachten. Een tweede reden is dat het hierdoor mogelijk wordt om push-transfers door de StreamingServer uit te voeren. De StreamingClient blijft immers niet wachten op een specifiek antwoord maar staat open voor elke transfer vanop een StreamingServer. In figuur 3.4 wordt het proces en fysiek perspectief van het Application Streaming System gecombineerd weergegeven. De StreamingClient en de StreamingServer worden op twee verschillende toestellen uitgevoerd die verbonden zijn via een netwerk. De StreamingClient en
3.2 Het StreamingClient subsysteem
38
<>
<<device>> Gebruikers toestel <<subsystem>> StreamingClient
*
<<device>> Server
* ATP
<<subsystem>> StreamingServer
Figuur 3.4: Proces en fysiek perspectief van het Application Streaming System
StreamingServer communiceren dan met elkaar over dit netwerk via het Application Transfer Protocol. Zowel de StreamingClient als de StreamingServer kunnen respectievelijk tegelijk met meerdere StreamingServers en StreamingClients verbonden zijn.
3.2
Het StreamingClient subsysteem
Het StreamingClient subsysteem is het meest complexe subsysteem van het Application Streaming System. Dit komt met name omdat er veel functionaliteit moet worden gebundeld in een applicatie die uiteindelijk toch bestemd is om uitgevoerd te worden op een resource-beperkt toestel. De resource vereisten van de StreamingClient zullen dan ook een voorname drijfveer zijn bij het ontwerp. Waar mogelijk moet dan ook zo veel mogelijk de vraag van het systeem naar resources onder controle gehouden worden. Een andere voorname drijfveer is het beheer van de resources. Bestanden van een applicatie uit een collectie moeten in het slechtste geval vanop de server via het netwerk gestreamd worden. De StreamingClient moet hiervoor eerst een aanvraag versturen naar de server die dan zal antwoorden met de gevraagde data. Dit zal tegenover het ophalen van data uit de lokale opslag een extra latentie opleveren. Als een applicatie nu uit twee of meer verschillende bestanden tegelijk leest is het onaanvaardbaar om de client te blokkeren en te laten wachten op een antwoord van de server. Er zal dan ook concurrenti¨ele uitvoering ingevoerd worden om de beschikbare resources effici¨enter te kunnen gebruiken. Hierdoor zal het subsysteem ook voldoende onderling moeten gesynchroniseerd worden om datacorruptie te vermijden. Deze beslissing zal de complexiteit van de software nog doen toenemen maar is essentieel voor een effici¨enter gebruik van de beschikbare resources. Om deze complexiteit onder controle te houden is de StreamingClient zo ontworpen dat potenti¨ele wijzigingen slechts invloed hebben op een zo klein mogelijk deel van het systeem.
3.2 Het StreamingClient subsysteem
39
<<subsystem>> StreamingClient UIInfo
<> UI
FileInfo
Filesystem
FileLocator <> Locator
<> ApplicationManager
<> CachingFilesystem
ApplicationInfo
FileStreamer
FileLocator
<> ClApplicationStreamer
ApplicationSource
Figuur 3.5: Decompositie in het ontwikkel perspectief van het StreamingClient subsysteem
Het systeem werd daarom opgedeeld in verschillende modules die elk een zeer specifieke en afgelijnde taak krijgen. De afhankelijkheden tussen de verschillende modules worden zo veel mogelijk beperkt door de communicatie tussen de modules tot het strikt noodzakelijke te herleiden en alzo de rimpeleffecten door wijzigingen in een module te verminderen. In figuur 3.5 wordt de decompositie van de StreamingClient in zijn verschillende modules weergegeven waarbij zo veel mogelijk rekening werd gehouden met de zopas beschreven drijfveren. In de volgende secties zullen de afzonderlijke modules verder besproken worden.
3.2.1
De module CachingFilesystem
De CachingFilesystem module is de module die het virtualiseren van de applicatiebestanden voor zijn rekening neemt. Het biedt daarom de Filesystem interface naar het besturingssysteem aan. In de eerste plaats biedt deze module dus toegang aan het besturingssysteem en aan de gebruiker tot de bestanden die vanop de StreamingServers gestreamd kunnen worden naar het toestel. Hierdoor zal de gebruiker de applicaties kunnen gebruiken zonder dat de inhoud van de bestanden reeds op zijn toestel aanwezig zijn. Het CachingFilesystem zal hiervoor een beroep doen op de ClApplicationStreamer module (zie sectie 3.2.3) via de FileStreamer interface. De verantwoordelijkheid van het CachingFilesystem beperkt zich hier enkel tot het beheer van bestanden uit applicaties die op het toestel van de gebruiker reeds geactiveerd zijn. Deze module heeft dan ook absoluut geen weet van het concept applicaties, StreamingServers of van
3.2 Het StreamingClient subsysteem
40
bestanden uit applicaties die niet geactiveerd zijn. Om deze loskoppeling van alle andere modules te bekomen, krijgt elk bestand bij activatie in het CachingFilesystem een uniek nummer mee, binnen de scope van de StreamingClient. Dit nummer kan dan door de andere modules gebruikt worden om de ware indentiteit (server, applicatie-, versie- en file-nummer) en andere informatie van een bestand op te zoeken in de Locator module (zie sectie 3.2.2). Indien deze module enkel de inhoud van de bestanden vanop de servers zou streamen en zou doorgeven aan het besturingssysteem dan zou er weinig toegevoegde waarde zijn ten opzichte van de klassieke netwerk-shares. Dat zou getuigen van een weinig effici¨ent gebruik van de resources van het toestel. Daarom zullen de gestreamde data ook lokaal op het toestel van de gebruiker gecachet worden. Omdat het systeem bruikbaar moet zijn op resource-beperkte toestellen, en dus ook bij beperkte lokale opslag, kan echter niet zomaar alle gestreamde data ook lokaal gecachet worden. De gecachete data zou dan immers alle lokale opslag kunnen opeisen terwijl het net een doelstelling van deze thesis is om een grote hoeveelheid aan applicaties te kunnen gebruiken zonder hieraan de overeenkomstige hoeveelheid aan lokale opslag te moeten besteden. De module zal daarom een datacache beheren die beperkt is in grootte. Wanneer nieuwe data vanop een StreamingServer gestreamd worden, zal getracht worden deze data in de datacache op te slaan. Is deze reeds vol, dan zal volgens een bepaalde strategie een datablok, van een ander bestand of van hetzelfde bestand, geselecteerd worden dat dan verwijderd wordt uit de datacache en vervangen wordt door de nieuwe data. Dit betekent evenwel dat verwijderde data opnieuw gestreamd moeten worden indien deze later opnieuw nodig blijken. De juiste keuze van strategie voor het selecteren van een datablok dat verwijderd wordt uit de datacache kan dan ook een belangrijke invloed hebben op de goede prestaties van het systeem. Bij het ontwerp van deze strategie mogen de geheugen-, opslag- en rekenkundige vereisten van het toestel niet uit het oog verloren worden. Een bespreking van mogelijke strategie¨en wordt gegeven in sectie 4.3.
Ontwikkel perspectief van het CachingFilesystem Omdat de CachingFilesystem module intern nog steeds complex is, werd deze van een gelaagde structuur voorzien zoals weergegeven in figuur 3.6. Hierbij mag een laag enkel gebruikmaken van de eerste onderliggende laag zodat een duidelijke scheiding in verantwoordelijkheden optreedt. De Filesystem laag mag dus bijvoorbeeld enkel gebruikmaken van de interface die door de Metabewerking laag wordt aangeboden.
3.2 Het StreamingClient subsysteem
41
Filesystem Metabewerkingen Cachebeheer Bestandsbewerkingen
Figuur 3.6: Gelaagde opbouw van de CachingFilesystem module
Om de datacache lokaal op te slaan maakt de module gebruik van het lokale bestandssysteem. De datacache verschijnt dus als een normaal bestand in de lokale opslag van het toestel. De onderste Bestandsbewerkingen laag, doet enkel bewerkingen op het bestand van de datacache en beschouwt dit bestand als een aaneenschakeling van blokken die allen even groot zijn. De laag kent dan ook niets van de interne structuur van dit bestand zoals directories, bestanden en data. Het biedt aan de laag daarboven een interface aan waarbij de bewerkingen uitsluitend op blokken plaatshebben. In de Metabewerkingen laag krijgen de data in de blokken een interpretatie zoals inodes, directories, bitmaps, indirecties of gewoon data. De bewerkingen op deze structuren zijn van een laag niveau en houden rekening met de correcte verdeling van de (meta-)data over verschillende blokken. De interface naar de bovenliggende laag bestaat dan nog enkel uit inodes, directoryentries en willekeurig grote data-blokken (in de zin van inhoud van bestanden). De bovenste Filesystem laag gebruikt dan de Metabewerkingen laag om een interface te bieden naar het besturingssysteem toe die bestaat uit pad-strings en data-blokken. De mogelijke bewerkingen zijn dan onder andere het aanmaken, verwijderen en verplaatsen van bestanden en directories en het lezen of schrijven van hun inhoud. Deze laag is zich volledig onbewust van het feit dat onderliggend de data onderverdeeld worden in blokken en hoe deze blokken gecombineerd kunnen worden tot een totaalbeeld. De Cachebeheer tussenlaag is verantwoordelijk voor het beheer van de datacache en van de datastructuren, nodig voor dit beheer. Deze laag wordt afzonderlijk van de Metabewerkingen laag weergegeven omdat de implementatie van deze laag veranderd kan worden door configuratie. Dit maakt het dan ook mogelijk om op eenvoudige manier meerdere strategie¨en voor het beheer van de datacache te ondersteunen.
3.2 Het StreamingClient subsysteem
42
Ophalen van server
Ontvang data
[Anders] Inode opzoeken
Bepaal startblok
Ophalen uit cache
[Data in cache]
Bepaal volgende blok
Data opslaan in cache
[Anders] Data teruggeven
[Voldoende data]
Data in buffer schrijven
Figuur 3.7: Activity diagram voor het lezen van data uit het CachingFilesystem
Proces perspectief van het CachingFilesystem In figuur 3.7 wordt een activiteitsdiagram weergegeven waarin beschreven wordt hoe de data van een bestand worden opgehaald uit de datacache of, in het geval de data zich niet in de datacache bevinden, opgehaald worden vanop de StreamingServer. In eerste instantie wordt de inode van het bestand opgezocht op basis van de opgegeven padstring. Vervolgens wordt het startblok bepaald op basis van de opgegeven offset en blokgrootte van de blokken in de datacache. In de inode kan dan opgezocht worden of het startblok zich in de datacache bevindt of vanop de StreamingServer opgehaald moet worden. In het eerste geval worden de data vanuit de datacache in de lokale opslag ingelezen waarna het in de buffer geschreven wordt. Wanneer de data zich niet in de datacache bevinden, wordt er een asynchrone aanvraag naar de StreamingServer verzonden. Vervolgens wordt het ontvangen van de gevraagde data afgewacht. Wanneer de data ontvangen worden, worden deze in de buffer geschreven. De ontvangen data moeten ook in de datacache opgeslagen worden maar dit kan zonder probleem uitgesteld worden naar een later moment. Dit wordt dan ook aangegeven door de fork na het ontvangen van de data van de StreamingServer. Wanneer er voldoende data in de buffer geschreven werden, worden deze teruggegeven aan het besturingssysteem. In het andere geval wordt het volgende blok met data bepaald en begint de cyclus weer opnieuw. Het proces zoals het hier beschreven staat, is de basisuitvoering. Het voordeel dat het asynchroon versturen van de aanvraag kan opleveren kan door een aangepaste volgorde van de ac-
3.2 Het StreamingClient subsysteem
43
tiviteiten eenvoudig worden aangetoond. De uitvoering wordt hiervoor opgesplitst in twee fasen. In een eerste fase wordt bepaald welke datablokken er precies nodig zullen zijn en of deze al dan niet aanwezig zijn in de datacache. Al de aanvragen voor de blokken die niet aanwezig zijn in de datacache, worden na elkaar verzonden naar de StreamingServer. In de tweede fase worden de data verzameld in de buffer. De data die vanop de StreamingServer opgehaald moesten worden zullen nu veel sneller beschikbaar zijn.
De Filesystem interface Deze interface is afhankelijk van het besturingssysteem en kan dus niet vrij gekozen worden. Het implementeert alle bewerkingen die het besturingssysteem voor een filesystem driver specificeert. Het CachingFilesystem is in essentie een bestandssysteem waarvan de inhoud enkel gelezen kan worden (Eng. read-only) omdat de bestanden een representatie zijn van bestanden die op een StreamingServer worden aangeboden. De bestanden mogen en kunnen uiteraard niet veranderd worden. Dit beperkt echter de flexibiliteit voor de applicaties die kunnen aangeboden worden. Beter is daarom om het CachingFilesystem schrijfbaar (Eng. read-write) te maken en schrijfoperaties af te leiden naar de lokale opslag.
De FileInfo interface De FileInfo interface wordt gebruikt voor twee zaken. In de eerste plaats biedt het de mogelijkheid om nieuwe bestanden toe te voegen aan het CachingFilesystem zonder hun inhoud te specificeren. Dit wordt dan ook gebruikt bij het activeren van een applicatie. Wanneer een applicatie geactiveerd wordt, ontvangt de StreamingClient van de StreamingServer een activatiepakket met een lijst van alle bestanden en diens eigenschappen in de applicatie. Al deze bestanden krijgen een uniek activatienummer van de Locator module (zie sectie 3.2.2) en worden dan via deze interface samen met het activatienummer aan het CachingFilesystem toegevoegd. In de tweede plaats biedt deze interface de mogelijkheid om informatie op te vragen over de bestanden in de CachingFilesystem. Zo kan voor elk bestand opgevraagd worden hoeveel van zijn inhoud er zich precies in de datacache bevindt. Op die manier kan bijvoorbeeld een overzicht samengesteld worden met hoeveel plaats elke applicatie inneemt in de datacache.
3.2 Het StreamingClient subsysteem
3.2.2
44
De module Locator
Deze module is een datarepository waarin alle gegevens over de StreamingServers, geactiveerde applicaties en de versies en bestanden van deze applicaties worden bijgehouden. Een belangrijke taak van deze module is een afbeelding te voorzien tussen het unieke nummer dat elk bestand bij activatie op het toestel krijgt en zijn externe gegevens. Deze externe gegevens zijn onder andere de StreamingServer waarop het bestand aangeboden wordt, de identificatie van het bestand op de StreamingServer, en bij welke applicatie en versie het bestand hoort. Deze gegevens kunnen door de andere modules geraadpleegd worden via de FileLocator interface. De gegevens zullen in de eerste plaats gebruikt worden door de ClApplicationStreamer module (zie sectie 3.2.3), wanneer de CachingFilesystem module data vanop een StreamingServer wil ophalen. Het CachingFilesystem zal in zijn aanvraag bij de ClApplicationStreamer enkel het uniek activatienummer van het bestand opgeven dat verstrekt werd bij het toevoegen van het bestand aan het CachingFilesystem. De ClApplicationStreamer moet de gegevens in de Locator module dan gebruiken om te weten met welke StreamingServer er een connectie gemaakt moet worden en welk bestand er precies vanop de server gestreamd moet worden. De Locator module bevat dus als enigste de gegevens die de geactiveerde bestanden in het CachingFilesystem kan linken aan de bestanden die aangeboden worden door de StreamingServers. Daarom zal de Locator module zijn gegevens ook steeds moeten bewaren in de lokale opslag van het toestel. Zonder deze gegevens kan de inhoud van de bestanden in het CachingFilesystem niet langer gestreamd worden.
De FileLocator interface Deze interface laat toe om nieuwe gegevens toe te voegen aan de Locator module en er gegevens uit op te vragen. Wanneer nieuwe gegevens toegevoegd worden, krijgen ze door deze module een uniek nummer toegewezen binnen de scope van de client. Dit nummer zal het gegeven te allen tijde identificeren en blijft ook na een herstart van de StreamingClient constant. Wanneer nieuwe gegevens worden toegevoegd, wordt gecontroleerd of deze geen duplicaat zijn van gegevens die zich reeds in de Locator module bevinden. In dat geval worden de gegevens niet opnieuw toegevoegd.
3.2 Het StreamingClient subsysteem
3.2.3
45
De module ClApplicationStreamer
De ClApplicationStreamer module wordt gebruikt voor het maken en onderhouden van de verbindingen met de StreamingServers. De module kan met meerdere StreamingServers tegelijk een verbinding maken en deze kunnen ook door elkaar gebruikt worden. De ClApplicationStreamer module is volledig asynchroon opgebouwd. Het lanceren van de aanvraag door een andere module en het ophalen van het antwoord gebeurt steeds door twee verschillende oproepen naar de ClApplicationStreamer. Op deze manier kan de oproepende module nog ander werk verrichten terwijl de aanvraag in behandeling is of kunnen er meerdere aanvragen na elkaar gelanceerd worden. Aanvragen kunnen ook door elkaar vanuit verschillende modules komen of vanuit dezelfde module maar vanuit verschillende threads. De ClApplicationStreamer module zal alle aanvragen zo snel mogelijk versturen naar de juiste StreamingServer en zal er voor zorgen dat de antwoorden met de juiste aanvragen gepaard worden. In figuur 3.8 wordt met een sequentiediagram weergegeven hoe een aanvraag voor een StreamingServer verwerkt wordt door de ClApplicationStreamer module. Hierin wordt weergegeven hoe een Requestor, dit is eender welke module die een aanvraag wil doen, eerst een nieuw Request aanmaakt en dit vervolgens asynchroon doorgeeft aan de Sender. De Requestor kan hierna verder gaan met het uitvoeren van andere bewerkingen of op dezelfde manier nieuwe aanvragen lanceren. Wanneer de Sender een nieuw Request ontvangt zal deze indien nodig eerst een verbinding maken met de StreamingServer, waarna het Request geserialiseerd en doorgestuurd wordt naar de StreamingServer. Dit is opnieuw asynchroon vermits het Request verzonden wordt via het netwerk. Wanneer de StreamingServer de aanvraag verwerkt heeft, stuurt deze, opnieuw asynchroon, een Response terug naar de StreamingClient. Deze Response wordt gepaard met het juiste Request en beschikbaar gemaakt om opgehaald te worden. De Requestor kan eender wanneer het Response komen ophalen. Dit kan zowel voor- als nadat het Response ontvangen werd. Indien het Response nog niet beschikbaar is zal de Requestor blokkeren totdat het beschikbaar komt.
3.2 Het StreamingClient subsysteem
:Requestor
46
:Sender
<>
:StreamingServer
req:Request addRequest(req) getHost() host <>
:Connection
connect(host) init(login, passw) getResponse() send(req) wait()
request(req) response(resp) setResponse(resp)
notify() resp <<destroy>>
Figuur 3.8: Sequentiediagram voor een asynchrone aanvraag bij een StreamingServer
De FileStreamer interface Deze interface wordt gebruikt voor het streamen van de inhoud van bestanden. De request bestaat uit het activatienummer van het bestand, dat door de ClApplicationStreamer module in de Locator module kan worden opgezocht om te weten te komen welk bestand vanop welke StreamingServer gestreamd moet worden. Verder bevat het request ook precieze info over welk deel van het bestand er gestreamd moet worden (voor een definitie van “deel” zie sectie 4.4) en een databuffer waarin de gestreamde inhoud opgeslagen moet worden.
De ApplicationInfo interface De ApplicationInfo interface wordt gebruikt om te achterhalen welke applicaties er beschikbaar zijn op de StreamingServers en om meer informatie te bekomen over deze applicatie. Verder wordt de interface ook gebruikt om het activatiepakket van een applicatie op te vragen.
3.2 Het StreamingClient subsysteem
3.2.4
47
De module ApplicationManager
De ApplicationManger module vervult, zoals de naam al suggereert, de rol van centrale manager in de StreamingClient. Zo zal het deze module zijn die bepaalt wat er moet gebeuren wanneer er een nieuwe versie van een applicatie beschikbaar is en zal het de acties die hiervoor nodig zijn co¨ordineren. Zijn acties zullen echter voor een groot deel afhangen van de voorkeuren van de gebruiker. Deze kan bijvoorbeeld de voorkeur hebben om de huidige versie van een applicatie te blijven gebruiken in plaats van over te schakelen naar een nieuwe versie. De voornaamste functie van de ApplicationManager module zal echter het activeren van applicaties zijn. Wanneer een nieuwe applicatie geactiveerd moet worden, zal de ApplicationManger het activatiepakket via de ApplicationInfo interface (zie sectie 3.2.3) opvragen bij de StreamingServer. Vervolgens zullen alle applicatiebestanden in het pakket geregistreerd worden in de Locator module waardoor ze een uniek nummer toegewezen krijgen. Daarna worden de bestanden aan de CachingFilesystem module toegevoegd via de FileInfo interface waardoor ze beschikbaar worden voor de gebruiker en uitgevoerd kunnen worden.
De UIInfo interface Deze interface is een fa¸cade die een vereenvoudigd gezichtspunt biedt op het onderliggende systeem die meer aangepast is aan de noden van een gebruikersinterface. Op deze manier worden de implementatiedetails van het interne systeem weggefilterd voor de gebruikersinterface. Zo hebben veranderingen in de interface van andere modules ook niet meteen een invloed op de gebruikersinterface. Zolang de UIInfo interface constant blijft, kan de gebruikersinterface ook ongewijzigd blijven. Op deze manier worden onnodige rimpeleffecten vermeden.
3.2.5
De module UI
Deze module bevat de gebruikersinterface. Dit kan op twee verschillende manieren gedaan worden. Ofwel wordt de gebruikersinterface hier effectief in ondergebracht waarbij de gebruikersinterface en de StreamingClient in eenzelfde geheugenruimte uitgevoerd worden. Ofwel – en dat is een betere aanpak – wordt de UIInfo interface als een RPC-protocol ontwikkeld dat via een netwerk gebruikt kan worden. De gebruikersinterface wordt in dit geval een afzonderlijke applicatie. Dit heeft bovendien als voordeel dat de StreamingClient gemakkelijk van verschillende
3.3 Het StreamingServer subsysteem
48
gebruikersinterfaces kan voorzien worden. Bijvoorbeeld een grafische- en tekstgebruikersinterface.
3.3
Het StreamingServer subsysteem
De StreamingServer is in vergelijking met de StreamingClient eerder eenvoudig te noemen. Eenvoudig in die zin dat er zoals bij de StreamingClient geen virtualisaties meer aan te pas komen. De StreamingServer is dus een meer klassieke serverapplicatie die erop gericht is aanvragen van clients te beantwoorden. Een voorname drijfveer van een server in het algemeen is natuurlijk dat er meerdere clients tegelijk moeten bediend kunnen worden. Het is weinig effici¨ent om andere aanvragen te laten wachten terwijl de huidige aanvraag die verwerkt wordt, geblokkeerd is op een I/O-bewerking naar de lokale opslag. Er zal dus concurrenti¨ele uitvoering ge¨ıntroduceerd worden zodat de resources van de StreamingServer meer optimaal gebruikt kunnen worden en de aanvragen van de clients steeds zo snel mogelijk behandeld worden. Om de invloed van potenti¨ele wijzigingen in de StreamingServer zo veel mogelijk te beperken werd het subsysteem opgedeeld in modules met elk een specifieke taak. Ook de communicatie tussen de verschillende modules werd weer tot een minimum herleid om rimpeleffecten, afkomstig van wijzigingen, doorheen de modules zo veel mogelijk te vermijden. In figuur 3.9 wordt de decompositie van de StreamingServer in zijn verschillende modules weergegeven. In de volgende secties zal elk van de modules meer in detail besproken worden samen met hun interfaces.
3.3.1
De module SvApplicationStreamer
De SvApplicationStreamer module is de server tegenhanger van de ClApplicationStreamer op de client. De StreamingClients maken via de ApplicationSource interface (zie sectie 3.1.3) met deze module verbinding en zo met de StreamingServer. Deze module kan met meerdere clients tegelijk een verbinding onderhouden en parallel hun aanvragen verwerken. In figuur 3.10 wordt met een sequentiediagram weergegeven hoe een aanvraag van een StreamingClient verwerkt wordt door de SvApplicationStreamer module. Nadat een Streaming-
3.3 Het StreamingServer subsysteem
49
<<subsystem>> StreamingServer UserInfo <> UserManager UserAuthentication
UIInfo
CollectionInfo
<> UI
ApplicationStorage <> CollectionManager
ApplicationSource
<> SvApplicationStreamer
<> Storage
FileStorage
Figuur 3.9: Decompositie in het ontwikkel perspectief van het StreamingServer subsysteem
:StreamingClient
:Receiver
:Worker
init(login, passw) <>
conn:Connection
request(req) handleRequest(req, conn) send(resp) response(resp)
Figuur 3.10: Sequentiediagram voor de verwerking van een aanvraag op de StreamingServer
Client een verbinding opgebouwd heeft, verwacht de SvApplicationStreamer eerst en vooral een initialisatie-request van de client. Hierin kunnen een aantal parameters uitgewisseld worden betreffende de communicatie tussen de StreamingClient en de StreamingServer. Het initialisatierequest kan ook de authenticatiegegevens van de gebruiker bevatten wanneer dit vereist is om de applicatiecollectie te kunnen gebruiken (R18). Deze gegevens kunnen dan gecontroleerd worden met de UserManager module via de UserAuthentication interface (zie sectie 3.3.4). Na de initialisatie van de Connection kan de StreamingClient zijn aanvragen lanceren naar de StreamingServer. Deze aanvragen kunnen van meerdere clients tegelijk op de StreamingServer aankomen en elkaar in een snel tempo opvolgen. Het sequenti¨eel afhandelen van de aanvragen door de Receiver zelf zou dan ook een enorm knelpunt kunnen vormen in de server. Daarom zal de Receiver bij het ontvangen van een nieuwe aanvraag deze doorgeven aan een Worker.
3.3 Het StreamingServer subsysteem
50
Deze Worker zal de aanvraag dan parallel met de Receiver verwerken. De Receiver kan ondertussen verder gaan met het ontvangen van nieuwe aanvragen die dan aan andere Workers worden doorgeven. Wanneer een Worker klaar is met het verwerken van de aanvraag zal deze de Connection gebruiken om het antwoord terug te sturen naar de StreamingClient. De Workers kunnen voor het uitvoeren van een aanvraag gebruikmaken van de CollectionManager module via de CollectionInfo interface (zie sectie 3.3.3) of de Storage module via de FileStorage interface (zie sectie 3.3.2). De eerste interface wordt hierbij gebruikt voor het verkrijgen van informatie over de inhoud van de applicatiecollectie. De tweede interface wordt gebruikt voor het ophalen van de inhoud van bestanden in de collectie. De SvApplicationStreamer is ook verantwoordelijk voor het beheer van de Workers. Er moeten hierbij steeds voldoende Workers beschikbaar zijn om de aanvragen vlot te kunnen opvolgen. Anderzijds mogen er ook niet te veel Workers tegelijk hun taak uitvoeren. Dit kan immers leiden tot een overmatig gebruik van de resources op de server waardoor er dus een overbelasting van de server ontstaat. Hierdoor zullen Workers er te lang over doen om een aanvraag uit te voeren, wat uiteraard vermeden moet worden.
3.3.2
De module Storage
Deze module is een datarepository waarin alle applicatiebestanden en de gegevens over de applicaties en hun versies in de collectie worden opgeslagen. Deze module groepeert met andere woorden alle data die betrekking hebben op de applicatiecollectie. De gegevens in de Storage module kunnen via twee interfaces worden opgevraagd, de ApplicationStorage interface en de FileStorage interface.
De ApplicationStorage interface De ApplicationStorage interface laat de CollectionManager (zie sectie 3.3.3) toe om nieuwe gegevens toe te voegen aan de Storage module en er gegevens uit op te vragen die verband houden met de organisatie van de applicatiecollectie. Wanneer een nieuw gegeven toegevoegd wordt, krijgt dit door deze module een unieke identificatie toegewezen dat door de StreamingClients gebruikt kan worden om de gegevens op te vragen via de SvApplicationStreamer. Ook de CollectionManager zal deze identificatie gebruiken om de gegevens samen te stellen voor zijn
3.3 Het StreamingServer subsysteem
51
interfaces. Het is toegestaan om duplicaatgegevens toe te voegen aan de Storage, deze zullen echter steeds onderscheiden kunnen worden aan de hand van hun unieke identificatie.
De FileStorage interface Deze interface is uitsluitend bedoeld om de inhoud van bestanden in de Storage module op te vragen. Deze functionaliteit wordt door de SvApplicationStreamer gebruikt om de delen van de bestanden uit een applicatie te streamen naar de StreamingClient. Deze interface is synchroon.
3.3.3
De module CollectionManager
Deze module treedt op als centrale manager van de applicatiecollectie op de StreamingServer. Alle aanvragen voor en bewerkingen op de collectie passeren langs deze module zodat ze gefilterd en bewerkt kunnen worden. De voornaamste taken zijn om nieuwe applicaties en applicatieversies toe te voegen aan de collectie en om de antwoorden op gegevensaanvragen van StreamingClients samen te stellen. Dit kan respectievelijk door de UIInfo interface en de CollectionInfo interface.
De CollectionInfo interface Deze interface kan worden gebruikt om samengestelde informatie over de applicatiecollectie op te vragen. Elk element (applicatie, versie, bestand, ...) zit in de Storage module afzonderlijk opgeslagen waarbij verbanden tussen de elementen enkel aangegeven worden door het opnemen van de identificatie van een ander element. Via deze interface kan bijvoorbeeld eenvoudig een lijst van alle versies van een bepaalde applicatie opgevraagd worden in plaats van alle gegevens individueel uit de Storage module te moeten opvragen. Via deze interface wordt er met andere woorden een gefilterd en samengesteld beeld gegeven van de applicatiecollectie zodat de andere modules dit niet steeds zelf moeten samenstellen. Op deze manier blijven wijzigingen in de interne opbouw van de Storage ook beperkt tot de CollectionManager module.
De UIInfo interface Deze interface is analoog aan de UIInfo interface van de StreamingClient (zie sectie 3.2.4).
3.3 Het StreamingServer subsysteem
3.3.4
52
De module UserManager
De UserManager module is verantwoordelijk voor het beheer van de gebruikers in het systeem. In het huidige ontwerp wordt deze module enkel gebruikt voor het verifi¨eren van de authenticatiegegevens van de gebruikers wanneer deze een verbinding maken met de StreamingServer. Deze gegevens kunnen door de SvApplicationStreamer gecontroleerd worden via de UserAuthentication interface. De UserInfo interface wordt door de CollectionManager module gebruikt om nieuwe gegevens toe te voegen aan de UserManager module en om de gegevens van de gebruikers op te vragen. Voor een mogelijke uitbreiding op deze module zie sectie 5.2.3.
3.3.5
De module UI
Deze module is analoog aan de UI module van de StreamingClient (zie sectie 3.2.5).
Hoofdstuk 4
Ontwerpkeuzes In dit hoofdstuk zal ingegaan worden op een aantal belangrijke keuzes die gemaakt zijn bij het ontwerpen van het prototype Application Streaming System, ontwikkeld voor deze thesis. Het is de betrachting om bij elke keuze de belangrijkste mogelijkheden te presenteren en te argumenteren waarom voor een bepaalde mogelijkheid werd gekozen.
4.1
Virtualisatie van bestanden
Bij de keuze van een bestandsvirtualisatietechniek zijn er een aantal vereisten die de keuze mee be¨ınvloeden. Zo moet het systeem transparant zijn voor de gebruiker (R8) en de applicatieontwikkelaar (R9) en zou het geen speciale technische kennis mogen vereisen om het systeem te installeren (R11). De transparantie naar zowel de gebruiker als de applicatieontwikkelaar toe is hierbij echter belangrijker dan de technische kennis die nodig is om het systeem te installeren op het toestel van de gebruiker. Vermits dit laatste een eenmalige handeling is, is het vaak mogelijk om dit door een expert te laten uitvoeren. De volgende alternatieven werden ge¨ıdentificeerd als mogelijke oplossingen voor het virtualiseren van bestanden.
4.1.1
Speciale streamingbibliotheek
Bij deze oplossing moet een applicatie, die in aanmerking komt voor distributie via het Application Streaming System, tijdens zijn ontwikkeling gelinkt worden met een speciale stream-
53
4.1 Virtualisatie van bestanden
54
ingbibliotheek. Een mogelijke denkpiste hier is het opvangen van de paginafouten (Eng. page faults) in de applicatie (voor een beschrijving van het pagineringmechanisme, zie sectie 4.4.3). De streamingbibliotheek zou hiervoor dan een signaalhanteerder (Eng. signal handler ) kunnen registreren die er voor zorgt dat bij elke paginafout, de applicatie hiervan in kennis gesteld wordt. Wanneer er dan een paginafout optreedt tijdens de uitvoering van de applicatie, zou deze signaalhanteerder de gevraagde code eerst kunnen ophalen bij de streamingserver en klaarzetten zodat ze door het besturingssysteem ingeladen kan worden. Het bleek echter dat paginafouten niet opgevangen kunnen worden door normale applicaties [FC]. Paginafouten behoren tot de abstracties die door het besturingssysteem geboden worden en waarmee de applicaties dus niet geconfronteerd worden. Anderzijds is er ook het probleem hoe de gestreamde data in de lokale opslag van het toestel beheerd moeten worden door het systeem. Dit is hier bijna onmogelijk omdat je steeds moet terugvallen op klassieke bestandssystemen die hiervoor niet over de juiste capaciteiten beschikken. Dit is dan ook een doodlopende piste. Bovendien faalt deze methode tegen vereiste die zegt dat het systeem ook transparant voor de applicatieontwikkelaar (R9) moet zijn. Het fundamentele probleem met deze methode is echter dat er aan de hand van een bibliotheek nooit voldoende controle verkregen zal worden op de herkomst van de code wanneer deze ingeladen wordt door het besturingssysteem. De tijd dat een applicatie zelf verantwoordelijk werd geacht voor het beheer van zijn applicatiecode in het geheugen is dan ook al lang voorbij en behoort nu tot het domein van het besturingssysteem. Er moet dan ook gezocht worden naar een methode die ofwel de uitvoering van de applicatie volledig zelf in de hand neemt (voor de kernel) of een methode die tussenkomt daar waar de kernel de code van de applicatie ophaalt en zo de herkomst kan sturen (achter de kernel).
4.1.2
Virtuele machine
Deze methode plaatst zich voor de kernel door de applicatie uit te voeren in een virtuele machine. Wanneer de gebruiker een applicatie wenst op te starten, zal eerst de virtuele machine opgestart worden die dan de applicatie zal uitvoeren op zijn virtuele processor. Op dat moment krijgt de virtuele machine de volledige controle over de uitvoering van de applicatie en dus ook over de herkomst van de applicatiecode wanneer deze ingeladen moet worden. De virtuele machine kan bijvoorbeeld te werk gaan door de basisblokken – een codesequentie zonder sprongen – van
4.1 Virtualisatie van bestanden
55
de applicatie telkens te vertalen naar instructies voor de virtuele processor. Deze vertalingen worden dan in de virtuele machine uitgevoerd. Een applicatie wordt in dit geval niet meer dan de invoer voor de virtuele machine, net zoals een C-bestand de invoer is voor een C-compiler. Dat deze manier van werken mogelijk is wordt aangetoond door de ontwikkeltool valgrind [Sew06] die precies hetzelfde doet. Het doel van valgrind is echter de code te instrumenteren en te analyseren om zo onder andere fouten in de geheugenallocatie van de applicatie te kunnen opsporen. Voordeel van deze methode van werken is dat ze voldoet aan alle vereisten (R8, R9 en R11) die gesteld worden aan een bestandsvirtualisatiemethode voor het Application Streaming System. Dit lijkt dan ook de ideale kandidaat. Er zijn echter andere overwegingen die in acht genomen moeten worden. Zo is de vertaling van de applicatiecode naar instructies voor de virtuele processor een zeer kostelijke bewerking. Deze vertaling kan eventueel nog uitgevoerd worden op de server tijdens het importeren van de applicatie in de applicatiecollectie. De vertaling naar virtuele processorinstructies is bovendien ook een zeer complexe bewerking die dus heel wat expertise vergt en processor specifiek is. Deze vertaling zal dus voor elke processorarchitectuur opnieuw gemaakt moeten worden. Daarnaast is er natuurlijk nog de overhead die gepaard gaat met de uitvoering in een virtuele machine. Elke instructie uit de originele applicatie zal immers aanleiding geven tot een veelvoud aan instructies uitgevoerd door de virtuele machine. Het geheugengebruik zal ook een stuk hoger liggen daar de virtuele machine heel wat management informatie over de applicatie moet bijhouden. Rekenkracht en geheugen zijn echter twee zaken die nog niet in overvloed aanwezig zijn op resource-beperkte toestellen. Een ander nadeel van deze methode is ook dat de virtualisatie enkel werkt voor applicaties uitgevoerd binnen de virtuele machine. Andere bestanden, zoals een lees-mij-bestand, kunnen dan ook niet gevirtualiseerd worden voor de gebruiker en moeten daarom nog steeds via de klassieke lokale opslag aangeboden worden. Deze niet-applicatie-bestanden kunnen wel gevirtualiseerd worden wanneer ze gebruikt worden door de applicatie die uitgevoerd wordt in de virtuele machine. Hiervoor moeten de systeemoproepen (Eng. system calls) voor het openen en lezen van bestanden en directories dan wel door de virtuele machine opgevangen worden en indien nodig omgeleid worden naar de bestandsvirtualisatie. Hoewel deze methode technisch realiseerbaar is, werd ze voorlopig nog niet als haalbaar voor de resource-beperkte toestellen beschouwd. Dergelijk systeem is ook zeer complex en vereist
4.2 Bestandsbeheer in het virtuele bestandssysteem
56
zeer veel expertise. Het systeem zou bovendien besturingssysteem en processor afhankelijk zijn waardoor elke overdraging naar een ander platform zeer tijdrovend zou zijn.
4.1.3
Virtueel bestandssysteem
De derde mogelijkheid is een virtualistatie van de bestanden aan de hand van een virtueel bestandssysteem. Deze methode plaatst zich achter de kernel in die zin dat het besturingssysteem nog steeds volledig verantwoordelijk is voor het inladen en het uitvoeren van de applicatie maar waarbij de kernel voor het inladen van de applicatie wel een beroep moet doen op het virtuele bestandssysteem. Hiervoor wordt een nieuwe systeemdriver (Eng. device driver ) ontwikkeld en aan het besturingssysteem toegevoegd. Deze systeemdriver is volledig artificieel en heeft geen banden met enige hardware in het toestel van de gebruiker. Hij kan dan ook gezien worden als een applicatie met als invoer de bewerkingen die het besturingssysteem uitvoert op het bestandssysteem. De interpretatie van de bewerkingen op de bestanden kan dan ook volledig vrij gekozen worden en zelfs afwijkend zijn van wat conventioneel is indien dit nuttig kan zijn. Doordat het virtuele bestandssysteem zich achter de kernel plaatst, blijft de interface tussen de kernel en de applicatie ongewijzigd en kan de applicatie zonder tussenkomst rechtstreeks uitgevoerd worden. Met deze techniek is het bovendien ook mogelijk om niet-applicatie-bestanden te virtualiseren omdat de bestandsvirtualisatie zich achter de kernel bevindt en dus ook zichtbaar is voor applicaties die niet gestreamd worden. Ook de vereisten van transparantie voor gebruiker en applicatieontwikkelaar zijn met deze techniek voldaan. De vereiste voor een niet technische installatie van het systeem zal hierbij echter niet gerealiseerd kunnen worden. Het systeem moet als een systeemdriver ge¨ınstalleerd worden en zal dus een administratoraccount vereisen om deze te installeren. Hiertegenover staat dan wel dat de geheugen- en rekenkundige vereisten van het systeem zonder grote inspanningen binnen deze van een resource-beperkt toestel kunnen gehouden worden. Bij de implementatie van het prototype van deze thesis werd dan ook voor deze optie gekozen.
4.2
Bestandsbeheer in het virtuele bestandssysteem
De voornaamste functie van een normaal bestandssysteem is het opslaan van informatie in bestanden. Deze bestanden kunnen georganiseerd worden in een boomstructuur van directories
4.2 Bestandsbeheer in het virtuele bestandssysteem
57
waarin de bestanden de bladeren vormen. Applicaties kunnen informatie in bestanden schrijven die bewaard zal blijven ook nadat de applicatie be¨eindigd werd. De informatie in het bestand kan dan later opnieuw ingelezen en eventueel veranderd worden. Het virtuele bestandssysteem van het Application Streaming System heeft echter niet als doel inhoud op te slaan. De inhoud van de bestanden die het aanbiedt is immers steeds beschikbaar op een streamingserver. Het virtuele bestandssysteem moet echter wel in staat zijn om een boomstructuur van directories en bestanden aan te maken en te bewaren. Directories en bestanden worden immers door het systeem aan deze structuur toegevoegd wanneer een applicatie geactiveerd wordt. Deze boomstructuur is, in tegenstelling tot de inhoud van een bestand, uniek voor elke client en moet dan ook door de client zelf bewaard worden. Daarnaast beschikt elk bestand over een aantal eigenschappen die niet terug te vinden zijn in een normaal bestandssysteem. Zo moet voor elk bestand bijgehouden worden waar zijn inhoud te vinden is en moet er ook ondersteuning zijn om precies te weten welke delen van een bestand beschikbaar zijn in de datacache en welke delen gestreamd moeten worden. Er bestaat reeds een zeer groot aantal normale bestandssystemen die elk voor- en nadelen hebben. Voor het ontwerp van het virtuele bestandssysteem voor het Application Streaming System werden dan ook geen nieuwe methoden ontworpen. In de plaats daarvan werden de bestaande bestandssystemen bestudeerd en hun technieken ge¨evalueerd in het licht van het virtuele bestandssysteem voor het Application Streaming System. In de volgende paragrafen worden de voornaamste technieken besproken en hoe deze de taak van het virtuele bestandssysteem zullen ondersteunen.
4.2.1
Beheer van de bestandsinhoud
Hoewel het virtuele bestandssysteem de inhoud van bestanden niet blijvend moet opslaan maar enkel zal cachen, moet er toch een techniek voorzien worden om te weten welke delen van een bestand in de datacache aanwezig zijn en welke niet. In de volgende secties worden twee courante technieken gebruikt voor de allocatie van datablokken aan bestanden en hoe deze al dan niet ingezet kunnen worden in het virtuele bestandssysteem.
4.2 Bestandsbeheer in het virtuele bestandssysteem
I-node
FAT 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
58
Attributen 10 11 7
Enkele indirectie Dubbele indirectie
Bestand A
3 2
Bestand B Triple indirectie
12 14 -1
...
Legende: Datablokadres Indirectieadres
-1
(a)
... (b)
Figuur 4.1: Datablok allocatie bij bestanden: (a) met een File Allocation Table [Tan01], (b) met inodes [Tan01]
Gelinkte lijst allocatie met een tabel in het geheugen Bij deze techniek wordt voor elk bestand een gelinkte lijst van zijn datablokken bijgehouden. Deze gelinkte lijst wordt in een tabel in het geheugen opgeslagen waarbij de index in de tabel overeenstemt met de index van het datablok. Voor elk bestand moet dus maar ´e´en verwijzing bijgehouden worden naar het eerste datablok. De anderen kunnen dan gevonden worden door de links in de tabel te volgen. Deze tabel wordt een FAT (File Allocation Table) genoemd en wordt onder andere gebruikt in het FAT-16 en FAT-32 bestandssysteem van Microsoft. In figuur 4.1(a) wordt een voorbeeld gegeven voor twee bestanden. Bestand A gebruikt de datablokken 4, 7, 2, 10 en 12 in die volgorde en bestand B gebruikt de datablokken 6, 3, 11 en 14. [Tan01] Hoewel deze methode eenvoudig werkt bij normale bestandssystemen, blijkt net het tegenovergestelde waar te zijn bij een virtueel bestandssysteem voor het Application Streaming System. Dit komt omdat elk element in de FAT moet corresponderen met een fysiek datablok terwijl dit bij het virtuele bestandssysteem enkel “virtuele datablokken” zijn. De enige fysieke datablokken in het virtuele bestandssysteem zijn deze uit de datacache maar deze veranderen constant van inhoud en vormen dus geen goede basis voor de allocatie van datablokken. Het grootste
4.2 Bestandsbeheer in het virtuele bestandssysteem
59
probleem is dus hoe deze virtuele datablokken afgebeeld kunnen worden op re¨ele datablokken. Hiervoor zal in elk element van de FAT extra informatie opgenomen moeten worden die het fysieke datablok op een server bepaalt. Daarnaast moet elk element in de FAT ook aangeven of het datablok zich al dan niet in de datacache bevindt en zo ja ook specificeren waar het zich bevindt in de datacache. Dit moet bovendien kunnen zonder de informatie over het datablok op de server te verliezen. Bovendien is het zo dat de FAT altijd en volledig in het geheugen aanwezig moet zijn. Zo zal de FAT voor elke gigabyte aan virtuele bestanden 1MiB1 aan geheugen innemen voor de links alleen. Daarbovenop komt nog eens voor elk element de informatie die nodig is om het virtuele datablok op een datablok op een server af te beelden. Bovendien zal deze tabel ook steeds blijven groeien in het virtuele bestandssysteem. Bij een normaal bestandssysteem ligt het aantal datablokken op voorhand vast en zal de tabelgrootte dus nooit wijzigen maar bij het virtuele bestandssysteem worden er bij elke activatie van een applicatie nieuwe bestanden toegevoegd en dus ook nieuwe virtuele datablokken. Dit heeft dan ook een zware impact op het geheugengebruik wanneer de gebruiker veel applicaties geactiveerd heeft. Dit maakt een FAT dan ook ongeschikt voor gebruik in het virtuele bestandssysteem voor het Application Streaming System.
Allocatie met een inode De tweede methode om datablokken te alloceren aan bestanden is gebaseerd op het associ¨eren van een inode – afkorting van index-node – met elk bestand. Elke inode bevat een lijst met de indexen van de datablokken die aan het bestand zijn toegewezen. De volgorde van indexen in de lijst duidt hierbij ook de volgorde van de datablokken in het bestand aan. Elke inode kan een klein, vast aantal directe datablokadressen bevatten. Wanneer dit vaste aantal onvoldoende blijkt, zal een blokadres in de inode gebruikt worden voor een indirectieblok dat de verdere datablokadressen zal bevatten. Dit blok wordt een enkelvoudig indirectieblok genoemd. Blijkt dit nogmaals onvoldoende, dan kan nog een blokadres in de inode gebruikt worden voor een indirectieblok dat dan adressen van enkelvoudige indirectieblokken bevat. Op die manier ontstaat een dubbele indirectie naar de datablokadressen. Dit blok wordt dan ook een tweevoudig indirectieblok genoemd. Tot slot is ook nog een drievoudig indirectieblok mogelijk. Deze methode wordt bijvoorbeeld toegepast in het minix- en ext2-bestandssysteem voor Linux. [Tan01] 1
1GiB = 262.144 blokken × 4KiB/blok; 262.144 referenties × 4bytes/referentie = 1MiB
4.2 Bestandsbeheer in het virtuele bestandssysteem
60
X
(a)
(b)
Figuur 4.2: Structureel verschil tussen (a) een FAT en (b) een inode. (
: gecodeerde verwijzing,
: impliciete verwijzing)
In figuur 4.1(b) wordt een voorbeeld weergegeven van een inode met zeven directe datablokadressen (wit). Het achtste blokadres wordt gebruikt voor een enkelvoudig, het negende voor een tweevoudig en het tiende voor een drievoudig indirectieblokadres (grijs). Met deze inode kan elk bestand tot 265 (= 7 + 6 + 62 + 63 ) datablokken bevatten. In de praktijk worden de indirectieblokken veel groter gekozen waardoor een inode enkele miljoenen enkelvoudig indirecte, tweevoudig indirecte en drievoudig indirecte datablokadressen kan bevatten. Deze methode blijkt veel beter geschikt te zijn voor gebruik in het virtuele bestandssysteem voor het Application Streaming System. Het verschil met een FAT zit in het subtiele feit dat de elementen in een FAT corresponderen met fysieke datablokken in de lokale opslag terwijl de elementen in de tabel van inodes corresponderen met logische datablokken in het bestand. Elk element in de FAT correspondeert met een fysiek datablok in de lokale opslag waarbij de index van het element in de FAT zijn corresponderend fysieke datablok identificeert. Door deze fysieke datablokken te linken ontstaat dan het bestand. De informatie in een element van de FAT is hier telkens een verwijzing naar het volgende element. De verwijzingen naar de corresponderende fysieke datablokken zit impliciet vervat in de volgorde van de elementen in de FAT. Dit wordt schematisch weergeven in figuur 4.2(a). Bij inodes daarentegen correspondeert elk element uit de tabel met een logisch datablok in het bestand waarbij de index van het element in de tabel zijn corresponderend logisch datablok identificeert. De informatie in een element is hier de verwijzing naar het corresponderende fysieke datablok en de volgorde van de elementen zit impliciet vervat in de volgorde van de elementen in de tabel. Dit wordt schematisch weergeven in figuur 4.2(b).
4.2 Bestandsbeheer in het virtuele bestandssysteem
61
Het is precies de impliciete correspondentie tussen het element in de FAT en een fysiek datablok dat ontbreekt in het virtuele bestandssysteem. Waarmee zou de index van het element in de FAT immers moeten corresponderen in een virtueel bestandssysteem? Een belangrijk verschil is bovendien dat de informatie van een inode enkel in het geheugen aanwezig moet zijn wanneer het bestand in gebruik is. Het geheugengebruik is dus evenredig met het aantal geopende bestanden in plaats van met het aantal (virtuele) datablokken. Een tweede reden die deze methode geschikt maakt voor een virtueel bestandssysteem is het eenvoudige beheer van de datacache. Daar waar de indexen in de inode bij normale bestandssystemen wijzen naar de fysieke datablokken op de disk, kunnen deze in een virtueel bestandssysteem wijzen naar de datablokken in de datacache. Een datablok dat zich dan niet in de datacache bevindt kan eenvoudigweg aangeduid worden met een speciale index in de inode. Deze methode werd daarom ook toegepast in het ontwerp van het Application Streaming System.
4.2.2
Beheer van de directorystructuur
Een directory is in essentie eigenlijk een normaal bestand waarvan de inhoud bepaald en ge¨ınterpreteerd wordt door het bestandssysteem zelf. De voornaamste functie van een directory is de naam van een bestand af te beelden op de informatie die nodig is voor het vinden van de inhoud van het bestand. De vraag is waar deze informatie, alsook de attributen van het bestand, bewaard moeten worden. Net zoals voor het beheer van de bestandsinhoud bestaan er ook voor het beheer van de directorystructuur twee gebruikelijke technieken. De eerste mogelijkheid is om deze informatie meteen bij de naam van het bestand in de directory op te slaan. In dit geval bestaat een directory uit een lijst van bestandsnamen met hun eigenschappen2 . Nadeel hierbij is echter dat wanneer de eigenschappen van een bestand veel plaats innemen, bijvoorbeeld wanneer er gewerkt wordt met inodes, deze een directorybestand zeer snel kunnen opblazen. Wanneer een directory veel bestanden bevat worden deze over een groot aantal datablokken verdeeld wat het zoeken in een directory sterk kan afremmen. Deze optie wordt daarom in vele gevallen enkel gebruikt in combinatie met een FAT waarbij alleen de index van het eerste datablok nodig is. Wanneer er met inodes wordt gewerkt, wordt de datablokallocatie informatie samen met 2
Dit zijn zowel de allocatieinformatie als de attributen van een bestand
4.3 Beheer van de datacache
62
de attributen van het bestand dan ook vaak in een afzonderlijke structuur buiten de directory opgeslagen. Een directory moet dan enkel nog maar de naam van een bestand bevatten en de verwijzing naar de bijhorende structuur van het bestand. Het doorzoeken van een directory wordt dan niet afgeremd door een teveel aan informatie die in eerste instantie nog niet nodig is. Omdat het virtuele bestandssysteem reeds gebruik maakt van inodes (zie sectie 4.2.1) werd voor directories ook deze laatste techniek gekozen.
4.3
Beheer van de datacache
De datacache van de streamingclient is een cache die in grootte beperkt wordt om te voorkomen dat alle lokale opslag van het toestel gebruikt wordt voor het opslaan van gestreamde applicaties. Een vereiste van het systeem is echter wel dat het uitvoeren van een applicatie niet kan geweigerd worden op basis van onvoldoende beschikbare lokale opslag (R4). Applicaties zullen de beschikbare ruimte in de datacache dan ook moeten delen met elkaar, of zelfs met zichzelf indien de applicatie groter is dan de datacache. Er moet dus een strategie ontwikkeld worden om deze datacache te beheren en om er data uit te kunnen verwijderen wanneer deze vol is. Een cachestrategie moet in staat zijn twee dingen te doen. In de eerste plaats moet er op een gefundeerde wijze een keuze gemaakt kunnen worden om een datablok te verwijderen en te vervangen door een ander datablok. Dit zal verder de keuzestrategie genoemd worden. Een tweede luik bestaat uit het updaten van de informatie in de inode van het bestand waartoe het verwijderde datablok behoorde. Dit zal dan verder de updatestrategie genoemd worden. Dit laatste is van belang om te zorgen dat een datablok in de cache niet door twee bestanden tegelijk wordt gebruikt. De volgende criteria zijn van belang bij de beoordeling van een cachestrategie. Hoe goed is de keuze van de keuzestrategie: in welke mate wordt een goede keuze gemaakt voor het verwijderen van een datablok uit de cache? Wat zijn de rekenkundige vereisten van de keuzestrategie: hoeveel berekeningen zijn er nodig om een keuze te maken met betrekking tot het datablok dat het best verwijderd kan worden? Wat zijn de geheugenvereisten van de keuzestrategie: hoeveel geheugen, werkgeheugen en lokale opslag, is er nodig om de keuze te kunnen maken?
4.3 Beheer van de datacache
63
Wat zijn de rekenkundige vereisten van de updatestrategie: hoeveel berekeningen zijn er nodig voor het aanpassen van de informatie in de inode? Wat zijn de geheugenvereisten van de updatestrategie: hoeveel geheugen, werkgeheugen en lokale opslag, wordt er gebruikt om een update van de juiste inode te doen? In de volgende paragrafen worden een aantal van de mogelijke strategie¨en besproken samen met hun voor- en nadelen.
4.3.1
Keuzestrategie¨ en
De optimale keuzestrategie De ideale keuzestrategie [Tan01] voor het beheer van de datacache zou erin bestaan om precies die data uit de cache te verwijderen die pas het verst in de toekomst opnieuw nodig zullen zijn. Dit komt neer op het zo lang mogelijk uitstellen van het opnieuw inlezen van de data die verwijderd werden uit de cache. Deze strategie is echter onmogelijk te implementeren daar het voor de computer zelfs onmogelijk is te weten welke data in de volgende stap nodig zullen zijn, laat staan na miljoenen stappen. Deze strategie kan echter wel gebruikt worden als referentie ter vergelijking van andere strategie¨en. Hiervoor moet een applicatie in een simulator uitgevoerd worden waarbij in een eerste uitvoering de benodigde data worden opgetekend zodat bij een tweede uitvoering, van precies hetzelfde programma met precies dezelfde invoer, de verzamelde informatie kan gebruikt worden door de cache. Deze methode is echter niet bruikbaar in praktische toepassingen maar ideaal om cachestrategie¨en te vergelijken.
De minst-recent-gebruikte keuzestrategie De minst-recent-gebruikte (Eng. least recently used of LRU) keuzestrategie [Tan01] is een goede benadering van de optimale cachestrategie. Wanneer er data uit de cache verwijderd moeten worden, worden steeds die data verwijderd die het minst recent gebruikt werden. Deze strategie gaat uit van de observatie dat het niet waarschijnlijk is dat data die niet recent gebruikt werden, in de eerstvolgende stappen opnieuw gebruikt zullen worden.
4.3 Beheer van de datacache
64
Een voor de hand liggende implementatie van deze strategie bestaat uit het bijhouden van een lijst van alle datablokken in de datacache met vooraan het meest recent gebruikte datablok en achteraan het minst recent gebruikte datablok. De lijst moet dan ge¨ updatet worden telkens er data uit de cache gebruikt worden. De keuzestrategie bestaat er dan eenvoudigweg uit om steeds het laatste datablok in de lijst te nemen. Het opzoeken, verwijderen en vooraan bijvoegen van data in de lijst kan in constante tijd gebeuren maar het geheugengebruik is dan 2n referenties, met n het aantal datablokken in de datacache. E´en referentie wijst namelijk naar het vorige datablok in de lijst en ´e´en referentie wijst naar het volgende datablok in de lijst. Een andere implementatiemogelijkheid is het bijhouden van een teller die bij elke toegang tot de cache met 1 verhoogd wordt. Ieder datablok in de cache heeft een veld waarin bij elk gebruik van het datablok de huidige waarde van de teller wordt opgeslagen. De keuzestrategie bestaat er dan in om telkens het datablok te kiezen met de laagste waarde van de teller. Het updaten van het veld bij gebruik van een datablok blijft mogelijk in constante tijd en het geheugengebruik is bij deze strategie verminderd naar n tellers. De keuzestrategie bestaat dan uit het overlopen van alle datablokken in de cache en het datablok te selecteren met de laagste teller. Deze bewerking kan uitgevoerd worden in een tijd die evenredig is met het aantal datablokken in de cache.
De pseudo-minst-recent-gebruikte keuzestrategie Deze keuzestrategie is een afgeleide vorm van de tweede implementatiemethode van de minstrecent-gebruikte keuzestrategie. Deze strategie werd voor het eerste gebruikt in de hardware cache van de embedded Intel Pentium processor met MMX-technologie [Int98]. De keuze die gemaakt wordt voor het verwijderen van een datablok uit de datacache is niet steeds optimaal, in de zin van minst-recent-gebruikt. Daar staat wel tegenover dat 1-bit per datablok voldoende is om de keuze te maken en dat het zoeken van dit blok in een tijd O(log(n)) kan uitgevoerd worden met n het aantal datablokken in de cache. De strategie is gebaseerd op een binaire boom waarin de datablokken de bladeren voorstellen. In figuur 4.3(a) wordt een dergelijke boom voorgesteld met acht datablokken (rechthoeken 0 tot 7). Elk knooppunt van de boom wordt voorgesteld door precies 1-bit die de configuratie van de rode en de blauwe boog vanuit dat knooppunt bepaalt. Als de bit in het knooppunt 0 is, ligt het rode pad langs links. Als de bit in het knooppunt 1 is, ligt het rode pad langs rechts. Een blauw pad vanuit een knooppunt leidt hierbij steeds tot het meest recent gebruikte datablok van
4.3 Beheer van de datacache
65
0 2
4
1
0
0
0
0
1
0 1
2
5
6
3
4
0 5
6
7
7
0
0 1
2
0 3
4
(a)
(b)
0
1
0 2
0
0
1
0 1
1
0
1
0
3
8
0 5
5
0
1 3
0
6
0
0 1
7
1
0 7
6
2
(c)
1 3
8
0 5
6
7
(d)
Figuur 4.3: Boomstructuur van een PseudoLRU cache met acht datablokken. (a) beginsituatie, (b) datablok 1 werd gebruikt, (c) een nieuw datablok 8 wordt gebruikt, (d) datablok 3 werd gebruikt.
de deelboom, een rood pad tot het pseudo minst recent gebruikte datablok van de deelboom. In vele gevallen zal het rode pad ook effectief naar het minst recent gebruikte datablok wijzen maar dit is, zoals reeds eerder vermeld werd, niet gegarandeerd. Wanneer nu een datablok uit de datacache gebruikt wordt, dan zal de boom zodanig opnieuw geconfigureerd worden dat het blauwe pad vanuit de basisknoop naar dit datablok wijst. Hiervoor worden alle knooppunten op het pad overeenkomstig geconfigureerd. Deze situatie wordt weergegeven in figuur 4.3(b) nadat datablok 1 gebruikt werd. Wanneer nu een nieuw datablok gebruikt wordt dat nog niet in de datacache aanwezig is, dan zal dit opgeslagen worden op de plaats die door het rode pad vanuit de basisknoop wordt aangegeven. Het datablok dat zich op dat moment op die plaats bevindt, wordt hierbij overschreven. Deze situatie wordt weergegeven in figuur 4.3(c) nadat het nieuwe datablok 8 gebruikt werd. Dat het hier een pseudo-minst-recent-gebruikte keuzestrategie betreft, wordt duidelijk geillustreerd in figuur 4.3(d). In figuur 4.3(c) was datablok 2 volgens de pseudo-minst-recent-
4.3 Beheer van de datacache
66
Algoritme 4.1 UseBlock(cache index) Pre-conditie: tree depth > 0; 0 ≤ cache index < 2ˆtree depth; sizeof (tree) = 2ˆtree depth Post-conditie: Blauwe pad wijst naar cache index 1:
for i = 0 to (tree depth − 1) do
2:
tree index ⇐ (1 << i) + (cache index >> (tree depth − i))
3:
mask ⇐ (1 << (tree depth − i − 1))
4:
if cache index & mask then
5:
tree[tree index] ⇐ 0
6: 7:
else tree[tree index] ⇐ 1
Algoritme 4.2 FindBlock() Pre-conditie: tree depth > 0; sizeof (tree) = 2ˆtree depth Post-conditie: Rode pad wijst naar cache index; 0 ≤ cache index < 2ˆtree depth; unchanged(tree) 1:
cache index ⇐ 0
2:
for i = 0 to (tree depth − 1) do
3:
tree index ⇐ (1 << i) + cache index
4:
cache index ⇐ (cache index << 1) + tree[tree index]
5:
return cache index
gebruikte keuzestrategie het meest geschikte datablok om vervangen te worden door een nieuw datablok. Door het gebruik van datablok 3 verandert deze keuze echter naar datablok 6 zonder dat datablok 2 eerst overschreven werd. Deze situatie zal echter slechts zelden optreden daar datablok 3 zelf het op ´e´en na minst recent gebruikte datablok was (in pseudo zin) en de kans dus eerder laag was dat het in de nabije toekomst gebruikt zou worden. De twee algoritmes, nodig voor het configureren van het blauwe pad en het opzoeken van het rode pad, zijn zeer eenvoudig wanneer de bits van de boomknopen in een aaneengesloten geheugenblok opgeslagen liggen. De index de index van elke bit die overeenstemt met elke knoop wordt in figuur 4.3(a) als superscript bij elke knoop weergegeven. De algoritmes worden dan eenvoudige iteraties op de diepte van de boom en de bewerkingen zijn eenvoudige schuifoperaties. De pseudocode van de algoritmes wordt weergegeven in algoritme 4.1 en algoritme 4.2.
4.4 Granulariteit van streamen
4.3.2
67
Updatestrategie¨ en
Elke inode van een bestand weet precies welke van zijn datablokken aanwezig zijn in de datacache en op welke plaats in de datacache deze zich bevinden. Daarom moet de informatie in de inodes consistent gehouden worden met de situatie in de datacache. Met name, wanneer een datablok verwijderd wordt uit de datacache omdat er plaats moet gemaakt worden voor een nieuw datablok, dan moet de informatie in de inode, waarvan het datablok verwijderd wordt, overeenkomstig aangepast worden. Een eerste mogelijkheid hiervoor is om voor elke cachepositie precies bij te houden welk datablok van welke inode er in de cachepositie opgeslagen ligt. Bij elke cachepositie moeten er dan steeds twee referenties bewaard worden: ´e´en referentie naar de inode en ´e´en referentie als index van het blok in de inode. Die informatie in de inode kan op basis van deze referenties dan in constante tijd ge¨ updatet worden. De geheugenvereiste is echter wel 2n referenties, met n het aantal cacheposities. Deze methode kan echter nog afgeslankt worden tot een geheugengebruik van n referenties, door per cachepositie enkel de referentie naar de bijhorende inode te bewaren. Uit recent onderzoek [THB06] is immers gebleken dat 90% van de leesbewerkingen plaatsvindt op bestanden met een grootte van 33.522 bytes of minder (zie tabel 4.1). Met andere woorden, een groot deel van de leesbewerkingen vindt plaats op inodes met een beperkt aantal datablokken (voor een bestand van 33.522 bytes zijn bijvoorbeeld 33 datablokken van 1024 bytes nodig of 9 datablokken van 4096 bytes nodig). Doordat de index naar het datablok in de inode ontbreekt bij de cachepositie zal deze index in de inode moeten opgezocht worden door te itereren over alle blokken in de inode. De tijd die hiervoor nodig zal zijn is evenredig met de grootte van het bestand. Maar zoals in de vorige paragraaf besproken zullen de meeste bestanden waaruit gelezen wordt, relatief klein zijn waardoor de tijd die nodig is voor het opzoeken van deze index relatief beperkt blijft.
4.4
Granulariteit van streamen
In deze sectie zullen de mogelijkheden besproken worden voor de kleinste eenheid waarin een applicatie opgesplitst kan worden om dan gestreamd te worden. Deze eenheden zijn verder
4.4 Granulariteit van streamen
68
Deciel
Lezen
Schrijven
10%
889
300
20%
1965
2821
30%
3055
4096
40%
5265
4096
50%
6629
4503
60%
9170
4767
70%
13.477
5511
80%
18.562
6918
90%
33.522
16.281
100%
235.507.712
1.121.274.484
Tabel 4.1: Dynamische bestandsgrootte (in bytes) voor lees- en schrijfbewerkingen per deciel [THB06]
ondeelbaar en kunnen individueel, op aanvraag van de client of op initiatief van de server, naar het toestel van de gebruiker gestreamd worden.
4.4.1
Streamen per applicatie
De meest eenvoudige opsplitsing is om een applicatie in zijn geheel als eenheid te beschouwen. Bij deze opsplitsing vervalt het streamen van applicaties uiteraard in het downloaden van de applicatie net voor zijn uitvoering. Hierbij gaat uiteraard een aantal voordelen van het streamen van applicaties verloren. Zo zal het downloaden en cachen van enkel die delen van een applicatie die effectief gebruikt worden tijdens de uitvoering, niet langer mogelijk zijn. Tevens zal het eerst streamen van die delen die nodig zijn voor het opstarten van de applicatie, ook niet meer mogelijk zijn. Het is echter wel zo dat het steeds streamen van de gehele applicatie de enigste bescherming vormt tegen het uitvallen van de netwerkverbinding. Daarom werd deze mogelijkheid dan ook als een vereiste geformuleerd die kan uitgevoerd worden op initiatief van de gebruiker.
4.4.2
Streamen per bestand
Een andere mogelijkheid is om de afzonderlijke bestanden van een applicatie telkens als eenheden te beschouwen. Dit is een eenvoudige opsplitsing maar de verantwoordelijkheid om een applica-
4.4 Granulariteit van streamen
69
tie effici¨ent te kunnen streamen wordt hierbij dan voor een groot deel doorgeschoven naar de applicatieontwikkelaar. Deze zal de applicatie in modules moeten opdelen om zo een voldoende kleine opsplitsing te bekomen. Een applicatie die als een monolitische executable gemaakt werd, zal immers minder effic¨ent gestreamd kunnen worden dan een applicatie die werd opgedeeld in modules. Dit gaat in tegen de vereiste dat het streamen van een applicatie ook transparant moet zijn voor de applicatieontwikkelaar. Het design van een applicatie mag niet be¨ınvloed worden door keuzes die gemaakt werden voor het Application Streaming System.
4.4.3
Streamen per vast blok
De volgende stap die genomen kan worden, is om de bestanden door het Application Streaming System zelf in kleinere delen op te splitsen. Dit kan uiteraard op verschillende manieren aangepakt worden. Een eenvoudige manier is om de bestanden allemaal in stukken van gelijke grootte op te delen zonder naar de precieze inhoud te kijken. Op die manier wordt een uniforme aanpak over alle soorten bestanden (uitvoerbaar, document, webpagina, . . . ) behouden, wat deze manier van opdelen relatief eenvoudig houdt. De vraag is natuurlijk hoe groot deze delen het best gekozen kunnen worden. Hiervoor moet eerst en vooral gekeken worden naar de manier waarop een applicatie ingeladen wordt door het besturingssysteem. Als voorbeeld zal de situatie in het Linux besturingssysteem besproken worden [Rus96]. Dynamisch gelinkte bibliotheken worden hierbij evenwel buiten beschouwing gelaten. Wanneer een applicatie opgestart wordt, zal het uitvoerbare bestand eerst door de Linux kernel in het virtuele geheugen van het proces afgebeeld worden (niet geladen!). Dit betekent dat er bepaald wordt waar in de virtuele adresruimte van het proces de code van de applicatie terecht komt. De applicatiecode wordt hiervoor in vaste stukken van 4KiB opgedeeld die elk afzonderlijk door de Linux kernel beheerd kunnen worden (inladen, swappen, toegangseigenschappen, . . . ). Zo’n ´e´en enkel deel van 4KiB wordt een pagina (Eng. page) genoemd. Bij aanvang zal enkel de eerste3 pagina van de applicatie fysiek vanuit het bestandssysteem in het geheugen geladen worden en afgebeeld worden op de correcte plaats in het virtuele geheugen van het proces. Hierna wordt de uitvoering van de applicatie meteen gestart. Op een gegeven moment zal de uitvoering van de applicatie tot een deel in het virtuele geheugen komen dat niet ingeladen is. Dit wordt herkend door de processor die een paginafout (Eng. page fault) rappor3
Meer precies de eerste pagina met de initialisatiecode van de applicatie. Dit komt niet noodzakelijk overeen
met de eerste pagina uit het uitvoerbare bestand.
4.4 Granulariteit van streamen
70
teert aan de Linux kernel. De Linux kernel zal de ontbrekende pagina opzoeken, inladen in het geheugen en opnieuw afbeelden in het virtuele geheugen van het proces waarna de uitvoering van de applicatie hervat kan worden. Dit is een vereenvoudigde versie van wat er in werkelijkheid gebeurt maar is voldoende om een gefundeerde keuze te maken voor de delen waarin een bestand opgedeeld moet worden. De kernel heeft zijn keuze immers reeds bekendgemaakt. Waarom zou de keuze voor de granulariteit van de gestreamde delen moeten afwijken van de voorkeursgrootte van de kernel? Een kleiner blok van bijvoorbeeld 1KiB kiezen is hierbij weinig zinvol, daar er dan telkens vier van deze blokken tegelijk verstuurd moeten worden en dit betekent enkel meer overhead. Een groter blok van bijvoorbeeld 16KiB is ook weinig zinvol. Ten eerste zal de kernel dan langer op zijn data moeten wachten omdat er steeds vier pagina’s tegelijk verzonden worden en dus ook ontvangen moeten worden door de client. Ten tweede kan in het slechtste geval de datacache voor 3/4 gevuld zijn met data die nooit eerder opgevraagd werden en misschien ook nooit opgevraagd zullen worden. In het prototype bij deze thesis werd daarom ook de keuze van de kernel gevolgd en elk bestand opgedeeld in telkens even grote blokken van 4KiB.
4.4.4
Streamen per variabel blok
Er bestaat nog een vierde mogelijkheid die echter niet toegepast kan worden bij het virtuele bestandssysteem. Bij deze methode wordt de code van de applicatie eerst geanalyseerd op de server. De applicatie wordt dan opgesplitst in zijn basisblokken die dan elk afzonderlijk gestreamd kunnen worden. Dit laat dus een veel fijnere granulariteit toe maar de kernel werkt hoe dan ook enkel met volledige geheugenpagina’s van 4KiB waardoor dit overkill is in het geval van een implementatie met een virtueel bestandssysteem. Deze methode kan echter prima toegepast worden in combinatie met de virtuele machine (zie sectie 4.1.2). In dit geval is het immers niet de kernel maar de virtuele machine die de code inleest zodat de granulariteit zo fijn als gewenst kan genomen worden. De code kan dan op de server georganiseerd worden als een gerichte graaf van basisblokken waarbij dan steeds enkel die basisblokken doorgestuurd worden naar de client die via een pad van beperkte lengte volgen op het opgevraagde basisblok.
4.4 Granulariteit van streamen
71
Elk basisblok afzonderlijk streamen zal echter een zware overhead over het netwerk tot gevolg hebben. Deze mogelijkheid kan dan ook best met een streamingvoorspeller in de server gecombineerd worden die, op basis van gebruikersprofielen, voorspellingen maakt over welke basisblokken het meeste kans hebben om in de toekomst opgevraagd te worden door de client zodat meerdere basisblokken in ´e´en keer doorgezonden kunnen worden.
Hoofdstuk 5
Resultaten en verder onderzoek In het eerste deel van dit hoofdstuk zullen een aantal testen besproken worden die uitgevoerd werden met het Application Streaming System dat voor deze thesis ontwikkeld werd. In het tweede deel van het hoofdstuk zal dan een aantal mogelijke onderwerpen besproken worden voor verder onderzoek.
5.1 5.1.1
Resultaten Testopstelling
De testen werden uitgevoerd in een gecontroleerde omgeving met twee virtuele computers en een virtueel lokale netwerk ertussen. De maximum snelheid van het lokaal netwerk kan ingesteld worden zodat de prestaties van het systeem bij verschillende netwerksnelheden getest kan worden. Achtereenvolgens werd het netwerk ingesteld op 4 Mbps, 384 Kbps en 128 Kbps. Deze snelheden werden gekozen als representatie voor een consumenten ADSL-lijn, mobiele communicatie met EDGE en een dubbele ISDN-lijn. De twee testcomputers zijn rechtstreeks met elkaar verbonden en er bevinden zich geen andere computers op het netwerk. De Test Server is een minimaal ingerichte serverconfiguratie gebaseerd op Ubuntu Linux en beschikt over 128 MiB geheugen. De Test Client is ingericht als een desktopconfiguratie met een grafische omgeving en beschikt over 512 MiB geheugen. De testopstelling wordt schematisch weergegeven in figuur 5.1.
72
5.1 Resultaten
73
Lokaal netwerk 4Mbps/384Kbps/128Kbps
Test Client
Test Server
Figuur 5.1: Testopstelling met een lokaal netwerk
5.1.2
Testprogramma’s
Om de prestaties van het systeem te meten werden een aantal programma’s en combinaties van programma’s gekozen die via het netwerk gestreamd werden. Voor elk van de programma’s werd gemeten wat hun uitvoeringstijd was, of in het geval van GUI-progamma’s de opstarttijd. De gestreamde applicaties bevinden zich hierbij steeds in de subdirectory ass-bin als afkorting voor Application Streaming System-binaries. Dezelfde applicaties bevinden zich ook lokaal in de subdirectory bin en worden gebruikt voor de referentie uitvoering. bash is de Bourne-again shell (v3.2) die op de meeste Linux distributies gebruikt wordt als shell. Het bestaat uit een enkele executable van ongeveer 3 MiB. De gemeten tijd bestaat uit het opstarten en afsluiten van de applicatie met het volgende commando: echo exit | ass-bin/bash lame is een open source MP3 encoder (v3.97). De applicatie bestaat ook uit een enkele executable van ongeveer 450 KiB. De gemeten tijd bestaat uit het encoderen in hoge kwaliteit van een klein audio-bestand met het volgende commando: ass-bin/lame -h sample.wav sample.mp3 javac is de java-compiler uit de Java Development Kit (v1.6.0 01) waarmee een kleine applicatie gecompileerd wordt. Het totale pakket is ongeveer 170 MiB groot maar bevat ook erg veel voorbeelden. Het volgende commando werd uitgevoerd: ass-bin/javac Base64.java jEdit is een uitgebreide editor (v4.2) die in Java is geschreven. Het pakket bevat naast de applicatie ook macro’s en plugin’s en is alles samen ongeveer 15 MiB groot. Dit is een GUI programma en dus werd de opstarttijd gemeten. Het uitgevoerde commando was: bin/java -jar ass-bin/jedit.jar
5.1 Resultaten
74
Totaal
Gestreamd
#Aanvragen
Gem. grootte/pakket
bash
3.270.841 B
737.280 B (22,5%)
180
4096 B
lame
460.416 B
452.224 B (98,2%)
111
4074,1 B
javac
180.602.622 B
3176
4082,7 B
jEdit
15.548.937 B
617
4071,8 B
java
196.151.559 B
4434
4081,0 B
12.966.756 B (7,2%) 2.512.297 B (16,2%) 18.095.353 B (9,2%)
Tabel 5.1: Gestreamde hoeveelheid en gemiddelde pakketgrootte
java in deze test werd de jEdit applicatie nogmaals uitgevoerd maar werden zowel jEdit als de Java Virtual Machine gestreamd. De Java Virtual Machine is deze afkomstig uit de Java Development Kit (v1.6.0 01). Het uitgevoerde commando was: ass-bin/java -jar ass-bin/jedit.jar
5.1.3
Gestreamde hoeveelheid
In de eerste twee kolommen van tabel 5.1 wordt een overzicht gegeven van de totale grootte van de applicaties en de hoeveelheid die daarvan effectief naar de Test Client gestreamd werden tijdens de uitvoering. Tussen haakjes staat ook telkens de procentuele hoeveelheid van de totale applicatie die gestreamd werd. Hieruit blijkt duidelijk dat er wel degelijk winst kan gehaald worden uit het selectief streamen van applicatiedelen. Bij de Java Development Kit is dit uiteraard zo omdat deze gebundeld wordt met een groot aantal voorbeelden. Dit hoeft echter niet altijd zo te zijn. Zo zal het openen van bijvoorbeeld het instellingenscherm in de jEdit-applicatie aanleiding geven tot het streamen van nieuwe delen. Hieruit blijkt dat bij het opstarten van interactieve applicaties, zoals jEdit, alleen delen gestreamd worden die nodig zijn om de applicatie op te starten. Vanaf dan zullen enkel die delen gestreamd worden die door de gebruiker effectief gebruikt worden. De laatste kolom van tabel 5.1 geeft de gemiddelde grootte van een gestreamd datablok (Eng. payload ) weer. Hieruit blijkt dat dit niet steeds 4096 bytes bedraagt. Dit komt omdat het laatste datablok van een bestand zelden volledig gevuld is. In dat geval worden uiteraard enkel maar de resterende bytes verzonden. Datablokken die zich echter niet aan het einde van een bestand bevinden zullen steeds als een volledig blok van 4096 bytes verstuurd worden.
5.1 Resultaten
75
Lokaal
Gestreamd Cache
4 Mbps
384 Kbps
128 Kbps
bash
0,008 s
0,150 s
1,747 s
16,230 s
48,558 s
lame
0,314 s
0,230 s
1,399 s
10,085 s
30,006 s
javac
1,148 s
2,562 s
35,313 s
256,506 s
857,012 s
jEdit
2,428 s
3,325 s
9,424 s
59,601 s
196,651 s
java
2,428 s
6,630 s
51,863 s
401,670 s
1198,909 s
Tabel 5.2: Totale uitvoeringstijd bij verschillende netwerksnelheden
5.1.4
Uitvoeringstijd
In tabel 5.2 wordt een overzicht gegeven van de uitvoeringstijden van de applicaties in een aantal gevallen. De eerste kolom geeft de uitvoeringstijd bij een lokale uitvoering weer. Dit is de uitvoeringstijd wanneer de applicatie uit de normale lokale opslag geladen wordt en het Application Streaming System dus niet gebruikt wordt. Ze worden vermeld als referentiekader voor de andere waarden. In de tweede kolom van tabel 5.2 werden de applicaties reeds eerder gestreamd en gecachet door het systeem zodat tijdens de testuitvoering alle datablokken reeds in de datacache aanwezig waren. Deze waarden liggen allemaal ongeveer in lijn met de uitvoering vanuit de normale opslag. Dat deze waarden altijd net iets hoger liggen moet gezocht worden in het feit dat de cache gebruikmaakt van de lokale opslag om de datacache op te slaan. De datacache is dus als het ware een extra indirectieniveau naar de lokale opslag. Bij de applicatie java is er meer dan een verdubbeling in uitvoeringstijd. Dit kan te wijten zijn aan het feit dat zowel de Java Virtual Machine als de jEdit-applicatie uit de lokale cache gelezen worden waardoor een groter aantal bestanden tegelijk benaderd worden. Waarschijnlijk zal de concurrenti¨ele uitvoering in dit geval nog niet optimaal zijn en dus afremmend werken. De laatste drie kolommen van tabel 5.2 geven dan de uitvoeringstijd weer wanneer de applicatie gestreamd werd via het netwerk. Hieruit valt duidelijk af te leiden dat het uitvoeren van een gestreamde applicatie beduidend meer tijd in beslag neemt. In sectie 5.1.5 zal echter aangetoond worden dat dit voor een groot deel te wijten is aan de beperkte snelheid van de netwerkverbinding. Deze cijfers geven echter wel een goede indruk van hoe de gebruiker de uitvoering van
5.1 Resultaten
76
4 Mbps Latentie
Overhead
384 Kbps Latentie
128 Kbps
Overhead
Latentie
Overhead
bash
9,6 ms
1,4 ms (16,7%)
89,8 ms
4,4 ms (5,2%)
269,5 ms
13,5 ms (5,3%)
lame
9,5 ms
1,3 ms (16,3%)
88,9 ms
4,1 ms (4,8%)
267,5 ms
12,8 ms (5,0%)
javac
10,5 ms
2,3 ms (28,2%)
89,2 ms
4,1 ms (4,8%)
269,5 ms
14,3 ms (5,6%)
jEdit
9,2 ms
1,1 ms (13,3%)
87,4 ms
2,6 ms (3,1%)
265,2 ms
10,7 ms (4,2%)
java
10,0 ms
1,9 ms (23,0%)
89,1 ms
4,1 ms (4,8%)
268,3 ms
13,3 ms (5,2%)
gem.
9,8 ms
1,6 ms (19,5%)
88,9 ms
3,9 ms (4,5%)
268,0 ms
12,9 ms (5,1%)
Tabel 5.3: Gemiddelde latentie bij verschillende netwerksnelheden
de applicatie zal ervaren. Het opstarten van de applicatie java neemt bij een netwerksnelheid van 128 Kbps immers bijna 20 minuten in beslag, wat niet erg prettig werken is voor een gebruiker. Daarom zal het streamen bij lage snelheden enkel aangenaam zijn met redelijk kleine applicaties. Bij hogere snelheden van 4 Mbps is het opstarten van diezelfde applicatie in 51 s nog steeds aanvaardbaar te noemen voor een gebruiker.
5.1.5
Latentie
In tabel 5.3 wordt een overzicht gegeven van de gemiddelde latentie die ondervonden wordt bij het opvragen van een datablok via het netwerk. Deze latentie is gedefini¨eerd als de tijd die verloopt tussen het moment waarop vastgesteld wordt dat een datablok niet aanwezig is in de datacache tot het moment dat het datablok beschikbaar gesteld wordt in de client. Deze waarden worden weergegeven in de kolom “latentie” bij elke netwerksnelheid. De kolom “overhead” geeft het deel van de latentie weer die het gevolg is van het niet ideaal verzenden van de datablokken. Deze overhead zou de tijd kunnen bedragen om een antwoord te verwerken door de client wanneer de datablokken aansluitend op elkaar verstuurd zouden worden door de server (cf. streamen van audio en video). Het is deze overhead die verder verminderd kan worden door optimalisaties als asynchrone aanvragen (zie sectie 3.2.3) en proactief streamen (zie sectie 5.2.2). Tussen haakjes wordt deze overhead weergegeven als percentage van de ideale verzendings-
5.2 Verder onderzoek
77
tijd1 . Bij de hoge netwerksnelheid van 4 Mbps is deze overhead gemiddeld 20% van de ideale verzendingstijd terwijl bij de lagere netwerksnelheden die in beide gevallen rond de 5% ligt. Dit kan erop wijzen dat bij de hogere snelheden de verwerking op de client en server de bepalende factor wordt in deze overhead terwijl bij de lagere snelheden de overhead vooral het gevolg is van het versturen van de aanvraag van de client naar de server. In beide gevallen heeft de client er alle belang bij om de verzending van de juiste datablokken op de server zo snel mogelijk te laten beginnen zodat de datablokken aaneensluitend verzonden kunnen worden.
5.2
Verder onderzoek
Het systeem dat ontwikkeld werd in deze thesis is een prototype systeem. In deze sectie zullen dan ook een aantal uitbreidingen besproken worden die het onderwerp kunnen zijn van toekomstig werk aan het systeem.
5.2.1
Gespecialiseerd cachebeheer
Een observatie bij gebruikelijke keuzestrategie¨en (LRU, PseudoLRU, ...) voor de datacache is dat een applicatie die op zichzelf groter is dan de grootte van de datacache, bij een eenmalige uitvoering de hele huidige inhoud van de datacache kan verwijderen. Dit is echter vaak ongewenst omdat deze data afkomstig kunnen zijn van applicaties die frequent gebruikt worden door de gebruiker. Na het eenmalig uitvoeren van deze grote applicatie, moeten deze frequent gebruikte applicaties dan ook weer opnieuw gestreamd worden. Een oplossing hiervoor kan er in bestaan om een datacache uit twee delen te gebruiken. Een eerste tijdelijke cache waarin de data die voor het eerst gestreamd worden, in ondergebracht worden. Een tweede grotere frequente cache wordt dan gebruikt om er de data uit de eerste cache naar toe te verhuizen wanneer blijkt dat deze data frequent gebruikt worden. Een gelijkaardig systeem werd beschreven door Mekhiel [Mek95]. Een eerste probleem hierbij is hoe “frequent” gedefini¨eerd moet worden. Dit bepaalt immers wanneer de data vanuit de tijdelijke cache naar de frequente cache mag verhuizen en moet dus zorgvuldig gekozen worden zodat niet onnodig vaak data uit de frequente cache verwijderd worden. 1
Dit is de theoretisch minimale tijd om de data van de server naar de client te sturen. Dit is dus gelijk aan de
datagrootte / netwerksnelheid
5.2 Verder onderzoek
78
Een ander probleem bij deze tweedelige cache is dat een frequent gebruikte applicatie die groter is dan de tijdelijke cache, nooit in de frequente cache zal komen omdat het frequent gebruik van de applicatie niet herkend kan worden. Hierin kan een streamingserver met gebruikersprofielen (zie sectie 5.2.3) misschien een rol spelen door dit in de plaats van de streamingclient te herkennen en deze informatie dan door te spelen naar de client. Een meer gespecialiseerde cachestrategie die afgestemd is op het streamen van applicaties kan een grote impact hebben op de prestaties van het systeem. Een grondig onderzoek van de mogelijkheden, ook buiten de klassieke cachestrategie¨en, kan een grote bijdrage leveren tot een effici¨enter systeem met een verbeterde gebruikerservaring.
5.2.2
Proactief streamen van applicaties
In het huidige ontwerp van het systeem is het zo dat elke aanvraag voor data bij de streamingserver door de streamingclient, beantwoord wordt met precies ´e´en datablok. Dit kan verbeterd worden daar er in vele gevallen een relatie zal bestaan met de daaropvolgende aanvragen. Een eenvoudig voorbeeld is het openen van een lees-mij-bestand door de gebruiker. Wanneer het eerste deel van het bestand opgevraagd wordt bij de streamingserver, dan mag de server zich in de nabije toekomst ook verwachten aan het opvragen van de andere delen van het bestand door dezelfde client. In dit geval moet de streamingserver deze aanvragen dan ook niet afwachten en kunnen de volgende datablokken reeds op eigen initiatief, dus niet als reactie op een directe aanvraag van de client, doorgestuurd worden naar de client. Op deze manier kan de latentie die de gebruiker ondervindt door het streamen van de data, verminderd worden doordat het volgende deel reeds verstuurd wordt wanneer het vorige nog in verwerking is op de client. Wanneer het volgende deel dan opgevraagd wordt zal dit reeds verstuurd zijn door de server of in het beste geval ook al aangekomen zijn op de client. Hetzelfde principe kan nu ook toegepast worden voor applicaties. Alleen worden de datablokken van een applicatie zelden in een sequenti¨ele volgorde uitgevoerd en dus ook zelden sequentieel opgevraagd bij de streamingserver. Ook hier bestaan er echter verbanden tussen de datablokken, namelijk de functieoproepen naar functies in een ander datablok. Vermits elk datablok een eindig aantal instructies bevat, kunnen er ook maar een eindig aantal oproepen naar functies in andere datablokken2 voorkomen. Als gevolg daarvan is er voor elk opgevraagd datablok van een 2
Dit is niet helemaal correct daar er ook pointers naar functies bestaan die van waarde kunnen veranderen.
5.2 Verder onderzoek
79
Blok 2
Blok 1
... int funcA(int x) { if(x > 0) funcB(x); else funcC(x); } ...
0.7
... int funcB(int x) { funcD(x + 1); } ...
1.0
Blok 3
0.3
... int funcC(int x) { funcD(x - 1); } ...
1.0
Blok 4
... int funcD(int x) { print(x); } ...
Figuur 5.2: Een voorbeeld blokgraaf voor gebruik door een streamingvoorspeller
applicatie maar een beperkt aantal mogelijkheden voor de datablokken die als eerstvolgende3 opgevraagd zullen worden. Door de streamingserver de opeenvolgende aanvragen voor eenzelfde applicatiebestand, uitgevoerd door eenzelfde client, te laten analyseren, kan een gerichte graaf opgebouwd worden. Deze graaf zal voor elk datablok uit het applicatiebestand weergeven welke datablokken een client mogelijks als volgende zal opvragen. Een voorbeeld hiervan wordt weergegeven in figuur 5.2. Door aan de bogen telkens gewichten toe te kennen, die bij elke aanvraag door een client worden aangepast, kan de streamingserver een voorspelling maken over welke blokken de meeste kans hebben om als volgende opgevraagd te worden door de client. Deze datablokken worden meteen naar de client doorgezonden. Zo zal in figuur 5.2 het opvragen van datablok 1 door een client aanleiding kunnen geven tot het versturen van datablokken 1, 2 en 4 door de streamingserver. Blok 2 heeft immers 70% kans om als eerstvolgende datablok opgevraagd te worden en blok 4 zal daarna met een kans van 100% opgevraagd worden door de client.
5.2.3
Gebruikersprofielen toevoegen
Het systeem zoals het in deze thesis gepresenteerd werd, maakt enkel gebruik van gebruikersaccounts voor het controleren van de toegang tot een applicatiecollectie. Dit is gelijkaardig aan de toegangscontrole voor bijvoorbeeld een FTP-server. Dezen zullen echter evenzeer aanleiding geven tot het opvragen van een datablok en doen dus geen afbreuk aan de algemeenheid. 3 Binnen hetzelfde applicatiebestand. Ondertussen kunnen door dezelfde client natuurlijk ook datablokken uit andere bestanden opgevraagd worden.
5.2 Verder onderzoek
80
Een uitbreiding hierop zou kunnen zijn dat de streamingserver voor elke gebruiker een profiel opstelt en bewaart. Op deze manier zou de server op een meer gepersonaliseerde manier kunnen bijdragen in het beheer van de client zodat de resource-beperkte client hiervan zoveel mogelijk ontheven wordt. Ook bij het proactief streamen van applicaties kan dit een hulp zijn door per gebruiker een afzonderlijke graaf op te stellen van de achtereenvolgens gestreamde blokken. Zo kan voor elke gebruiker een ge¨ındividualiseerde voorspelling gemaakt worden die accurater zal zijn dan bij een algemene voorspelling. Hierdoor zullen dan ook minder foutief voorspelde datablokken verzonden worden wat zich vertaalt in een verminderd gebruik van resources.
5.2.4
Gebruiksmodel opstellen
De architectuur van het systeem voor het streamen van applicaties dat in deze thesis ontwikkeld werd is zeer algemeen. Het houdt in principe nog alle mogelijkheden open voor een meer gespecialiseerd gebruiksmodel. Om de vereisten van het systeem verder uit te werken zal dan ook eerst een meer specifiek gebruiksmodel moeten opgesteld worden. Hieronder worden enkele mogelijkheden opgesomd. Eenvoudig client-server model: dit is het meest eenvoudige model dat reeds voor een groot deel beschikbaar is in het huidige systeem. Het principe is vrij gelijkaardig aan dat van een FTP-server: de client maakt een verbinding met de server, de client doet zijn aanvraag bij de server en de server antwoordt met wat de client gevraagd heeft. Het gebruik van een applicatie is hierbij anoniem op de eventuele toegangscontrole na. Er worden geen gebruikersprofielen opgesteld en de server biedt maar in beperkte mate ondersteuning aan de client. Abonnementsdienst: gebruikers kunnen zich, eventueel tegen betaling, inschrijven op de volledige applicatiecollectie, een geselecteerd deel van de applicatiecollectie of een individuele applicatie. Dit kan eventueel gepaard gaan met het opstellen van een gebruikersprofiel voor de applicaties. Vereenvoudigde ondersteuning van een doelgroep: het systeem is er op gericht om een groep van gebruikers op een snelle en effici¨ente manier te ondersteunen in hun activiteiten. Het doel hierbij is om de administratie van de toestellen te vereenvoudigen en om de gebruikers in de doelgroep sneller toegang te geven tot nieuwe applicaties alsook om meer applicaties ter beschikking te stellen.
Hoofdstuk 6
Conclusie In deze thesis werd een specificatie opgesteld en een architectuur ontworpen voor een systeem dat applicaties kan streamen naar resource-beperkte toestellen. Het systeem is transparant voor zowel de eindgebruiker als de applicatieontwikkelaar, is eenvoudig in gebruik, houdt rekening met de beperkingen van resource-beperkte toestellen en biedt theoretisch een oneindig grote hoeveelheid applicaties aan, die continu beschikbaar blijven voor de gebruiker.
Het systeem is transparant voor de eindgebruiker:
applicaties die gestreamd worden
via het systeem kunnen door de gebruiker niet onderscheiden worden van normale applicaties. De gestreamde applicaties verschijnen dan ook als normale applicaties op het systeem van de gebruiker en voor het opstarten van een gestreamde applicatie moet er geen speciale handeling uitgevoerd worden.
Het systeem is transparant voor de applicatieontwikkelaar:
een applicatieontwikkelaar
die zijn applicatie wil aanbieden via het systeem moet hiermee tijdens de ontwikkeling van zijn applicatie geen rekening houden. Het systeem is bovendien ook zo ontworpen dat elke applicatie gelijk behandeld wordt en even effici¨ent gestreamd kan worden als alle anderen, ongeacht de ontwerpbeslissingen van de gestreamde applicatie.
Het systeem is eenvoudig in gebruik:
om applicaties te kunnen streamen moet de ge-
bruiker enkel beschikken over een streamingclient en een URI die de applicatiecollectie identificeert. Nadat de gebruiker de applicatiecollectie heeft toegevoegd aan zijn configuratie, kan
81
CONCLUSIE
82
hij de applicaties in de collectie activeren. Elke applicatie is na activatie binnen ongeveer een seconde beschikbaar op zijn systeem. De applicatie kan dan opgestart worden en zal automatisch gestreamd worden tijdens de uitvoering. De gebruiker hoeft dus nooit te wachten tot een volledige applicatie gedownload werd naar zijn toestel waardoor hij de applicatie sneller kan opstarten en gebruiken.
Het systeem houdt rekening met resource-beperkte toestellen:
het systeem is er op
gericht om een aantal begrenzingen van resource-beperkte toestellen op te heffen. Zo zal de plaats die de applicaties innemen in de lokale opslag, beheerd worden door het systeem zodat de applicaties nooit alle plaats innemen. Ook het netwerk transfervolume kan, afhankelijk van het gebruiksprofiel van de geactiveerde applicaties, lager liggen doordat enkel de effectief gebruikte delen van een applicatie naar het toestel van de gebruiker gestreamd worden. Anderzijds werd ook tijdens het maken van ontwerpbeslissingen voor het systeem rekening gehouden met resource-beperkte toestellen. Zo werd voor de bestandsvirtualisatie een techniek gekozen die een acceptabele hoeveelheid resource gebruikt op een resource-beperkt toestel.
De gebruiker kan gebruikmaken van een oneindig grote hoeveelheid applicaties: de gebruiker kan tegelijk gebruikmaken van verscheidene applicatiecollecties waaruit hij zoveel applicaties kan activeren als hij wenst. Eens een applicatie geactiveerd is, blijft deze steeds beschikbaar voor de gebruiker. Dit is onafhankelijk van de beschikbare lokale opslag van het toestel. Het systeem zal automatisch applicaties opslaan in de lokale opslag of ze er uit verwijderen, gebaseerd op de applicaties die door de gebruiker gebruikt worden. Zo zal de gebruiker dus nooit een applicatie van zijn toestel moeten verwijderen uit plaatsgebrek waardoor de applicatie ook niet langer beschikbaar is. Uit de testresultaten bleek dat het streamen van applicaties tijdens hun uitvoering een grote impact kan hebben op hun uitvoeringstijd. Dit was echter voor het grootste deel te wijten aan de lagere bandbreedte van de netwerkverbinding in verhouding met de lokale opslag. Uit de testresultaten bleek dat er grote besparingen op zowel gebruikte lokale opslag en gebruikt netwerkvolume kunnen bekomen worden door applicaties te streamen. De testen werden uitgevoerd met onaangepaste versies van onder andere de Bourne-Again Shell en de Sun Java-compiler.
Bibliografie [app]
AppStream. http://www.appstream.com/.
[BCK03]
Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, second edition, 2003.
[Coc97]
Alistair Cockburn. Structuring Use Cases with Goals. Journal of Object-Oriented Programming, Sep-Oct and Nov-Dec 1997.
[EA]
Mohamed
El-Attar.
Examples
of
Use
Case
Modeling
Antipatterns.
http://www.steam.ualberta.ca/. [FC]
Keir Fraser and Fay Chang. Operating System I/O Speculation: How two invocations are faster than one.
[Fir]
Donald G. Firesmith. Use Cases: the Pros and Cons. http://www.ksc.com/.
[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [Int98]
Intel Corporation. Embedded Pentiumr Processor Family: Developers Manual, December 1998.
[JT05]
Michael K. Johnson and Erik W. Troan. Linux Application Development. AddisonWesley, second edition, 2005.
[Kru95]
Philippe Kruchten. Architectural Blueprints: The “4+1” View Model of Software Architecture. IEEE Software, 12(6):42–50, November 1995.
[Leo]
Thomas Leonard. The Zero Install system. http://zero-install.sourceforge.net/.
83
BIBLIOGRAFIE
[Mek95]
84
Nagi N. Mekhiel. Multi-Level Cache With Most Frequently Used Policy: A New Concept in Cache Design. In International Conference on Computer Applications in Industry and Engineering, November 1995.
[MH06]
Russ Miles and Kim Hamilton. Learning UML 2.0. O’Reilly Media, Inc., Sebastopol, CA, USA, 2006.
[Rus96]
David A. Rusling. The Linux Kernel, 1996.
[Sew06]
Julian Seward. Valgrind Technical Documentation, 2006.
[Tan01]
Andrew S. Tanenbaum. Modern Operating Systems. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, second edition, 2001.
[THB06]
Andrew S. Tanenbaum, Jorrit N. Herder, and Herbert Bos. File size distribution on unix systems: then and now. SIGOPS Oper. Syst. Rev., 40(1):100–104, 2006.
Lijst van figuren 2.1
Streamen van applicaties tussen servers en clients . . . . . . . . . . . . . . . . . .
16
2.2
Use case diagram voor het Application Streaming System . . . . . . . . . . . . .
20
3.1
Het “4+1” view model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.2
Globaal informeel overzicht van de Application Streaming System architectuur .
35
3.3
Client-server patroon toegepast op het Application Streaming System . . . . . .
36
3.4
Proces en fysiek perspectief van het Application Streaming System . . . . . . . .
38
3.5
Decompositie in het ontwikkel perspectief van het StreamingClient subsysteem .
39
3.6
Gelaagde opbouw van de CachingFilesystem module . . . . . . . . . . . . . . . .
41
3.7
Activity diagram voor het lezen van data uit het CachingFilesystem . . . . . . .
42
3.8
Sequentiediagram voor een asynchrone aanvraag bij een StreamingServer . . . . .
46
3.9
Decompositie in het ontwikkel perspectief van het StreamingServer subsysteem .
49
3.10 Sequentiediagram voor de verwerking van een aanvraag op de StreamingServer .
49
4.1
Datablok allocatie bij bestanden . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.2
Structureel verschil tussen een FAT en een inode . . . . . . . . . . . . . . . . . .
60
4.3
Boomstructuur van een PseudoLRU cache met acht datablokken . . . . . . . . .
65
5.1
Testopstelling met een lokaal netwerk
. . . . . . . . . . . . . . . . . . . . . . . .
73
5.2
Een voorbeeld blokgraaf voor gebruik door een streamingvoorspeller . . . . . . .
79
85
Lijst van tabellen 2.1
Overzicht van de uitgewerkte use cases voor het Application Streaming System .
4.1
Dynamische bestandsgrootte (in bytes) voor lees- en schrijfbewerkingen per deciel 68
5.1
Gestreamde hoeveelheid en gemiddelde pakketgrootte . . . . . . . . . . . . . . .
74
5.2
Totale uitvoeringstijd bij verschillende netwerksnelheden . . . . . . . . . . . . . .
75
5.3
Gemiddelde latentie bij verschillende netwerksnelheden . . . . . . . . . . . . . . .
76
86
20
Lijst van algoritmes 4.1 4.2
UseBlock(cache index) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FindBlock() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
66 66
