2011 35th IEEE Annual Computer Software and Applications Conference

Cloudifying User-Created Content for Existing Applications in Mobile Devices Subhamoy Ghosh∗ , Juha Savolainen † , Mikko Raatikainen∗ , and Tomi M¨annist¨o∗ ∗ School of Science, Aalto University, Espoo, Finland Email: {subhamoy.ghosh, mikko.raatikainen, tomi.mannisto}@aalto.fi † Cloud Computing Systems, Nokia Research Centre, Tampere, Finland Email: [email protected]

are available to share contents from different devices. VFS implementations especially for mobile devices including MDFS [4] can withstand disruptive network connections and can also resolve conflicting file updates. However a VFS approach merely provides a network channel to remotely access and operate on the content; the users still need to explicitly share the content into VFS. In this paper we describe an approach by which UGC can be shared from mobile devices in an implicit way, that is without any additional user input. By this approach the contents residing in a remote location also appear to be locally available in the operating device. The approach is exemplified by a middleware that extracts meta-information of the contents created by any application. This metainformation is provided to a Content Manangement System (CMS) that enables the user to access her content irrespective of the location of the content in the network. The middleware presents the content to the user as files. Thus the default applications in the device can operate on remote contents exactly as on other local contents. Following this approach the user gets a uniform experience while using the content. The contents of the user is hence cloudified, since the location of the content is made irrelevant to the user. The middleware has been deployed on Maemo Linux - an embedded linux development environment [5], and Ubuntu linux platform. We tested two example usecases of the approach using the middleware the latency in sharing and retrieving content over WLAN and 3G network connections; we also measured the power consumed in the Maemo platforms during this operation. The rest of the paper is organized as follows. Section 2 presents a background followed by section 3 describing the approach we have taken to cloudify mobile devices and section 4 elaborating on the components involved in our middleware. Section 5 presents two example scenarios we used to evaluate our implementation and measure the performance and power consumption metrics using the two scenarios. Some of the future research possibilities are discussed in Section 6, and finally the paper concludes in Section 7.

Abstract—Currently users own and use many networkconnected devices such as laptop, smartphone, or tablet. The user creates content using the default applications in these devices. One approach is to share and ubiquitously access the contents through a social media. Nevertheless, the contents residing in these devices should be available from anywhere, without any explicit user activity; even the contents residing in a remote location should also appear to be locally available in the operating device. With this approach we believe a user’s content gets cloudified, while still remaining operable with the existing applications. In this paper we propose to cloudify a user’s content in all her mobile devices. We present a middleware that allows a user to uniformly use the existing applications on local as well as remote content, and to also share the contents in a controlled way. The middleware hides all network activity to the user; it also makes the applications almost unaware while operating on a content residing in a remote location. To evaluate our approach in a mobile device context, we also present the efficiency measures of the middleware in terms of latency in content-retrieval, as well as in terms of resource usage viz. power consumption. Keywords-Middleware, Mobile Devices, User Generated Content, Social Media, Filesytem In User-Space, Atom Syndication Format.

I. I NTRODUCTION Vaquero et. al. [1] defines the Cloud as “a large pool of easily usable and accessible virtualized resources (such as hardware or development platform and/or services)”. However this view of the cloud is limited mostly to delivering services or scaling of computing resources. The focus of this paper is to widen the scope of cloud by including a means for sharing content from different devices, irrespective of the location of the device in the network. Recently User Generated Content (UGC) has received popularity [2] due to increased availablity of bandwidth and storage, coupled with users having many more new applications to create different types of content. A significant share of these UGC is created in mobile devices such as laptop, smartphone or PDA. But the contents generated in these mobile devices cannot be easily shared with other users without any explicit user activity. To share a content from a laptop or smartphone, a user either needs to upload the content to a Web platform such as Flickr, Picasa or Youtube, or share the content using a file-sharing application viz. Dropbox [3]. Alternately several Virtual File Systems (VFS) 0730-3157/11 $26.00 © 2011 IEEE DOI 10.1109/COMPSAC.2011.98

526 529 510

