MOBILE CLOUD COMPUTING: CASE STUDIES

ŀ MOBILE CLOUD COMPUTING: CASE STUDIES

by

ELIZABETH HALASH

THESIS

Submitted to the Graduate School

of Wayne State University,

Detroit, Michigan

in partial fulfillment of the requirements

for the degree of

MASTER OF SCIENCE

2010

MAJOR: COMPUTER ENGINEERING

Approved by:

_____________________________________ Advisor Date _____________________________________ _____________________________________ _____________________________________ _____________________________________

UMI Number: 1490482

All rights reserved

INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted.

In the unlikely event that the author did not send a complete manuscript

and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion.

UMI 1490482

Copyright 2011 by ProQuest LLC. All rights reserved. This edition of the work is protected against

unauthorized copying under Title 17, United States Code.

ProQuest LLC 789 East Eisenhower Parkway

P.O. Box 1346 Ann Arbor, MI 48106-1346

ii

Acknowledgements

I would like to especially thank my family for supporting me throughout my academic

career, everyone studying in the Cloud and Internet computing Lab at Wayne State for all of

their help and great technical discussions, and D. Cheng-Zhong Xu for encouraging me to

continue my research and for guiding me throughout my work.

iii

TABLE OF CONTENTS

ACKNOWLEDGMENTS ............................................................................................................................................. ii

List of Figures ............................................................................................................................................................ vi

List of Tables ............................................................................................................................................................ vii

Chapter 1 Introduction and Motivation........................................................................................................................1

1.1 Background of Cloud Computing......................................................................................................................1

1.2 Challenges of Cloud Computing .......................................................................................................................4

1.3 Objective ...........................................................................................................................................................5

1.4 Summary of Contribution ..................................................................................................................................6

1.5 Thesis Organization ..........................................................................................................................................7

Chapter 2 Related Work .............................................................................................................................................9

2.1 Survey of the State of the Art ...........................................................................................................................9

2.2 Current Market Cloud Providers .................................................................................................................... 10

2.2.1 Google App Engine................................................................................................................................. 10

2.2.2 Microsoft Azure ....................................................................................................................................... 10

2.2.3 Amazon Elastic Compute Cloud ............................................................................................................. 11

2.3 Mobile Cloud Computing ............................................................................................................................... 12

2.3.1 Mobile Cloud Computing Categories ...................................................................................................... 13

2.3.2 Mobile Cloud Architecture ...................................................................................................................... 16

2.4 Sidebar on Google’s High Speed Network .................................................................................................... 18

Chapter 3 System Design ........................................................................................................................................ 19

3.1 Remote Execution Methods .......................................................................................................................... 19

3.2 Dynamic vs. Static Code Offload ................................................................................................................... 19

3.3 Communication Protocols .............................................................................................................................. 19

3.4 Code Partitioning ........................................................................................................................................... 20

3.5 Extraction Requirements ............................................................................................................................... 21

3.6 Architecture Choices ..................................................................................................................................... 21

Chapter 4 System Implementation .......................................................................................................................... 22

iv

4.1 Outline ........................................................................................................................................................... 22

4.2 Java RMI NASA Benchmark ......................................................................................................................... 22

4.2.1 Java RMI ................................................................................................................................................. 22

4.2.2 NASA Benchmarks ................................................................................................................................. 23

4.2.3 Remotely: Desktop to WSU servers ....................................................................................................... 24

4.2.4 iPhone Implementation Using a Distributed File System ....................................................................... 24

4.3 Java RMI Chess Game ................................................................................................................................. 25

4.3.1. Small HTTP Server for Dynamic Code Offload ..................................................................................... 26

4.3.2 Sending Multiple Requests ..................................................................................................................... 26

4.4. Java RMI Security......................................................................................................................................... 26

4.5 Google Android to App Engine Chess Game ................................................................................................ 27

4.5.1 Communication Protocol: HTTP ............................................................................................................. 27

4.5.2 Android Development Mobile Device ..................................................................................................... 28

4.5.3 Google App Engine as the Remote Server ............................................................................................ 29

4.5.4 Remote Execution .................................................................................................................................. 29

4.5.5 The Client Android Application – App Inventor ....................................................................................... 30

Chapter 5 Evaluation ............................................................................................................................................... 31

5.1 Evaluation Methodologies ............................................................................................................................. 32

5.2 NASA Benchmarks Evaluation ...................................................................................................................... 33

5.3 Android App Evaluation ................................................................................................................................. 36

5.4 Discussion ..................................................................................................................................................... 37

5.4.1 Performance ........................................................................................................................................... 37

5.4.2 Reliability ................................................................................................................................................ 39

5.4.3 Replication .............................................................................................................................................. 39

5.4.4 Consistency ............................................................................................................................................ 39

5.4.5 Mobility .................................................................................................................................................... 40

5.4.6 Security ................................................................................................................................................... 40

Chapter 6 Conclusions and Future Work ................................................................................................................ 41

v

6.1 Conclusions and Contributions ...................................................................................................................... 41

6.2 Future Work ................................................................................................................................................... 43

References .............................................................................................................................................................. 45

ABSTRACT .............................................................................................................................................................. 47

AUTOBIOGRAPHICAL STATEMENT ..................................................................................................................... 48

vi

LIST OF FIGURES

FIGURE 1: CLOUD COMPUTING MANAGEMNET OFFERINGS [2]GGGGGGGGGGGGGGGGGGG.. 2

FIGURE 2: JAVA RMI COMMUNICATION FLOWGGGGGGGGGGGGGGGGGGGGGGGGGGG 23

FIGURE 3: RMI USING A DISTRIBUTED FILE SYSTEMGGGGGGGGGGGGGGGGGGGGGGGG 25

FIGURE 4: CHESS GAME EXECUTIONGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG 25

FIGURE 5: GOOGLE ANDROID TO APP ENGINEGGGGGGGGGGGGGGGGGGGGGGGGGG.. 27

FIGURE 6: ANDROID EMULATOR RUNNING THE CHESS GAMEGGGGGGGGGGGGGGGGGGG. 28

FIGURE 7: APP INVENTOR INTERFACE IN CHROME BROWSERGGGGGGGGGGGGGGGGGGG 30

FIGURE 8: MG BENCHMARK RUN TIMES GGGGGGGGGGGGGGGGGGGGGGGGGGGGG..33

FIGURE 9: BG BENCHMARK TESTGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG34

FIGURE 10: DYNAMIC VS. DEDICATED SERVER GGGGGGGGGGGGGGGGGGGGGGGGGG35

vii

LIST OF TABLES

TABLE 1: MG BENCHMARK RUN TIMESGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG. 33

TABLE 2: EXECUTION TIMES OF SERVER, LAPTOP, AND IPHONE RUNNING A NASA BENCHMARK

TEST. GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG36

TABLE 3: EXECUTION TIMES OF MOBILE DEVICE AND APP ENGINE SERVERGGGGGGGGGGGG.. 36

TABLE 4: GOOGLE APP ENGINE SERVER RTT INFO GGGGGGGGGGGGGGGGGGGGGGGG.37

TABLE 5: HUMAN-COMPUTER INTERACTION EVALUATIONS. LEFT-SUBJECTIVE OPINIONS RELATED

TO RESPONSE TIMES. RIGHT-SURVEY OF OPIIONS RELATED TO RTTGG........................................ 38

1

Chapter 1 Introduction and Motivation

In the early days of computing technology, when computers took up the space of an entire room,

many ’dumb’ terminals, or clients, would be connected to a main computer. Many clients could utilize the

computational power and storage of the mainframe at the same time. As transistors and CPUs came into

play, shrinking personal computers, it became more feasible for a user to purchase their own computer.

However, today, mobile devices are becoming smaller and smaller and we are seeing that there

is either a physical or economic limit to the amount of storage and processing power that can fit into these

devices. It seems that the original model of client-mainframe computing may be a good answer for this

situation. However, we can now utilize existing wireless networks to connect mobile devices to servers in

massive datacenters, rather than hardwiring all clients to a server. This idea of connecting to unseen

data may be where the term “cloud” came from, since it seems that the extra power is coming out of

nowhere.

Companies are only just beginning to investigate the possibilities of the cloud and provide cloud

services for business and personal use. There is much potential in utilizing the resources of the cloud,

most of which has not been researched yet. Client machines can become much more powerful by

connecting to these cloud datacenters, but what are the options of doing so? Furthermore, integrating

mobile devices with the cloud could prove even more advantageous. As these devices become smaller

and smaller, consumers are conversely demanding more functionality and features. Bridging the gap

between high-end servers and mobile devices could solve the computing problem, though research is

needed to identity the advantages and limitations.

1.1 Background of Cloud Computing

Cloud computing is the combination of hardware and software provided remotely as a service.

When people refer to the “cloud,” they are usually referring to a datacenter of servers that provide the

storage and processing power of the applications contained in the “cloud.” From an IT perspective, it has

the potential to transform a large portion of the industry. This is due to both relative ease of use and

economics.

Any application needs a computation

communication. In order to achieve

virtualized to hide their implementation.

on the requirements of the programmer and the level

following list and figure 1 provides three examples of cloud providers across the spectrum of user control:

1) Users have nearly full contro

