Server Architectures of Existing Presence Services

19 Apr 2018

This essay has been written and submitted by students and is not an example of our work. Please click this link to view samples of our professional work witten by our professional essay writers. Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of EssayCompany.

In this section, we describe the system model, and the search problem. Formally, we assume the geographically distributed presence servers to form a server to-server overlay network, G = (V,E), where V is the set of the Presence Server (PS) nodes, and E is a collection of ordered pairs of V . Each PS node ni ∈ V represents a Presence Server and an element of E is a pair (ni,nj) ∈ E with ni,nj ∈ V . Because the pair is ordered, (nj,ni) ∈ E is not equivalent to (ni,nj) ∈ E. So, the edge (ni,nj) is called an outgoing edge of ni, and an incoming edge of nj. The server overlay enables its PS nodes to communicate with one another by forwarding messages through other PS nodes in the server overlay. Also, we denote a set of the mobile users in a presence service as U = {u1,...,ui,...,um}, where 1 ≤ i ≤ m and m is the number of mobile users. A mobile user ui connects with one PS node for search other user’s presence information, and to notify the other mobile users of his/her arrival. Moreover, we define a buddy list as following. Buddy list, Bi = {b1,b2,...,bk} of user ui ∈ U, is defined as a subset of U, where 0 < k ≤ |U|. Furthermore, B is a symmetric relation, i.e, ui ∈ Bj implies uj ∈ Bi.For example, given a mobile user up is in the buddy list of a mobile user uq, the mobile user uq also appear in the buddy list of the mobile user up. Note that to simplify the analysis of the Buddy-List Search Problem, we assume that buddy relation is a symmetric. However, in the design of Presence Cloud, the relation of buddies can be unilateral because the search operation of PresenceCloud can retrieve the presence of a mobile user by given the ID of the mobile user.

Problem Statement: Search Problem

When a mobile user ui changes his/her presence status, the presence service searches presence information of mobile users in buddy list Bi of ai and notifies each of them of the presence of ai and also notifies ai of these online buddies. The Search Problem is then defined as designing a server architecture of presence service such that the costs of searching and notification in communication and storage are reduced.

1.2 Motivation

Because of the increasing of the Internet, mobile devices and cloud computing environments can provide presence-enabled applications, i.e., social network applications/services, worldwide. Facebook , Twitter, Foursquare, Google Latitude , buddycloud and Mobile Instant Messaging (MIM) , are examples of presence-enabled applications that have grown rapidly in the last decade. Social network services are changing the ways in which They exploit the information about the status of participants including their appearances and activities to interact with their friends. The huge availability of mobile devices (e.g., Smartphones) that utilize wireless mobile network technologies, social network services enable participants to share presence experiences instantly across great distances. For example, Facebook receives more than 75 billion shared items every month and Twitter receives more than 60 million tweets each day. In the future, mobile devices will become more popular than today, sensing and media capture devices. Hence, we believe it is useful and social network services will be the next generation of mobile Internet applications.

A mobile presence service is an important component of social network services in cloud computing environments. The key function of a mobile presence service is to maintain an present list of presence information of all mobile users. The presence information includes details about a mobile clients or user location, availability, activity, device capability, and their choices. The service must also bind the this clients ID to his/her current presence information, as well as retrieve and subscribe to changes in the presence information of the user’s friends. In social network services, each mobile user has a friend list, typically called a buddy list, which contains the contact information of other users that he/she wants to communicate with. The mobile user’s status is known automatically to each person on the buddy list whenever he/she moves from one location to the other. For example, when a mobile user logs into a social network application, such as an Instant Messaging system, through his/her mobile device, the mobile presence service searches for and notifies everyone on the user’s buddy list. To maximize a mobile presence service’s search speed and minimize the notification time, most presence services use server cluster technology. Currently, more than 400 million people use social network services on the Internet. Given the growth of social network applications and mobile network capacity, it is expected that the number of mobile presence service users will increase substantially in the near future. Thus, a scalable mobile presence service is deemed essential for future Internet applications.

In the last decade, many Internet services have been deployed in distributed paradigms as well as cloud computing applications. For example, the services developed by Google and Facebook are spread among as many distributed servers as possible to support the huge number of users worldwide. Thus, we explore the relationship between distributed presence servers and server network topologies on the Internet, and propose an efficient and scalable server-to-server overlay architecture called PresenceCloud to improve the scalability of mobile presence services for large-scale social network services.

First, we examine the server architectures of existing presence services, and introduce the search problem in distributed presence architectures in large-scale geographically data centers. The search problem is a scalability problem that occurs when a distributed presence service is overloaded with buddy search messages.

Then, we discuss the architecture of PresenceCloud, a scalable server-to-server architecture that can be used as a building block for mobile presence services. The rationale behind the architecture of PresenceCloud is to distribute the information of millions of users among thousands of presence servers on the Internet. To avoid single point of failure, no single presence server is supposed to maintain all the information about all users. PresenceCloud arranges presence servers into a quorum-based server-to-server architecture to facilitate efficient searching. It also leverages the server overlay and a directed buddy search algorithm to achieve small constant search latency; and employs an active caching strategy that substantially reduces the number of messages generated by each search for a list of searching process. We analyze the performance of PresenceCloud and two other architectures, a Mesh-based scheme and a Distributed Hash Table based scheme. Through simulations, we also compare the performance of the three approaches in terms of the number of messages generated and the search satisfaction which we use to denote the search response time and the buddy notification time. The results demonstrate that PresenceCloud achieves major performance gains in terms of reducing the number of messages to reduce network traffic without sacrificing search satisfaction. Thus, PresenceCloud can support a large-scale applications distributed among thousands of servers on the Internet.