II. BACKGROUND Kaplan [2] defines Social Media as “Internet-based applications that build on the ideological and technological foundations of Web 2.0, and that allow the creation and exchange of UGC”. Currently there exists many content communities for photos (e.g. Flickr), videos (e.g. Youtube) or presentations (e.g. Slideshare) that already provide webbased interfaces to share content between users. While it is quite easy to share content in such content communities, the process is not entirely seamless. For instance, to share a video from a smartphone to Youtube, a user at least needs to e-mail the content to a unique e-mail address provided by Youtube to the registered user. Moreover the user-experience of playing a local video in a smartphone is not similar as playing a video shared through a content community such as Youtube. Unlike sharing a content in communities such as Flickr or Youtube, a user may prefer to share it with only a selected group of members. Synchronized file-hosting services, such as Dropbox [3], allow a user to selectively share a content from a mobile or fixed device connected to the Internet. However this service actually archives the content in a repository connected to the Internet and replicates in the devices of every user who have access to the content. A more traditional approach is to share content over a network filesystem. Filesystems designed for mobile-hosts support mobility [6], as well as versioning of contents to avoid conflicting updates. However these file-sharing approaches do not allow standalone applications in a device to uniformly operate on web - based contents. For example it is not easy to represent a content hosted in Flickr to be easily available as a file in a device. Consquently the applications in a device cannot directly operate on contents which cannot be easily represented as files. Alternative distributed filesystem implementations for large-scale storage such as Google Filesystem [7] support a metadata based distributed file management, but currently cannot be deployed easily on mobile platforms. A more recent and popular approach is to share contents using Content Addressable Networks [8]. However such a peer-to-peer content sharing approach is not suitable for mobile devices with limited network bandwidth and battery life [9]. Hu et. al. [9] has introduced a file-sharing mechanism over Gnutella [10] using mobile agents. The content in this case is however replicated into the user’s device before any operation.

Figure 1.

A typical view of cloudified mobile devices.

to be locally available for use; in addition a user should be able to operate on the content similarly as of today, primarily using the default applications in her devices. A. Cloudifying content in the Internet The mobile devices cloudify the contents by forming a uniform distributed repository for all the UGC created and shared by the user. To create such a uniform repository by connecting all mobile devices, we have developed a middleware that helps to efficiently hide all network activities from a user. The middleware presents the content shared from different devices to be locally available as files. The applications in the device can then operate on the contents availed through this middleware. We refer this middleware as a content sharing mechanism, where the content actually resides in one device, but is readily available on request to another user or a group of users in the network. An overview of the approach is shown in Figure 1. The design involves a Content Management System (CMS) that keeps track of the user’s devices. A user registers all her devices to the CMS; the middleware extracts the meta-information of the content and provides the meta information to the CMS, which makes the content available from anywhere in the Internet irrespective of the physical location of the device. B. Managing content-in-the-cloud using meta-information The meta-information provided to the CMS, as described in the previous section, consists of content properties such as name, type, size, date of creation, date of last modification. The types of meta-information provided to the CMS is however not restricted, but the CMS allows a user to add customized meta-information types and values for a content. The middleware also sends to the CMS, the access-rights of the content as set by the user. A user thus not only access her contents hosted in different devices, but can also share

III. C LOUDIFYING CONTENT IN MOBILE DEVICES Current users possess multiple mobile devices and use them to create and share different UGC. Consequently content created in one device should be easily accessible from another device. Such a uniform share and access mechanism can be achieved by cloudifying the contents. Cloudifying refers to the contents shared over the Internet that appears 511 530 527

the content from these devices with other users. Contents may have access - rights as personal - available only to the creator, shared - available to a selected group of users in the CMS, or public - available to any user in the CMS. For example, in Figure 1, photos taken by User A are personal; so the photos are accessible only to User A from any of her own device. But User B may take meeting notes in her laptop and with “shared” access-rights allow it to be accessed by User C, who can then operate on the content from her own device. Figure 2.

C. Accessing content-in-the-cloud Alongwith implicit sharing of contents from a device the middleware also allows the default applications in a device to operate uniformly on both local and remote contents. The meta-information of the contents is used to create a fileview and abstract all network activity from the application. A user inputs meta-information values to the middleware that is formatted into a query and sent to the CMS. The CMS parses the query and creates a result set. The middleware also allows a user to attach a customized metainformation e.g. a “tag”, to a set of contents; querying with this “tag” collates all contents into a single file-view. For example a family can create a view of a shared photo-album by cloudifying the pictures taken in their smartphones and add specific a “tag” such as summer2011 to associate all the contents hosted in their devices. The implementation of the middleware by default only pushes the meta-information to the CMS while the actual content resides in the device. However a user can sometimes cache to the CMS a set of contents that are frequently accessed by many users.

Schematic diagram of vREST attribute hierarchy.

