Mobile Cloud Messaging Supported by XMPP Primitives Huber Flores
[email protected]
Satish Narayana Srirama
[email protected]
Institute of Computer Science, Mobile Cloud Lab, University of Tartu, J. Liivi 2, Tartu, Estonia.
ABSTRACT
1.
The increasing demand of the smartphones for processing power, storage space and energy saving is leading the rapid adaption of the mobile cloud computing (MCC) domain. Asynchronous mobile cloud communication is a two way process which in most cases is managed via REST (from mobile to cloud) and push technologies (from cloud to mobile). There are several push notification mechanisms provided by the cloud vendors and mobile operators for delivering messages to the mobile applications (e.g. GCM, APNS, MPNS, etc.). However, these mechanisms have certain constraints such as being platform specific, limited message payload and the number of the messages that can be sent to a single handset. This paper explored the possibility of implementing a messaging framework that can be used as open notification mechanism running at the cloud for handling asynchronous delegation of mobile tasks to cloud. The framework is developed by extending a XMPP-based IM infrastructure, which can be integrated with any application server and reconfigured on demand as the mobile workload grows or shrinks. The detailed analysis of the framework shows that it is possible to send messages to the smartphones with IM, at a quality of service similar to that of other push notification mechanisms.
The increasing demand of the smartphones for processing power, storage space and energy saving, and the continuous improvements of the telecommunication infrastructures for the provisioning of high performance services is leading the rapid adaption of the mobile cloud computing (MCC) domain. Given this context, from a mobile perspective, MCC focuses on the benefits that can be achieved by the mobile resources when a mobile operation such as data storage or processing is offloaded or delegated to the cloud [4]. From a mobile operator perspective (e.g. middleware), MCC focuses on finding an optimal configuration of a mobile cloud infrastructure in order to handle the oscillating telecommunication loads (scale-out), to facilitate the process of deploying services without managing the underlying technology (on the fly) and to reduce operational and provisioning costs (payas-you-go model). [4] Mobile applications may be bonded to cloud resources by following a delegation or offloading criteria. In a delegation model, a mobile device utilizes the cloud to perform resource-intensive operations which are time-consuming, programmable and parallelizable among multiple servers (e.g. based on distributed frameworks like MapReduce), and computationally unfeasible for offline devices. In contrast, in an offloading model, a mobile application may be partitioned (e.g. methods, classes) and analyzed a priori (at development stages) or a posteriori (at runtime) so that the most computational expensive operations at code level can be identified and offloaded for remote processing. A mobile operation may be offloaded or not, depending on the impact of its execution over the mobile resources. Conceptually, offloading is preferable only if a mobile operation requires high amounts of computational processing and the same time, low amounts of data need to be sent in the communication. Otherwise, offloading is not encouraged [14]. Unlike delegation, offloading does not require online connectivity as it can be executed by the mobile in standalone. However, offloaded mobile operations require a low-level scale processing compared with delegated mobile tasks. While most of the research works have proposed solutions to bring the cloud to the vicinity of a mobile [5, 3, 2] from an offloading perspective, a mobile application may enrich its functionality from other approaches such as those based on resource intensive delegation. However, delegating a mobile operation to cloud is a complex process mainly due to a cloud request by nature is time consuming and without a proper mechanism to handle the communication, this can cause an overhead in the mobile resources. To address partially this
Categories and Subject Descriptors C.1.3 [Computer Systems Organization]: Other Architecture Styles—Cellular architecture (e.g., mobile); C.2.4 [Computer-Communication Networks]: Distributed Systems—Client/Server
General Terms Design, Performance, Reliability
Keywords Mobile Cloud Computing, Mobile Delegation, Middleware, Notification Services, XMPP
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MCS’13, June 25, 2013, Taipei, Taiwan Copyright 2013 ACM 978-1-4503-2072-6/13/06 ...$15.00.
17
INTRODUCTION
issue, mobile applications can rely on push technologies (aka notification services) for dealing with remote executions, and thus avoiding the effect of polling caused by protocols such as HTTP (Hypertext Transfer Protocol). However, these mechanisms are considered as black box services which have certain constraints and limitations such as being platform specific (e.g. AC2DM [6] for Android, APNS [1] for iOS, MPNS for Windows Phone 7, etc.), the size of the message that can be pushed into the device (e.g. 1024 bytes for Android, 256 bytes for iOS, 4096 bytes for Windows Mobile etc.) and the number of the messages that can be sent to a single handset (e.g. 200,000 for AC2DM). Moreover, such mechanisms are considered to be moderately reliable, and thus are not recommended in scenarios that require high scalability and quality of service. For example: AC2DM simply stops retrying after some delivery attempts. Furthermore, even though push architectures are conceptually based on Open Mobile Alliance (OMA) standard, changes or replacements in such mechanisms (e.g. Google recently changed from AC2DM to GCM [7]), require a considerable effort for managing low-level programming modifications in the application server and the mobile clients. On the other hand, instant messaging (IM) is a widely used technology for real-time communication that enables to establish a digital ubiquitous presence with other individuals (buddies) and it is a common service of any business infrastructure (e.g. private cloud). Moreover, IM technologies are flexible and scalable so that they can be adapted for any specific purpose. For example, XMPP (aka eXtensible Messaging and Presence Protocol) [15] enables augmenting its functionality via XEPs (XMPP Extensions) and multiple works have envisioned it as a data transportation protocol for cloud computing scenarios [9], [17]. In order to investigate the primitives that can be used to adapt XMPP as a specialized notification service that handles delegation of resource-intensive tasks from mobile to cloud, to introduce an approach for extending the capabilities of an IM infrastructure for the provisioning of interoperable mobile cloud messaging services and to foster the decoupling of the handset to a specific cloud vendor, we have designed a framework which can be integrated with any middleware solution for pushing data to the smartphones. Once the framework was developed, it was analyzed for its performance (delivery rate) and scalability under heavy loads, and the details are addressed in further sections. The rest of this paper is organized as follows; section 2 introduces the framework and its deployment in the cloud. Section 3 presents a comparison between our XMPP mechanism and other notification service solutions. Section 4 explains the scalability properties of the framework under heavy loads. Section 5 addresses the related work and section 6 concludes the paper with future research directions.
2.
private, etc.) and orchestating (e.g. parallel, sequential, etc.) those transactions for achieving a common purpose. We have studied the delegation of mobile tasks to hybrid clouds in detail and we have developed a Mobile Cloud Middleware [4] framework (MCM) that addresses the issues of interoperability across multiple clouds, transparent delegation and asynchronous execution of mobile tasks that require resource-intensive processing, and dynamic allocation of cloud infrastructure. Moreover, we have developed several successful study cases of data-intensive mobile cloud applications that benefit by going cloud-aware [5]. These applications make use of cloud functionality supported by MCM in order to provide richer mobile experience (e.g. video processing) to the end user. In an asynchronous process, when a mobile application sends a request to access a cloud service, the handset immediately gets a response that the transaction has been delegated to remote execution in the cloud, while the status of the mobile application is sent to local background so that the mobile device can continue with other activities. Once the process is finished at the cloud, a notification about the result of the task is sent back to the mobile, so as to reactivate the application running in the background, and thus the user can continue the activity. Since XMPP allows establishing an asynchronous communication between entities, it is ideal for managing the resource-intensive nature of the cloud from a mobile device.
2.1
Fundamentals and Extensions
XMPP is a near real-time communication protocol that relies on Extensible Markup Language (XML) and enables the exchange of structured data between network entities [15] (e.g. users, bots, etc.). XMPP uses decentralized clientserver model, where each user connects to the server that controls its own domain. Thus, allowing the creation of an interoperable and federated architecture based on multiple authorities. XMPP uses globally unique addresses in order to route and to deliver messages. All entities are addressable by using unique identifiers called domainpart and JID for the server and the client, respectively. A XMPP session is established after creating a TCP connection, XMPP exchanges input/output XML streams for opening the channel that is going to be used during all the communication process. XML stream is a container for exchanging XML stanzas between entities. The stream is started by sending a stream header tag with appropriate attributes and namespace declarations. After the stream header is accepted, the connection remains alive and the server sends a first level child element tag, which contains actions that the server is offering to the client for proceeding with the next step. Upon successful actions’ execution, the XML stream must be restarted by sending the stream header to the server once again, same sequential process is repeated. A server should enable an entity to maintain multiple connected resources simultaneously. Once, the stream negotiation has finished, either party can send XML stanzas. A XML stanza is the base of the XMPP protocol and it can be defined as a first-level XML element whose name can be , and (info query) and whose qualifying namespace may vary from ’jabber:client’ or ’jabber:server’ depending on the entity.
RESOURCE-INTENSIVE MOBILE TASK DELEGATION TO CLOUD
Asynchronous delegation of mobile tasks to the clouds is useful to overcome the problems of multi-cloud service integration in mashups that can be accessible from the handset, when those include data-intensive operations. A multi-cloud operation consists of delegating mobile tasks to a diversity of cloud services (e.g. from the infrastructure level, platform level, etc.) located on different clouds (e.g. public,
18
A message stanza is used for pushing information to another entity using synchronous or asynchronous communication. Presence stanza is used for sending presence notifications. For example, when a user logs into server, the client sends a presence stanza to the server indicating that the user has changed status. The server sends this status notification to every entity that is online and is in the user’s buddy list. Info query stanza is a request-response mechanism, (similar to the HTTP) that enable an entity to make a request to and receive a response from another entity. When the presence for the entity or resource has been set, the client is able to exchange unbounded number of XML stanzas with other entities on the network until the stream is closed. The stream closing is rather simple. If the client wishes to log out from the server, it only needs to send the closing tag of the stream (). The closing entity must not immediately close the TCP connection but wait for the receiving entity to respond with the same. This indicates that the server has halted any data transmission to the entity and is in state to end the connection. Usually the server closes the connection and the client is not involved in the rest of the process. In order to extend the capabilities of the IM infrastructure for sending notification messages, while keeping intact the other IM features such as chat. An attribute ’notification’ is added by the messaging framework so that the notifications are routed to the XMPP notification manager of the mobile, when this is received by the PacketListener of the XMPP client (discussed in the next subsection).
2.2
checks the status of the client, in this case, the message is sent by the framework and its delivery is delegated to a second mechanism which is an inherent feature of the XMPP server for handling offline messaging. Once the message has been verified for delivery, the message is passed to the Message-packer which encapsulates the text into a JSON payload (using json-simple library [12]). By default, the Message-packer tries to divide the text in attributes of the type name-value (similar to common notification services). In the case of a packing exception (unexpected format), the Message-packer creates a JSON with a unique attribute containing as value the overall text. Messages are distributed in a round-robin fashion by the Messagepacker, among the available Message-dispatchers. A Messagedispatcher can be associated to an automated JID that contains the complete roster and it is used for adding the ’notification’ attribute to the XML streaming, which is sent as payload to the XMPP cluster. Each Message-dispatcher is added, monitored and removed dynamically by the Sessionhandler according to the data generated from the Runtimeprovisioner. Runtime-provisioner is in charge of determining the number of Message-dispatchers to be created by analyzing the queue length of the messages. This number is determined by the capacity of a single standalone framework for handling concurrent automated JIDs as shown in section 4. The framework is developed in Clojure which is a distributed language suitable for cloud deployment and portability purposes. It uses the SmackAPI [10] for implementing the logic and behavior of the Message-dispatchers. Notification data is managed by MySQL and H2 databases, for storing pending messages and queueing messages, respectively. H2 uses an in-memory approach for handling the message information. This approach was prefer as the life span of the messages is short and to avoid unnecessary CPU load created by more sophisticated DBMS. From a client perspective, a mobile application is to be developed for receiving messages using the framework. It has to implement a XMPP client that extends the native notification features of the mobile platform. For example, in the case of Android, we have created a XMPP client that uses the SmackAPI and the NotificationManager Class of Android. It implements a PacketListener and PacketFilter that filters the received messages according to its type. The NotificationManager Class is used to create the notification event that informs the user about the message received. Once, the user selects the notification icon, an Intent Broadcast is created for passing the raw data to the application.
Implementation Details of the Messaging Framework
The messaging framework is introduced as a component that follows a client/server architecture, which can easily be integrated with any application server for sending JSONbased notifications to any mobile platform that implements a XMPP mobile client functionality. Thus, message distribution can be performed to a variety of mobile applications developed in multiple mobile technologies. The architecture is shown in figure 1. The framework establishes an asynchronous communication between the mobile and the cloud, based on the JID of the user and it scales an instant messaging XMPP infrastructure for sending notifications to a large number of mobile devices. From a server side perspective, the framework implements a message interface that receives two parameters, the JID of the mobile client and the text message in CSV format. When a notification message is created for being delivered, the message is passed to the Message-receiver for inspection. The Message-receiver analyzes whether the mobile client can receive the message by checking its status (e.g. online, away, etc.). Status data of the users is retrieved from the Sessionhandler, which manages the information of the complete roster. If the user’s status is other than offline, the message will continue to the next step of the notification process. Otherwise, the message is put in a temporal space (pending messages) and the JID account will be monitored so that the process for that particular message is reactivated when the user gets online again. The aim of the inspection is to guarantee that the message is delivered to an active client and to reduce the queue of messages by filtering those that can not be processed by an inactive mobile. In some scenarios, the mobile client may go offline after the Message-receiver
3.
ANALYSIS OF XMPP AS NOTIFICATION MECHANISM
Generally, notification mechanisms are used to push information to the handset from the cloud in order to improve the real-time usability of a mobile application, when its bonded to the functionality of a cloud-based solution (e.g. e-mail). While conceptually a basic notification architecture may be utilized to develop a data-intensive mobile cloud application that follows a task delegation model [4], a notification server may be extended with many other features (e.g. communication mobile to cloud) that could help to reduce the gap between cloud and mobiles, in terms of cloud-based service integration (at different levels), invocation of time consum-
19
Figure 1: Mobile cloud messaging architecture ing operations (e.g. MapReduce) and communication support with low-level energy consumption (e.g. small data). Unlike other technologies (e.g. SIP) that can be implemented or extended to push data to cloud, XMPP is preferable due to enables to mantain a two-way asynchronous communication and fosters a flexible, scalable and manageable infrastructure which can be adapted for any mobile platform (interoperable). In this section, we analyzed and compared our proposed messaging mechanism against different notification solutions provided by some of the most popular mobile vendors. The analysis is based on the promise that the responsiveness of XMPP to push data is at a quality of service similar to that of other push notification mechanisms. Notice that our messaging framework is tested in a low-level scale traffic when compared with a notification service in a production scenario. The aim of the messaging framework is to proposed new features that can be added to a common notification architecture in order to enhance the delegation process of mobile tasks to cloud. Moreover, the framework can be also considered as an alternative for a developer that wanted to build his or her own notification server.
3.1
(with maximum of 5 attempts) or stored in the case the mobile is offline. GCM allows up to 100 messages stored before discarding it. Once, the device is active for receiving the message, the system executes an Intent Brodcast for passing the raw data to the specified Android application. GCM does not guarantee the delivery of a message and the sending order. Messages with payload can contain up to 4K of data and are encapsulated in a JSON format.
3.2
Apple Push Notification Service
Similar to above mechanism, Apple devices running iOS 3.0 or newer can also receive asynchronous messages provided through APNS (Apple Push Notification Service). APNS messages are sent through binary interface (gateway.push.apple.com:2195, gateway.sandbox.push.apple.com:2195) that uses streaming TCP socket design. Forwarding messages to device happens through constantly open IP connection. TLS (or SSL) certificate (provisioned through iOS developer portal) is needed for creating secure communication channel and for establishing trusted provider identity. To avoid being considered a DoS (Denial of Service) attacker, using one connection for multiple notifications rather than creating new connection for each notification, is desired. APNS has a feedback service that records failed notification delivery attempts. This information should be checked regularly to avoid sending messages to devices that do not have the targeted application installed anymore. For the same reason application should register itself at the messaging server for notifications at each start by providing at least it’s device token that it has received from APNS. Device token is a 32 byte hexadecimal number that is unique for an application on a device and does not change. Messages sent to iOS devices via APNS consist of JSON payload with maximum length of 256 bytes. Within message payload, values for keys alert, sound and badge can be used to customize the message alert being shown to user upon receiving it. Because the payload size is limited, it is used to provide enough information for the application to make request for additional details. When the device cannot receive notifications for some time (e.g. due to being offline or switched off) and multiple notifications have been sent, only the last one is guaranteed to be delivered.
Google Cloud Messaging
GCM (Google Cloud Messaging for Android) is the enhanced notification service provided by Google for sending asynchronous messages to Android devices. It has been released as replacement for the deprecated AC2DM (Android Cloud to Device Messaging Framework) service and includes new features such as unlimited message quota, decoupling of the mobile device from a Google account for receiving message data (devices running Android 4.0.4 or higher) and message throttling that enables to prevent sending a flood of messages to a single handset, among others. Basically, a mobile application that implements the GCM mechanism for receiving messages, first, has to register itself against the GCM server for acquiring a registration ID. Messages are sent to the mobile using this identifier from the application server, which lasts till the mobile explicitly unregisters itself, or until Google refreshes the GCM servers. An API key is required for the application server, in order to pass message data to the GCM service. This key is generated by the developer using the Google APIs console and it is used as the sender ID of the message. An application server sends a message to the mobile by sending the registration ID, the API key and the payload to the GCM servers, where the message is enqueued for delivery
3.3
Microsoft Push Notification Service
MPNS (Microsoft Push Notification Service) is the push technology provided by Microsoft for sending messages to
20
the mobiles running with the Windows Phone 7 platform. MPNS maps each device into a set of URI channels that can be invoked via REST/POST with the possibility of creating up to 30 different channels for pushing data to the applications (one application corresponds to one channel). Prior to use of the MPNS mechanism, a phone has to request a push notification URI from the Push Client service (located in the phone), which handles the negotiation process with the MPNS server. An URI can be requested without authentication, however, in this case, a limit of 500 messages per day is fixed. Once, the mobile has obtained the URI, this is passed to the application server so that the URI can be integrated within any remote service that needs to notify data to a mobile application. A message is sent from the application server to the mobile by performing a request to the URI, which works as an interface between the application server and the MPNS service. A request can be based on different HTTP headers (depending on the mobile version), MessageID (to identify the response), NotificationClass (to set the sending notification timeinterval), NotificationType (sets the type of the notification) and CallbackURI (for authenticated channels). When the message is received by the phone, a notification event is triggered. MPNS differentiates three types of notifications, Toast Notifications, Tile Notifications and Raw Notifications. A Toast Notification is used for raising alarms, passing parameters to the applications, etc. A Tille Notification is an interactive notification that enables to change the design properties of Tile elements such as color, image background, etc. Finally, A Raw Notification is utilized for passing information to a running application (if the application is not running, the notification is discared). Similar to APNS or GCM, MPNS do not guarantee the delivery of a message.
3.4
an specific device. Each GCM message is encapsulated in a JSON payload that includes an index number that identify the creation of the message and a sending timestamp taken from the server. GCM client application is developed for Android 2.3.3. Once a notification arrives, the payload is extracted from the message and then it is stored in a SQLite database along with receiving client timestamp taken from the mobile. In the case of APNS server, the gem library jpoz [11] written in Ruby on Rails is considered. Jpoz for APNS is a library that enables to send push notifications from Ruby scripts. Scripts are executed in the server for sending notifications to the mobile (with the same format as described for GCM) and then are processed at the phone, once the notification is triggered. Messages are stored in a SQLite database along with receiving client timestamp taken from the device. MPNS application server is deployed in a Tomcat server by implementing a Servlet that executes a POST request to the URI channel created from the Windows Phone 7 device. The request contains the complete headers + payload, where the payload consists of an index number that identify the creation of the message and a sending timestamp taken from the server (similar to GCM and APNS). Once, a notification arrives, the Windows Phone client extracts the payload from the message and then it is stored in a database along with receiving client timestamp taken from the handset.
3.5
Evaluation and Analysis
For all the described mechanisms, messages are fixed to a size of 254 bytes, which is the lowest common denominator of the allowed message sizes of the considered approaches. Messages are formatted with similar characteristics so that they can ensure a fair comparison that is not affected by transportation factors such as data size, among others. The aim of the experiments is to determine the latency between a provider submitting a request and the target device receiving the notification (responsiveness). Messages are sent 1 per second for 15 seconds in sequence, then with a 30 minute sleep time, later followed by another set of 15 messages, repeating the procedure for 8 hours (240 messages in total). The frequency of the messages is set in this way, in order to mitigate the possibility of being detected as a potential attacker to the cloud vendor (e.g. Denial of Service) and to refresh the notification service from a single requester and possible undelivered data. Moreover, the duration of the experiments guarantee to have an overview of the service under different mobile loads, which may arise during different hours of the day. Since there is no a clear understanding of the architecture behind of each notification mechanism, their behavior analysis is based on multiple assumptions that may affect their functionality. For example, the utilization of the same policy for managing different loads, etc. Results are shown in figure 2 for each mechanism. According to the data, GCM is the most unreliable real-time mechanism that provides poor delivery rates for notifications, with an average of ≈ 10 sec, and longer and shorter delivery times of ≈ 380 sec and ≈ 0.15 sec, respectively. From the GCM delivery rate diagram, it can be observed that the quality of service started to decrease as the number of messages increase across time. Consequently, messages tend to arrive without a specific order (different queues).
Performance of the Mobile Cloud Messaging Framework
Several experiments based on the delivery rate of the message were conducted using the described mechanisms. The aim of the experiments is to determine the latency between a provider submitting a request and the target device receiving the notification (responsiveness). Mobile devices considered in the experiments are a Samsung galaxy S2 i9100 with Android 2.3.3, 32GB of storage, 1 GB of RAM and support for Wi-Fi 802.11 a/b/g/n; an iPhone 4 with 16GB of storage, 512 MB of RAM and support for 802.11b/g/n Wi-Fi (802.11n 2.4GHz only); and a Nokia Lumia 800 with Microsoft Windows Phone 7.5 Mango with 16 GB of storage, 512 MB of RAM and support for Wi-Fi 802.11 b/g/n. All the devices are connected via Wi-Fi to a network with an upload rate of ≈ 1409 kbps and download rate of ≈ 3692 kbps, respectively. Notification servers are configured to run on Amazon EC2 infrastructure using small instances (a small instance has 1.8 GB of memory and up to 10 GB of storage). One EC2 computational instance is equivalent to a CPU capacity of 2.66 TM R GHz Intel Xeon processor. Servers were running on 64 bit Linux platforms (Ubuntu). XMPP mechanism (server and client) is developed as described in subsection 2.2. GCM application server is written in Java using Servlets technology version 3.0. It is deployed as war project in a Tomcat server. It allows to register multiple devices simultaneously for receiving GCM notifications and to send messages to
21
Moreover, it can also be observed that after the service has decreased, it reaches a point, when the service becomes predictable under certain interval. In contrast, APNS is a more reliable mechanism that allows to send messages under a shorter delivery rate, with an average of ≈ 0.5 sec. In most of the cases, messages tend to arrive in the same order as they were sent. This kind of behavior points out a possible APNS overprovisioning (more servers than required for managing the load). In the case of MPNS, messages which are sent tend to reach the device without a specific order (similar queues), but with a shorter inter-arrival time. Delivery time for MPNS is in the range of ≈ 1 sec. On the other hand, the proposed XMPP mechanism shows to share a similar reliability as APNS for delivering messages, with an average of ≈ 0.6 sec, using an unique queue (a single XMPP server).
4.
Figure 3: Load test setup for the messaging framework
SCALABILITY OF THE MOBILE CLOUD MESSAGING FRAMEWORK
While the framework supports the provisioning of messages for smartphones, it depends on the elasticity of a complete infrastructure which has to be maintained by adding functional capabilities (e.g. memory, bandwith, etc.) at runtime. Dynamic cloud reconfiguration mainly focuses on the distribution of application components that alleviates the entire system, when it is facing a certain condition (e.g. heavy loads, CPU utilization, etc.), thus, increasing its capabilities for managing concurrency. To verify the capacity of the framework for distributing messages and the number of active mobile users that a XMPP server can handle, multiple tests were carried out taking in consideration their different functionalities and implementations. Both, IM and messaging framework were deployed in Amazon EC2 and configured to work as XMPP and Web application cluster, respectively. Then, different mobile loads were simulated using benchmarking tools for testing their scalability properties. Both, cluster-based configurations consist of a front-end node (Load balancer - LB) and multiple working nodes (backend servers). Figure 3 shows the test setup for the complete end-to-end scenario. Basically, the front-end node distributes the load between the back-end servers, and thus it requires a powerful CPU to handle the heavy demand. HAProxy [8] is considered as the LB as it allows dynamic behavior to the architecture and new working nodes can be added, while the system is running (hot reconfiguration). Back-end servers can be considered as commodity servers which can be replaced without affecting the overall performance of the clusters.
4.1
Figure 4: Scalability results for the messaging framework based on different loads of 0.06 was used. On the cloud front, per each cluster configuration (messaging framework and XMPP) a load balancer and up to n worker nodes were setup, where n is increased by one in each test and it represents the maximum number of nodes that can be used for scaling the cluster. Servers were deployed on Amazon EC2 infrastructure using EC2 small instances running on 64 bit Linux platforms (Ubuntu). The load balancer was setup for using Round-robin scheduling. In the load test, for the messaging framework, it is measured how many concurrent users can successfully request to send a message, while increasing the number of working nodes. A request is considered as success, if it gets a response back (i.e. transaction completed) before the connection or response timeout occurs. Similarly, the success rate indicates the number of requests that have succeeded from all performed requests. The results of the experiments are shown in figure 4. From the diagram it can be observed that the percentage of succeeded requests grows logarithmically with the number of nodes and degrades exponentially as load grows. The performance of six nodes drops to ≈ 85% after receiving 2000 concurrent requests, however, 10 nodes can handle this load with ≈ 98% success rate. It can be also seen that with current test architecture adding more worker nodes does not show any visible improvement in the performance after 10 nodes in contrast when the setup was composed of 1, 2, 3 or 4 nodes. This is as the load balancer itself becomes a bottleneck. Hence adding more nodes does
Scalability Analysis
Load testing on the whole system was performed using Tsung [16] (open source load testing software). Tsung was deployed in a distributed cluster composed of three nodes running on Amazon EC2 (one primary and two secondary nodes). The primary node is in charge of executing the test plan and collecting all the results of each secondary node, so that the information can be combined and analyzed into a single report using Tsung-plotter utility. The test plan is configured with the server/client configurations and its defined to generate different loads in each test. For instance, for generating a load of thousand users in one minute a mean
22
Figure 2: XMPP delivery rate againts different mechanisms not improve the performance as desired. The analysis also shows that the elasticity of the cloud helps in achieving this required setup easily, without long cooldown times. In the case of the XMPP cluster, it is measured, how many concurrent users can have an active session (logged into the server) for receiving messages while the number of XMPP servers is increased. The results are shown in figure 5. Basically, a single XMPP node can handle ≈ 5200 users concurrently. Moreover, according to the results, it can be observed that the cluster with one load balancer is able to grow up to 6 nodes before the load balancer started to become a bottleneck that refuses more users to login. However, in order to increase the number of users, it may be possible to replace the load balancer for a more powerful cloud instance (e.g. m1.medium or m1.large). Based on the previous information, we can observe that a single XMPP server is enough for managing the distribution of messages to the mobiles, which may be sent by the messaging cluster. However, in this case, the n queues of the messaging cluster may degrade the delivery rate of the notifications by relying on a single standalone framework (e.g. longer delivery times, possible loss of messages as the XMPP storage limit is reached, etc.). Moreover, since the XMPP server is also used for IM purposes, it is affected by a constant load (e.g. CPU). Thus, it is recommended to increase the XMPP cluster, in order to provide similar delivery rates anytime (same approach as APNS).
5.
Figure 5: Scalability results for XMPP
Telemetry Transport (MQTT) developed by IBM. MQTT is a lightweight network protocol based on the principle of publishing messages and subscribing to topics (pub/sub). Multiple clients connect to a broker and subscribe to topics which may be of their interest. The broker acts a simple common interface that routes the messages according to the recipient. Even though, MQTT can be used as a notification service for the smartphones, it requires to maintain a separate specialized infrastructure from the IM. In contrast, the proposed framework extends and reuses the existing IM features (e.g. JIDs, authentication mechanisms, etc.), in order to foster a multi-purpose infrastructure. MAS [9] is other framework that uses XMPP, which depends on three entities: users, managers and workers. Users are generally agents that publish job requests to managers which then select the most appropriate available worker to perform the job. MAS uses XMPP for presence notifica-
RELATED WORKS
Lot of research has been conducted that envisions XMPP as a real-time data transportation protocol for cloud applications [9], [17]. Messaging approaches similar to the proposed mobile cloud messaging framework have been addressed in the literature. The most similar solution, which is also inspired by several XMPP features, is the Message Queue
23
tions that allow the entities of the system to track machine presence, real-time status and web service availability. XMPP has been used in different collaborative cloud-based projects. One of them is the Alliance for Flexible Disaster Management [13] that uses mobile XMPP and cloud service collaboration, in order to support post-disaster management. It’s aim is to combine mobility with real-time presence for establishing communication between the involved parties and to collect sensor data which can be managed and visualized through the use of cloud-based storage and analysis services, respectively. XMPP cloud services are also considered in bioinformatics [17]. Although SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) are widely utilized in bioinformatics projects, XMPP cloud services offer solutions to a variety of drawbacks that SOAP and REST can not overcome, like the lack of service discovery and inability to send status notifications. In this context, a XEP, named IO Data was designed for sending messages from one computer to another, providing a transport for remote service invocation. The XEP enables services to publish their own input and output data types, which are discovered asynchronously without the use of any additional technology. When compared with the other described solutions, our proposed framework uses XMPP for sending messages to the smartphones, by adapting an IM infrastructure that can be used by multiple mobile platforms. Moreover, the framework uses the inherent properties of the cloud, in order to scale the infrastructure according the mobile load, thus, providing a flexible infrastructure for mobile cloud scenarios.
6.
sending messages from the cloud to the mobile, as a future research direction, we are interested in implementing a feature that enables to request the execution of a cloud task via XMPP so that the framework can be used in a bi-directional operation mode (cloud-to-mobile and mobile-to-cloud).
7.
ACKNOWLEDGMENTS
This research is supported by the Tiger University Program of the Estonian Information Technology Foundation, the European Regional Development Fund through the EXCS, Estonian Science Foundation grant ETF9287, Target Funding theme SF0180008s12 and European Social Fund for Doctoral Studies and Internationalisation Programme DoRa.
8.
CONCLUSIONS AND FUTURE RESEARCH DIRECTIONS
There are several mechanisms provided by the cloud vendors for delivering messages to the mobile applications (e.g. GCM, APNS, MPNS, etc.). These mechanisms are considered as black box services, which mainly are used by the cloud vendor for empowering the management of realtime data of their own cloud-based applications, when those are consumed by their associated mobile platform (Android, iOS, Windows Phone 7, etc.). This paper explored the possibility of implementing a messaging framework that can be used as open notification mechanism running at the cloud for handling asynchronous delegation of mobile tasks. The framework is created by extending the capabilities of a XMPP-based IM infrastructure and it can be reconfigured on demand as its mobile workload grows or shrinks. Moreover, the framework can be integrated with any application server and it uses a decentralized model that enables the creation of an interoperable and distributed architecture that may be used for fostering the routing of mobile information between organizations. The framework is explained in detail along with its architecture and the detailed analysis of the framework is provided from cloud-to-mobile and cloud-deployment perspective. According to the results, the framework shows that it is possible to send messages to the smartphones at a rate of service similar to that of other mechanisms and it also eases the process of mantaining an infrastructure which is fault-tolerant, flexible to changes on the fly and reliable for managing concurrency on demand. While current implementation of the framework supports
24
REFERENCES
[1] Apple, Inc. APNS. http://developer.apple.com/library/ios/. [2] B. Chun et al. Clonecloud: elastic execution between mobile device and cloud. In Proc. Of the 6th Conf. On. Computer systems, pages 301–314, 2011. [3] E. Cuervo et al. Maui: making smartphones last longer with code offload. In 8th int. Conf. On Mobile systems, applications, and services, pages 49–62, 2010. [4] H. Flores et al. A generic middleware framework for handling process intensive hybrid cloud services from mobiles. In 9th Int. Conf. On Advances in Mobile Computing and Multimedia, pages 87–94. ACM, 2011. [5] H. Flores et al. Towards mobile cloud applications: Offloading resource-intensive tasks to hybrid clouds. Int. Journal of Pervasive Computing and Communications, 8(4):344–367, 2012. [6] Google, Inc. AC2DM. http://code.google.com/android/c2dm/. [7] Google, Inc. GCM . http://developer.android.com/guide/google/gcm/. [8] HAProxy. The Reliable, High Performance TCP/HTTP Load Balancer. http://haproxy.1wt.eu/. [9] A. Hornsby et al. From instant messaging to cloud computing, an xmpp review. In 14th Int. Sym. On Consumer Electronics, pages 1–6. IEEE, 2010. [10] Ignite. SmackAPI - A XMPP client library. http://www.igniterealtime.org/projects/smack/. [11] jpoz/APNS. a gem for the Apple Push Notification Service. https://github.com/jpoz/APNS. [12] JSON simple. A simple Java toolkit for JSON. http://code.google.com/p/json-simple/. [13] R. Klauck et al. Mobile xmpp and cloud service collaboration: An alliance for flexible disaster management. In 7th Int. Conf. On Collaborative Computing: Networking, Applications and Worksharing, pages 201–210. IEEE, 2011. [14] K. Kumar et al. Cloud computing for mobile users: can offloading computation save energy? Computer, 43(4):51–56, 2010. [15] RFC6120. Extensible Messaging and Presence Protocol (XMPP). http://xmpp.org/rfcs/rfc6120.html. [16] Tsung - load testing. http://tsung.erlang-projects.org. [17] J. Wagener et al. Xmpp for cloud computing in bioinformatics supporting discovery and invocation of asynchronous web services. BMC bioinformatics, 10(1):279, 2009.
