Information Systems and Computer Engineering

Transcription

1 FileCloud Cloud Filesystem based Processing Offloading Tiago Amaral Almeida Lima Thesis to obtain the Master of Science Degree in Information Systems and Computer Engineering Examination Committee Chairperson: Supervisor: Member of the Committee: Professor José Carlos Alves Pereira Monteiro Professor João Nuno de Oliveira e Silva Professor Renato Jorge Caleira Nunes October 2013

2

3 Agradecimentos Tenho muito a agradecer a várias pessoas pela ajuda prestada e disponibilidade durante a realização desta dissertação, especialmente: Ao meu orientador João Nuno de Oliveira e Silva, pela oportunidade e confiança dada para a realização deste projeto. Por todos os esclarecimentos durante todas as fases do projeto, e pela disponibilidade para ler e comentar o meu trabalho, permitindo-me obter um melhor resultado final. Um obrigado muito especial aos meus pais, Jorge Lima e Ana Almeida, por todo o incentivo, paciência, e especialmente, pelo grande esforço financeiro que fizeram durante a minha vida académica. Ao meu irmão, Pedro Lima, por todo o incentivo dado. À minha namorada, Carolina Gomes, pelo apoio e carinho dado durante esta fase. Ao INESC-ID, por me ter fornecido todas as condições de trabalho necessárias para a realização deste projeto. Aos meus colegas pela partilha de conhecimentos e pelas críticas construtivas. Um agradecimento especial ao Hugo Pimentel e ao André Ribeiro, pela disponibilidade para me ajudarem durante a fase de testes. i

4 ii

5 Resumo Hoje em dia, os dispositivos móveis, como smartphones ou tablets, têm a capacidade de estarem conectados à Internet, onde quer que estejam, com velocidades razoáveis. Portanto, os utilizadores conseguem aceder aos serviços na cloud sempre que quiserem. Para além disso, os dispositivos móveis estão a tornar-se muito poderosos, pelo que os utilizadores atualmente conseguem realizar tarefas tão exigentes, que há poucos anos, apenas computadores pessoais conseguiam desempenhar. Apesar das baterias e dos ecrãs estarem a evoluir, a capacidade da bateria e o tamanho do ecrã continuam a ser um fator de limitação, para que o utilizador consiga usar estes dispositivos com eficiência. O offload do processamento é uma solução viável para ultrapassar estas limitações, melhorando assim tanto a eficiência do consumo de energia, como a experiência de utilizador. O FileCloud une os dispositivos móveis com computadores não usados na vizinhança, permitindo o processamento de ficheiros no dispositivo com melhores características. Estes ficheiros podem ser armazenados num sistema de ficheiros baseado na cloud, estando disponíveis para ambos os dispositivos, ou podem ser transferidos diretamente do dispositivo móvel para o computador. O FileCloud reduz os problemas de usabilidade, porque os ficheiros podem ser acedidos no computador, reduzindo o consumo de energia no dispositivo móveis, já que este entra no estado inativo. O FileCloud é completamente transparente para o utilizador (no que diz respeito à descoberta e seleção dos recursos disponíveis, e execução da aplicação), permite um consumo de energia mais eficiente na maioria das tarefas e reduz o tempo despendido pelo utilizador. Palavras-chave: Cloud, Offload de computação, Economia de energia, Poder de computação, Dispositivos móveis iii

6 iv

7 Abstract Nowadays, mobile devices, such as smartphones or tablets, have the ability to be connected to the Internet anywhere and anytime with very reasonable speeds. With this feature, users can access the cloud services wherever they are, whenever they want. Furthermore, mobile devices are also becoming very powerful, so that users start doing there demanding tasks, that some years ago only desktop or laptop computers could perform. Although battery and display technologies are improving, battery capacity and display size are still limiting factors for the user to use mobile devices efficiently. Processing offloading (in order to user remote, but nearby desktop computers) is a viable solution to overcome battery and display limitations, increasing energy efficiency and usability. FileCloud unifies mobile devices with nearby idle desktop computers in the neighborhood, allowing the processing of files on the device with better characteristics. These files can be stored in a Cloud based FileSystem, thus being available to both devices, on can be transferred directly from the mobile device to the desktop computers. With FileCloud, usability issues are reduced since files can be accessed on desktop computers, thus the energy consumption is reduced on the mobile devices since they become idle after the offload of the task. FileCloud is completely transparent to the user (w.r.t. the discovery and selection of the best host and application to be launched), allows gains in the energy consumption on most tasks (e.g. video visualization) and reduces the time spent by the user (in task such as image editing). Keywords: Cloud, Offload Computing, Energy Saving, Computing power, Mobile devices v

8 vi

9 Contents Agradecimentos i Resumo iii Abstract v List of Tables ix List of Figures xii 1 Introduction Motivation Objectives Dissertation outline Related Work Cyber foraging SPADE CloneCloud Jupiter Cuckoo Framework Virtual Network Computing Media Centers Distributed User Interfaces Resource Discovery Current solutions limitations Target Environment Operating System Android SDK Other Android programming tools Cloud services Cloud-based File System Connectivity Wi-Fi Bluetooth vii

10 3.4.3 Mobile Cellular Systems FileCloud Architecture Client Architecture Server Architecture Execution Flow Resource Discovery Phase Offloading Task Phase Implementation Installation and configuration File System Task Manager FileGetter Resource Discovery Offloader Request Listener Application Management User Interaction Client UI Server UI Interoperability Mono on Xubuntu Evaluation Video Visualization Image Editing Invert colors Crop Writing Overheads Discussion Conclusions Future Work Bibliography 51 viii

11 List of Tables 5.1 Hardware specifications Properties of the video samples Video visualization tests overview Results of Invert colors test Overhead times ix

12 x

13 List of Figures 2.1 CloneCloud system model Cuckoo Framework VNC architecture HTPC architecture UPnP protocols stack STARC architecture Mobile Operating System market share Android architecture Wi-Fi usage example Bluetooth usage example G usage example FileCloud usage overview Architecture overview Client architecture Server architecture Execution Flow Execution flow of the resource discovery phase Execution flow of the offloading task phase FileGetter mapping File mapping Information sent on Resource Discovery s LAN Broadcast Information sent to start the task Application found and launched for the image file selected Launching Google Docs editors Client File Explorer Client action selector FileCloud Server UI FileCloud usage example User Credentials UI xi

14 5.1 Video visualization results Invert colors test Invert colors test results Crop test Crop test results Writing test results Future work on Resource Discovery module: PC s location xii