2) General purpose computing, no access to underlying operating system (Microsof

3) Specific application, less control, but faster automatic scaling of resources (Google AppE

An important question is why cloud computing is becoming popular now. One of the biggest

factors needed to enable cloud computing is high speed pervasive broadband internet. Without a

connection between the client and server, cloud computing would be impossible. Other important factors

are related to new business strategies. These strategies involve a pay

allows customers to only pay for the cloud services that they use. This allows a bus

productivity without worrying about being able to meet higher demand at a moment’s notice. Also, new

unprecedented economies of scale have allowed massive datacenters to be built for much less than a

company trying to maintain their own

the creation and use of virtual machines. Additionally, the growing use of these technologies has led to

the standardization of certain software stacks.

FIGURE

2

Any application needs a computation engine, physical and virtual storage space

communication. In order to achieve the illusion of infinite capacity, each of these resources

implementation. Different utility computing offerings will be distinguished based

the programmer and the level of management needed by the IT profession

provides three examples of cloud providers across the spectrum of user control:

Users have nearly full control of software stack (Amazon EC2)

General purpose computing, no access to underlying operating system (Microsof

Specific application, less control, but faster automatic scaling of resources (Google AppE



server, cloud computing would be impossible. Other important factors

are related to new business strategies. These strategies involve a pay-as-you-go billing model that

allows customers to only pay for the cloud services that they use. This allows a bus



company trying to maintain their own room of servers. [2] Fast x86 virtualization has allowed process in


software stacks.

FIGURE 1: CLOUD COMPUTING MANAGEMNET OFFERINGS [2]

space, and a model of

each of these resources needs to be

computing offerings will be distinguished based

of management needed by the IT professional. The

provides three examples of cloud providers across the spectrum of user control:

General purpose computing, no access to underlying operating system (Microsoft Azure)

Specific application, less control, but faster automatic scaling of resources (Google AppEngine)



server, cloud computing would be impossible. Other important factors

go billing model that

allows customers to only pay for the cloud services that they use. This allows a business to increase



has allowed process in


3

Another reason cloud computing is becoming popular now is because of user demand. Cloud

computing promises many benefits to users, such as the Illusion of limitless resources and accessible

data from anywhere. Application developers are able to add more resources to their apps on demand, as

needed. Start-up companies do not need to pay a large up-front commitment to use the cloud, instead

using a pay-as-needed model. Performance does not need to be reduced due to cost as the cost of 1000

servers/1 hour = cost of 1 server for 1000 hours.

This presents a very attractive quality of cloud computing: its economics. Previously, the only

options were either over-provisioning or under-provisioning. Over-provision refers to buying more

resources than normally needed so that peak load can always be handled. Though service interruptions

are avoided and peak demand is always met, resources are wasted the majority of the time. On the other

hand, under-provisioning means that resources are purchased based on the average load. In this

situation business is lost during peak demand, and resources are still wasted during times of low demand,

though not as dramatically as over-provisioning. Neither of these situations is ideal. Fortunately, cloud

computing does provide a near-ideal solution. Since cloud resources can be added and removed on

demand, users can allocate resources to meet their customer demand. Thus, businesses only pay for

what they use and do not lost any business during peak times,

Cloud computing also provides the opportunity for new types of applications. Parallel processing

and mobile applications stand to benefit the most. Processes that analyze terabytes of data that took

hours to finish could take a fraction of the time to complete if the resources of the cloud are used. Lastly,

mobile interactive applications could provide real time data by connecting to the cloud. Such services

need the power of the cloud because they rely on large data sets that need to be highly available. This is

especially true of applications that rely on multiple data sources.

Mobile Cloud Computing

Mobile devices, such as smart phones, PDAs and netbooks, continue to grow in popularity.

However, cell phones are no longer considered to be simple communication devices. Today most mobile

devices incorporate various functions, such as music players or games. A shortcoming of mobile devices

is their limited computing capabilities due to portability and cost issues. Bridging the gap between high-

4

end servers and mobile devices could solve the computing problem and is an important research focus of

distributed computing.

Cloud computing is the key technology that enables a seamless integration of high performance

servers and mobile devices. It is a style of computing in which dynamically scalable resources are

provided as a service over the Internet. Mobile devices can extend their computing capabilities by

exporting the service from computing clouds. In this cloud computing model, mobile devices are thin-

clients that only provide the interfaces or consoles to the complex applications. [4] The computational-

heavy processing like 3D image rendering in games or mathematical optimization in scientific simulations

is actually processed in the cloud. Thus, mobile applications could become more complex while the actual

devices could become smaller. [1]

1.2 Challenges of Cloud Computing

From this cloud computing model, it is easy to see the great possibility of this technology.

However, there are obstacles to address before cloud computing can be deemed reliable. Challenges

related to network latency and bandwidth limitations must tackled. The biggest issue is availability of

service. People will not want to move all of their data to the cloud if they do not feel they can always

reliably access and modify it. Other network-related issues include deadzones, and poor, slow internet

connections. There are many points along a network that can bottleneck transfer speeds.

Another key issue is data confidentiality and security. Users must be assured that their privacy

will remain intact. This will require various types of encryption and layers of firewalls.

Manageability is particularly important in cloud environments. Relative to traditional systems, it is

complicated by three factors: limited human intervention, high-variance workloads, and a variety of

shared infrastructures. [3] In the majority of cases, there will be no system administrators to assist

developers with their cloud-based applications; the platform will have to do much of that work

automatically. Mixed workloads have always been difficult to tune, but may be unavoidable in this context.

Even a single customer’s workload can vary widely over time due to short bursts of work. Furthermore,

unknown bugs seem to occur as datacenters scale upward. Finding these issues and fixing them is a

very difficult task on such a large scale.

5

As more cloud providers enter the market, more proprietary software is offered to users. Variable

storage standards will ultimately hinder cloud computing from growing. Instead, cloud computing needs

standardization. Lastly, from a business perspective, a good software payment model has yet to be

proposed. Will users want to pay buy the hour in order to use Microsoft Word?

1.3 Objective

The goal of this project is to stretch the usual implementation of client-server communications

using the common communication platforms of both JAVA RMI and HTTP (hypertext transfer protocol). It

will create an infrastructure-as-a-service model and analyze the benefits of cloud computing. JAVA RMI

is used as one of the main communication protocols to connect and pass information between the client

and server. The results of the project should show decreased execution times when a client offloads

applications, such as the computationally intensive NASA benchmark tests or chess engine calculations,

to a more powerful server. The capabilities of the server are measured by executing multithreaded

versions of the benchmark tests and by increasing the search depth of the chess engine. A chess game

demonstration will provide a visual and interactive model that displays the advantages of cloud computing

and providing infrastructure-as-a-service. The scalability of this model is also tested by sending multiple

requests on different ports and measuring any execution delay. Finally, security issues will be addressed

by working with the Java security manager and policy file options.

In addition to using a laptop computer as the client machine, an iPhone mobile device as well as

a Google Android mobile device emulator are used to initiate server execution. This mobile cloud

computing framework should further prove the possibilities of IaaS.

The goal of this work is not only to offer an IaaS model, but also to evaluate its potential. Thus,

this research attempts to answer the questions: is Infrastructure as a service a time efficient, viable option

and what are the advantages and limitations of mobile cloud computing?

Research Phases

The first step of this research is to study and identify mobile cloud computing options. This

includes a survey of the existing cloud providers, such as Google and Microsoft, as well as current

research implementations of mobile cloud computing. Next, I build my own small-scale examples.

Implementations begin on desktop machines since this is the most familiar and accessible platform. From

6

there, applications can be ported to mobile devices such as an Apple iPhone and Google Android mobile

device. The applications used as benchmarks include the NASA Benchmark tests and a chess game.

Both were chosen because they involve computationally-intensive code execution and easily changeable

degrees of computation. The CPU power can be tested by increasing the depth of search of these

applications. Two communication protocols are used to implement these cloud computing examples: 1)

JAVA RMI for its accessible use of socket programming and 2) HTTP because of its widespread and

ubiquitous use.

Next, I evaluate those implementations by measuring the advantage through execution times.

The goal of the evaluation step is to answer two main questions: Is cloud computing feasible and

quantitatively advantageous and what are the advantages and limitations of mobile cloud computing? For

comparison purposes, the NASA benchmarks are run on a common desktop machine, the android

device, and remotely on CIC lab servers. The clients used for remote execution include the desktop

machine and the iPhone. Both static and dynamic code offload execution times are recorded in order to

measure the cost of using dynamic code offload.

Remote chess game execution is accomplished through the use of both Java RMI and HTTP.

The Java RMI implementation is only run using a desktop machine as the client and the CIC lab servers

as the remote cloud. It provides an example of dynamic code offload for an interactive application.

Finally, a system using an Android device as the client, Google’s App Engine as the remote server, and

HTTP as the communication protocol is created. Execution times are measured, comparing local mobile-

device-only runtimes with runtimes using the App Engine. This provides a real-world example of mobile

cloud computing and a quantitative analysis of the current power of the cloud.

The quantitative analysis of each of the above experiments will provide the first evidence of the

advantages of cloud computing. In addition, I evaluate the obstacles related to cloud computing, such as

security, network reliability, and infrastructure and programming issues.

1.4 Summary of Contribution

My results show that mobile cloud computing is indeed a viable option and a time-efficient way

to perform CPU-intensive operations. Several cloud computing systems were created and evaluated.

7

Java RMI and HTTP were used in new implementations, as was Google’s App Engine, which is used to

support a mobile application rather than a web-based application. Evaluation results show clear

advantages of cloud computing. Computing execution time on a server vs. a local client machine, the

server completes its calculation in 40% less time. The results are even more drastic comparing a mobile

device with using the cloud, with as much as 99% less time measured by server vs. the mobile device.

Lastly, running a chess game’s decision engine took 30 times longer on an Android mobile device

compared to running it on the Google App Engine. Thus, mobile cloud computing was studied in details

and determined to promise great possibilities

1.5 Thesis Organization

Now I outline the road map of this thesis. Chapter 2 reviews related work in Cloud Computing

and Mobile Cloud Computing. I first discuss current market cloud providers, including Google’s App

Engine, Microsoft Azure , and Amazon’s Elastic Compute Cloud. Then I discuss implementations of

mobile cloud computing including MAUI and a 3-tiered architecture involving cloudlets.

Chapter 3 discusses the design options of cloud computing. Design Options include remote

execution methods, dynamic vs. static code offload, communication protocols, code partitioning, and

number of architecture tiers. These options are discussed with the relevance of mobile cloud

computing in mind.

Chapter 4 outlines the different research implementations of cloud computing. Java RMI is used

to remotely execute NASA Benchmark tests from both a desktop client machine and a mobile device

client machine. Java RMI is also used to remotely execute a desktop chess game. The creation of an

android application that communicates with Google’s App Engine is also summarized. This application is

a chess game and the computer engine is executed remotely on Google’s servers.

8

Chapter 5 summarizes the test results of the above implementations. The execution times of

the NASA Benchmark tests are compared and analyzed. The time to remotely execution code from the

android device is also measured.

Chapter 6 offers further discuss related to the evaluation in the context of cloud computing in

broader terms. Cloud computing performance, reliability, replication, consistency, mobility, and security

are reviewed.

Chapter 7 presents conclusions of this research work. The contributions to this area are also

reviewed. Finally, possible future work is mentioned. In particular, this research could be expanded in

the areas of scheduling, scalability, security, and reliability.

9

Chapter 2 Related Work

2.1 Survey of the State of the Art

Cloud computing is the combination of hardware and software provided remotely as a service;

however, as can be imagined, this can be offered in a wide variety of forms [9]:

Software as a service (SaaS): Complete application systems delivered over the Internet on some

form of "on-demand" billing system. Examples include Salesforce.com, which provides software for

tracking sales, accounts, contacts, etc. and WebEx, which provides online desktop sharing and

conference calling.

Platform as a service (PaaS): Vendors provide development platforms and middleware, allowing

developers to simply code and deploy without directly interacting with underlying infrastructure. Examples

include Google AppEngine and Microsoft Azure,

Infrastructure as a service (IaaS): Raw infrastructure, such as servers and storage, is provided

directly as an on-demand service. Examples include Amazon Web Services and GoGrid.

There are two different ways providers and users view IaaS. The cloud can either act as a

datacenter, strictly providing the hardware to users, or it can provide more services, but less user control.

Cloud Infrastructure providers are in the business of providing you equivalent datacenter functionality in

the cloud using their scale for cost-effective service delivery. They must also package this functionality to

provide you a high level of control as it’s no longer your datacenter.

“Cloudcenters,” datacenters in the cloud, focus on making your Cloud Infrastructure look very

much like infrastructure you already have or are already familiar with, while Infrastructure Web Services

ask you to embrace a new paradigm. Cloudcenters provide a direct equivalent to traditional datacenters

and hence are usually more desirable for IT staff, systems operators, and other datacenter savvy folks.

Infrastructure Web Services on the other hand are more analogous to Service-Oriented-Architectures

(SOA), require significant programming skills, and are much more comfortable for software developers.

The three most popular consumer cloud providers currently are: Microsoft Azure, Google AppEngine, and

Amazon’s EC2. Microsoft Azure and Google AppEngine are closer to the definition of Platform-as-a-

Service then Infrastructure-as-a-Service. In terms of providing IaaS, those two services are limited. Even

10

Amazon’s web service used proprietary protocols, forcing the user to learn and adapt to their methods.

Each is described in more detail below.

2.2 Current Market Cloud Providers

2.2.1 Google App Engine

This is a platform for developing and hosting web applications in Google-managed data centers.

Google-managed is the key word in that sentence because Google maintains tight control over this

service. Below is an example of some of the Google’s restrictions:

• Threads cannot be created; one can only modify the existing thread state.

• Direct network connections are not allowed; URL connections can be used instead.

• Direct file system writes are not allowed; memory, memcache, and the datastore are used

instead. (Apps can read files which are uploaded as part of the apps.)

• Java2D is not allowed.

• Native Code not is allowed; only pure Java libraries are allowed.

Google even places restrictions of the timing of requests. Each request gets a maximum of 30

seconds in which it has to complete or the AppEngine will throw an exception. If you are building a web

application which requires large number of datastore operations, you have to figure out how to break

requests into small chunks such that it does complete in 30 seconds. You also have to design a way to

detect failures such that clients can reissue the request if they fail.

Though seemingly very restrictive, Google App Engine does provide a simple gateway to cloud

computing. Google provides a free software development kit that allows a user to easily setup a servlet

programming environment. Inexperienced web programmers can have their own server running on the

internet fairly quickly. Communication between the client and the app engine uses HTTP requests. Thus,

if required, java objects can be passed to the server using serialization and xml documents. Its

availability and accessibly made App Engine a great choice as a commercial server to use with the

mobile chess application demonstration.

2.2.2 Microsoft Azure

11

Microsoft Azure is an application platform in the cloud that allows applications to be hosted and

run at Microsoft datacenters. It provides a cloud operating system called Windows Azure that serves as a

runtime for the applications and provides a set of services that allows development, management and

hosting of applications remotely. All services and applications run on top of the Windows Azure OS.

As this is a Microsoft product, it is not surprising that development is limited to Microsoft software. Users

must develop on Windows 7, Vista, or Server 2008 and use Microsoft visual studio to write code.

In support of the Azure OS, Microsoft also created three core components:

Microsoft SQL Azure: database

AppFabric platform: connects cloud services and applications running on the platform

Codename “Dallas”: information marketplace for data and web services

As these are all Microsoft-created products, it will take time to become familiar with them. For example,

even though Microsoft’s database is similar to SQL, it is modified with Microsoft functionality. Also, one

can only build apps with .NET, PHP, and Java.

I setup my own azure account and found my experience with Google’s App Engine better overall.

Google provides a great user experience and developer software, which is constantly updated and

supported. Microsoft’s demanding use of their proprietary software was Azure biggest setback.

2.2.3 Amazon Elastic Compute Cloud

EC2 is the central part of Amazon's cloud computing platform, Amazon Web Services (AWS).

EC2 allows users to rent VMs to run their own computer applications. EC2 provides a web service

enabling a user to boot an Amazon Machine Image to create a virtual machine, which Amazon calls an

"instance", containing any software desired.

A user can create, launch, and terminate server instances as needed, paying by the hour for

active servers, hence the term "elastic". EC2 provides users with control over the geographical location of

instances which allows for latency optimization and high levels of redundancy. For example, to minimize

downtime, a user can set up server instances in multiple zones which are insulated from each other for

most causes of failure.

Although this service is more in-line with the IaaS definition, Amazon does introduce proprietary

measures. It provides Xen hosting machines, but image management and storage is completely Amazon

12

customized. Amazon also customized the file system, database, and message protocol, rather than

sticking with industry standards. It does support different kinds of applications, usually a batch processing

or web application of some kind. Amazon’s language of choice is python, but others are supported.

Thus, although Amazon’s features may be familiar, they are not exactly the same as industry standards.

Offloading your work to their cloud will likely require some workarounds, rather than being seamless.

Returning to the idea of cloudcenters, using them should be a comparatively easy transition.

Cloudcenters provide the same kinds of tools that all datacenter and server operators are already

accustomed to, but with all the traditional advantages of cloud (i.e. self-service, pay-as-you-go, and

scalability). Instead of creating completely new paradigms, cloudcenters are a methodology by which

you, the customer, can have a virtual datacenter hosted ‘in the sky’.

Besides the obvious advantage of ‘looking like’ your current datacenter, cloudcenters allow for

strategies like using the Cloud for off-site disaster recovery. It will be much easier to model a copy of your

current datacenter to a cloudcenter than it would be to model a copy onto an Infrastructure Web

Service. It is the Cloud of choice for sysadmins, operators, and Enterprise IT staff who need

infrastructure that looks just their current datacenter infrastructure.

Other research in this area has manly focused on large-scale IaaS, examining VM migration and

scheduling. Instead, this work focuses on IaaS in terms of applications and thread-level management.

2.3 Mobile Cloud Computing

One of the key areas that presents great possibilities for cloud computing is the mobile handset

market. The global mobile phones market grew by 12% in 2006 to reach a value of $104.3 billion at a

volume of 800.2 million units. In 2009 its value was 1.26 billion. In 2011, the global mobile phones

market is forecast to have a value of $211.9 billion at 1.804 billion units, an increase of 103.1% since

2006. [13] In addition, users continue to expect an experience more and more similar to their desktop

computers or laptops when using their mobile devices. Demand is increasing for resource-intensive

applications, such as video games, navigation guides, or location-based social networking. Other

applications could see widespread use if offered, such as augmented reality apps, which automatically

provide the user data from just a picture, or behavior-corrective apps that real-time fact checking.

Healthcare also provides an untapped market. For example, body-worn sensors could become more

13

sensitive through the use of the cloud and doctors could quickly access full databases of patient histories

and receive real-time updates of patient statues.

Computational power and battery consumption are the two main limiting factors of mobile

applications. At any level of technology, considerations of size, weight, battery life, and ease of use lead

to compromises when it comes to computational resources such as processor speed, memory size, and

disk capacity. While mobile hardware continues to evolve and improve, it will always be resource poor

compared to static hardware. Thus many different research teams are investigating ways to connect

mobile devices to the vast resources of the cloud, thereby granting such devices with seemingly limitless

computational power and energy.

2.3.1 Mobile Cloud Computing Categories

It is possible for mobile devices to use the cloud for a variety of services. The three main areas

mobile cloud computing can enhance are computation, data storage and search, and communication.

These are the three focus areas since cloud computing offers seemingly limitless resources through

remote computation, remote memory management and search, and communication methods that utilize

internet networks and the web.

Utility Computing: Remote Computation

Often called utility computing since it adds functionality, using the cloud for remote computation

introduces many benefits for mobile computing. One huge advantage is that the mobile devices can save

a considerable amount of energy and battery life since their CPUs are required to do less work. Also, it

gives cell phones the illusion of unlimited computing power since programs can run on clusters of servers

rather than a single gigahertz processor.

Mobile cloud computing achieves remote execution through code replication, process/function

migration, or VM migration of the entire operating system. Through remote execution applications can

take advantage of the resource-rich infrastructure by delegating code execution to remote servers. Code

replication creates a copy of the program code on the server prior to execution. When communication is

possible, the program executes all or certain parts of the code, determined by the programmer, on the

server and delivers the results back to the client. Process, or function, migration offloads the

computationally intensive parts of the code to the server at runtime. Again, this method relies on the

14

programmer to choose which methods are resource or CPU-intensive and should be executed on a more-

powerful server. The third popular technique is to use full process or full VM migration in which individual

applications or entire OSs are offloaded on run on the cloud infrastructure.

Example applications that could utilize offloading computation to the cloud include entertainment

applications, such as video games, high resolution image rendering, and scientific data analysis.

Specially, applications that can efficiently utilize parallel computing.

MAUI

One research implementation of remote execution is MAUI. [15] MAUI focuses on energy

savings. It can best be described as a dynamic system that decides whether methods should be

migrated and run remotely. It relies on the programmer to choose which methods are considered

“remotable,” then, based on network conditions, offloads those methods at runtime. It uses code

portability to create two versions of a smartphone application: one that runs locally on the smartphone

and the others that runs remotely in the infrastructure. If a disconnect occurs, MAUI resumes running the

method on the local smartphone. The MAUI system is broken up into three parts on the client: the

interface, proxy, and profiler, and four parts on the server: the proxy, profiler, solver, and coordinator.

The profiler runs on both because it instruments the program and collects measurements of the

program’s energy and data transfer requirements. The solver is a decision engine which periodically

determines the practicality of running remotely.

Since my project focuses on time rather than energy, I made a few different decisions while

implementing remote execution. Instead of requiring the smartphone to profile the program while running,

I remove all decision-making requirements from the phone so as to avoid any time penalty. Both the

NASA Benchmark application and the android application will always contact the server to run the CPU-

intensive code. Due to the nature of the chess game application, slight lag due to network latency is

tolerable. This removes any extra time needed to profile the program and decide whether or not to

offload. Also unlike MAUI, the android application does not maintain constant contact with the server.

Instead, the application contacts the server when it’s the computer player’s turn and closes contact once

it retrieves the computer’s move.

Data

15

Due to physical size limits, mobile devices offer limited local memory for storing data. The cloud

offers vast amounts of memory for storing personal user data. It can also provide automated data

management with sophisticated algorithms that can automatically organize your data to your

specifications. Not only does the cloud offer unlimited storage and control of personal data, but also

access to clusters full of world knowledge and peer user’s public data. Access to this much information

would be impossible on a mobile device alone. By connecting to the cloud, a user is able to initiate

searches on the data in the cloud, like performing a google search of the web or finding a location in

google maps. This type of search is related to the Software as a Service class of cloud computing. By

being able to perform these searches virtually anyway, cell phones become “powerful killer application

enablers.” [19] Cell phones more and more are becoming information hubs – a user’s link to all of their

personal data. As information hubs, they are the crossroads of personal information such as mail,

schedule, address, picture, and music. Therefore, cloud computing provides enhanced storage and

usage of personal data. One key factor to realize and capitalize on is context awareness: how all of that

information is connected and related. Context awareness can translate into targeted advertizing and new

ways to generate revenue for the cloud. An example is an application that teaches users lyrics of stored

music also promotes a social network that allows users to add, edit and synchronize lyrics to audio and

video files in all languages; and displays location based charts and maps of music played around the

globe. Mobile cloud computing could also help the health industry by enabling remote diagnostics

through access to patient data in the cloud, as well as enabling universal patient files that are always

complete and current.

Just as google provides a gateway to search websites on the internet, you’ll be able to search

information provided by fellow mobile device users connected to the cloud. Mobile device users are

capable of creating and adding to a pool of real-time information. In addition to being able to access vast

amounts of static data, a user will also be able to benefit from more relevant, real time data. For

example, information about parking spots or traffic. Or a user could search his peer’s information for the

best local restaurant with the shortest wait times. Since mobile devices are always on hand, they provide

a way to change and take advantage of dynamic information; i.e, information that is always changing,

such as traffic or social news.

16

The Mobile Web

As mentioned In an IEEE panel discussion about “Mobile, cloud, and Crowd Computing,” the

panelists discuss using cell phones to create a sensor hub. Using cell phones as sensors makes sense

since most smartphones are not being equipped with various I/O devices, such as GPS, picture and video

cameras, and microphones. Combining this information with a user’s data as well as other peer’s data in

the cloud creates a real-time content acquisition and delivery network. This virtual mobile sensor network

is the clear distinction between mobile web and internet web. Most users have their mobile device with

them at all times. However, applications such as speech diction need backend servers to perform the

computationally intensive work that a small mobile device cannot. Furthermore, visual of pictures taken

from camera phones need to be able to access the vast amounts of information in the cloud in order to

produce the best information. For example, the Google Goggle application is capable of integrated

character recognition and finger print identification of CD titles and sightseeing picture. Another

application could track a user’s location, automatically updating their social media status and prompting

ads for local business.

The key factors of the mobile web are obtaining and aggregating information in one place and

reaching critical mass via total number of users so that the data can be turned into a system service. But,

none of this could be possible without cloud computing

2.3.2 Mobile Cloud Architecture

Due to network reliability issues it may be necessary to incorporate a third tier in between the

existing 2-tier platform. The current cloud computing model includes only the mobile device connecting to

more-powerful servers in the cloud. By adding a go-between layer, latency observed by the mobile

device may diminish.

Cloudlets

There are many discussions about the limits of the cloud, especially as it pertains to mobile

devices. One such article was published in IEEE’s Pervasive Computing journal: “The Case for VM-

based Cloudlets in Mobile Computing” (November 2009, co-authored by MSR’s Paramvir Bahl along with

colleagues from Carnegie Mellon University, AT&T Research, and Lancaster University). The authors of

this paper make a valid point about mobile devices; they argue that “Resource poverty is a fundamental

17

constraintG On hardware that people carry or wear for extended periods of time, improving size, weight

and battery life are higher priorities than enhancing compute power. This is not just a temporary limitation

of current mobile hardware technology, but is intrinsic to mobility. Computation on mobile devices will

always be a compromise.” The authors of this paper propose what they call “cloudlets,” which represents

a 3-tier model of mobile cloud computing. Instead of the traditional 2-tier model that connects the mobile

device directly to the cloud, they introduce a third, middle tier. They propose this model to solve the issue

of poor or slow connections to the cloud. The reasoning behind this involves the speeds of Wireless LAN

bandwidths (400 Mbps) compared to wireless Internet bandwidth (2 Mbps) available on a mobile device.

From the viewpoint of use interaction, latency at these bandwidths can vary significantly: 80 ms versus 16

seconds for a 4MB JPEG image. [16] This difference can be drastic for a deeply immersive application.

One requirement for the cloudlet to be effective is physical proximity of the mobile device. Only this

enables fast end-to-end, predictable response times of applications executing in the cloudlet. If no

cloudlet is available nearby, the mobile device can fallback to using a distant cloud or, in the worst case,

solely its own resources. As soon as a nearby cloudlet is discovered, the mobile device will automatically

join it to increase performance.

The authors argue that Cloudlets could provide easier and quicker VM migration. They focus on

VM migration instead of process migration because it is less brittle, less restrictive, and more general than

language-based virtualization approaches that require applications be written in a specific language such

as Java or C++. Their mobile cloud system preloads a base VM on the cloudlet. Called dynamic VM

synthesis, the client device delivers a small VM overlay to the cloudlet, which then applies the overlay and

begins execution right where it left off on the mobile device. Their biggest challenges entail deployment

and performance issues.

While the authors of this paper resent a novel idea, they made many assumptions about both the

hardware and software infrastructure needed for Tier-3 model. More “datacenter-in-a-box” devices will

need to be added to create the cloudlet. This alone could be a large undertaking when you consider the

economic, legal, and even political issues to overcome. They also anticipate that a relatively small

number of base VMs will be popular worldwide. It may be awhile before such standards are achieved in

such a competitive market. In the end, the future of technology is always a guessing-game no one can

18

reliably predict. However, it seems that the consumer’s demand for faster network speeds will be more

important than the more focused market of mobile devices. With this in mind, cloudlets may not be

implemented as the authors envision. Since high speed wireless broadband networks could solve the

same problem, cloudlets may or may not be needed to link mobile devices to the high speed cloud. Thus,

my research has a more narrow focus on the applications rather than the rapidly changing internet

delivery network.

2.4 Sidebar on Google’s High Speed Network

Google’s 1 GB network fights claims of low bandwidth. Google is currently testing an ultra high-

speed broadband network in a small number of locations across the United States. This network delivers

speeds of 1 GB per second using fiber-to-the-home connections, which provides speeds more than 100

times faster than the average American can access to today. They want to experiment with new ways of

making Internet access faster and better for everyone. Google is focusing on three specific points for this

experiment: next-generation apps, new deployment techniques, and openness and choice. With 1 GB

speeds next-generation apps may allow streaming of three-dimensional medical imaging over the web or

downloading a high-definition feature film in less than five minutes. [17]

Google already offers free citywide Wi-Fi in Mountain View, CA, the headquarters of the

company. Partnering with the city, Google has mounted over 500 nodes, mostly on light poles, to setup

the network. There, they are testing applications, such as Wi-Fi in polices cars, a cheaper and faster

alternative to cell phones, or Wi-Fi water meters, eliminating the need for manual readers. [18] If this new

high speed Wi-Fi network grows and is adapted by more communities, the question becomes how mobile

devices will fit into the picture. Will it be easier to have the devices connect to distant, already-in-place

datacenters, as in the Tier-2 architecture, or will it still be advantageous to have the devices connect to

local machines over the local area network as in the cloudlet model? It all depends on whether the

network is provided wirelessly and not just through fiber optic cable, which would allow Wi-Fi-enabled

mobile devices access to it.

19

Chapter 3 System Design

3.1 Remote Execution Methods

The first choice that needed to be made is how to implement remote execution. As mentioned

previously, there are two main options: method/function migration and VM migration of the entire OS. I

chose to work with function migration as the focus of my research has a more narrow scope dealing with

individual applications. This holds true for both the remote execution of the NASA Benchmarks and

desktop chess game using Java RMI as well as the android chess application using HTTP to connect to

Google’s App Engine.

3.2 Dynamic vs. Static Code Offload

The next step was deciding how to load the executable code on the server: dynamically at

runtime or statically before the application is run. Dynamic code-offload allows for more flexibility as far

as updating an application or choosing when to use remote execution. However, it requires more data to

be passed over the communication channels as entire methods need to be serialized and transferred.

The programmer must also ensure that any dependencies or required objects are passed along with the

main execution method. Pre-loading code requires more server administration, especially when updates

are needed; conversely, it requires less data to be passed between client and server, making it faster and

easier to implement. In either scenario, there needs to be some sort of framework installed on the server

that is ready to receive the executable code regardless of dynamic or static installation. In the case of

Java RMI three main classes are required: a class that makes the socket connections, a class that calls

the executable file and an interface with function calls to the executable class file. Thus, while the

function of an executable file may chance, some aspects, such as the method calls, need to remain the

same if the same server framework is used. I actually implement both dynamic and static code offload,

which is discussed further in the implementation section. This introduces another design option: which

communication protocol to use.

3.3 Communication Protocols

20

I decided to use two different protocols: Java RMI and HTTP. Using Java RMI gives the

opportunity to test delivering a java-based infrastructure platform-as-a-service. Using HTTP allows for

more general communication as many programming languages and applications are able to work with it.

Java RMI provides for synchronous communication between client and server. When the client sends the

request, it does not continue execution until it receives the result in the response from the server. Using

HTTP requests, it is possible to provide both synchronous and asynchronous communication.

Asynchronous communication could be useful by allowing the client interface to respond to user input

while the server is executing the CPU-intensive code. It also provides for a more reliable application

since it would be less likely to crash due to a dropped connected whereas synchronous applications

depend on a stable connection.

3.4 Code Partitioning

Once the framework and communication protocols, Java RMI and HTTP requests in this case,

are in place the next step is to decide exactly which part of the code to execute remotely. There are

certain pieces of code that will never be able to be removed from the client machine. User interface code,

interactions with I/O devices, and any functions that interact with third party components will need to be

run locally. Hardware examples include measurements from accelerometers or GPS chips. Third party

connections pose difficulties related to reliability and network connections. E-commerce websites are the

perfect example as one wouldn’t want to lose their money to purchase if a connection between the server

and third party was dropped without warning or backup. This setup would also make security more

difficult since it adds a node in any authentication route. Security would need additional layers to prove

ones identity as well as the trustworthiness of the server.

The key is deciding the part of code to offload is identifying the computationally-intensive portion.

There have been many research papers produced on just this subject, so it will not be discussed in depth

here. For the purposes of this research, the simplest notifiers of CPU-intensive code are recursive loops

and iterations, such as depth searches for a chess game or repetitions needed to solve numerical

equations (as seen in the NASA Benchmark tests). It is much more difficult to attempt to partition existing

code than it is to design an application with remote execution in mind from the beginning. This process is

made much simpler for the network engineer if the programmer identifies the portions of code that may be

21

executed remotely. The authors of the MAUI paper agree with this idea and direct programmers to

identify code as “remoteable” so that their execution system can dynamically decide whether or not to

offload the remotely executable code. [15] So, as you can see, code partitioning can affect offloading and

vice versa. As mentioned above, code can be offloaded to the server either statically before-hand or

dynamically at execution time. If programmers provide for it, dynamic code offload can make execution

much more efficient.

3.5 Extraction Requirements

Once the code is partitioned, extraction requirements need to be examined. Specifically, what

objects, libraries, and classes does the remote code need to run? These elements of the code need to

be offloaded with the execution code for it to run properly. The most common way to pass objects is to

use serialization so that the cod can be passed as a string of bytes. Both Java RMI and HTTP support

serialization. With HTTP it is best to incorporate xml to wrap the serialized object in xml code and send it

using an HTTP request. Lastly, runtime parameters as well as the required results of the remote

execution need to be passed at runtime.

3.6 Architecture Choices

All of the previous design options have assumed a 2-tier architecture, but there are also models

for a 3-tier architecture. As discussed in the related work section, “cloudlets” can be added to the existing

2-teir architecture in an effort to provide faster, more reliable network connections for mobile devices.

Cloudlets require adding an additional computing machine, whether a router or desktop running a server,

to your local area network. The mobile device connects to this machine, which than connects to the

cloud. I actually implement two different cloud computing models that utilize both 2-tier and 3-tier

architectures.

One last feature to mention is interchangeability: allowing for different remote execution code and

different clients. While this is a plus because it provides more flexibility, it is not always feasible.

22

Chapter 4 System Implementation

4.1 Outline

As is evident from the previous discussion, there are many definitions of ‘cloud computing’ and

many implementation options. I created three categories of tests: Java RMI NASA Benchmarks, a Java

RMI Chess game, and an Android App Engine chess game. The applications used as benchmarks

include the NASA Benchmark tests and a chess game. Both were chosen because they involve

computationally-intensive code execution. Two communication protocols are used to implement these

cloud computing examples: 1) JAVA RMI for its accessible use of socket programming and 2) HTTP