Initiating MIST for the first time in any of the user’s device, generates a unique device identifier which is used by vREST to authenticate the device in all future communications. Now on creating a content in the device e.g., Content A in Figure 2, MIST extracts meta-information from the content and pushes it to vREST. vREST then places the set of information created by MIST in the hierarchy as meta-type and meta-value pairs. At times a content residing in a device may be simultaneously queried by several users; a user may also temporarily carry one or more of her devices behind a firewall [12] or NAT box [13] or even out of network connection. In such scenarios in order to improve the response time and optimize the use of bandwidth and battery life, vREST allows each host to safely cache some contents. The hypervized infrastructure of Amazon Elastic Cloud ensures that vREST is always available to the user, and does not become a single point of failure. B. MIST - the device middleware component

IV. I MPLEMENTATION OF THE APPROACH The implementation of the aforementioned approach consists of two major components. The first component is vREST, which is an otherwise transparent CMS deployed on Amazon Elastic Compute Cloud [11]. The other component is a middleware named MIST, that is deployed in the user’s device and is the focus of our work in this paper.

MIST is the middleware component that plays multiple roles while operating in the device as a middleware component. MIST identifies and authenticates a user’s device to vREST; extracts and pushes all content-related metainformation to vREST; sends the query attributes of a user to vREST, and receives a syndication feed of meta-information; and creates a file-view for the user with the syndication feed received from vREST. Mobile devices have a limited battery life and sometimes may need to operate with a limited network bandwidth. So MIST has been implemented as a user-level process, and a user can terminate MIST under certain conditions for example if the device has very little battery life or the user is in a low network coverage area. We designed the middleware following the REST style [14] of software architecture. A content or a device is managed by vREST as a resource. Each cloudified content has a Uniform Resource Identifier (URI) [15] as part of the meta-information. MIST operates on a content with known content-types [16] and currently extracts the properties of any newly cre-

A. vREST - the content management system vREST categorizes the meta-information of the contents into a hierarchy of attributes that helps to easily manage and identify content over the network. All content specific metainformation is provided to vREST in a uniform format as (attribute-name, attribute-value) pair. Figure 2 presents a schematic diagram of how the metainformation is generated for each user. For each user vREST places the username as a root element with all her devices as child elements. The meta-information of the contents in each device are maintained as children of the respective device elements in the hierarchy. vREST provides a web-interface where a user is first required to register with a unique username and password. 512 531 528

ated content as htype, valuei pairs, such as file-size, file-type, date of last modification, thumbnails. However it is capable of adding customized content-type types and corresponding values for a content as well. MIST also adds the accessrights of a content into its meta-information. By default the access-rights is set to personal. But a user can set the access-rights in MIST as shared or public. The new contents then get shared access-rights and can be accessed by other users. MIST finally formats the set of meta-information as a multipart/form-data [17] and sends it as HTTP POST [18] request to vREST. A user inputs a set of meta-information values into MIST that is passed on to vREST to fetch a set of meta-information as a syndication feed. vREST formats the meta-information as an ATOM Syndication Format [19] and sends an HTTP Response to MIST, which presents the feed through a filesystem view using FUSE [20]. The meta-information in the feed is used by FUSE to create the file-view of contents. This file-view allows the default applications in the device to operate on the remote contents similar to other local contents in the device. When user requests to operate on a content using an application, MIST requests vREST to provide the cloudified content by sending an HTTP reqeust containing the URI of the content present the feed. vREST sends an XMPP notification [21] to the host location, which then transfers the content to vREST over HTTP as a multipart/form-data [17]. The content is passed on to MIST that provides the content in a temporary buffer for the application. As the user terminates the application the buffer is flushed by MIST without caching the content in the device. MIST provides the content that are more than 1 MegaByte in size into smaller array of buffers. The applications requesting a content thus need not wait till the full content is delivered to MIST from vREST.

that all users have registered apriori in vREST; MIST is initialized in all the respective devices and the devices can be identified by vREST using their unique identities.

Figure 4.

User B views a content created and shared by User A.

1) User B views and operates on content shared by User A: Figure 3 shows the sequence of operations where user B requests to view a new content X shared by User A shared from her smartphone. MIST deployed in the smartphone, extracts the meta-information from X and pushes the information as a multipart/form-data to vREST. User B queries in MIST with a set of attribute values to generate a file-view of contents. MIST sends the attibute values to vREST which parses the values to create a list of meta-information of the contents; the list contains the newly created content X. vREST returns an HTTP Response that contains an ATOM Syndication of the list of contents. On receiving the list of meta-information, MIST presents the contents as a file-view through FUSE. User B selects to view content X from the list of files shown in the file-view. The default photo viewer application in her laptop requests the file-view in MIST to open content X. MIST sends an HTTP GET Request to vREST to fetch the content. vREST forwards the URI of content X as an XMPP notification to the host of the content. The MIST running in host location returns an HTTP Response to vREST with the content X as a multipart/form-data. vREST forwards the content X to the MIST in the laptop of user B. MIST then provides content X in a temporary buffer to the photo viewer application. 2) User Q requests to view and operate on contents shared by both User S and User T through one file-view: Following on the above example, we extend the scenario where User S and User T share a set of contents from their device and associate the content with a customized metainformation. The contents actually reside in the respective hosts but are associated in vREST. User Q can query with the custom “tag” to retrieve the set of contents. Both User S and User T share photos taken with their smartphones similar to User A in Figure 3. The users choose to add the “tag” value VACATION along with the meta-