15 Chapter 1 Introduction 1.1 Motivation Nowadays, mobile devices, like smartphones and tablets, have the ability of being connected to the Internet anywhere and anytime with very reasonable speeds by using LTE or 3G network, or even by Wi-Fi connection. With this, either the users can access the cloud services whenever they want. This is useful because, in some way, cloud resources can be used to reduce hardware limitations of mobile devices [1]. Over the past few years, several cloud services were developed for many different purposes. Storage cloud services are those more used by regular users, for example, Dropbox 1 or Google Drive 2. With these services the users can store their files in the cloud and access them anywhere, every time they are connected to the Internet. Mobile devices are also becoming very powerful. So powerful that they can perform some demanding tasks that some years ago only desktop or laptop computers could do, for example, video visualization or word processing. But running these tasks introduces some problems to the user. The battery technology has improved over the past years, but processors power has also increased and due to this, the battery continues to drain fast [13]. To address this problem, many systems implemented the concept of Computation Offloading. This concept consists in assigning part, or even all of the workload onto devices in the neighborhood or in the cloud, freeing the device of this work and saving battery power. But there is one specific problem that has never been addressed by these kinds of systems: how to take advantage of nearby idle computers to complement and augment mobile devices. It would be very useful for the users to take advantage of desktop applications, which provides a much richer user experience. For example, currently, the applications available for video or word document editing aren t even comparable to the desktop ones. They lack many features that the user may want to use. Nowadays, users working on a smart-phone or tablet can t, in an easy and straightforward manner, take advantage of nearby computers to execute tasks that are slow or cumbersome to execute on the mobile device (such as image edition of word processing: user must to walk to his desktop computer or 1 Dropbox, 2 Google Drive, 1

16 laptop, search again for the file and open the appropriate application. All this process is a burden for the user. 1.2 Objectives This document presents FileCloud, a system that unifies the following resources: mobile devices, cloud storage and nearby desktop PCs. With FileCloud the user can take advantage of idle desktop computer to execute some actions that are not suited to run on a mobile device. Also, the better processor on the desktop computer helps a lot doing these tasks, because the majority of the mobile devices still have very weak processors, and lack a large display and keyboard. With FileCloud, the user opens a file on the mobile device, but transparently FileCloud searches for a suitable device to open this file, and transfers the processing (or visualization) to such computer. When the user reaches the computer the application was already launched and ready for the user to do what they want. FileCloud also allows the user to take advantage of the better user interface of the desktop application, and at the same time take advantage of a bigger display. FileCloud implements a client-server architecture: a client installed on a mobile device and servers on a neighbor desktop computers. On the client after the user selects a file, stored in the cloud, FileCloud scans the neighborhood for available computers and communicates, in order to know their specifications, together with the actions that can be made for that file type, depending on the installed applications. When the action is selected the client sends the information needed for the server installed in the desktop computer. Then the appropriate application is selected automatically and launched for the user. In sections 4.1 and 4.2 the architecture and execution flow are explained in more detail. 1.3 Dissertation outline Chapter 2 addresses the current state of the art, describing some systems currently available related to FileCloud. On Chapter 3 is described the technologies studied to use on FileCloud. Then, Chapter 4 describes FileCloud in more detail. It presents the architecture, execution flow and its implementation. On Chapter 5 the evaluation results are presented and discussed. Finally, on Chapter 6 the conclusions are presented, together with the achievements of this project and some ideas for the future work. 2

17 Chapter 2 Related Work In this section is described some system that are related to FileCloud. The systems and architectures here described fall in one of the following categories: Processing Offloading, Mobile Cloud, User Interface (UI) mobility and Home Entertainment Systems. Although the systems try to solve the same problem as FileCloud, none of them use the existing Cloud file systems as a data communication to layer and use neighbor computer to provide a better user experience on a mobile environment. 2.1 Cyber foraging Cyber foraging [1] [20] [7] is a mechanism to augment the computational and storage capabilities of mobile devices. It uses discovered servers in the environment to improve the performance of applications and distributed file systems on mobile clients. Cyber foraging solves the problem of making mobile devices smaller, lighter and long-running without compromises their computing capabilities. This is because the user has an ever-growing expectation that requires computing and data storage ability beyond that of a tiny mobile computer with a small battery. The idea is to dynamically augment the computing resources of a wireless mobile computer by exploiting nearby compute and data staging servers. In [1], it was believed that in the future public spaces such as airport lounges or coffee shops will be equipped with compute and data staging servers [5] connected to the wired Internet through highbandwidth networks. When hardware in the wired infrastructure plays this role, it is called a surrogate of the mobile computer it is temporarily assisting. These surrogates are untrusted and unmanaged, so it is the responsibility of the mobile clients to establish adequate trust in the surrogates they choose to use. The following challenges must be overcome in order to utilize the idea of cyber foraging: Developing mechanisms whereby a potential surrogate can make some of its resources available to resource-constrained clients. Providing a means for surrogates to advertise their availability and clients to locate surrogates with appropriate available resources. 3

18 Developing a mechanism whereby clients can transfer tasks to the surrogate. Making the remote execution of surrogate tasks be (largely) transparent and easy to program. Developing security and trust mechanisms so that surrogates can be assured that they (and their neighbors) will not be abused by surrogate computations. In [7], some work has been done in order for the user to have secure cyber foraging infrastructures without requiring a heavyweight middleware system. The goal was to support cyber foraging on a conventional platform, without a large middleware layer, and demonstrate its use on real applications and systems. In order to achieve this goal, it was built a surrogate framework on top of widely available technology. It is used machine virtualization technology, such as VServer 1 and Xen [2], to provide basic isolation. As the foundation of the security and authentication infrastructure, it uses publicly available encryption technologies, both public and private key. To locate potential surrogates, it was used a lightweight discovery protocol. This work demonstrated the basic value of cyber foraging and shown how it can be used to enable interesting applications on small (potentially embedded) devices, but many challenges must still be overcome before this long term vision will come to fruition. In eyedentify [11], Ibis, which is a Java based high performance distributed middleware [26], is explored for cyber foraging on mobile devices. It was used the Ibis Distributed Deployment to deploy the heavy weight computations onto surrogates and the Ibis High-Performance Programming System to efficiently communicate with them. In order to evaluate Ibis, it was developed eyedentify, a smartphone application, which can perform object recognition using the phone s camera sensor. Two versions of eyedentify were developed: a standalone version that runs on the phone itself and a distributed version that uses Ibis cyber foraging to offload computation. The Ibis cyber foraging improved the responsiveness of the application, with speedups of around 60 times, while the energy efficiency was about 40 times better. The following systems implement cyber foraging in multiple ways. These systems allow, for example, the offloading of the computation of tasks to remote computers, but the user can t take advantage of all the resources available on those computers. FileCloud aims to offload the computation to computers in the neighborhood, so the user can use all the resources available. 2.2 SPADE SPADE [23] is a scheduler for parallel and distributed execution. SPADE can accelerate the manipulation of a batch of files using idle remote computer through jobs. These jobs that run on remote computers are composed of simpler tasks. Using a simple user interface, a user with minimum computer knowledge can define the jobs, what is usable and how they can possibly be divided. Then SPADE transparently selects a computer on the 1 Linux VServer project, 4

19 LAN and automatically uploads the files to the remote computer, executes the application defined by the user and downloads the resulting files back to the mobile device. With quick tasks SPADE should not be used because the time being spent on sending the files and the jobs to the remote computer do not compensate. Therefore, SPADE is more useful if a user wants to perform lengthy tasks, such as repetitive data analysis of batches of files. Furthermore, to be accelerated, they have to be partitioned in a natural way, for example, batch image processing or statistical analysis of different data sets where each task processes a different input. Another example is to generate a movie with POV-Ray 2, where each task has a numerical argument ranging from 0 to N, being this number the frame being generated by that task. FileCloud aims to be completely transparent to the user, i.e., the user only selects the proper file and the desired action and the system automatically stars the appropriate desktop application in the remote computer. So, SPADE does not solve our problem because it only uses the remote computer to process batches of files, not allowing the user to take advantage of the bigger screen and of the desktop applications to have a more complete environment for editing the files. SPADE also does not take advantages of the cloud storage. Every time the user wants to process a file, this file has to be sent to the remote computer and back to the mobile device. Furthermore, SPADE requires that the user have to define the application to run and the arguments. 2.3 CloneCloud CloneCloud [3] is a system that automatically transforms mobile applications to benefit from the cloud, by optimizing the execution time and the energy used in the mobile device. The system solves problems such as bringing a demanding mobile application to needed cloud resources. It tends to be inflexible since an application is either written as a monolithic process, cramming all it needs to do on to the mobile device, or it is split in the traditional client-server paradigm, pushing most computation to the remote server, or it is perhaps tailored to match an expected combination of client, environment and service. But what might be the right split for a low-end mobile device with good connectivity may be the wrong split for a high-end mobile device with intermittent connectivity. As Figure 2.1 shows, CloneCloud transforms a single-machine application into a distributed one, by rewriting an unmodified application executable. While the modified executable is running, at automatically chosen points individual threads migrate from the mobile device to a device clone in a cloud. The remaining functionality on the mobile device keeps executing, but blocks if it attempts to access migrated state. The migrated thread executes on the clone, possibly accessing native features of the hosting platform such as the fast CPU, network, hardware accelerators, storage, etc. Eventually, the thread returns back to the mobile device, along with remotely created state, which it merges back into the original process. The choice of where to migrate is made by a partitioning component, which uses static analysis to discover constraints on possible migration points, and dynamic profiling to build a cost model for execution and migration. A mathematical optimizer chooses migration points that optimize 2 POV-Ray, 5

20 objective (such as total execution time or mobile-device energy consumption) given the application and the cost model. Finally, the run-time system chooses what partition to use. Figure 2.1: CloneCloud system model. CloneCloud transforms a single-machine execution (mobile device computation) into a distributed execution (mobile device and cloud computation) automatically. By offloading the right portion of the applications execution onto the device clones that are operating in the cloud, CloneCloud can boost these applications since they can take advantage, for example, of a better processing power of the remote computer reducing the execution time. But there are other variables that are analyzed before starting partitioning the execution, for example, if the execution on the clone is more reliable or more secure it may be worth it to take advantage of that. The partitioning of the application depends on the expected workload, such as CPU speed or network performance. It may be more fine-grained or not depending on these factors. This means that the same application run on different times may be partitioned differently. Some design goals for CloneCloud are: to allow such fine-grained flexibility on what to run where and to take the programmer out of the burden of application partitioning. The work made by the authors applies primarily to application-layer virtual machines (VMs), such as the Java VM 3, DalvikVM 4 from the Android Platform 5, and Microsoft s.net 6. They chose to work with application-layer VMs since they are widely used in mobile platforms. CloneCloud takes advantage of the resources in the remote computer, but partitioning applications is not a good solution for our execution environment. The main feature of FileCloud is to take advantage of neighbor computers larger screens and better processors in the use of applications with a graphical user interface. Partitioning a user interface is very difficult, but does not free the mobile device from complex computations. 3 Java, 4 DalvikVM, 5 Android Developers, 6 Microsoft.NET, 6

21 2.4 Jupiter Jupiter [8] is a system to augment the capabilities of smartphones transparently and with the support of cloud computing. One or more cloud servers can be employed as the extension of the storage and computing capabilities of smartphones. The cloud provides storage of applications and user data, and also provides virtual machines to execute large applications that cannot be on smartphones due to resource constraints. Jupiter aims to achieve three primary goals. The first goal was for mobile application management to be transparent to the user. To achieve this goal, the authors developed a customized application library, called the AppLib, as the storage of pre-certified applications. Applications (.apk) are processed before they are added to AppLib, such that the whole meta information can be extracted and converted to a searchable format. Sometimes this process required Human intervention. These applications can be upgraded and installed via the AppLib. When a user wants to run an application, the AppLib searches and compares all the applications and retrieves only the most appropriate one. When retrieved, the application is installed and launched without any intervention of the user. To upgrade one application transparently, new versions are update in the AppLib, either automatically or with human intervention. Then when the users run the application on their smartphones, the new version is loaded. When the phone storage is full, the applications less frequently used are removed without the notice of the user. The configurations and the data of these removed applications are kept in a transparent data storage, which is the second goal, and is restored automatically the next time the user requests an application. The second goal was to create a transparent data storage. In order to create this data storage, the authors developed a mobile file system named TransFS, in which each user will have its space and provides the transparent data storage for their Android applications. The data and configurations can be stored at the server-side and accessed through the TransFS file system in a transparent way. The third and final goal was a transparent desktop application execution. When a smartphone does not have capabilities to run an application or when a user requires a desktop application that do not have a mobile version, the virtual machine technology on the server is employed, with virtual network computing (VNC) capabilities implemented on the Android, the users can execute desktop applications just as they are executed on a desktop computer on their smartphones. There are two ways to load an application. The first one is choosing an application in the Android Launcher. Jupiter maintains a list of applications, which are stored in the AppLib and the required application is loaded through a click. The second way is on-demand, in which an application is loaded through another, for example, when a user wants to view an attachment file in an client, Jupiter loads the corresponding viewer automatically from the AppLib based on the file. Desktop application can also be loaded similarly through the above two ways. Jupiter introduces some concepts that are wanted for this project, such as executing desktop application or loading an application based on the file, but there are some differences. Jupiter does not take advantage of bigger screens on the neighbor when loading a desktop application. A bigger screen is very useful when editing an image or a video. 7

22 2.5 Cuckoo Framework The Cuckoo framework [10] simplifies the development of smartphone applications that benefit from computation offloading and provides a dynamic runtime system that decides, at runtime, if a part of an application is going to be executed locally or remotely. This framework can be used to easily write and efficiently run applications that can offload computation. Cuckoo offers a very simple programming model that is prepared for mobile environments. This programming model offers the developers an interface of the system, so it should be easy to use and understand. It must support both local and remote execution since when the mobile devices are not connected to the Internet, the cloud resources are unreachable. It must also allow the remote method implementation to be different from the local implementation. For example, the remote method could be parallelized in order to get full performance from the remote resources. If an Android application that contains compute intensive operations is well programmed, there is already an interface available. If not, an interface can easily be extracted from the code. This interface is implemented as a local service that has a proxy object at the activity. Next to this local interface, the Cuckoo framework generates another interface for the remote implementation. In the beginning, the implementation of this new interface contains only dummy methods, in which the developer then replaces with real method implementations to be executed at the remote location. These methods can be equal to the local ones, but may also be different, since the remote implementation can run a different algorithm, use a different library, run in parallel, etc. During runtime, the method invocations to services are intercepted at the service side of the Stub/Proxy pair, which is at the Stub. Then, Cuckoo decides if the method should be invoked locally or remotely. Cuckoo also queries the Cuckoo Resource Manager for any available resources to see if they are reachable, and if so, use them. Using Cuckoo for computation offloading, an application can offload its computation to any remote server, which runs a Java Virtual Machine. The user runs the server, written in Java, on the remote resource to enable it to be used for computation offloading. This server does nothing by itself, but services can be installed on it. The Android IPC mechanism directs the activity s method invocation of a service through the proxy and the kernel to the stub. In a normal situation, this stub invokes the local implementation of the method and then return the result to the proxy, but Cuckoo intercepts all method calls and decides if it s beneficial to offload the method invocation to a server, or not. In order for the mobile device to be able to execute methods on a remote resource, it has to communicate with that resource. For this, Cuckoo uses Ibis communication middleware [25], since it offers a simple and effective interface that abstracts from the actual used network (Wi-Fi, Cellular or Bluetooth). Figure 2.2 shows the process of building an Android application from source code to a user installable apk file. To enable an application for computation offloading, the only thing the developer has to do is to overwrite remote service dummy implementations (1) generated by the Cuckoo Remote Service Deriver. Cuckoo has a different goal of FileCloud. The goal of Cuckoo is to provide a programming model to simplify the development of applications that benefit from computation offloading. The use of pre-existing applications is not possible with Cuckoo. 8

23 Figure 2.2: Schematic overview of the build process of an Android application using Cuckoo Framework. 2.6 Virtual Network Computing VNC [19] is an ultra-thin client system based on a simple platform independent display protocol that frees the user of the burden of carrying around the hardware all the time. The network computer (NC) aims to give users access to centralized resources from simple, inexpensive devices. These devices operate as clients to powerful server machines that are connected to the network. These servers provide applications, data and storage for the user. VNC takes a stage further by providing applications and data, as well as the entire desktop environment. This can be accessed from any machine connected to the Internet. Unlike many recent Internet applications, VNC focuses on providing access to home computing environments from anywhere in the world instead of giving users access to resources located anywhere in the world from their home computing environments. Therefore, VNC provides mobile computing and the user does not have to carry around any sort of device. VNC also allows a single desktop to be accessed from different locations at the same time, supporting application sharing in the style of computer-supported cooperative work (CSCW). The simplicity of the simple remote display protocol underlying VNC is what makes it so powerful. This protocol allows remote access to graphical user interfaces. Since it works at the framebuffer level, it applies to all operating systems, windowing systems, and applications. The protocol operates over any reliable transport such as TCP/IP. The endpoint with which the user interacts, i.e., displays or input devices, is called the VNC client or viewer. The endpoint where changes to the framebuffer are performed, i.e., the windowing system and applications, is known as the VNC server (see Figure 2.3). Its design Figure 2.3: VNC architecture. 9

24 makes very few requirements of the client, and therefore simplifies the task of creating clients to run on a wide range of hardware. VNC does not solve the problem that FileCloud aims to solve, because the goal of FileCloud is not to access the mobile device s entire environment on remote computers. The goal is to take advantage of the bigger display and of the better user interface of desktop applications for certain types of tasks. 2.7 Media Centers A Media Center or a Home Theater PC (HTPC) is a device that has the goal of integrating televisions with PCs, in order to access remote media content, stored in File Servers, on a TV display. Figure 2.4 illustrates a typical HTPC architecture. It consists of a television, a Home Theater PC that runs a media center software and a file server that hosts all sorts of media, for example, DVD/Blu-Rays, music, photos, etc. Figure 2.4: HTPC architecture. There is no single standard protocol, however there is several systems that offer the functionality of a Media Center. XBMC 7 [17] is a free and open source media center developed by XBMC Foundation and it s available for multiple operating systems and hardware platforms. It allows users to play and view most videos, music and all common digital media files from local and network storage media. Boxee 8 is a fork of XBMC that provides social network features. It allows the users to view, rate and recommend content to their friends through social networks. It is known as the first Social Media Center. Windows Media Center 9 is a digital video recorder and media player developed by Microsoft. 7 XBMC, 8 Dlink s Boxee Box, 9 Windows Media Center, It 10

25 allows the users to organize and play their slideshows, videos and music, as well as view and record live television. The media can be played on computer monitors or on televisions through the use of a Windows Media Center Extender 10 device, such as a Xbox , and can be stored in local hard drives, optical drives and network locations. Windows Media Center can also use services like Netflix 12 to stream, for example, movies and TV shows. Digital Living Network Alliance (DLNA) 13 enables wireless sharing of media content between devices. It uses Universal Plug and Play (UPnP) 14 [16] for media management, control and discovery. UPnP defines the type of device that DLNA supports and the mechanisms for accessing media over a network. Then, the DLNA guidelines apply a layer of restrictions over the types of media file format, encodings and resolutions that a device must support. Media Transfer Protocol is a protocol described and introduced by Microsoft. It is compatible with Picture Transfer Protocol (PTP), which was designed to download photos from digital cameras. MTP supports the transfer of music files on digital audio players, media files on portable media players and personal information on personal digital assistants. It was originally implemented for use across USB, but later was extended for use across TCP/IP and Bluetooth. Media Centers main goal is to take advantage of a bigger screen like a TV, for playing media content such as videos and music. With FileCloud, the user can offload the same content to play in a bigger screen, together with other features such as edit, print and open links, which is not possible with Media Centers. The DLNA, MTP and PTP protocols will not be used in FileCloud since the files will stored in the cloud. Also, the initiation of the task in each system is different. On the media centers the file is selected on the device where the task will be started, and then the file is downloaded from the File Server. On FileCloud, the mobile device notifies the computer which file was selected, and then the file is retrieved from the cloud. 2.8 Distributed User Interfaces Distributed User Interfaces (DUIs) [27] become a new field of research and development in Human- Computer Interaction (HCI). DUIs are those interfaces whose different parts can be distributed in time and space on different monitors, screens, and computing platforms. DUIs attempt to surpass user interfaces that are manipulated by only one user, always on the same computing platform and environment, with little to no variations among of the user or the execution environment. A UI can be distributed by one of the following distribution types: Multi-monitor usage: a single user using a single computing platform distributes the UI across multiple monitors connected to the same platform. 10 Windows Media Center Extender, 11 Xbox 360, 12 Netflix, 13 DLNA, 14 UPnP Forum, 11

26 Multi-device usage: a single user uses several different devices together, even if they are running the same operating system or not. Multi-platform usage: a single user uses different computing platforms, probably running different operating systems. Multi-display usage: a single user distributes the UI across multiple monitors and devices simultaneously. Multi-user: one or many users may distribute parts or whole of the UI across several monitors, devices, platforms, or displays. In order to understand and classify existing approaches for DUIs, as well as to identify underexplored situations, a reference model was introduced. This reference model examines DUIs according to the 4C [4] dimensions: Computation: What is distributed? Communication: When is it distributed? Coordination: Who is distributed? Configuration: From where and to where is the distribution operated? In order to obtain a flexible user interface distribution across multiple devices a model-based user interface language was extended in order to address the specification of distribution at various user interface granularities [15]. The language was extended in order to be able to specify DUIs and was also designed a solution to generate implementations of such DUIs. These DUIs can dynamically change how the user interface elements are distributed according to user requests or other events. The approach developed aims to satisfy the two following requirements: Flexible support able to address a wide variety of granularities in terms of user interface components to distribute. Small and simple set of primitives to indicate how to perform the distribution. DUIs do not support the offloading of computation: optimizes user interaction, but power consumption remains high. FileCloud differentiates from DUI s because the goal is not to distribute the user interface of the mobile application. The goal is to use the user interface of an application installed on a neighbor desktop computer. 2.9 Resource Discovery Universal Plug and Play (UPnP) is a set of networking protocols that allows devices that are connected to the Internet to discover each other s presence. It also establishes a functional network services so that these devices can, for example, share data and communicate between them. 12

27 UPnP architecture enables pervasive peer-to-peer network connectivity between all sort of devices. It is a distributed, open networking architecture that leverages TCP/IP and Web technologies to enable seamless proximity networking. The architecture supports zero-configuration networking and automatic discovery of devices. The devices can also leave the network automatically without leaving any remaining unwanted state information. UPnP is universal because: It uses common standard protocols instead of proprietary drivers made by the vendors. It is independent of the underlying physical media and transports. It is compatible with all programming languages and operating systems. It leverages HTTP and other Internet technologies like XML and SOAP. It enables vendor control the device s user interface and interaction through a browser. It enables conventional application programmatic control. Vendors can extend the basic control protocols when needed. Vendors agree on UPnP control protocols on a per-device-class basis. Figure 2.5: UPnP protocols stack. Figure 2.5 illustrates the protocol stack that UPnP Device Architecture defines for the communication between the UPnP control points and devices. Next is described the sic phases if interaction specified by the architecture: Addressing: Phase where the device obtains an IP address. Discovery: Phase where the control points become aware of the existence of devices. Description: Phase where the control points learn details about devices and their services. 13

28 Control: Phase where the control points invoke service actions. Eventing: Phase where the devices notify the control points of changes in state. Presentation: Phase where the devices allows for status and control interactions by presenting a web page to the control points. UPnP can be used by FileCloud for the discovery the available desktop computers in the neighborhood. However, UPnP does not provide information about the applications installed on those computers. For this, a new step has to be implemented in order to get this information. STARC is a middleware platform that allows the resource discovery to be more adaptive via extensibility and increased flexibility. This means that STARC has the ability to incorporate new resources and increased expressiveness in requirement description, utility function depreciation on partial fulfillment, and employing fuzzy-logic to combine multiple requirements. STARC is able to interface with different network topologies, for example, LAN and P2P (Peer-to- Peer). Its extensibility not only allows the evaluation of the most usual resources, such as CPU speed and number of cores, but also the evaluation of new characteristics dynamically included, for example, presence of specific applications or services. As for flexibility, STARC uses XML files in order to application requirements. Logic operator states the relation between the several relevant resource characteristics with associated value ranges and utility depreciation, for the case that only partial fulfillment is possible. The Hosts responses range from no availability (0.0), to requirements fully met (1.0). If requirements are only partially met, a value between 0.0 and 1.0 is returned (partial-utility). This value takes into account the partial fulfillment ranges and the associated utility depreciations, as well as the evaluation policies provided by the client. These utility depreciations can also be applicable to individual resource alternatives not enclosed within ranges, for example, OS family. Figure 2.6: STARC architecture. Figure 2.6 illustrates the architecture of STARC, as well as the steps to use the STARC middleware. For the applications to discover, evaluate and select the resources present and available in remote computers as well as services and software provided by them, they use the STARC middleware platform, an assemblage of components (STARC daemons), that execute both in clients and in resource providers. 14

29 Each daemon handles all requirement evaluation requests. This means that they handle the requirements generated from a local application, as well as the remote requests generated by other remote daemons. In order for an apllication to use STARC, it must provide the local daemon a XML Requirement File (step 1). After reading the requirements, the relevant Environment Probing Classes are executed in order to know if they are fully, partially not at all fulfilled by the resources available (step 2). After evaluating the local resources, if the request was originated from a local application, the STARC daemon contacts the remote daemons (steps 3). Each contacted daemon evaluates the requirements (step 4) and returns the resulting value (Step 5). The Remote Host Discovery module finds hosts that have a STARC daemon running. This component abstracts the middleware from different network topologies. It interfaces with the rest of the middleware uniquely by providing for each request a list of available hosts. These hosts are later contacted by the Communication component. STARC is a middleware that can be very useful to FileCloud, since we need to not only know the available resources, but also other important information, such as, what actions can a a PC perform to a file, depending on the applications installed Current solutions limitations In this section is summarized the limitations, of the systems described above, that FileCloud aims to solve. The following systems implement cyber foraging in multiple ways. These systems allow, for example, the offloading of the computation of tasks to remote computers, but the user can t take advantage of all the resources available on those computers. FileCloud aims to offload the computation to computers in the neighborhood, so the user can use all the resources available. FileCloud aims to be completely transparent to the user, i.e., the user only selects the proper file and the desired action and the system automatically stars the appropriate desktop application in the remote computer. So, SPADE does not solve our problem because it only uses the remote computer to process batches of files, not allowing the user to take advantage of the bigger screen and of the desktop applications to have a more complete environment for editing the files. SPADE also does not take advantages of the cloud storage. Every time the user wants to process a file, this file has to be sent to the remote computer and back to the mobile device. Furthermore, SPADE requires that the user have to define the application to run and the arguments. CloneCloud takes advantage of the resources in the remote computer, but partitioning applications is not a good solution for our execution environment. The main feature of FileCloud is to take advantage of neighbor computers larger screens and better processors in the use of applications with a graphical user interface. Partitioning a user interface is very difficult, but does not free the mobile device from complex computations. Jupiter introduces some concepts that are wanted for this project, such as executing desktop application or loading an application based on the file, but there are some differences. Jupiter does not take 15

30 advantage of bigger screens on the neighbor when loading a desktop application. A bigger screen is very useful when editing an image or a video. Cuckoo has a different goal of FileCloud. The goal of Cuckoo is to provide a programming model to simplify the development of applications that benefit from computation offloading. The use of pre-existing applications is not possible with Cuckoo. VNC does not solve the problem that FileCloud aims to solve, because the goal of FileCloud is not to access the mobile device s entire environment on remote computers. The goal is to take advantage of the bigger display and of the better user interface of desktop applications for certain types of tasks. Media Centers main goal is to take advantage of a bigger screen like a TV, for playing media content such as videos and music. With FileCloud, the user can offload the same content to play in a bigger screen, together with other features such as edit, print and open links, which is not possible with Media Centers. The DLNA, MTP and PTP protocols will not be used in FileCloud since the files will stored in the cloud. Also, the initiation of the task in each system is different. On the media centers the file is selected on the device where the task will be started, and then the file is downloaded from the File Server. On FileCloud, the mobile device notifies the computer which file was selected, and then the file is retrieved from the cloud. DUIs do not support the offloading of computation: optimizes user interaction, but power consumption remains high. FileCloud differentiates from DUI s because the goal is not to distribute the user interface of the mobile application. The goal is to use the user interface of an application installed on a neighbor desktop computer. 16

31 Chapter 3 Target Environment 3.1 Operating System There are several Mobile Operating Systems available nowadays. The most popular ones are Apple ios 1, Google Android and Microsoft Windows Phone 2. The choice here goes to Google Android. Android is an open-source mobile operating system and because of that is the OS with biggest market share at the time this article is being written as is shown in Fig Being the OS installed on most mobile devices currently is a factor of motivation to develop for this platform. Figure 3.1: Mobile Operating System market share. The latest version of Android is 4.3 Jelly Bean, but this version is currently available for only a few mobile devices. The version most used is still the version 2.3 Gingerbread. This is due the fact that unlike ios and Windows Phone, Android is used in a lot of entry level devices, which brands do not support for a long time or even at all, and those users can t afford buying newer devices frequently. Due to this fact, FileCloud should be developed for this version despite being a little old, so that it can run on 1 Apple Developer, 2 Windows Phone Dev Center, 17

32 almost all Android devices out there. Figure 3.2: Android architecture Figure 3.2 illustrates Android architecture. It is built on top of a Linux Kernel, with some architectural changes made by Google. Here is where all the drivers needed are, for example the Display or Wi-Fi drivers. The next layer has the libraries and the Android Runtime. These libraries are written in C/C++ 3 and they are specific for a particular device s hardware. The Android Runtime consists of DalvikVM and Core Java Libraries. The DalvikVM is a modified Java Virtual Machine designed especially for Android. One difference between the two is that DalvikVM uses a register-based architecture instead of the stackbased used in JVM. Above this layer is the Application Framework layer. The blocks on this layer are the ones that the applications interact with, for example, the Location Manager or Activity Manager. Finally there is an Application layer, which is where FileCloud application will fit. Since Android is an open-source OS, the developers can do whatever they want to with their applications Android SDK The Android SDK 4 was the platform chosen to develop the application. It s the most used development kit for Android in the world. The SDK includes: a debugger, libraries, a handset emulator based on QEMU, documentation, sample code, and tutorials. The debugger provided, is very useful to detect possible bugs and errors during the implementation phase, which is something other SDKs do not have included. The following operating systems versions are currently supported development platforms: Linux (any modern desktop Linux distribution) Mac OS X or later 3 GNU C Compiler, 4 Android SDK, 18

33 Windows XP or later The official supported IDE is Eclipse 5 with the official plug-in provided by Google, Android Development Tool (ADT). However, other IDEs also support Android programming, such as NetBeans 6 or IntelliJ IDEA 7. The applications are written in Java, so they run natively on the Android. With this development kit, the developers have direct access to all Android APIs, thus having total control of the application, both on design and on the core code. Having this fine-grained development, allows us to implement the application with more detail and implement modules that we can t with other development kits, for example, develop communication modules, such as Socket or have access to a remote WebService Other Android programming tools In this section is presented some alternatives available to develop application to the Android platform. PhoneGap 8 is a mobile development framework supported by Adobe Systems. PhoneGap allows the user to develop their application without using device-specific programming language, as Java for Android or Objective-C for ios. These applications are developed using JavaScript, HTML5 and CSS3. The result is a hybrid application, which is neither native nor completely web-based, since besides being web apps, they have the ability to access native device APIs. Adobe AIR supports Flash applications by running them in a contained Flash Player instance. It also supports HTML/JavaScript/Ajax web applications by running them in the included WebKit rendering engine. To start developing with AIR, the user needs to set up the developing environment, which consists in: Adobe Flash Professional 9 (a 30 day free trial is available for all), AIR for Android extension 10, AIR SDK 11 and Android SDK. Also the user needs to install Adobe AIR on the mobile device 12 before using the application developed. With the environment ready to use, the developer can start implementing the on the Flash Professional IDE, as it were a normal Flash application. After the application is developed, AIR for Android in cooperation with the Android SDK is able to publish the.apk package, ready to install on the mobile device. The MIT App Inventor 13 is a Web-based visual development environment for novice programmers. It s based on MIT s Open Blocks Java library and provides access to Android devices GPS, accelerometer and orientation data, phone functions, text messaging, speech-to-text conversion, contact data, persistent storage, and Web services. 5 Eclipse, 6 NetBeans IDE, 7 IntelliJ IDEA IDE, 8 PhoneGap, 9 Adobe Flash Professional, 10 AIR for Android extension, 11 AIR SDK, 12 Adobe AIR for Android devices, 13 MIT App Inventor, 19

34 3.2 Cloud services Over the past few years, several cloud services were developed for many different purposes. There are three type of service models: Infrastructure as a Service (IaaS) [12] (e.g. Dropbox, Amazon EC2 14, etc.), Platform as a Service (PaaS) [9] (e.g. Google App Engine 15, Windows Azure Compute 16, etc.) and Software as a Service (SaaS) [28] (e.g. Google Apps 17, Microsoft Office , etc.) and some work was done integrating it with mobile computing. Using cloudets [21], a user with a poor-resource device, can be empowered by exploiting the virtual machine (VM) technology to rapidly instantiate a customized service software. A cloudlet is a trusted, resource-rich computer or cluster of computers that s well-connected to the Internet and available for use by nearby mobile devices. Some years ago, there was only two ways to run an application: on the phone or run on the server and accesses remotely by the user. To overcome this limitation, a middleware platform was presented to automatically distribute different layers of an application between the phone and the servers [6]. With this, a variety of objective functions are of attained, for example, latency and data transferred, can be optimized improving the performance and the user experience from mobile phones. Another model to augment the capabilities of a mobile device was presented [29]. This model enables seamless and transparent use of cloud resources to augment the capability of resource constrained mobile devices. The features of this model include the partition of a single application into multiple components called weblets, and a dynamic adaptation of weblet execution configuration. The weblet can run on a mobile device or migrated to the cloud, i.e., run on one or more nodes offered by an IaaS provider. The IaaS model is the most relevant for this project, since it provides storage for the users using, for example, Dropbox or Google Drive 19. With these services the users can store their files in the cloud and access them anywhere, every time they are connected to the Internet. Although the storage capacity is increasing over the past years, flash storage that is used in this kind of devices is still quite expensive. Due to this fact, the majority of the devices have very limited storage resources, making the access to this kind of cloud service very useful. Also, with this service the users can have their files replicated through multiple devices. When updating one file, it is automatically updated in all other devices when connected to the Internet. The SaaS model is another model relevant to the project, since if there is no application available, or a Google Docs document is selected, the Google Docs editors can be launched, on a web browser, for the user. 14 Amazon EC2, 15 Google App Engine, 16 Windows Azure, 17 Google Apps, 18 Microsoft Office 365, 19 Google Drive, 20

35 3.3 Cloud-based File System Google Drive is a file storage and synchronization service. In addition to storage, since the old Google Docs service is integrated in Google Drive, the users can take advantage of a suite of productivity applications, such as documents, spreadsheets and presentation, etc. This service also allows sharing a folder or a specific file with other users. Google SDK 20 allows the users to integrate their own mobile applications with Google Drive for Android. The other possibility to use as file system is Dropbox. Like Google Drive, it is a file storage and synchronization service. In the other hand, it does not offer a suite of productivity applications and does not allow sharing only a specific file with other users. The Dropbox API 21 allows the users to download and upload files from Dropbox. It also provides them with methods to securely read and write files. Finally, the users also have access to features like sharing, search and restoring previous versions of files. When developing with the API, the user needs to choose one of the following levels of Dropbox access: App folder: The application only has read and write access to a dedicated folder created within the App folder of the user. Full Dropbox: The application get full access to all files and folders of the user. But for security reason, the developers need to provide a good reason to request this kind of access level before the application is approved for release. The security features of the Full Dropbox level of access can be a reason to choose Google Drive over Dropbox. 3.4 Connectivity In this section is described possible communication protocols, in which the FileCloud daemons can possibly use to contact with each other Wi-Fi Wi-Fi is the most used technology in the world that allows a device to exchange data or connect to the internet, without the use of wires using radio waves. Wi-Fi is defined by the Wi-Fi Alliance as any wireless local area network (WLAN) products that are based on the Institute of Electrical and Electronics Engineers (IEEE) standards. Wi-Fi is not as secure as wired connections, such as Ethernet, since the possible attacker does not need a physical connection. This way, a variety of encryption technologies, such as WPA and WPA2, 20 Google Drive SDK, 21 Dropbox - Developers, 21

36 were added to Wi-Fi because unencrypted internet access can easily be detected by these attackers. The WPA2 protocol is considered secure, as long as the user uses a strong password. Figure 3.3 illustrates how devices can communicate with each other wirelessly. Wi-Fi Access Point Print Print Laptop Printer a) b) Figure 3.3: Wi-Fi usage example: a) The computer uses a wireless access point to communicate with a printer instead of using the traditional wires. b) The computers communicate with each other in an ad-hoc network. The devices are aware of the existence of other devices connected to the same network. In order for devices to communicate with each other with Wi-Fi, they either need to be connected to a wireless access point or to an ad-hoc network. The access point allows the devices to connect to a wired network using Wi-Fi, while ad-hoc network works by two or more devices communicating between each other without the use of an access point. Using an access point, the devices can communicate with each other as long as they are connected to the same network. This means, that the devices can be localized far away from each other and still be able to communicate, while in an ad-hoc network, the devices can only communicate as long as they are in range of each other. Wi-Fi Direct defines a new pre-association discovery method, allowing Wi-Fi Direct-certified devices to discover devices and limited information about device services. With this pre-association discovery, the users can know if a desired device, such as a printer, is available on the network before connecting Bluetooth Bluetooth 22 is a wireless technology standard for exchanging data over short distances between devices, such as faxes, mobile phones or smartphones, creating personal area networks (PANs) with high levels of security. A device to be marketed as a Bluetooth device must met the standards defined by the Bluetooth SIG. A network of patents is required in order to implement the technology. This network of patents is licensed only for the qualifying device. A Bluetooth device can discover other devices, provided that they are in range. A master Bluetooth device can communicate with a maximum of seven devices in a piconet (a network created by using a 22 Bluetooth Technology Website, 22

37 wireless Bluetooth connection), but not all the devices reach this maximum. These devices can switch roles, and thus the master can become a slave, while a slave becomes the master. After the network is established, data can be transferred between the master and one of the slaves at any time. The master selects which slave device to address, and can typically switch rapidly from one device to another. Print Smartphone Bluetooth printer Figure 3.4: Bluetooth usage example. communicates directly with the printer. Unlike the Wi-Fi technology, with bluetooth the smartphone Figure 3.4 illustrates an example where a smartphone uses the Bluetooth technology to communicate with a printer Mobile Cellular Systems Mobile technology is the technology used for cellular communication. This technology allowed the mobile devices to communicate and exchange data between them. Most recently, this technology has been integrated on tablets, allowing them to have access to the Internet everywhere, similarly to the current smartphones. 3G is the third generation of mobile telecommunications technology. Lately, mobile carriers have provided services, often denoted as 3.5G. These services allow the mobile devices to have a broadband access of several Mbit/s. Regarding the discovery of other devices, this technology does not offer such services, like Wi-Fi and Bluetooth do. Figure 3.5 shows an example of a mobile device sending a message to another using the 3G network. Provider Access Point Hello Hello Smartphone Smartphone Figure 3.5: 3G usage example. In this example a smartphone send a message to another one. Like the Wi-Fi technology, an access point is used. In this case, the service provider access point. 23