because of its widespread and ubiquitous use.

Implementations of the Java RMI ASA Benchmarks begin on desktop machines since this is the

most familiar and accessible platform. From there, the application is ported to mobile devices such as an

Apple iPhone and Google Android mobile device. The NASA iPhone application is executed remotely

using dynamic code offload from a desktop on the same LAN. The NASA Benchmarks are also run

locally on a desktop machine and locally on an android device for comparison purposes.

Similarly, the Java RMI Chess Game is run locally on desktop and remotely from a desktop to

WSU servers using dynamic offload.

The last implementation involves an Android to App Engine chess game that executes using

static offload and HTTP communication.

4.2 Java RMI NASA Benchmark

4.2.1 Java RMI

RMI is Java’s application programming interface that performs the object-oriented equivalent of

remote procedure calls (RPC). It is key to this project since it provides for communication and data

exchange between the client and server. In order to run the Java RMI system, certain java script files are

installed on the server as well as the host. Obviously, the class files as well as the imported java

packages of the NASA Benchmark test need to be installed on the server. There is a certain file, called

the stub file, which is generated through compilation that needs to be saved on both the client and the

server. This is the file that links the client to

complied without errors, the RMI Registry is run on the server side. Next, the class file on the server that

links to the client is started. Finally, the class file on the client side that in