V. O PERATING DEFAULT APPLICATIONS ON CLOUDIFIED CONTENT

In this section we describe two use-cases of the middleware deployed on Maemo and Ubuntu platforms, and provide some performance metrics such as the latency in sharing meta-information and retrieving content over WLAN and 3G Networks. We also measured the power consumed in the Maemo platforms during this operation. A. Sharing and accessing content in the cloud In the first scenario User A shares a picture taken with her smartphone which is accessed later by User B from her laptop. In the second scenario User S and User T are family members in a vacation. They have taken pictures during the vacation using their smartphones and the pictures are associated through a customized “tag” and also shared with User Q. User Q queries with this tag and to view all the associated contents through a single file-view. We assume 513 532 529

(a) Wireless network Figure 3.

(b) 3G network

Operational latency of vREST and MIST over WLan and 3G network.

was 0.0365452 sec. We also measured the power consumed by the devices during these tests using the Nokia Energy Profiler application. The file-size of the pictures taken during this test ranges between 3620 KBytes - 3780 KBytes. We calculated the average power consumed by the devices while communicating the meta-information and also that for the contents. Table 1 and Table 2 shows the average power consumed by the devices on both WLAN and 3G networks. The average idle state power consumption in the devices was measured to be 1.06 Watt.

information to associate their contents. User Q later queries through MIST in her laptop similar to user B in Figure 3. The query result formed by vREST includes only those contents of User S and User T, that are shared with “tag” value VACATION. User Q can select the contents available through file-view similar to user B in Figure 3. The contents will be retrieved from their respective devices. Multiple users in vREST can thus associate contents from their devices by adding a unique attribute value to set of meta-information of the contents. This can be considered an alternative content community on mobile devices. Users can host the contents in their own device; vREST ensures that the associated contents are selected altogether when a user queries with the unique attribute value. In our example scenario User S and User T can directly share the vacation photos from their own smartphones. User Q with accessrights having access-rights to the contents can view the contents like a photo album in a social media.

Table I AVERAGE POWER CONSUMED WHILE OPERATING MIST OVER WIRELESS NETWORK

Operation POST meta-information to vREST POST Content to vREST GET query result from vREST GET content from vREST

Size[KBytes] 208.54 3672.62 108.19 3720.90

Power[Watts] 1.93 2.16 1.82 2.14

B. Performance of MIST on mobile devices using Wireless and 3G networks Table II AVERAGE POWER CONSUMED WHILE OPERATING MIST OVER 3G

We tested the use-cases described in the previous section on Maemo platforms. The middleware was deployed on three Nokia N900 mobile devices and used to test the approach described in this paper. The middleware was tested on WLAN and 3G networks [22]. The default camera application in the mobile device was used to create and share photos through the middleware. During this test we measured the overall latency incurred between a query input and viewing a query result; between opening a remote content with an application and viewing the actual content. The process was repeated 12 times on both WLAN and 3G network connections. We measured the latency in communicating the meta-information between vREST and MIST and also that of the actual content. Figure 4 graphically shows the latencies on WLAN and 3G network connections. The average latency measured between receiving the query values and generating a feed

NETWORK

Operation POST meta-information to vREST POST Content to vREST GET query result from vREST GET content from vREST

Size[KBytes] 208.54 3672.62 108.19 3720.90

Power[Watts] 1.86 2.07 1.73 2.06

VI. D ISCUSSION AND C ONCLUSION In this paper we presented an approach to share UGC in a secure way without uploading the contents to a social media platform or a content community. The middleware we developed consists of a content management system named vREST and a device component named MIST. The average latency in viewing a content through the middleware seem to be within an acceptable time limit. 514 533 530