38 24

39 Chapter 4 FileCloud FileCloud tries to unify the following three resources: mobile devices, use of idle desktop computers in the neighborhood and the access to files stored in the cloud. Systems like Dropbox or Google Drive allows the access to the user s personal files any-time, anywhere. With FileCloud the user can take advantage of idle desktop computer to execute some actions that are not suited to run on a mobile device for several reasons, such as the excessive battery drain. Also, the better processor on the desktop computer helps a lot, because the majority of the mobile devices still have very weak processors. Services to offload tasks[24] already exist, but these services are too complex to configure by the average mobile device user. FileCloud aims to optimize this through a transparent execution on a remote computer and automatically providing the following usual tasks: i) File open, ii) File Edit, and iii) File Print Resource Discovery Offloading Task Application Launched Select File Select Action Best PC Get File Figure 4.1: FileCloud usage overview. Figure 4.1 illustrates how FileCloud works. After the user selects the desired file from his cloud-based file system, to work with, the system starts searching for available PCs in the neighborhood (Resource Discovery Phase). Then, after the user selects the action he wants to do (open, edit or print), FileCloud selects the best PC to perform the task and offloads it (Offloading Phase). Finally, the proper application automatically starts on the PC. In section 4.2, the execution flow of the system is described in more detail. 25