the command line. When the client file is run, it prompts the user for any required input and then directs

the server to run the NASA Benchmark test. Any user input arguments are sent to the server. Once the

test is finished running on the server side, a message is sent back to the client including the results or

error messages. As you can see from this example, the user should be oblivious that the program was

run remotely. The following figure presents a visual example

4.2.2 NASA Benchmarks

In order to test my IaaS system, I needed a proper application that could potentially be offloaded

to the server. This application needed to be very computationally intensive so that a less powerfu

device would struggle to run it. Additionally, if the application could be multithreaded, even more of the

server’s power capability could be utilized. Thus, I used a series of mathematically intensive code

23

server. This is the file that links the client to the server and allows communication. After all Java files are


links to the client is started. Finally, the class file on the client side that interacts with the user is run on



hed running on the server side, a message is sent back to the client including the results or


The following figure presents a visual example of the flow of the Java RMI process.


to the server. This application needed to be very computationally intensive so that a less powerfu



FIGURE 2: JAVA RMI COMMUNICATION FLOW

the server and allows communication. After all Java files are


teracts with the user is run on



hed running on the server side, a message is sent back to the client including the results or


of the flow of the Java RMI process.


to the server. This application needed to be very computationally intensive so that a less powerful mobile



24

segments created by NASA that run different types of benchmark tests. These applications presented