Currently we have only the basic functionality of the middleware working that can share and view contents generated in mobile devices. There are quite a few possible extensions on the existing implementation. For example the XMPP notifications and the multipart/form-data response, to request and retrieve a content respectively, are currently routed through vREST and hence follow a server-assisted transfer mechanism; instead a direct device-device communication mechanism can be to request and retrieve a content. Again, vREST at present, archives each updated version of a content using a version control system. Alternately, the updated versions of a content can be synchronized from vREST using rSync [23] synchronization protocol. To improve the querying of contents through MIST, we are designing a solution to have a user-centric content classification and previewing for each user registered in vREST. This would allow a user to refine her query and retrieve more relevant content for viewing. We are currently working on some of these identified areas and also deploying the middleware on other platforms.

[6] A. Boukerche, R. Al-Shaikh, and B. Marleau, “Disconnection-resilient file system for mobile clients,” in The IEEE Conference on Local Computer Networks, 2005. 30th Anniversary. [7] S. Ghemawat, H. Gobioff, and S.-T. Leung, “The google file system,” in Proceedings of the nineteenth ACM symposium on Operating systems principles, ser. SOSP ’03, 2003. [8] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker, “A scalable content-addressable network,” in Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications. [9] T. Hu, B. Thai, and A. Seneviratne, “Supporting mobile devices in Gnutella file sharing network with mobile agents,” in Computers and Communication, 2003.(ISCC 2003). Proceedings. Eighth IEEE International Symposium on. [10] T. Klingberg and R. Manfredi, “Gnutella 0.6,” Network Working Group, June, 2002. [11] E. Walker, “Benchmarking amazon EC2 for high-performance scientific computing,” USENIX Login, vol. 33, no. 5, 2008.

VII. ACKNOWLEDGEMENTS

[12] N. Freed, “Behavior of and requirements for Internet firewalls,” RFC 2979, October 2000, Tech. Rep., 2000.

We thank Niko M¨akitalo, Heikki Peltola, and Tommi Mikkonen from Tampere University of Technology, Tampere, Finland for their contributions in developing vREST, and also to Timo Aaltonen, Vlad Stirbu, Rod Walsh and Tapani Lepp¨anen from Nokia Research Centre, Tampere, Finland, for providing key inputs and reviewing the contributions in this paper. This research was part of the Cloud Software Program of Strategic Centre for Science, Technology and Innovation in the field of ICT (TIVIT), and was partially funded by the Finnish Funding Agency for Technology and Innovation (TEKES).

[13] K. Egevang and P. Francis, “Rfc1631: The ip network address translator (nat),” RFC Editor United States, 1994. [14] R. T. Fielding, “REST: architectural styles and the design of network-based software architectures,” Doctoral dissertation, University of California, Irvine, 2000. [15] T. Berners-Lee, R. Fielding, and L. Masinter, “RFC2396: Uniform Resource Identifiers (URI): Generic Syntax,” RFC Editor United States, 1998. [16] N. Freed, “Multipurpose internet mail extensions (mime) part two: Media types,” Internet Assigned Numbers Authority (IANA), Tech. Rep., 1996.

R EFERENCES

[17] L. Masinter, “RFC2388: Returning Values from Forms: multipart/form-data,” RFC Editor United States, 1998.

[1] L. M. Vaquero, L. Rodero-Merino, J. Caceres, and M. Lindner, “A break in the clouds: towards a cloud definition,” SIGCOMM Comput. Commun. Rev., vol. 39, 2009.

[18] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, “Hypertext transfer protocol– HTTP/1.1,” 1999.

[2] A. M. Kaplan and M. Haenlein, “Users of the world, unite! the challenges and opportunities of social media,” Business Horizons, vol. 53, 2010.

[19] R. Sayre, “Atom: The standard in syndication,” Internet Computing, IEEE, vol. 9, no. 4.

[3] A. Z. Schwartz, “Ud dropbox 2.0: collaboration magic,” in SIGUCCS ’07: Proceedings of the 35th annual ACM SIGUCCS fall conference, 2007.

[20] M. Szeredi, “Filesystem in user space,” March 2010. [21] P. Saint-Andre et al., “Extensible messaging and presence protocol (XMPP): Core,” 2004.

[4] N. Michalakis, “Designing an NFS-based Mobile Distributed File System for Ephemeral Sharing,” in in Proximity Networks, Proc. of 4 th Workshop on Applications and Services in Wireless Networks, IEEE CS. Citeseer, 2004.

[22] V. Garg and T. Rappaport, Wireless network evolution: 2G to 3G. Prentice Hall PTR Upper Saddle River, NJ, USA, 2001. [23] A. Tridgell, “Efficient Algorithms for Sorting and Synchronization: The rsync Algorithm,” Ph.D. dissertation, PhD Dissertation (Feb 1999).

[5] J. Bosch, “Software product families in nokia,” Software Product Lines, 2005. 515 534 531