40 4.1 Architecture In order for the system to run, it needs two daemons: one installed on the mobile device and another on at least one PC in the neighborhood. As illustrated in Figure 4.2, the architecture of both daemons is very similar. Both have three layers: the User Interfaces which the user directly interacts with, the Core and a layer with the communication modules. This architecture is described in more detail in the following sections. FileCloud Client Server UI UI Core Core Comm Comm Figure 4.2: Architecture overview Client Architecture Client UI Action Selector UI Task Manager FileGetter Resource Discovery Offloader Communication File System Figure 4.3: Client architecture. In gray are the modules implemented during the project and in white are the already existing technologies, which FileCloud will use. 26

41 As aforementioned, the client is composed by three layers. The upper layer is the one the user directly interacts. This layer is implemented by two modules. The Client UI is the main interface of the client. It is responsible to show all the file information of the user s Cloud-based File System account and is where the user can select the wanted file. We also have the Action Selector UI. This interface is where the user can select the action he wants to perform on the file selected. The middle layer is the core of the client. This is where all the information is processed in order to offload the task. The Task Manager module is responsible to coordinate the execution flow, by calling the other modules whenever they are needed. The FileGetter module communicates with the cloudbased File System and gets all the file information needed from it. The Resource Discovery module searches for available PCs and communicates with them in order to obtain information about them. The Offloader is the module responsible to assemble all the information the user inserted and start the offload of the task. Finally, we have the bottom layer. This layer is implemented by two modules: the Communication that offers the mechanisms to communicate with the PCs and the File System, which is where all the file meta-data is stored. These modules are implemented by existing technologies that will be used by FileCloud Server Architecture Server UI User Credentials UI Application UI Task Manager Resource Discovery FileGetter Request Listener Application Management Communication File System Figure 4.4: Server architecture. In gray are the modules implemented during the project and in white are the already existing technologies, which FileCloud will use. Similarly to the client, the server is also composed by three layers. The upper layer is implemented by three modules. The Server UI is the main interface of the server, where the user can view all the important information about the state of the server. The Application UI is not explicitly implemented since it is the interface of the chosen application to do the task. The User Credentials UI is the interface where the user can input his File System s credentials so FileCloud can have access to it. 27