the optimal choice since they are written in Java and all have the option of choosing the number of

threads to use while running the programs.

These benchmarks were developed at NASA Ames Research Center to compare the

performance of parallel computers and are recognized as a standard indicator of computer performance.

The Numerical Aerodynamic Simulation (NAS) Program, located at NASA Ames Research Center, is a

pathfinder in high-performance computing for NASA and is dedicated to advancing the science of

computational aerodynamics. [8] The NAS Benchmarks consist of a set of eight benchmark problems,

each of which focuses on some important aspect of highly parallel supercomputing for aerophysics

applications. The implementation is available as the NPB3.0-JAV package from www.nas.nasa.gov.

Hardware Specifications

For my work with JAVA RMI as the communication protocol, I execute the java code in either a

Linux or Windows operating system environment on a desktop computer with an Intel Pentium Dual CPU

E2160 1.8 GHz processor and 2.00 GB of ram. I connect to the remote server’s IP address using an

Ethernet switch over a LAN with a connection speed of 100mb. The server has an Intel Core 2 Due

E2700 2.66GHz processor and is capable of running virtual machines of up to 8 cores and 8 GB of ram.

A Linux based virtual machine was installed on the server as the base operating system environment.

4.2.3 Remotely: Desktop to WSU servers

There are two ways I used Java RMI. One way involves pre-loading the class files on the server

and simply initiating their execution from the client. Another way, which emulates an IaaS model, only

requires a few interface classes to be installed on the server to provide for open registry ports and

communication with the client. In this scenario, the user can write code on their local machine and upload

it on-demand for execution by the server in ‘the cloud.’

4.2.4 iPhone Implementation Using a Distributed File System

I was able to access the iPhone’s Linux-based operating system using its mobile terminal and

install the latest version of Java. I then enabled SSH protocol on it and copied the necessary files onto

the phone. This allowed me to run the java files to tell the server to execute the NASA benchmarks by

downloading the files from a separate computer running a web server. Figure 2 below shows how this

works.

4.3 Java RMI Chess Game

I choose to use a chess game as a visual and functional model of IaaS. I use the second

implementation of Java RMI so that chess code can be dynamically downloaded by the server. The

challenge of this implementation was extracting the computationally int

that the server would run that portion while the client machine runs the

diagram above demonstrates the code

FIGURE

25


Chess Game


so that chess code can be dynamically downloaded by the server. The

challenge of this implementation was extracting the computationally intensive part of the chess game so

that the server would run that portion while the client machine runs the graphical user interface.

demonstrates the code execution.

FIGURE 3: RMI USING A DISTRIBUTED FILE SYSTEM

FIGURE 4: CHESS GAME EXECUTION



so that chess code can be dynamically downloaded by the server. The

ensive part of the chess game so

user interface. The

26

4.3.1. Small HTTP Server for Dynamic Code Offload

The server downloads the code from the client machine. Java RMI makes this possible using

HTTP communications. This means that I had to run a HTTP server on my client machine. I was able to

find a free, small application online that turns your computer into a fully functional Web-server. As long as

the files-to-be-transferred were placed in a certain directory, the server could reach them given my

computer’s IP address.

4.3.2 Sending Multiple Requests

I tested if it were possible to send and execute multiple concurrent requests on the server. I did

this by manually opening new registry ports and sending new requests to those ports. Initial testing

showed that it was possible to run multiple NASA benchmarks on the server at the same time with little

effect on the execution time. In fact, run times were nearly identical compared to sending only one

request. I did not have the time to try to overload the system by sending multiple requests. But, I think

this exercise would help to show the scalability of this model and the point at which another physical

machine would be needed for more requests.

4.4. Java RMI Security

Downloading class definitions of Serializable classes often violates system security. For

example, RMI will download a Serializable class from another machine only if a security manager permits

the downloading of the class from that machine. Java provides a way to make communications more

secure through the use of such a security manager and policy files. Both the server and client programs

run with a security manager installed. When either program is run, a security policy file is specified so that

the code is granted its required security permissions. The basic format of a policy file is:

grant signedBy "signer_names", codeBase "URL" {

permission permission_class_name "target_name", "action",

signedBy "signer_names";

}

Code being executed is always considered to come from a particular "code source." The code source

includes not only the location (URL) where the code originated from, but also a reference to the certificate

containing the public key corresponding to the private key used to sign the code. Certificates in a code

source are referenced by aliases from the user's keystore.

certificate for public/private key par. The public key within that certificate is used to verify the digital

signature on the code. Thus, a signer signs the code using a private key, then uses the policy file to grant

certain permissions. A codeBase value indicates th

code from that location.

Another security obstacle is firewalls on both the client and server. I had to disable the firewall on

my local machine to allow the server to download files from it. However,

communication through a firewall using HTTP tunneling, proxies, or simply

4.5 Google Android to App Engine Chess Game

The goal of this experiment was to enable the Android device to connect to

Engine. A chess game application would connect to Google’s cloud, which would execution the chess

engine code and return the computer player’s next move.

4.5.1 Communication Protocol: HTTP

