Streamen van applicaties naar resource-beperkte toestellen

Transcriptie

1 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

2 Toelating tot bruikleen De auteur geeft de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en delen van het afstudeerwerk te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit dit afstudeerwerk. Dieter GOVAERTS, 4 juni 2007

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

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

5 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

6 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. INTRODUCTION MANY 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. APPLICATION 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. DESIGN 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 III- C) 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

7 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. ARCHITECTURE Figure 1 shows a general overview of the Application Streaming System. Streamed Applications Operating System Kernel Page Loader Global Filesystem Caching Filesystem Normal Filesystem Application Manager Streaming Client User Client Server Collection Manager Streaming Server Application Storage Administrator Fig. 1. General overview of the Application Streaming System. Grey blocks belong to the described system. 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 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. TEST 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. CONCLUSION 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.

8 Inhoudsopgave 1 Inleiding Probleemschets Doelstellingen Centrale vragen van deze thesis Hoe kan een systeem voor het streamen van applicaties gebouwd worden? Wat zijn de praktische problemen bij het streamen van applicaties? Is het praktisch haalbaar om applicaties te streamen? Bijkomende vragen Software over een netwerk Remote execution Local delivery Verwant werk Het Zero Install systeem AppStream Overzicht van deze thesis Specificatie Informele beschrijving Vereisten Use cases Architectuur Het Application Streaming System Het globale systeem Het StreamingClient subsysteem vii

9 INHOUDSOPGAVE viii Het StreamingServer subsysteem Het StreamingClient subsysteem De module CachingFilesystem De module Locator De module ClApplicationStreamer De module ApplicationManager De module UI Het StreamingServer subsysteem De module SvApplicationStreamer De module Storage De module CollectionManager De module UserManager De module UI Ontwerpkeuzes Virtualisatie van bestanden Speciale streamingbibliotheek Virtuele machine Virtueel bestandssysteem Bestandsbeheer in het virtuele bestandssysteem Beheer van de bestandsinhoud Beheer van de directorystructuur Beheer van de datacache Keuzestrategieën Updatestrategieën Granulariteit van streamen Streamen per applicatie Streamen per bestand Streamen per vast blok Streamen per variabel blok

10 INHOUDSOPGAVE ix 5 Resultaten en verder onderzoek Resultaten Testopstelling Testprogramma s Gestreamde hoeveelheid Uitvoeringstijd Latentie Verder onderzoek Gespecialiseerd cachebeheer Proactief streamen van applicaties Gebruikersprofielen toevoegen Gebruiksmodel opstellen Conclusie 81

11 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

12 LIJST VAN AFKORTINGEN xi 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

13 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ële 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

14 1.1 Probleemschets 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ëren 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.

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

16 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:

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

18 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ënt 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 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.

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

20 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 één 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 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ënter 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 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.

21 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óór 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 Remote execution Bij remote execution wordt de applicatie geladen en uitgevoerd op een server en wordt enkel de presentatielaag geëxporteerd 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.

22 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-standaard 3 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ëren 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ëxporteerd 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 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 tegen- 3 Met de CGI-standaard kan er informatie van de client naar de server gezonden worden, ingebed in de HTTPaanvraag of gecodeerd in de URL van de webpagina.

23 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üpdatet 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 één 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

24 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óór 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 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.

25 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 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 één enkele bron.