42 The middle layer is the server s core and is implemented by five modules. The Task Manager is responsible for starting/stopping the server, as well as storing all relevant information. The FileGetter is responsible to communicate with the FileSystem of the user. The Resource Discovery is the complementary module to the one in the client. It is responsible to let the clients discover the PC. The Request Listener module listens to requests to start a task. Finally, the Application Management module is responsible to search the installed applications and to know which application is the proper one for the file type and action specified. Finally, the bottom layer is similar to the one in the client. We have a Communication and a File System modules, which are existing technologies used by FileCloud. 4.2 Execution Flow Client PC 1 PC 2 Cloud User 1 Open FileCloud() getfilelist() :File List Select File() 2 par Resource Discovery(FileMimeType) :Specs and actions available Resource Discovery(FileMimeType) 3 :Specs and actions available Select Action() SelectBestPC() Offload Task(Action, FileID, ) 4 getfile(fileid) :File RunApplication(File Location, MimeType, Action) 5 opt Upload File(File Location) 6 Figure 4.5: FileCloud execution flow. As shown in Figure 4.5, in order for the system to function properly, a FileCloud client must be running in the mobile device and a FileCloud server running in at least one neighbor PC. By the time the client starts, it connects to the cloud-based file system and retrieves the meta-data of the user s file list (step 1). Selecting one of the files, FileCloud starts to search for available PCs in the neighborhood by sending a LAN broadcast message (step 2). Each PC receiving this message, searches for what actions can be performed on that type of file and returns it together with the PC s specifications. After knowing all the available PCs, they are sorted in order to select the best one available for the task. Now 28

43 a list of the available actions that can be made to the file is shown on the screen for the user to select. Selecting one of these actions, FileCloud connects to the best PC and offloads the task to it (step 3). Then the meta-data is retrieved from cloud file systems and, if the file is not present on the file system s sync folder, the real file is downloaded (step 4). Finally, the proper application is executed for the user to use it (step 5). When the application is closed, the file is transparently uploaded to the cloud (step 6) Resource Discovery Phase Client Server Client UI Action Selector UI T ask Manager Offloader Resource Discovery Resource Discovery Application Management User 1 Select File() :File 2 searchcomputers(file Mime Type) Broadcast(File Mime Type) :Specs, Actions 3 checkapps(file Mime Type) :Actions :Computers List 5 show(file Title, Actions) sortcomputersbyspecs() 4 Figure 4.6: Execution flow of the resource discovery phase. Figure 4.6 shows in detail the resource discovery steps. After the user selects the desired file (step 1), the Task Manager calls the Resource Discovery module to search for computer in the neighborhood with a LAN Broadcast (step 2). In this broadcast, the MIME type of the file selected is sent, so the Application Management on the server can check the applications installed, and consequently, the actions available for that type of file (step 3). After knowing the actions available, the Resource Discovery module on the server-side, responds to the client with the PC s specifications, together with the actions. After receiving the responses from all the available PCs, they are sorted by their specifications (more information on Section 4.3.5) (step 4). Finally, the Action Selector UI is popped for the user, showing the available tasks for the file (step 5) Offloading Task Phase Figure 4.7 illustrates the execution flow of the offloading task phase. After receiving the message from the client, if FileCloud doesn t have access to the user s file system, the user authenticates himself, providing FileCloud the access (step 1). The next step is to lock in the user s FileGetter and use it to get the file meta-data from the file system. With the meta-data FileCloud can check if the user is present on the file system s sync folder on the hard drive. If not, the file is downloaded (step 2). 29

44 Action Selector UI Client T ask Manager Server User Credentials Task Manager Request Listener FileGetter Application Offloader File System Application UI UI Management User Select Action() :Action getbestpc() :PC OffloadTask(Action, File ID, ) 1 opt Check FileGetter [!users.contains( )] new FileGetter() authentication(this) show(file Getter) InputCredentials() setkey(key) storeuserfilegetter( , FileGetter) selectfilegetter( ) GetFile(File ID) 2 Get(File ID) :File meta-data SearchFileOnSyncFolder() opt [File not found] DownloadFile() :File :File Location run(file Location, File Mime type, Action) 3 searchproperapp() Open(File Location) opt [File Downloaded] 4 UploadFile(File Location) Figure 4.7: Execution flow of the offloading task phase. Then, the Request Listener calls the Application Management to start searching for the proper application depending on the action and file mime type. After searching, the file is opened in the application (step 3). Finally, if the file was downloaded, it means that the file system s sync application is not installed or is not configured for the user s account. So, FileCloud uploads the newer version of the file back to the file system (step 4). 4.3 Implementation In this section is described the details of how the modules of FileCloud were implemented. To develop the server it was used Microsoft.NET C# programing language. This was the chosen programming language since Microsoft Windows is the most used operating system in the world. For the client, Android was the chosen platform, since it is the most used mobile operating system in the world. Regarding the cloud-based File System, Google Drive was the chosen one, since it offers good integration with Android. In the end of this section, we will show that these options don t limit the target environment of File- 30

45 Cloud Installation and configuration The installation of FileCloud on the mobile device is a standard one. As for the server, no installation is needed. Starting the.exe file, the server is launched and ready for the user. However, the following requirements must be met in order for the system to work properly. Client Requirements: The device must have installed Android 3.0 Honeycomb or a superior version. The user must have configured at least one Google account on the device. Wi-Fi must be ON and connected to a hotspot. Server Requirements: The PC must have installed.net Framework 3.5. Wi-Fi must be ON and connected to the same hotspot as the client File System The chosen cloud-base File System was Google Drive. This option was elected amongst the alternatives since it provides good integration with Android. In order for both the client and server have access to Google Drive, some configurations had to be done in Google APIs Console 1. On the Services tab the Drive API and Drive SDK options had to be enabled. The next step was to create two OAuth 2.0 client IDs in the API Access tab: one for installed applications and another for Android apps. The Client ID and Client Secret provided here are required in order to configure the FileGetter in the server. Finally, a new Android key had to be created on the Simple API Access section. The same SHA-1 fingerprint certificate and the package of the FileCloud project used on the Oauth 2.0 client ID for android apps was used to create this key Task Manager Client On the client, the Task Manager is responsible for coordinating the execution flow of the system. Another responsibility is to call the right modules when they are needed, for example, after the user selects the file wanted, the Task Manager, calls the Resource Discovery module to start searching for PCs, or to call the Action Selector UI. It is also responsible for storing important information, such as, PCs specifications and the meta-data of the user s file list. Finally, this module has access to the account configured on the 1 Google APIs Console, 31