This setup uses HTTP as the communication protocol to execute a chess game application on a

mobile Android device, displaying the possibilities of mobile clo

Protocol (HTTP) is a networking protocol for distributed information systems and

27


source are referenced by aliases from the user's keystore. A signedBy value indicates the alias for a

public/private key par. The public key within that certificate is used to verify the digital


A codeBase value indicates the code source location; you grant the permission to


my local machine to allow the server to download files from it. However, it is possible to allow RMI

communication through a firewall using HTTP tunneling, proxies, or simply allowing certain ports through.

Google Android to App Engine Chess Game

The goal of this experiment was to enable the Android device to connect to


engine code and return the computer player’s next move.

4.5.1 Communication Protocol: HTTP


mobile Android device, displaying the possibilities of mobile cloud computing. The Hypertext Transfer

rking protocol for distributed information systems and is the foundation of data

FIGURE 5: GOOGLE ANDROID TO APP ENGINE


A signedBy value indicates the alias for a

public/private key par. The public key within that certificate is used to verify the digital


e code source location; you grant the permission to


it is possible to allow RMI

allowing certain ports through.

The goal of this experiment was to enable the Android device to connect to the Google App



The Hypertext Transfer

is the foundation of data

28

communication for the World Wide Web. In the client-server computing model, HTTP functions as a

request-respond protocol. The client sends a request to the server, which then responds with content

such as images or HTML files. The server is also capable of performing functions on behalf of the client:

this is how HTTP is utilized by cloud computing.

4.5.2 Android Development Mobile Device

The HTC Android Development Mobile Device was the best choice for a development platform.

The device was chosen because it runs the Android Operating System, developed by Google. The model

used for this research ran the Android 2.2 platform. Its hardware specifications include 512Mb flash

memory, 512Mb RAM, Wi-Fi (802.11b/g), High-Speed Uplink Packet Access (HSUPA) at 2 Mbps, and

High-Speed Downlink Packet Access (HSDPA) at 7.2Mbps.

Google has made all of the source code available to download online. Google also provides the

Android SDK, software development kit, which allows a programmer to create, write, and test applications

to be run on the Android operating system. This software emulates the environment of the mobile device

on a computer so that applications can be tested and debugged before being uploaded to the physical

device. The image below displays the Android emulator.

FIGURE 6: ANDROID EMULATOR RUNNING THE CHESS GAME

29

4.5.3 Google App Engine as the Remote Server

The App Engine uses the Java Servlet standard for web applications. A programmer provides an

app's servlet classes, JavaServer Pages (JSPs), static files and data files, along with the deployment

descriptor (the web.xmlfile) and other configuration files, in a standard WAR directory structure. App

Engine serves requests by invoking servlets according to the deployment descriptor. For the chess

engine implementation, I include the chess engine files among static files that are deployed to the App

Engine.

In this remote chess application, the only function of the server is to perform the computation of

deciding where the computer player should move next. It stores game info such as the location of all of

the pieces on the board. Thus, every client request asking for the next computer move sends the last

move of the client user so that the client and server game boards are synced. The client takes care of all

of the user interface tasks so that a continuous connection is not necessary.

4.5.4 Remote Execution

It was decided to pre-load the code for the chess engine on the server rather than support

dynamic code-offload. This decision was made because using a server to run the chess engine will

almost always be more efficient than running the engine on the mobile device. Furthermore,

communication costs can be lower this way since less data needs to be exchanged between the mobile

device and the App Engine. Rather than waste time and power deciding whether or not to offload the

chess engine code, that decision is pre-made so that the server will always be used. A good addition to

this application would be allowing the game to switch to a local chess engine on the device if a

connection to the App Engine cannot be made. This would not be too difficult to implement and would

still allow game play if remote communicate was impossible.

The original application only supported one client at a time. However, multiple clients could be

supported if the App Engine’s Mem Cache or Datastore were utilized. Similar to cookies for websites, the

client could set the user name along with a request and the server could user that name as the key to

locate the saved game stored in the value field of the datastore. This setup would provide more robust

persistent storage. Additionally, App Engine provides support for Oauth and OpenID authentication.

30

Thus, either of these authentication methods could be used to verify the identity of a user before a saved

game could be accessed.

4.5.5 The Client Android Application – App Inventor

Google’s App Inventor was used to design and create the interface for the chess game

application. App Inventor provides a block programming model instead of strictly code in order to create

Android apps. While the App Inventor is great for designing an interface and building an app quickly, it

provides decreased functionality and flexibility in the long run. For example, in order to send HTTP GET

requests, the TinyWebDB widget was used. This widget is meant to connect an application to an online

database, thus it was the only way to get HTTP requests. The requests and responses needed to be

formatted with specific parameter values as json objects, thus; communication between client and server

was much more limited than desired. Below is a screenshot of the App Inventor, which is run directly in

Google’s Chrome internet browser.

FIGURE 7: APP INVENTOR INTERFACE IN CHROME BROWSER

31

Chapter 5 Evaluation

The goal of the test systems is to answer to main questions: 1) is cloud computing feasible and

quantitatively advantageous, and 2) what are the advantages and limitations of mobile cloud computing?

For comparison purposes, the NASA benchmarks are run on a common desktop machine, the

android device, and remotely on CIC lab servers. The clients used for remote execution include the

desktop machine and the iPhone. Both static and dynamic code offload execution times are recorded in

order to measure the cost of using dynamic code offload.

Remote chess game execution is accomplished through the use of both Java RMI and HTTP.

The Java RMI implementation is only run using a desktop machine as the client and the CIC lab servers

as the remote cloud. It provides an example of dynamic code offload for an interactive application.

Finally, a system using an Android device as the client, Google’s App Engine as the remote server, and

HTTP as the communication protocol is created. Execution times are measured, comparing local mobile-

device-only runtimes with runtimes using the App Engine. This provides a real-world example of mobile

cloud computing and a quantitative analysis of the current power of the cloud.

A chess game was chosen as the demo application because it could easily allow the evaluation

to focus on user experience. A chess game’s engine can be made “smarter” by increasing the search

level of the search algorithm. Thus, it provides a means to evaluate two conflicting consumer demands:

game response time and the game’s level of intelligence. This struggle is also related to the conflict

between battery conservation and a game’s functionality since the “smarter” the game is, the more CPU

power it uses, and the more energy it will drain as it runs.

Chess is a two player board game played on a checkerboard of 64 squares arranged in an eight

by eight grid with 32 total pieces; 16 for each player. There are six different types of pieces: eight pawns,

two knights, two rooks, two bishops, one queen, and one king. Each piece has different rules for how it is

allowed to move. The object of the game is to overtake the opponent’s king by positioning your pieces in

such a way that the opponent’s king has nowhere to move. Because of the variety of moves of each

piece, chess is a very complicated game. The number of legal positions in chess is estimated to be

32

between 1043

and 1047

, with a game-tree complexity of approximately 10123

. Because there are so many

moves, the problem size is large enough to run the chess engine on a cluster of servers.

One popular algorithm for a chess game is the minimax algorithm. Minimax (sometimes minmax)

is a decision rule used in for minimizing the possible loss while maximizing the potential gain.

Alternatively, it can be thought of as maximizing the minimum gain. It is a recursive algorithm for

choosing the next move in an n-player game, usually a two-player game. A value is associated with each

position or state of the game. In the case of chess, each position of a piece is assigned a static value so

that each move is given a score when the algorithm runs. The move that is calculated to have the best

score is chosen as the best move to make. This move minimizes the maximum possible payoff for the

other player, hence the name minimax.

You can limit the minimax algorithm to look only at a certain number of moves ahead. This

number is called the "look-ahead" or “search-depth”, measured in "plies". For example, the chess

computer Deep Blue (that beat Garry Kasparov) looked ahead at least 12 plies, then applied a heuristic

evaluation function. In my chess evaluation I measure the chess running at a search depth from 3 to 7.

The algorithm can be thought of as exploring the nodes of a game tree. The number of branches

of the tree is the average number of children of each node, which is the average number of legal moves

in a position for chess. The number of nodes increases exponentially with the search depth. The number

of nodes to be explored for the analysis of a game is approximately the branching factor raised to the

power of the search depth. It is therefore impractical to completely analyze games such as chess using

the minimax algorithm. This chess engine also applies alpha-beta pruning to speed up the time needed

to calculate the next move. Alpha-beta pruning is a search algorithm which seeks to reduce the number

of nodes that are evaluated by the minimax algorithm in its search tree. It stops completely evaluating a

move when at least one possibility has been found that proves the move to be worse than a previously

examined move. Such moves need not be evaluated further

The quantitative analysis of each of the above experiments provides evidence of the advantages

of cloud computing. In addition, I evaluate the obstacles related to cloud computing, such as security,

network reliability, and infrastructure and programming issues.

5.1 Evaluation Methodologies

33

The most important unit of measurement for this research is time, specifically execution time of

an application. Execution time is measured on a desktop machine, laboratory servers, an iPhone, an

Android mobile device, and Google’s App Engine servers. These measurements will provides a means to

analyze the viability of mobile cloud computing and evaluate whether executing code remotely on more

powerful servers is advantageous. Time needed to communicate with remote servers will also be

measured in order to analyze the added communication cost of remote execution. Furthermore, with

an interactive game, measuring time is important in terms of user experience and the quality of play. It

is effective in analyzing the tradeoff between responsiveness and the level of intelligence of the

computer engine.

5.2 NASA Benchmarks Evaluation

Below are the results of running the MG NASA benchmark test on the local desktop as well as

remotely on the server.

TABLE 1: MG BENCHMARK RUN TIMES

Table 1 shows the averages of running the benchmark on both machines using different numbers

of threads. The time to run the benchmark test was calculated and returned by the NASA Benchmark

application itself, which I call “NASA Time.” The command line function, ‘time,’ was used to measure the

total execution time, starting from when the user hits the enter button to when the results are returned to

the user. I call this measurement “Total Time.” The same results are displayed in the following figure 8.

FIGURE 8: MG BENCHMARK RUN TIMES

Threads

Server Total Server NASA Time ClientTotal Client NASA

1 10.60 5.22 27.20 16.95

2 7.80 2.89 12.85 5.87

4 7.00 2.08 12.35 5.91

6 7.10 2.19 11.85 6.11

8 6.15 2.15 11.85 6.02

Total Time (s)

Each of the bars represents the average number of seconds for each test run using a different

number of threads. As you can see from the chart, the tests run on the server are significantly faster than