The contribution of this paper is threefold. First, PresenceCloud is among the imporatanta architecture for mobile presence services. To the best of our knowledge, this is the first work that shown the architecture of presence cloud that significantly best than those based distributed hash tables. PresenceCloud can also be utilized by Internet social network applications and services that need to replicate or search for mutable and dynamic data among distributed presence servers. The second contribution is that we analyze the scalability problems of distributed presenceserver architectures, and define a new problem called the buddy-list search problem. Through our mathematical formula, the scalability problem in the distributed server architectures of mobile presence services is analyzed. Finally, we analyze the performance complexity of Presence- Cloud and different designs of distributed architectures, and evaluate to prove the applications of PresenceCloud.

1.3 Existing System

In this section, we describe the previous research on presence services, and survey the presence service of existing systems. Well known commercial Instant Messaging systems has some form of centralized clusters to provide presence services. Jennings III et al. presented a taxonomy of different features and functions supported by the three most popular Instant Messaging systems and Yahoo! Messenger. The authors also provided an overview of the system architectures and observed that the systems use client-server-based architectures. Skype, a popular voice over Internet Protocol application, utilizes the Global Index (GI) technology to provide a presence service for clients and people. Global Index is a multi-tiered network architecture where each node maintains full knowledge of all available clients connected to it. Since Skype is not an open protocol, it is difficult to determine how GI technology is used for presence services. Moreover, Xiao et al. analyzed the traffic of MSN and AIM system. They found that the presence information is one of most network traffic in instant messaging systems. In, authors shown that the largest message traffic in existing presence services is buddy NOTIFY messages.

1.4 Limitations of Existing System

  • This system allows makes congestion in the network.
  • It is not applicable for large scale network.
  • It increases the search latency.

1.5 Proposed System

Recently, there is an increase amount of interest in how to design a peer-to-peer Session Initiation Protocol. P2PSIP has been developed to remove the the disadvantages of centralized server, reduce costs, and prevent loses due to failures in server-based SIP deployment. To maintain presence information, P2PSIP clients are organized in a Distributed Hash Tables system, rather than in a centralized server. However, the presence service architectures of Jabber and P2PSIP are distributed,

the buddy-list search problem we defined later also could affect such distributed systems.

It is noted that few papers in discuss about the scalability issues of the distributed presence server architecture. Saint Andre observed the traffic generated as a result of presence information between users of inter-domains that support the XMPP. Houri et al. Show that the amount of presence traffic in SIMPLE can be extremely high, and they analyze the effect of a large presence system on the memory CPU loading. Those works in study related problems and developing an initial set of guidelines for optimizing inter-domain presence traffic and present a DHT-based presence server architecture.

Recently, presence services are also developed in the mobile services. For example, 3GPP has defined the integration of presence service into its specification in UMTS. It is based on SIP protocol, and uses SIMPLE to manage presence information. Recently, some mobile devices also support mobile presence services. For example, the Instant Messaging and Presence Services (IMPS) was developed by the Wireless Village consortium and was united into Open Mobile Alliance (OMA) IMPS in 2005. In, Chen et al. proposed a weakly consistent scheme to reduce the number of updating messages in mobile presence services of IP Multimedia Subsystem (IMS). However, it also suffers scalability problem since it uses a central SIP server to perform presence update of mobile users. In, authors presented the server scalability and distributed management issues in IMS-based presence service.



Chapter – 2

Literature Survey

2.1 Introduction

In this section, we describe previous researches on presence services, and survey the presence service of existing systems

2.2 Related Paper Discussions

2.2.1 Title: A study of internet instant messaging and chat protocols

Year: 2006

Author: R. B. Jennings, E. M. Nahum, D. P. Olshefski, D. Saha, Z.-Y. Shae,


Well known commercial Instant Messaging systems has some form of centralized clusters to maintain presence services. Jennings III presented a taxonomy of different features and functions supported by the three most popular Instant Messaging systems, AIM, Microsoft MSN and Yahoo! Messenger. The authors also provided a description of the system architectures and analized that the systems use client-server-based architectures.

2.2.2 Title: Understanding instant messaging traffic characteristics

Year: 2007

Author: Z. Xiao, L. Guo, and J. Tracey


Xiao analyzed the traffic of MSN and AIM system. They observed and got that the presence information is one of most messaging traffic in instant messaging systems

2.2.3 Title: Ims presence server: Traffic analysis and performance modelling

Year: 2008

Author: C. Chi, R. Hao, D. Wang, and Z.-Z. Cao,


In this, authors shown that the huge message traffic in existing presence services is searching the locations ,buddies etc.

2.2.4 Title: Peer-to-peer internet telephony using sip


Author: K. Singh and H. Schulzrinne


Now a days, there is an increase amount of interest in how to design a peer-to-peer Session Initiation Protocol . Peer to Peer SIP has been developed to remove the centralized server, reduce maintenance costs, and prevent disadvantages in server-based SIP deployment. To maintain presence information, P2PSIP clients are arranged in a DHT system, rather than in a centralized server. However, the presence service architectures of Jabber and P2PSIP are distributed, the search problem we defined later also could affect such distributed systems.


Request Removal

If you are the real writer of this essay and no longer want to have the essay published on the our website then please click on the link below to send us request removal:

Request the removal of this essay
Get in Touch With us

Get in touch with our dedicated team to discuss about your requirements in detail. We are here to help you our best in any way. If you are unsure about what you exactly need, please complete the short enquiry form below and we will get back to you with quote as soon as possible.