46 mobile device. After getting the account, it filters the com.google account types. If there is more than one Google account configured, a pop-up shows with a list if these account for the user to select the desired one. Server On the server side, the Task Manager is responsible to start or stop the Resource Discovery and Request Listener threads, according to the user s input on the Server UI. The Task Manager is the only module that can update the UI or call other modules with an interface like the User Credentials UI. Another responsibility of this module, is to store some important information, such as, a Dictionary (C# s version of Java s Hashtable) linking the user s account to the correspondent FileGetter (proxy to the user s cloud fie system), as is shown in Figure 4.8. FileCloud keeps the reference to the user s FileGetter until he logs out on the Server UI (See section for more information) or until the server application is closed. KEYS [email protected] [email protected] VALUES joao's FileGetter maria's FileGetter Figure 4.8: FileGetter mapping. correspondent FileGetter. It represents the Dictionary linking the user s account to the FileGetter In this section is described the implementations of the FileGetter on both the client and the server. In order to obtain user s files meta-data from Google Drive, we used the Drive API v2 provided officially by Google. Client To configure the FileGetter, FileCloud needs to get an authentication token from the user s Google account. To this, it is selected the Google account configured on the mobile device. Then, FileCloud gets the authentication token with the type oauth2: from this account. This token is then set as the access token of the GoogleCredential instance. Having this information, FileCloud can now access the user s Google Drive and get the list of all files. After obtaining this list, the FileGetter starts the process of mapping the files to their parent folder on a Hashtable as Figure 4.9 exemplifies. This organization allows FileCloud to present the files the same way they are shown on the Google Drive website, instead of listing a bunch of files and folders on a single list. When a folder is selected a new instance of the Client UI is created showing the files inside the selected folder. 32

47 ID FILE TITLE PARENT ID 1 FILE 1 0* KEY VALUES 2 FILE 2 0* root FILE 1, FILE 2, FOLDER 1 3 FOLDER 1 0* FOLDER 1 FILE 3 4 FILE 3 3 * 0 is root Figure 4.9: File mapping. Server In order to configure a FileGetter on the server side, the steps are different. Instantiating the class, the Oauth2 Client ID and Client Secret configured on Section had to be used. Then, we can get a link for the Google authorization website to obtain a temporary key. Now, the User Credentials UI is popped up and after the user inputs their Google credentials the key generated. This key links the FileGetter to the user s Google Drive. When the Requests Listener requests the FileGetter to obtain the file, it connects to the user s Drive and gets the file meta-data. With the meta-data, it s possible to know the path of the file on Google Drive, which will be the same inside the Google Drive s synchronized folder, in case the Drive Sync application is installed on the PC and configured for the account using FileCloud. If the file already exists on the hard drive, after the user finishes his job, Drive Sync automatically updates the file to the cloud. If not, the file is downloaded, and FileGetter warns the Request Listener that when the user finishes the task, the file needs to be uploaded back to the cloud and deleted afterwards Resource Discovery The evaluation and discovery of available resources weren t the focus of this project, but in order to implement a functional prototype it was developed a simple resource discovery mechanism, that is described in this section. Systems, such as Condor s ClassAd [18] or STARC [22], could be integrated in FileCloud providing a more advanced system to discover host and evaluate the available resources. Furthermore, locations should be taken into account when evaluating resources. Client Besides discovering a nearby computer, it is necessary to evaluate the resources of the remote computers and select the best one. Only doing this evaluation, it is possible to optimize available resource usage and off the user the best experience. Host discovery is performed by means of a LAN broadcast. This broadcast is made by sending a Socket in parallel threads to all available PCs. Each Socket contains the information described in Figure As we can see, the message only has the file MIME type, which is the only information needed in this phase, since it allows the server to discover which actions can be performed to the type of file selected. 33

48 MIME TYPE Figure 4.10: Information sent on Resource Discovery s LAN Broadcast. The evaluation of the found hosts is made using a technique similar to the one presented in STARC. With a suitable requirement (display size, memory and processor characteristics) STARC sorts the available computers for FileCloud to select the best one. First, a rating value is calculated for each computer. This value is the sum of the RAM, processor and operating system version rating values. Each of these values are to capped to 10. For the RAM, 8GB is the cap. Any value above 8GB of RAM is still a rate 10 because there aren t many tasks that require even 8GB, not even most of the games with high graphs need it. For the processor the cap is 8 cores with 2.5GHz in each core and for the operating system version the cap is the version 6.2 corresponding for the Windows 8. The computer rank is calculated with the following formulas: RAMRating = RAM 10, IF (RAMRating > 10) RAMRating = 10 (4.1) 8192 P rocessorrating = P rocessorspeed NumberOfCores 10, IF (P rocessorrating > 10) P rocessorrating = 10 (4.2) OSV ersionrating = OSV ersion 10, 62 IF (OSV ersionrating > 10) OSV ersionrating = 10 (4.3) ScreenSizeRating = ScreenSize 10, 22 IF (ScreenSizeRating > 10) OSV ersionrating = 10 (4.4) ComputerRating = RAM Rating + P rocessorrating+ OSV ersionrating + ScreenSizeRating (4.5) A note on the OS Version Rating: 62 corresponds to version 6.2, this is due the version of the Windows 8 being , so taking only the first two numbers with the dots makes the calculations easier. After calculating this rating value it is made a Bubble Sort algorithm to sort the computers on the list. 34

49 Server On the server side, it is used a TcpListener, on port 3000, for listening the client s LAN broadcast. The TcpListener class provides simple methods that listen for and accept incoming connection requests in blocking synchronous mode. Unlike Sockets, which can be used with TCP or UDP protocols, the TcpListener is pre-configured with TCP and gives a TcpClient object when handling a connection. When the Resource Discovery instance is created, it gets the aforementioned specifications of the PC. When receiving the message, presented in Figure 4.10 from the client, the module first verifies if a user is already using FileCloud. If not, it checks through the Client ID and Client Secret if the user exists and if is logged in. If yes, it returns the PC s specifications together with the IP address and port of the Request Listener of the PC Offloader In order to offload the task, a PC has to be chosen. As we saw in the Resource Discovery section above, the PCs available are sorted in a list by their specifications. But there is the possibility that the best PC does not have, for example, software to edit a video, while the second on the list can. After the PC is chosen, a Socket is opened, connecting the mobile device to the server and the information needed (described in Figure 4.11) is sent, in a String, in order to start the task. Finally, finished sending the message to offload the task, the mobile device enters the idle state. ACTION ID ACCOUNT Figure 4.11: Information sent in order to start the task Request Listener The Request Listener, similarly to the Resource Discovery, uses its own TcpListener, but on port When receiving a request message it locks the FileCloud server, by selecting the user through the Client ID and Client Secret. Using the ID and the user s FileGetter, the file meta-data is retrieved from the user s Google Drive. If the file is not present on the user s shared Drive folder, it downloads the actual file. After this process, the module calls the Application Management to start the proper application. When the application is closed the user is released, leaving the server available for new requests, and finally, the file is uploaded back to the cloud Application Management The Application Management module verifies the existence if the applications installed in the operating system in order to return the available actions for a specific type of file during the Resource Discovery. On the Offloading phase, after the Request Listener obtains all the information needed, this module is called in order to launch the proper application for the type of file and action selected. 35

50 FileCloud is able to recognize the following type of files: Multimedia (image, video, music) Text files Common documents (Word, Excel, Powerpoint and PDF) As Figure 4.12 illustrated, opening one file of these types, an installed application is launched, if there is one. If no application is found, FileCloud opens the file on the Drive website. Figure 4.12: Application found and launched for the image file selected. The user selected the file sample image.jpg and the action Edit. With this information, the Application Management found the MS Paint application installed and opens the file on it. Another type of file that do not open in an installed application is the Google Docs file type. When selecting this type of file, FileCloud automatically opens it on the proper Google Docs editor, as shown in Figure For the Document and Presentation types, the user can select between the Open and Edit actions, since Google Docs offers the ability to preview these files. As for the Spreadsheet and Form types, the user can only edit them, since it is not possible to open a spreadsheet page on a preview option. Figure 4.13: Launching Google Docs editors: After the user selects a Google Docs Spreadsheet, the Web Browser is launched automatically. 36

51 All the other file types that are not mentioned above will also be opened on the Drive website, though it may not be an available preview tools for these files. 4.4 User Interaction Client UI The Client interface was developed as a normal file explorer for the user s Google Drive files as is shown in Figure For the list it was used the ListView class that the Android SDK provides. It was developed a customized Adapter for this ListView in order to customize the layer, allowing each item to have its own file icon. On the title we can see the correspondent to the Google Drive account plus the current directory. This is the interface where the user selects the desired file to work with. Figure 4.14: Client File Explorer. Action Selector UI The Action Selector UI is the interface where the user can select the available action that can be made to the file selected. There are three options available: Open, Edit and Print. Is the PCs available can t Figure 4.15: Client action selector. On the right it shows an example where the PCs available can do all possible actions. On the left side we can see an example where the Edit and Print options is not available. 37

52 perform one of these actions, those actions are not shown. As Figure 4.15 shows, the interface was developed as a simple pop-up dialog with a ListView listing the actions. Integration with existent file explorer applications Integrating FileCloud with the official Google Drive for Android application or other file explorer, that offers the ability to configure a Drive account, is not possible. This is duo to the fact that in order to open the file with a custom application is not possible without downloading it. The current only possibility to integrate with normal file explorer applications would be by selecting a file on the device s storage and open it with FileCloud. Then, the file would be uploaded to the cloud and finally, the system would continue with the normal execution flow. Another option would be to obtain the source code of these file explorers and modify it in order to integrate FileCloud on the applications Server UI Figure 4.16: FileCloud Server UI. As we can see in Figure 4.16, the server interface was designed with two different sections. The one on the right is aimed for the user management, while the one on the left is a TextBox where the user can check the activity log of the current session. Figure 4.17: FileCloud usage example. On the right it shows that the user selected a file and already has the action list to select. On the left side we can see that the task was offloaded and the application was launched for the user. 38

53 The user management section was developed with a ListBox, which lists all the accounts added to the server. There is also one button, which allows a user to logout, so the server have no more access to his Google Drive account. The button on the bottom, allows the user to start or stop the server, depending on the current state. Figure 4.17 shows two photos of a usage example of a user selecting an image file to edit. User Credentials UI This is where the users will input their Google account s credentials in order for the FileCloud server to have access to their Google Drive. This interface is only shown when a user uses FileCloud for the first time on the PC installed, since the application was launched. As illustrated in Figure 4.18, the interface has only one form: a WebBrowser. Through the user s FileGetter, we get the url to open in this WebBrowser so the user can login to his Google account. After the user logs in, Google asks permission for the application to access the user s Drive. By accepting, a page with the key would be shown for the user to copy. But the module intercepts the page title and retrieves the key automatically, simplifying the user s job. Figure 4.18: User Credentials UI. On the left is shown the page to insert the Google account credentials. On the right is shown the page asking permission for FileCloud to have access the user s Google Drive. 4.5 Interoperability Although the client was written for the Android platform, it could be possible to develop it for other platforms, such as Apple s ios or Microsoft s Windows Phone OS. A new FileCloud file explorer should be re-developed since the programming languages and APIs for each operating system are different, but the communication protocols are the same since it is independent of the platform. A possible integration with existent file explorers could also be possible, while developing FileCloud for these platforms. 39

54 Despite the server has been developed in C#, it doesn t mean that it is stuck to only run on the Windows platform. Mono 2 is a free and open source project led by Xamarin 3. It offers a.net Framework-compatible set of tools including, among others, a C# compiler. Mono s goal is not only to be able to run Microsoft.NET applications cross-platform, but also to bring better development tools to Linux developers. Mono can be run on almost all major platforms, such as, Android, most Linux distributions, BSD, OS X, Windows, Solaris, and even on some game consoles like PlayStation 3, Wii, and Xbox 360. The current version of Mono ( as of April 2013) provides the core API of the.net Framework and support C# versions 2.0, 3.0 and 4.0. Windows Forms 2.0 despite being supported is not actively developed, meaning that its support on Mono is still incomplete. The missing parts of the.net Framework are under development in an experimental Mono subproject called Olive 4. Xamarin.iOS 5 and Xamarin.Android 6 are implementations of Mono for the ios and Android OS, but they are release under a commercial license only Mono on Xubuntu Xubuntu 7 is a distribution of Ubuntu 8, hence they have the same repositories. Since the releases prior to version 12.04, the mono packages come by default on these repositories. After installing the following packages, the system is ready to start compiling C# code: install mono-complete install monodevelop The monodevelop package offers an IDE, similar to Microsoft Visual Studio for the Windows platform. In order to compile FileCloud, some changes should be made. The layer in which more changes would be made is the upper one, because Mono uses the Gtk package for the interface instead of the Windows.Forms used in Windows. This way, the upper layer of FileCloud should be re-developed. Most of the core code remains the same, though some changes should be made. In the Resource Discovery module, the portion of code that obtains the PC s specifications must be re-worked, since FileCloud is using Windows libraries for this effect. The Application Management module must be reworked too. The applications paths must be adapted to the paths of the applications of the new OS. 2 Mono, 3 Xamarin, 4 Olive, 5 Xamarin.iOS, 6 Xamarin.Android, 7 Xubuntu, 8 Ubuntu, 40

55 Chapter 5 Evaluation In order to evaluate FileCloud, some test where performed: battery energy consumption when viewing videos (Video Visualization), usability when editing an image (Image Editing) and writing text (Writing), and finally, the communication and resource evaluation overhead (Overheads). For the execution the tests described above was used an Android tablet and laptop (used as fixed personal computer with the following specifications: Tablet Personal Computer Toshiba AT Asus K53SD Processor Nvidia Tegra 250 Mobile 1GHz Intel 2.2GHz RAM 1GB (724MB available) 6GB Screen :9 HD (1280x800) :9 HD (1366x768) Operating System Android (Ice Cream Sandwich) Windows 8 Pro Wi-Fi b/g/n b/g/n Table 5.1: Hardware specifications. 5.1 Video Visualization The goal of these tests is to evaluate how energy consumption varies when viewing videos (of different sizes) on the mobile device and on a remote computer (by means of FileCloud). In this test three samples with different sizes and lengths where used. The properties of each sample are shown in Table 5.2. Sample 1 Sample 2 Sample 3 Length 00:08:52 00:04:49 00:02:15 Resolution 640x x x360 Size 44.89MB 18.41MB 10.45MB Table 5.2: Properties of the video samples. Five different experiments were performed: i) local viewing with the screen on maximum brightness, 41

56 Number of visualizations Visualization time (min) ii) local viewing with the screen on minimum brightness, iii) remote viewing with direct file transfer, and iv) remote viewing with FileCloud. Test Screen Brightness Wi-Fi File Transfer base Min Off No i Max Off No ii Min Off No iii Auto dim On Yes iv Auto dim On No Table 5.3: Video visualization tests overview. During tests i) and ii) wireless network was off, while on tests iii) and iv) the screen was naturally dimmed when the tablet got inactive. Each test consisted on continuous and repeated viewing of a video file until battery drained completely. The base test consisted in obtaining the maximum battery life of the mobile device, with the screen always ON. The number of total video visualizations and battery duration is presented in Figure 5.1. sample 1 sample 2 sample 3 sample 1 sample 2 sample Local (Maximum Local (Minimum Brightness) Brightness) a) Direct File Transfer FileCloud 0 Local (Maximum Brightness) Local (Minimum Brightness) b) Direct File Transfer FileCloud Figure 5.1: Video visualization results: a) Number of visualizations, b) Battery time As we can see in Fig. 5.1.a), comparing the results of the same sample, FileCloud allows the most number of visualizations. With respect to power consumption File Cloud is close to the minimal power consumption possible: the red horizontal line on Fig. 5.1.b) represents for how long the tablet is able to be on with Wi-Fi off and the screen dimmed to the minimum. File cloud does not add much power consumption overhead to that base consumption. It is evident that when using a remote computer to view the videos the battery drain on the mobile device is lower. This happens because the tablet display is dimmed and turned off, when the user is viewing the video on the remote computer. The cost to have the wireless on is lower than the gains from turning off the display. It is also possible to observe that the use of a cloud file systems reduces network usage and as such power consumption. 42