the tests run on a local machine. Using one thread, the run time on the server is 40% of the time it took

to run the same test on the local machine. It appears tha

results, but this is probably due to the nature of the benchmark test.

The chart below is the execution times of the BG benchmark test run using four thr

included this test because it is on the timescale of minutes rather than seconds.

34

FIGURE 9: BG BENCHMARK TEST


As you can see from the chart, the tests run on the server are significantly faster than


to run the same test on the local machine. It appears that using more than one thread produced similar

results, but this is probably due to the nature of the benchmark test.

The chart below is the execution times of the BG benchmark test run using four thr

included this test because it is on the timescale of minutes rather than seconds.


As you can see from the chart, the tests run on the server are significantly faster than


t using more than one thread produced similar

The chart below is the execution times of the BG benchmark test run using four threads. I

As you can see, running the test on the server still shows a considerable time advantage, like the

other benchmark test.

The following chart compares the two RMI

the model that preloads the required files on the server, similar

model I use to mirror an IaaS environment. As expected RMI 1

needed for the server to dynamically download files. However, the time difference is only 30 seconds

longer, which represents the time needed to upload the files to the server. This is easily a tolerable time

for the amount of added functionality.

FIGURE

The last results of the NASA Benchmarks tests

device. The chart below displays

server vs. on the mobile device.

offloading work to the cloud using IaaS.

35


The following chart compares the two RMI methods mentioned previously. “RMI 2

the model that preloads the required files on the server, similar to Software-as-a-Service. “RMI 1

S environment. As expected RMI 1 total execution is greater since time



for the amount of added functionality.

URE 10: DYNAMIC VS. DEDICATED SERVER

of the NASA Benchmarks tests show the testing done on the iPhone mobile

displays the extreme time difference running a NASA Benchmark test on the

These results present possibly the most convincing argument of

offloading work to the cloud using IaaS.


ds mentioned previously. “RMI 2” represents

Service. “RMI 1” is the

total execution is greater since time is



show the testing done on the iPhone mobile

running a NASA Benchmark test on the

the most convincing argument of

36

Server Laptop iPhone

Total Time (s) 7.00 12.35 541.75

NASA Time (s) 2.08 5.91 64.42

Total time includes communication cost and NASA Time; NASA Time strictly measures the CPU-intensive

execution time.

Lastly, though I did not record quantitative data, the Java RMI chess application proved to be a

good demonstration of separating and offloading the computationally intensive portion of a program to a

server.

5.3 Android App Evaluation

The following chart shows the execution runtimes computing the local execution on the android

device to remote execution on the app engine servers. The android phone is connected to the internet

(and App Engine) over Wi-Fi. The times for the server include network communication costs and any

latency.

Depth

Total

Nodes

Mobile Total

time (ms)

Server Total

Time (ms)

4 2064 7317 255

5 104525 343436 2130

7 209057 592359 4500

As you can see, even at a small search depth of 4, the Android device took 30x longer to execute

than connecting to the App Engine. At a search depth of 7, the numbers grow to over 100x longer,

proving that utilizing the resources of the cloud from a mobile device can vastly improve performance. A

larger search depth increases the number of nodes considered exponentially. The number of nodes

TABLE 3: EXECUTION TIMES OF MOBILE DEVICE AND APP ENGINE SERVER

TABLE 2: EXECUTION TIMES OF SERVER, LAPTOP, AND IPHONE RUNNING A NASA BENCHMARK TEST.

37

relates to the number of different piece moves considered by the computer player. A larger search depth

also means that the computer looks more turns ahead when calculating the score of a particular move to

measure how good the move is.

Ave. RTT Google App Engine 43.7ms

Location of App Engine Servers Mountain View, CA ~ 2400 mi

The round trip time from the mobile device in Detroit, MI to Google’s App Engine in Mountain

View, CA is minimal, especially in the context of the entire request-response time measured by the mobile

device. A traceroute was also done is trace the hops taken to Google’s servers and also to pinpoint the

physical location of the app engine servers. The traceroute confirmed that the servers are actually in

Mountain View, CA, Google’s headquarters, which is about 2400 miles away from the local client mobile

device. These results are very encouraging because the round trip times are still small even accessing

servers on an opposite coast of the country.

5.4 Discussion

5.4.1 Performance

There were some issues getting the programs to run. These included communication issues

between the app inventor chess application and the google app engine server. There is only one way the

app inventor can send and receive http connections: by sending requests to access a json-formatted

database. A widget is available to provide for database storage from the app inventor. Thus, I had to

format the http requests from the chess interface as json database requests. I also had to change the

tags and values the server checks for when accepting the request parameters.

All of the small-scale models performed as expected, decreasing execution times and adding

more power to applications running on weak machines. Especially in the case of the iPhone, many tests

could not even be run on the device due to memory limitations. Furthermore, with the help of ‘the cloud’

applications could be run with no change in user experience.

TABLE 4: GOOGLE APP ENGINE SERVER RTT INFO

38

Static code offload is the proper choice for the Android chess game application do to the nature of

player interaction with the game. See the bottom left figure for the breakdown of acceptable response

times according to established HCI guidelines. Human-Computer Interaction (HCI) is a discipline

concerned with the design, evaluation and implementation of interactive computing systems for human

use and with the study of major phenomena surrounding them. According to studies of a player’s

interactions with interactive games done by Tolia et al [12], the user-perceived quality of thin client

performance is highly variable. As is expected, it mostly depends on the end-to-end latency of the

network as well as the degree of interactivity of the application.

The table on the right shows survey results of 3318 people reporting their experience with GIMP, a photo

editing software, which is a highly interactive task. As the table illustrates, usability suffers even at a

moderate network latency of 100 milliseconds RTT. However, this round trip time would be more than

acceptable for browsing the web. Response times for a chess playing game would need to be

somewhere in between those of photo editing software and browsing the web. According to the MAUI

authors [15], the worst case for performance offload occurs over 3G: the “Select Piece” method for chess

incurs a 77% performance overhead. This equates to a time increase from 800 ms to 1.5 sec. Though

the wait time is doubled, 1.5 sec is still a tolerable wait for chess game.

Response times for a chess playing game would need to be somewhere in between those of

photo editing software and browsing the web. Users could tolerate some wait time, but would be

frustrated if that grew to the order of tens of seconds. Even if the user waits a few seconds, they will not

mind playing the game. Since communication with the App Engine does not add much time and

dynamically offloading code would only increase communication time, it makes sense to always use the

Resp. Time Subjective Impression

< 150ms Crisp

150ms - 1s Noticeable to Annoying

1s - 2s Annoying

2s - 5s Unacceptable

> 5s Unusable

RTT Crisp Noticeable Annoying Unaccep. Unusable

1ms 3278 40 0 0 0

20ms 3214 82 4 18 0

66ms 2710 572 12 3 21

100ms 2296 973 20 6 23

TABLE 5: HUMAN-COMPUTER INTERACTION EVALUATIONS. LEFT-SUBJECTIVE OPINIONS RELATED TO RESPONSE TIMES. RIGHT-SURVEY OF OPIIONS RELATED TO RTT

39

cloud for code execution. Instead of increasing execution times by deciding at runtime, the decision is

made prior by the programmer due to the nature of the application.

This introduces an important conclusion: network programmers need to evaluate cloud computing

options on an application-by-application basis. For example, chess and photo-editing applications have

vastly different interaction requirements. The photo-editing will need to execute locally since network

latencies can never be fast enough for tolerable response times. However, chess requires less stringent

user interaction, so some latency is tolerated. Thus, the cloud can always be used to support this

application. The burden falls on programmer to partition their code into local and remote portions and to

decide if remote execution is possible according to user interaction requirements.

5.4.2 Reliability

The degree of IaaS availability will depend on server load and network connection reliability; the

same issues faced by all cloud computing research. The best way to improve reliability is for cloud

providers to provide backup servers, removing any single-point-of-failure. However, that still leaves

failure issues with the connecting network and the cloud provider itself. Having only one cloud provider

is, in itself, a single point of failure. Thus, allowing an application to utilize different cloud providers would

add reliability.

5.4.3 Replication

Replication responsibility falls on either the server or the client depending on whether static or

dynamic code offload is used. If dynamic code offload is used, responsibility lies with the client since the

application code is passed with the request. Thus, even if a server fails, there will still be a copy of the

code on the client side and the client can resend the request to another server. However, if the server

fails in the process of executing a long-running program, all that work and data will be lost. On the other

hand, it static code offload is used, and a connection is lost with the server, the client may lose all

functionality unless it maintains a copy of the code locally for backup purposes.

5.4.4 Consistency

The following questions must be addressed: What happens if the client-server connection is

broken 1) during initial connection setup, 2) while transferring data to the server, 3) while the server is

computing, or 4) when the server is sending results back to the client? Each scenario would have to be

40

handled differently. The most reliable answer would lead to the client sometimes re-issuing unneeded

requests. In all scenarios, if a timer was added to the client, the client could simply re-issue the request if

a timeout occurred.

5.4.5 Mobility

This research displays the possibilities of providing high mobility for users. Devices could

become smaller and more powerful. The model in which the mobile device directs the server to

download the data from a local desktop computer is especially efficient. This removes the need for the

mobile device to maintain a copy of the application on its limited storage resources.

5.4.6 Security

Though authentication protocols can be implemented fairly easily, this work does not touch on

issues related to man-in-the-middle tasks, when data is intercepted between the client and server.

Though benchmark tests and chess games do not necessarily require it, encryption would be needed to

protect more sensitive information. It would be an interesting study to measure the cost of encryption on

mobile cloud computing.

41

Chapter 6 Conclusions and Future Work

6.1 Conclusions and Contributions

In conclusion, this research work shows that cloud computing technology will only progress since

there are obvious advantages. These results prove that cloud computing is very possible and that

offloading computations to a server is a viable, timesaving option. As long as network speeds are decent,

it is advantageous to offload computationally intensive applications to a more powerful server. Not only is

it advantageous, but also necessary in some situations, as the mobile device is unable to even run certain

applications due to memory restrictions. The demo shows the advantage of offloading applications to the

cloud in the context of providing an Infrastructure-as-a-Service. By outsourcing computational

intelligence to the backend servers, the simple mobile device becomes more powerful than its physical

constraints allow. However, there is no best or simple implementation of mobile cloud computing.

Options include dynamic vs. static code offload, method vs. OS migration, and various connections

protocols. Different applications have different resource requirements affecting the best possible

