2014 IEEE 3rd Symposium 3rd Symposium on Network on Network CloudCloud Computing Computing and Applications and Applications
A Comparative Study of Signaling Protocols for Data Management and Synchronization in Fatih Project with School Level Cloud Proxy Server Deployment Fidan Kaya#, Süleyman Eken#, Zana İlhan*, Adnan Kavak#, Ahmet Sayar#, Umut Kocasaraç*, Suhap Şahin# #
Computer Engineering Department, Kocaeli University, İzmit, Turkey (fidan.kaya, suleyman.eken, akavak, ahmet.sayar, suhap.sahin @kocaeli.edu.tr) * Ardıç Arge Bilgi ve Teknoloji Cozumleri, Tübitak TEKSEB, Gebze, Kocaeli, Turkey * (zana.ilhan, umut.kocasarac @ardictech.com) #
Abstract— “Movement of Enhancing Opportunities and Improving Technology”, abbreviated as Fatih, is among the most important educational projects in Turkey, in which students and teachers can use their tablet PCs to obtain educational data (text, images, media, etc.) stored in cloud servers. However, given the large number of users along with vast amount of educational data to be accessed, traffic overload and ineffective signaling protocols to manage connection and synchronization are the potential problems in Fatih project. To provide possible solution to this, we propose to employ proxy server at school level. A signaling protocol that provides connection mechanism and synchronization between tablet-proxy server and tablet-cloud server, and that meets cloud-based SaaS (Software as a service) in this architecture is necessary. In this paper, signaling protocols such as XMPP (Extensible Messaging and Presence Protocol), SIP (Session Initiation Protocol), and ARCSPXP (ARDIC Cloud Service Platform Extension Protocol) are reviewed and compared for their feasibility of employing in this school level proxy server based architecture. Keywords— SIP, XMPP, ARCSPXP, signaling, synchronization, communication, Fatih project.
accessing the educational data. Although tablets at outside of schools communicate with the cloud server directly, tablets at schools communicate with the cloud server via a proxy server. Proxy server has two critic roles, (i) reducing data traffic in the school ecosystem and (ii) ensuring continuity of service in case of not accessing to cloud services. Signaling protocols are used for establishing communication at tablet-cloud level, and proxy-cloud level. This study evaluates feasibility of signaling protocols such as XMPP, SIP and ARCSPXP. Detailed information about these protocols is presented. And, the most suitable protocol for our system is elucidated by comparing these protocols.
II. PROPOSED SYSTEM ARCHITECTURE
data
I. INTRODUCTION Turkish Ministry of Education has recently launched Fatih project that is primarily based on employing tablets and smart boards in classes for students and teachers and using educational data stored in centralized cloud based servers. Currently, there are three main actors of the ecosystem within the scope of this system: (i) a cloudbased SaaS services, (ii) the smart boards in classes, and (ii) tablets at students and teachers/educators. These actors are foreseen to actively exchange data with cloud services within the project ecosystem. However, there exist limitations due to network traffic and infrastructure between the tablet clients and cloud servers that store educational data. The limited network bandwidth and large amount of educational data , which are two major parameters affecting the system performance, cause increase in network delays and degradation of system performance in case of that a user in school network wants to access to the cloud servers to download educational data. In order to solve these problems, we propose using a client-side proxy server located at schools and an extension framework for integrating it into the cloud system. Proxy server is a solution approach to both decreasing network traffic and increasing the efficiency in data transfers between the end users (tablets) and cloud servers in Fatih project. Tablets, cloud servers and proxy servers are the elements of the proposed system. Here, tablets in the schools and outside of schools are in communication with the cloud server for /14 $31.00 © 2014 IEEE 978-0-7695-5168-5/14 $31.00 © 2014 IEEE DOI 10.1109/NCCA.2014.29
Fig. 1: Proposed system architecture with school level proxy in Fatih Project
We propose to employ school level proxy server in Fatih project ecosystem as shown in Figure 1. In current architecture, Tablets at school or home involve communication with cloud server. By installing a proxy at school, overall system becomes manageable and scalable, and overall network traffic can be decreased. However, such architecture requires effective signaling protocols to achieve following: x Data synchronization between proxy server and tablet x Update of educational data in proxy server, which is already modified on Tablet. x Synchronization and back up of data from tablet to cloud server. x Synchronization of educational data stored in Proxy server to cloud server.
133
III. XMPP (JABBER) PROTOCOL
A simple SIP call procedure is given in Figure 2.
XMPP (Extensible Messaging and Presence Protocol), originally named as Jabber, is an XML based signaling protocol for message oriented middleware. It enables two endpoints on the Internet to mutually transfer any structural information. Also, it allows message, file, and status transfer among more than one unit (user, device, etc.). Although XMPP is first intended for instant messaging, its XMPP has been improved for larger systems such as cloud computing in parallel with an increase in human requests for communication [1]. XMPP finds large areas of application such as instant messaging [2], interactive social media [3], and collective work flow [4], internet of Things, multi-agent systems, and cloud computing [5]. It conveys not only text or status information, but also voice and video messages in real-time is transmitted between users. An example of a message that supports XMPP protocol is as follows:
Fig. 2: Simple SIP call procedure [9]
V. ARCSPXP PROTOCOL ARCSPXP is a protocol developed by ArdicTech [10] for facilitating communication between “client-to-server” and “server-toserver” and monitoring the connection between the client-server. ARCSPXP is an optimized signaling protocol that is specialized to mobile devices which are communicating with cloud based services via its internet connection. ARCSPXP is also used service level signaling for cloud internal signaling processes in the ArCloud. The message format in ARCSPXP consists of two parts. Mandatory fields of message are available in the first part, and they are XML-based. The second part has parametric types of message. These sections are filled through Cloud APIs which are open to the outside and have Java Script Object Notation (JSON) [11] format which is a text-based open standard designed for human-readable data interchange. An example of a message belonging to ARCSPXP protocol is following:
XMPP has three basic XML elements: status (presence), messages and iq (info / query). Notification mechanism that allows entities to acquire network usability information is provided by element from an entity which the other entities are member of it. An entity sends information to other entities by means of element asynchronously. Request and responses are carried by element.
IV. SIP PROTOCOL SIP is a signaling protocol which creates, set up and finishes VOIP phone calls and has a text-based message structure and defines messages which will be sending between couples during a call. Also SIP can be used in many areas such as; video conferences, fax transmission, file transfer and transferring status information [6]. Elements of the SIP protocols are defined by RFC 3261, which are divided into two types: user agents and servers; User Agents define endpoints, which are responsible for managing a SIP session and transmission of SIP messages. There are also four different server types in SIP protocol: redirect server, proxy server, registrar server, and location server [6, 7]. Besides being a text-based, SIP is also http-like protocol. Its messages are similar to http messages. Request and response messages defined by RFC3261 are the two types of messages in SIP. An example of a SIP request message is below [8]. INVITE sip:
[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID:
[email protected] CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142
Due to the fact that XML is structurally powerful, i.e., structure and namespace are easily extendible; the main structure of the message is expressed in XML. Content of the command is sent in JSON format. ARCSPXP protocol deals with three level result of a process. First level result is related to real delivery of the message to the end-point; Sender receives an in-band result of the message that responded by receiver. This delivery information is managed out of presence and session management of the connection that is established between two peers (Server and Client). Second level result is related to start of task and third level result is related to completion of the task. Fig. 2 shows lifecycle of an ARCSPXP signaling. ARCSPXP is designed in a manner of “Idempotent Consumer Pattern” [12].
134
VI. EVALUATION OF SIGNALING PROTOCOLS Features of ARCSPXP, XMPP, and SIP protocols are summarized in Table 1. If we compare the semantic structures and functional messaging background of protocols which are examined in our study, ARCSPXP signaling protocol has a significant difference in terms of integration support of SaaS services. This difference provides flexibility to ARCSPXP protocol's SaaS services for expanding message scale. XMPP and SIP protocols are general purposed protocols and these protocols try to solve the security problems at transport layer except protocol messaging. In addition to supporting functionalities of SIP and XMPP, ARCSPXP also provides enhanced security solution with AAA (Authentication, Authorization, and Accounting) [13] support. ARCSPXP protocol is not a general purposed protocol so today’s clients are not use this protocol widely, But ARCSPXP is specialized about large scale service layer signaling. So that ARCSPXP provides a more manageable and easy to use integration structure for mobile devices. SIP protocol is specialized in audio/video communication. It specialized about definition of VoIP session and life-cycle of VoIP session. XMPP protocol is different from SIP protocol and care about the semantic message structure and offline state of client. XMPP has better message support for instant messaging and state communication. But XMPP uses too many port ranges so this may cause security vulnerabilities [14]. There is a possibility of contamination harmful files, viruses, trojan etc. during file sharing and data transfer between clients. Many advanced communication and collaboration system contains some of these protocols in itself. ARCSPXP cares about the lifecycle of message and related task that we want to monitor. ARCSPXP has ability to deliver the same message to multiple clients with structured data types using streaming structure. ARCSPXP protocol monitors the activities of the clients via a status messages and transmits operations about functionality of ArCloud SaaS via type of messages. Suppose that, the status message is transmitted once every 10 minutes and also a command message is transmitted at an average of 60 minutes. In XMPP protocol, total of 168 (1*24 + 6*24) messages are sent per day for such communication. However, status messages are concealed in ACK messages in the architecture developed for ARCSPXP. In other words, when the message is sent to the client machine, status message has been concealed in ACK messages arrived from client. So, it avoids the necessity to send some status messages at server side and to receive response from client. Thanks to this structure, this corresponds to possibility of eliminating 24 status messages to be send and received response daily. This provides decreasing bandwidth usage at server side by up to 14%. Table 1: Features of signaling protocols Property ARCSPXP XMPP Authentication user name and Authentic is done with password ation user name, Mechanis password, m certificate, and the HW provided id Protocol It is clientIt is clientconnectio server protocol server n type based on XML- protocol based JSON on XML
Usage
It is used as connection oriented UDP and TCP
It is used as connection oriented UDP
NAT and Firewall Support
It works seamlessly with NATs and firewalls (STUN enabled)
Communi cation types
Communication is between the client-server, Server to Server, and it is used as IPC in ArCloud Services[15] It can manage Offline messages of an endpoint In-Band Transfer Out-of-Band Transfer
It works seamlessly with NATs and firewalls (STUN enabled) Communicati on is between the clientserver
Offline Message Support In-Band transport Out-ofBand transport Message lifecycle managem ent
Endpoint presence
Message compressi on
SIP user name, Radius password
It is used as connectionles s UDP usually. But sometimes connection oriented Problems may occur while working with NATs and firewalls Peer to peer (client-server)
It can manage Offline messages of an endpoint In-Band Transfer Out-of-Band Transfer
There is no offline message
3 Layer message lifecycle management (Presence Independent) Connection oriented endpoint presence
1 Layer message lifecycle management (Presence dependent) Connection oriented endpoint presence
Message compression support(GZip [16]) as a part of protocol
Provided by implementatio ns protocol doesn’t care about compression supports of messages
1 Layer message lifecycle management (Presence dependent) Endpoint Presence is not provided by the protocol Provided by implementatio ns protocol doesn’t care about compression supports of messages
In-Band Transfer Out-of-Band Transfer
Performances of XMPP and SIP have been tested on Eyeball Server systems [17]. The system has 8 servers each with Dual Processor Intel Xeon CPU Speed 3.00 GHz 2 MB cache, 2 GB RAM, Fedora 6 Kernel 2.6.18. The test scenario for XMPP is as follows: average 3600 seconds online duration, average 0.01 seconds message sending duration, average 6 seconds status update duration, average 0.5 seconds roster update duration. Each test server has 60000 users. 30000 of the users are connected simultaneously. XMPP has resulted in bandwidth usage of 4907 Kbits/s for incoming and 5858 Kbits/s for outgoing 120 K TCP connections. Memory usage is 3.2 KB per TCP connection.
It is requestresponse protocol based on text (ASCII). Also it has http based messages.
135
Regarding SIP server, the test scenario is as follows: among 100 K users, 20 TRANSACTION, 111 INVITE, 111 ACK and 111 BYE messages are sent. It resulted in bandwidth usage of 3019 Kbits/s for incoming and 5560 Kbits/s for outgoing 100 K TCP connections. Memory usage is 8.25 Kbyte per TCP connections.
VII.
CONCLUSIONS
In this paper, we have reviewed some of the signaling protocols such as XMPP, SIP, and ARCSP-XP which may be candidate protocols for use in Fatih Project with the proposed deployment architecture based on school level cloud proxy server. XMPP provides smaller memory usage compared to SIP. In terms of integration support of SaaS services, ARCSP-XP signaling protocol has a significant difference. It can provide reduction at bandwidth usage with the properties provided at client - server communication. Acknowledgments This work is supported by the TUBİTAK under grant EEEAG 113E033 within 1003 Fatih Project Call. REFERENCES [1]
[2] [3]
[4]
[5]
[6] [7]
[8]
[9]
[10] [11] [12] [13] [14]
[15] [16] [17]
Hornsby A. and Walsh R., “From Instant Messaging to Cloud Computing, an XMPP review”, IEEE 14th International Symposium on Consumer Electronics, 2010. Saint-Andre P., Jingle: Jabber Does Multimedia, IEEE Multimedia, (14)1, pp. 90-94, 2007. Hoekman K., Ide M., Deryckere T., and Martens L., “XMPP and iDTV or How to Make Television a Social Medium”, 4th Consumer Communications and Networking Conference, pp. 686-690, 2007. Roczniak A., Melhem, J., Lévy P., and El Saddik A., “Design of Distributed Collaborative Application through Service Aggregation”, 10th International Conference on Distributed Simulation and Real-time Applications, 2006. Wagener J., Spjuth O., Willighagen E.L., and Wikberg J.E.S., “XMPP for cloud computing in bioinformatics supporting discovery and invocation of asynchronous web services”, BMC Bioinformatics, 2009. J. Rosenberg et al., “SIP: Session Initiation Protocol”, IETF RFC 3261, June 2002. SIP Server Technical Overview (April 2004). [Online]. Available: http://www.radvision.com/NR/rdonlyres/0AFA30DF-DAD6-461D-943 C-ED33F3E7ABD8/0/ SIPServerTechnicalOverviewWhitepaper.pdf. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers, Session initiation protocol (SIP) basic call flow examples, Internet Society, 2003. [Online]. Available: http://www.ietf.org/rfc/rfc3665.txt R.Srinivasan, V. Vaidehi, K. Harish, K. LakshmiNarasimhan, S. LokeshwerBabu, V. Srikanth ,“Authentication of Signalling in VOIP Applications”, Asia Pacific Conference on Communications, 3-5 October 2005. Arcloud, http://www.ardictech.com http://www.ietf.org/rfc/rfc4627.txt Enterprise Integration Patterns, Gregor Hohpe and Bobby Woolf ,ISBN 0321200683 Authentication, Authorization, Accounting (AAA), http://en.wikipedia.org/wiki/AAA_protocol Saint-Andre P., Extensible Messaging and Presence Protocol (XMPP): Core (March 2011) [Online]. Available: http://xmpp.org/rfcs/rfc6120.html IPC, http://en.wikipedia.org/wiki/Inter-process_communication GZip, http://en.wikipedia.org/wiki/Gzip http://summit.sfu.ca/item/8911
136