57 5.2 Image Editing Another advantage of FileCloud is the use of bigger screen and better data input methods (mouse and full size keyboard). This test evaluates if productivity gains (from using better data input methods) are enough to overcome the overhead from launching the file from FileCloud and from the communication between the mobile device and the remote compute. It was made two tests of editing images with different degrees of difficulty: a very simple task of inverting an image s colors and a cropping test since it requires more skill from the user. With these tests we can know with more accuracy, if compensates to use FileCloud, even in very simple tasks Invert colors As aforementioned, this test consisted on a simple image manipulation (invert colors) as illustrated in Figure 5.2. Figure 5.2: Invert colors test. The workflows to perform the test were this following: 1. Tablet: select on file on Gallery, select Edit option, choose Photo Studio application, invert colors, save the image exit. 2. PC using FileCloud: use FileCloud to select the image, select the operation, wait for the desktop application to open (MS Paint), invert colors on the laptop, save the image and exit. Number of editions Total time spent Tablet s PC using FileCloud s Table 5.4: Results of Invert colors test. As we can see in Table 5.4, the time to perform 5 image conversions in a row on the mobile device is more than 1 minute (1m11s), while using FileCloud and a remote computer it only takes slightly less than 1 minute (56 seconds) to perform the same transformations. As illustrated in Figure 5.3.a), in average, the user takes 11s to do the task the on the PC using FileCloud, while on the tablet it takes approximately 14s. With these results, we can conclude that, in the same period of time, even tasks that are very simple to perform on a tablet, gain from using a remote computer as illustrated by Figure 5.3.b). 43

58 Time in seconds Number of editions Tablet FileCloud Tablet FileCloud a) 0 b) Figure 5.3: Invert colors test results: a) Average time per edition, b) Number of editions comparison Crop In this test, three users were asked to crop in image, as illustrated in Figure 5.4, the best they could in each of the workflows of this test. In this test, 3 users were asked to perform it, because unlike the previous test, this one requires some skill to crop the image, while the previous one, it was only needed to press some buttons. Figure 5.4: Crop test. The workflows to perform this test were the following: 1. Tablet: select on file on Gallery, select Edit option, choose Photo Studio application, crop image, save the image exit. 2. PC using FileCloud: use FileCloud to select the image, select the operation, wait for the desktop application to open (MS Paint), crop the on the laptop using the mouse, save the image and exit. As Figure 5.5.a) shows, the results were different for each user. Some users are more comfortable doing the task on the tablet than others, for example, User 1 took more than 1 minute (1m4s) to crop the image while User 2 took less than half of the time (29.86s). We can also conclude that even the more skillful users on the tablet, still gains by using FileCloud to perform the same task on the PC with a mouse. As shown in Figure 5.5.b), all users took approximately half the time to perform such task. 44

59 Number of words Time in seconds Tablet FileCloud 120% 100% Tablet FileCloud 100% 100% 100% % 60% 40% 20% 40.5% 50.2% 41.7% 0 User 1 User 2 User 3 a) 0% User 1 User 2 User 3 b) 5.3 Writing Figure 5.5: Crop test results: a) Time to perform task, b) Time comparison in %. In this test, the same three users were asked to copy text as much as they could during 5 minutes on a document editor installed on the tablet, and then open a Word document using FileCloud, and again write as much as they could for the same period of time. The workflows to perform this test were the following: 1. Tablet: Open new document on Toshiba s Write application, copy as much words as they could, from the abstract of a selected paper, in 5 minutes, save the document exit. 2. PC using FileCloud: use FileCloud to select a Word document file, select the operation, wait for the desktop application to open (MS Word), copy as much words as they could, from the abstract of a selected paper, in 5 minutes, save the document and exit Tablet 110 FileCloud Tablet FileCloud User 1 User 2 User 3 a) 0 User 1 User 2 User 3 b) Figure 5.6: Writing test results: a) Number of words in 5 minutes, b) Performance comparison. As shown in Figure 5.6.a), the number of words a user writes are higher using FileCloud for writing on a PC with a physical keyboard. The results on the tablet have a bigger difference between each other than the results on the PC, due to the fact that some users don t have much experience with virtual 45

60 keyboards. Because of this inexperience, the users did more mistakes while writing and they took more time correcting the mistaken words. The number of mistakes could have been even more significant if instead of using a tablet with a 10.1 screen, the user used, for example, a smartphone with a 4 screen. In Figure 5.6.b), we can see that even the user that performed better on the tablet, still had some gains using the PC (about 1.5 times more words). As for the other users they had a much better performance on the PC in comparison with the tablet test, since they wrote about 2 times more words. 5.4 Overheads The overhead test has the goal measure the time it takes to perform resource evaluation and communication. In lengthy tasks the energy consumption is more relevant, but on small tasks the time needed to start the task on a remote computer is relevant. The test was made using 1 available PC in the neighborhood. As we can see in Table 5.5, the total overhead cost of offloading a task is less than 1 second (0.875s). This value include the resource discovery (a broadcast), the evaluation of the available resources on the remote computers, retrieving of the file identification and the actual initiation of task. This small value is orders of magnitude smaller than any task that users usually performs on a mobile device, allowing us to conclude that this overhead will be unnoticed by the user. Averages Resource Discovery Phase Offload Task Phase 0.045s 0.830s Total overhead (s) 0.875s Table 5.5: Overhead times. 5.5 Discussion After the observation of the results of these tests, we can make some conclusions about FileCloud. First of all, using FileCloud to offload the task to a PC, the user can perform the tasks in less time, increasing their performance. This increase of performance is achieved, not only because the PC have a better processor and more RAM, but also due to the use of mouse and keyboard. For example, in the image crop test, the users were more precise and quicker selecting the contours of the square with the mouse on the PC, than on the tablet using his finger. Also, on the writing test, it was possible to observe that the users were more comfortable using a physical keyboard and a virtual one, despite being on a 10.1 screen tablet. If a 4 screen smartphone was used as the mobile device, the results would be even worse comparing to the results on the PC. We can also conclude that we can save battery power on the mobile device, since it is idle during the execution of the task. Finally, we can see that the overhead of using of FileCloud to offload the task does not overshadow the gains of using the PC. 46