connection to the cloud. As seen in the android chess application, chess can tolerate some lag while

photo editing software cannot. Though a system like MAUI is a great option for certain applications, my

android-app engine chess game example shows that always offloading code may be the best choice.

Ultimately, it is up to the programmer to decide what a user can tolerate and which setup is best for their

particular application.

My work focuses on providing infrastructure as a service because I feel it offers the largest growth

opportunity for cloud computing since it provides the most user control. I do so by supplying both the

software framework for executing code remotely and the physical hardware needed to run the code. This

project seeks to evaluate cloud computing on both a statistical and functional level.

I utilize Java’s Remote Method Invocation Protocol to provide for communication between the

server and client machines, which include both a laptop PC and a mobile device. This project expands

the common use of transferring files and objects to push the limits of this object distribution model. It

42

connects a client machine running an application to a server machine in order to provide more

computational power, while staying invisible to the client user. Applications I ran while testing include a

set of benchmark tests designed by NASA and a chess game.

I also ported these tests to a mobile device to show the opportunity cloud computing presents in

the realm of mobile computing. To do so, I created a small scale distributed storage system so that the

server could download class files from a remote location specified by the mobile device.

Finally, my last research model involves the Google App Engine as the server and a Google

Android mobile device as the client machine. Working specifically with the chess game application, this

demonstration attempts to show the capabilities of mobile cloud computing on a basic, familiar level. The

user can observe in real time the speedup when intensive computation of the chess engine is performed

on Google’s App Engine server versus locally on the mobile device. The model also provides many

areas of expansion including providing ‘smart’ tips to help the player choose a move or even enable

multiplayer games connected through the app engine.

My research shows that offloading a computationally intensive application to a remote server can

be significantly faster than running the same application on a local desktop machine. Furthermore,

utilizing the cloud from a mobile device is not only advantageous, but also necessary to run certain

applications that require more computing power or memory than a mobile device can provide. All of the

NASA Benchmark tests I ran executed faster when offloaded to the server compared to running it on the

local machine. In fact, it can take 40% less time to run an application on the server compared to running

it on the local client machine. The results for a mobile device are even more staggering; the server

completing the benchmark in 99% less time. In other words, the server is capable of running an

application in 1% of the time is takes to run on a mobile device. Lastly, the chess game example showed

how the cloud can make a user experience better and more responsive as execution time on the mobile

device was 30x longer than the cloud. Using Google’s app engine servers, the computer portion of the

chess game became both quicker and smarter. Even if latency became noticeable, it was still tolerable,

confirming remote execution as the optimal choice for the chess engine.

Additionally, I evaluate the options of mobile cloud computing. While total OS migration may

provide more complete remote execution, today’s technology is more ready to support process migration.

43

The chosen communication protocol must provide flexibility, security, and reliability. I implement both

Java RMI and HTTP and both work well, though HTTP provides more functionality including synchronous

and asynchronous capabilities. Code can be offloaded both dynamically and statically. There are

advantages and disadvantages to both and it often depends on the specific application. Ultimately, it is

most efficient if the programmer provides for remote execution from the beginning of creating an

application. This way the network engineer does not have to be concerned with code partitioning and can

focus on the communication framework. Lastly, a3-tier cloud architecture could provide smaller latencies,

but requires a physical infrastructure that would take time and money to build.

6.2 Future Work

Future work related to this project should be driven by the common issues of cloud computing, including:

Scheduling

If possible application requests are known, how could the service benefit by implementing some

type of priority scheduling? Currently, if a multiple requests are sent to the same registry port, the first

request will run, but the others will be dropped. The system could benefit from a buffer or queue that

would save requests until they could be run. Alternatively, each request could be run as a different

thread.

Scalability

Measuring the ability to scale out is closely related to scheduling. Once a scheduling protocol is

defined, the system could be sent requests until it becomes overloaded. This test would produce a

measure of the resources needed in order to scale out. Furthermore, is it possible for the software to

automatically open new registry ports as new requests are received, allowing for requests to run

concurrently, possibly using multiple threads?

Security

Object serialization can be coupled with any available encryption technology. Thus, any files

passed between server and client could be encrypted. Also, if a secure channel is needed the network

connections could be made using SSL. The authentication methods discussed as part of the Android

application would also improve security.

44

Reliability

The Java RMI system is not very reliable; if the server shuts down, all data and computation

occurring on the server is lost. This is not a hopeless scenario, because the client could simply resend

the data and computation directions to another server. Java RMI will notify when the server cannot be

reached, so if there was another server ready, the client should be able to automatically move to that

server. The Android app could improve by switching to a local chess engine if a network connection is

lost or unavailable. The current android application does not have a local copy of the chess engine, so

game play will not be able to continue if a connection to the server is dropped. However, this would not

be hard to rectify by adding the chess engine algorithm to the local code and having the application

switch to local execution when I connection error is received.

45

REFERENCES

[1] Jianbin Wei, Xiaobo Zhou, Cheng-Zhong Xu. Robust Processing Rate Allocation for Proportional

Slowdown Differentiation on Internet Server. IEEE Computer Society. 2005

[2] Armsbrust, Michael, Fox, Armando, etc. UC Berkeley. Above the Clouds: A Berkeley View of

Cloud Computing. Technical Report No. UCB/EECS-2009-28. February 10, 2009.

[3] Chun Byung-Gon, Maniatis Petros. Intel Berkeley Research. Augmented Smartphone Applications

Through Clone Cloud Execution. HotOS 2009.

[4] Rakesh Agrawal, etc. The Claremont Report on Database Research. SIGMOD Record, September

2008 (Vol. 37, No. 3). Retrieved on May 12, 2009 from: http://delivery.acm.org

[5] Cassimir Medford. Computing in a Mobile Cloud. 08 September 2008. Retrieved on May 12, 2009

from: http://www.redherring.com/Home/24836

[6] Java Remote Method Invocation (Java RMI). Sun Microsystems, 2006. Retrieved from:

www.sun.java.com

[7] Michael A Frumkin, etc. Implementation of the NAS Parallel Benchmarks in Java. NASA

Advanced Supercomputing (NAS) Division, 2002. Retrieved from:

http://www.nas.NASA.gov/Resources/Software/npb.html

[8] Subhash Saini and David H. Bailey. NAS Parallel Benchmark (Version 1.0) Results 11-96. Report

NAS-96-18, November 1996. Retrieved from:

http://www.nas.NASA.gov/Resources/Software/npb.html.

[9] Uquhart, James. Finding distinction in 'infrastructure as a service’. January 11, 2009. Retrieved

on April 30 , 2010 from: http://news.cnet.com/8301-19413_3-10140278-240.html.

[10] Alexandre di Costanzo, etc. Harnessing Cloud Technologies for a Virtualized Distributed

Computing Infrastructure. IEEE Computer Society. 2009.

[11] Borja Sotomayor, etc. Virtual Infrastructure Management in Private and Hybrid Clouds. IEEE

Computer Society. 2009.

[12] Tolia, N., Andersen, D., Satyanarayanan, M. Quantifying Interactive Experience on Thin Clients.

IEEEComputer Society 39, 3 (Mar. 2006).

[13]Mobile Phones: Global Industry Guide. Report Code: DO-4965 Date: 5/2008 By: Datamonitor

46

[14] X. Gu, K. Nahrstedt, A. Messer, I. Greenberg, and D. Milojicic. Adaptive Offloading Inference for

Delivering Applications in Pervasive Computing Environments. In Proceedings of the First IEEE

International Conference on Pervasive Computing and Communications (PerCom), 2003.

[15] Eduardo Cuervo, etc. MAUI: Making Smartphones Last Longer with Code Offload. Mobisys ’10,

June 15-18, 2010

[16] Mahadev Satyanarayanan, etc. The Case for VM-based Cloudlets in Mobile Computing. IEEE

Pervasive Computing, 8(4), 2009.

[17] Minnie Ingersoll and James Kelly. Think big with a gig: Our experimental fiber network. Google

Inc. 2/10/2010 08:00:00 AM. Retrieved from: http://googleblog.blogspot.com/2010/02/think-big-with-

gig-our-experimental.html

[18 ] Minnie Ingersoll. Free citywide WiFi in Mountain View. Google Inc. 8/16/2006 06:00:00 AM.

Retrieved from: http://googleblog.blogspot.com/2006/08/free-citywide-wifi-in-mountain-view.html

47

Abstract

MOBILE CLOUD COMPUTING: CASE STUDIES

by

ELIZABETH HALASH

December 2010

Advisor: Dr. Cheng-Zhong Xu

Major: Computer Engineering

Degree: Master of Science

The current consensus of the definition of the “cloud” is the combination of hardware and

software provided remotely as a service. One of the biggest and potentially most consequential

questions related to the cloud is how mobile devices can access and tap into this vast resource. As these

devices become smaller and smaller, consumers are conversely demanding more functionality and

features. Bridging the gap between high-end servers and mobile devices could solve the computing

problem. This research focuses on providing an infrastructure-as-a-service (IaaS), which remotely

provides both the physical hardware and platform needed to run applications. Both an overview of

current cloud providers and mobile cloud systems are discussed. Additionally, a few small scale

implementations of cloud computing were tested in order to gain quantitative data about the viability of

cloud computing. These include computationally intensive benchmark tests dynamically offloaded to a

remote server using Java RMI and a chess game Android application that connects to the Google App

Engine, which executes the chess game engine remotely. Through analysis of the current state-of-the-art

and the test applications, the advantages and limitations of cloud computing are measured and

quantified.

48

Autobiographical Statement

Elizabeth Halash

Born in Hutzle Hospital in Detroit, Elizabeth Halash decided to return to her roots for my higher

education. She received her Bachelor of Science in Electrical and Computer Engineering from Wayne

State University in December 2009. She has been working as a research student in the Cloud and

Internet Computing Laboratory since March 2009. Her research focuses on Networking Engineering,

client-server communications, and cloud computing, specifically mobile cloud computing.

She received a full-tuition Presidential Scholarship to attend Wayne State University fall 2005. In

Summer 2009, she received a National Science Foundation Fellowship to participate in the Research

Experience for Undergraduates program at Wayne State University. She presented her research work at

the Honors College Research Convocation in November 2009 and won an oral presentation award.

She has also worked as a teaching assistant at Wayne State University for the Network

Programming for Engineers class.

Date post:	28-Jan-2023
Category:	Documents
Upload:	independent
View:	1 times
Download:	0 times

MOBILE CLOUD COMPUTING: CASE STUDIES

Documents