61 Chapter 6 Conclusions FileCloud aims to optimize the relationship between mobile devices and desktop computers in an automatic way, allowing the user to offload tasks to idle desktop computer in the neighborhood. FileCloud automatically chooses the most appropriate application to launch, freeing the user of the burden of having to configure a lot of stuff before offloading the tasks, making it very simple and straightforward for him/her. FileCloud integrates cloud and mobile computing in a manner not yet experimented. While most systems resource to the cloud to extend mobile devices capabilities, FileCloud extends mobile devices with the help of nearby devices, but uses the cloud as the data communication subtract. In FileCloud, the offloading of these tasks to a PC allows the user to take advantage of better resources (screen size, keyboard and mouse, better CPU) and reduce mobile device power consumption. These resources, together with other peripherals of the PC, can provide the user an environment that significantly improves the productivity during the task. When the user selects one of the files on the mobile device, FileCloud starts searching for available PCs in the neighborhood. Each PC returns the possible actions to be done on that file, together with their specifications. Then the user selects one of possible actions and FileCloud connects to the best PC to offloads the task. Finally, the proper application is executed for the user to use it. When the application is closed, the file is transparently uploaded to the cloud. The FileCloud now runs on Android mobile devices and Windows desktop computers and takes advantage of Google Drive, but clients and servers for different combination are possible to develop. FileCloud also allows the use of Cloud based desktop applications (such as Google Docs), not requiring the previous installation of the needed applications on the desktop computer. If no suitable application is installed on the remote computer, the FileCloud server is capable of opening a Web Browser, and redirects it to the on-line application capable of showing or editing the file. Experimental results prove that the offloading of tasks to remote computers reduces energy consumption since the mobile device becomes idle while the task executes on the neighbor PC. Offloading a task every 135 seconds had very little effect in terms of battery consumption, meaning that each offload spends very little battery energy. 47

62 Regarding the productivity, even with a very simple task (inverting the color of an image) we still had a positive speed-up (1.28). Other more complex tasks (image crop and text writing) showed better speed-ups (around 2, in average). A tablet with a 10.1 screen was used to perform these tasks. If the mobile device had a smaller screen, the tasks would have been more difficult for the user, taking longer to perform them. Thus, the results using FileCloud would have been even greater. The overhead of offloading a task is very little (around 0.8 seconds). This value is the sum of the resource discovery plus the offload task overheads. This means that it is unnoticed by the user and does not overshadow the gains from using the better UI and lower energy consumption. Finally, we can conclude that FileCloud is a viable system, even for the execution of very simple test since the user, despite not gaining too much time, still has a better experience, with the better UIs and input devices. We could also see that the more complex the task is, greater are the gains since the PC is more fit to some tasks than the mobile device, also with a reduction of energy consumption and with no noticeable overhead. The work here presented was also published and presented in INForum 2013, in Évora, Portugal [14]. 6.1 Future Work In this section it s pointed some ideas do to in the future in order to continue this project. Security issues and discovery mechanisms were not handled in this initial work but are planned to be incorporated. It is necessary to guarantee the privacy of the data handled in the desktop computer, preserve the integrity of the desktop computer against any malicious attack from the user. To accomplish this, virtual machines, such as, sandboxes, could be integrated in FileCloud, this way, protecting the system. The message exchanged between the mobile devices should also be secured, with an cryptographic algorthim, for example, Public Key cryptography (also known as Asymmetric cryptography). This way, the messages exchanged are secured against possible attackers. As for the resource discovery module, some work should be done in order to improve the discovery and selection of the PCs available on the neighborhood. For example, as illustrated in Figure 6.1, the Figure 6.1: Future work on Resource Discovery module: PC s location. 48

63 location of the PCs should be take into account since the user don t want FileCloud to select a PC on the next room while there are other PCs available for the task in his room. Furthermore, more exhaustive tests with more users should be made in order to evaluate the system, though the current results are indicative of the gains that can be obtained. The use of FileCloud in public places, for example kiosks, can also be studied. Currently, kiosks normally provide computers with access to a web browser, not having available applications for the users to perform some kind of tasks, such as image editing. Though, having FileCloud installed on these computers, the users could have, at least, access to the Google Docs editors. But more work could be done in this field. With the use of cloud applications, we could use the web browser to run these applications, providing the user more options of performs their tasks in these public places. 49

64 50

65 Bibliography [1] BALAN, R., FLINN, J., SATYANARAYANAN, M., SINNAMOHIDEEN, S., AND YANG, H.-I. The case for cyber foraging. In Proceedings of the 10th workshop on ACM SIGOPS European workshop (New York, NY, USA, 2002), EW 10, ACM, pp [2] BARHAM, P., DRAGOVIC, B., FRASER, K., HAND, S., HARRIS, T., HO, A., NEUGEBAUER, R., PRATT, I., AND WARFIELD, A. Xen and the art of virtualization. In Proceedings of the nineteenth ACM symposium on Operating systems principles (New York, NY, USA, 2003), SOSP 03, ACM, pp [3] CHUN, B. G., IHM, S., MANIATIS, P., NAIK, M., AND PATTI, A. CloneCloud: elastic execution between mobile device and cloud. In Proceedings of the sixth conference on Computer systems (New York, NY, USA, 2011), EuroSys 11, ACM, pp [4] DEMEURE, A., SOTTET, J. S., CALVARY, G., COUTAZ, J., GANNEAU, V., AND VANDERDONCKT, J. The 4C Reference Model for Distributed User Interfaces. In Autonomic and Autonomous Systems, ICAS Fourth International Conference on (Mar. 2008), IEEE, pp [5] FLINN, J., SINNAMOHIDEEN, S., TOLIA, N., AND SATYANARYANAN, M. Data staging on untrusted surrogates. In Proceedings of the 2nd USENIX Conference on File and Storage Technologies (Berkeley, CA, USA, 2003), FAST 03, USENIX Association, pp [6] GIURGIU, I., RIVA, O., JURIC, D., KRIVULEV, I., AND ALONSO, G. Calling the Cloud: Enabling Mobile Phones as Interfaces to Cloud Applications. In Middleware 2009, J. Bacon and B. Cooper, Eds., vol of Lecture Notes in Computer Science. Springer Berlin Heidelberg, 2009, pp [7] GOYAL, S., AND CARTER, J. A lightweight secure cyber foraging infrastructure for resourceconstrained devices. In Proceedings of the Sixth IEEE Workshop on Mobile Computing Systems and Applications (Washington, DC, USA, 2004), WMCSA 04, IEEE Computer Society, pp [8] GUO, Y., ZHANG, L., KONG, J., SUN, J., FENG, T., AND CHEN, X. Jupiter: transparent augmentation of smartphone capabilities through cloud computing. In Proceedings of the 3rd ACM SOSP Workshop on Networking, Systems, and Applications on Mobile Handhelds (New York, NY, USA, 2011), MobiHeld 11, ACM. 51

66 [9] KELLER, E., AND REXFORD, J. The Platform as a service model for networking. In Proceedings of the 2010 internet network management conference on Research on enterprise networking (Berkeley, CA, USA, 2010), INM/WREN 10, USENIX Association, p. 4. [10] KEMP, R., PALMER, N., KIELMANN, T., AND BAL, H. Cuckoo: A Computation Offloading Framework for Smartphones Mobile Computing, Applications, and Services. vol. 76 of Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering. Springer Berlin Heidelberg, Berlin, Heidelberg, 2012, ch. 4, pp [11] KEMP, R., PALMER, N., KIELMANN, T., SEINSTRA, F., DROST, N., MAASSEN, J., AND BAL, H. eyedentify: Multimedia cyber foraging from a smartphone. In Proceedings of the th IEEE International Symposium on Multimedia (Washington, DC, USA, 2009), ISM 09, IEEE Computer Society, pp [12] LEE, B. S., YAN, S., MA, D., AND ZHAO, G. Aggregating IaaS Service. In SRII Global Conference (SRII), 2011 Annual (Mar. 2011), IEEE, pp [13] LI, Z., WANG, C., AND XU, R. Computation offloading to save energy on handheld devices: a partition scheme. In Proceedings of the 2001 international conference on Compilers, architecture, and synthesis for embedded systems (New York, NY, USA, 2001), CASES 01, ACM, pp [14] LIMA, T., SILVA, J. N., AND VEIGA, L. Filecloud - cloud filesystem based processing offloading. In INForum o Simpósio de Informática (Évora, Portugal, September 2013), pp [15] MANCA, M., AND PATERNÒ, F. Flexible support for distributing user interfaces across multiple devices. In Proceedings of the 9th ACM SIGCHI Italian Chapter International Conference on Computer-Human Interaction: Facing Complexity (New York, NY, USA, 2011), CHItaly, ACM, pp [16] MILLER, B. A., NIXON, T., TAI, C., AND WOOD, M. D. Home networking with Universal Plug and Play. Communications Magazine, IEEE 39, 12 (Dec. 2001), [17] NEAL T. BAILEY. An XBMC HTPC W7.pdf. [18] RAMAN, R., LIVNY, M., AND SOLOMON, M. H. Matchmaking: An extensible framework for distributed resource management. Cluster Computing 2, 2 (June 1999), [19] RICHARDSON, T., STAFFORD-FRASER, Q., WOOD, K. R., AND HOPPER, A. Virtual network computing. Internet Computing, IEEE 2, 1 (Jan. 1998), [20] SATYANARAYANAN, M. Pervasive computing: vision and challenges. Personal Communications, IEEE 8, 4 (2001), [21] SATYANARAYANAN, M., BAHL, P., CACERES, R., AND DAVIES, N. The Case for VM-Based Cloudlets in Mobile Computing. Pervasive Computing, IEEE 8, 4 (Oct. 2009),

67 [22] SILVA, J. N., FERREIRA, P., AND VEIGA, L. Service and resource discovery in cycle-sharing environments with a utility algebra. In Parallel Distributed Processing (IPDPS), 2010 IEEE International Symposium on (2010), pp [23] SILVA, J. N., VEIGA, L., AND FERREIRA, P. SPADE: scheduler for parallel and distributed execution from mobile devices. In Proceedings of the 6th international workshop on Middleware for pervasive and ad-hoc computing (New York, NY, USA, 2008), MPAC 08, ACM, pp [24] SOUSA, J. P., POLADIAN, V., GARLAN, D., SCHMERL, B., AND SHAW, M. Task-based adaptation for ubiquitous computing. Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEE Transactions on 36, 3 (May 2006), [25] VAN NIEUWPOORT, R. V., MAASSEN, J., HOFMAN, R., KIELMANN, T., AND BAL, H. E. Ibis: an efficient Java-based grid programming environment. In Proceedings of the 2002 joint ACM-ISCOPE conference on Java Grande (New York, NY, USA, 2002), JGI 02, ACM, pp [26] VAN NIEUWPOORT, R. V., MAASSEN, J., WRZESIŃSKA, G., HOFMAN, R. F. H., JACOBS, C. J. H., KIELMANN, T., AND BAL, H. E. Ibis: a flexible and efficient java-based grid programming environment: Research articles. Concurr. Comput. : Pract. Exper. 17, 7-8 (June 2005), [27] VANDERDONCKT, J. Distributed User Interfaces: How to Distribute User Interface Elements across Users, Platforms, and Environments. In Interraccion 2010 (Sept. 2010). [28] XIN, M., AND LEVINA, N. Software-as-a-Service Model: Elaborating Client-Side Adoption Factors. Social Science Research Network Working Paper Series (Dec. 2008). [29] ZHANG, X., KUNJITHAPATHAM, A., JEONG, S., AND GIBBS, S. Towards an Elastic Application Model for Augmenting the Computing Capabilities of Mobile Devices with Cloud Computing. Mob. Netw. Appl. 16, 3 (June 2011),