Sip2Share

A Middleware for Mobile Peer-to-Peer Computing

Gerardo Canfora and Fabio Melillo

Department of Engineering, University of Sannio, viale Traiano 1, 82100 Benevento, Italy

Keywords:

Mobile Device Programming, Service Oriented Computing, Peer-to-Peer, Android.

Abstract:

The growing success of mobile devices is enabling a new class of applications that overcome the traditional

models of desktop applications and web browsing, and embrace entirely new ways of computing. Service-

oriented computing and the rapidly growing power of mobile devices are the key ingredients of a new gener-

ation of low-cost, lightweight applications where mobile devices are no longer intended as a means to access

server-side data and functionality, but as a source of services that other devices can discover and invoke.

In this paper we introduce Sip2Share, a middleware that allows for publishing, discovering and invoking ser-

vices in a peer-to-peer network of Android devices. A characteristics of our middleware is that services are

advertised, discovered and called using the same native mechanisms of the Android platform, i.e. intent,

manifests and broadcast receivers.

1 INTRODUCTION

Mobile devices, such as smartphones and tablets, are

experiencing a growing popularity, to the point that

in 2010 the number of handled devices sold has ex-

ceeded the sales of personal computers (Maier, 2011).

Most of these devices are increasingly powerful in

terms of computation, data storage and visual dis-

plays, are equipped with a rich array of sensors, are al-

most always connected, and have a good autonomy of

batteries. According to market research(ComScore,

2012), the top 5 smartphone sold in the world have, on

average, 1GHz CPU, 512MB RAM, 1500mAh bat-

tery, WiFi and 3G/4G data connection. Thus, it is

possible to use handled devices as part of a network,

not only as simple users of back-end services, but also

as providers of services.

As a matter of fact, the pervasiveness of mo-

bile devices is enabling a new generation of service-

oriented applications where different kinds of actors,

including people, sensors, and software agents, ex-

change services in dynamic, peer-to-peer overly net-

works. This entails overcoming the traditional ap-

proach of sharing content among devices to move to-

wards environments that allows for publishing generic

services, including human-based services, on smart-

phones. In this paper, we introduce a middleware

architecture to support the development of service-

oriented pervasive applications for mobile devices.

The middleware, named Sip2Share, implements a

peer-to-peer network of services provided by mobile

devices and offers mechanisms to publish, advertise,

discover and invoke the services. Sip2Share has been

designed for the Android

platform and uses extended

versions of Android native mechanisms, namely in-

tent, manifests and broadcast receivers, to publish,

discover and consume services. Thus, developers

who are familiar with application development for

Android will need very little training to be productive

with our middleware. The choice of using Android

derives from several factors, including the growing

diffusion according to the market data (Pettey, 2011),

Android is the most widespread OS for handled de-

vices, the open-source nature of the platform, and the

fact that it is well supported and easily programmable

using classic IDEs, like Eclipse

, and the Java lan-

guage. A point of strength of our middleware is the

transparency. From a user point of view, spatial, tem-

poral and synchronization transparency is supported

by using a publish/subscribe pattern. In addition, the

middleware supports transparency for software devel-

opers, which allows for easily migrating existing ap-

plications without a need for reengineering.

The middleware has many areas of application,

for example: social and collaborative applications,

health and emergency management and war games.

http://developer.android.com/index.html

http://www.eclipse.org

445

Canfora G. and Melillo F..

Sip2Share - A Middleware for Mobile Peer-to-Peer Computing.

DOI: 10.5220/0004123004450450

In Proceedings of the 7th International Conference on Software Paradigm Trends (ICSOFT-2012), pages 445-450

ISBN: 978-989-8565-19-8

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

Whilst the work is still in progress, a stable version

of Sip2Share has been developed and is available for

download at Googlecode

. To demonstrate the mid-

dleware, we implemented a social application, named

HelpMe!, that supports networks of people sharing in-

terests and expertise to pose and answer questions on

speciﬁc topics.

The paper is organized as follows: section 2 dis-

cusses technologies for mobile peer-to-peer commu-

nication and section 3 introduces the main ideas our

middleware and discusses current implementation, in-

cluding the architecture, APIs, and the communica-

tion among components. Section 4 describes the

HelpMe! application and section 5 concludes the arti-

cle by addressing some technical challenges and pro-

viding a future development roadmap.

2 RELATED WORK

The expansion of mobile communication into IP

based networks, allow for designing complex archi-

tectures also for handled devices. Most research work

has focussed on peer-to-peer communication, due to

the dynamic nature of the domain.

Several researchers use the Mobile Ad-Hoc Net-

work (MANet) paradigm for communication. An ex-

ample is the middleware Rescue (Juszczyk and Dust-

dar, 2008), designed as a support for emergency teams

in the management of natural disaster, a scenario in

which, very often, static internet infrastructures are

not available. Haggle (Nordstr

om et al., 2009) is a so-

lution for sharing content in spontaneous ad-hoc net-

works; it uses pure peer-to-peer communication based

on the publish/subscribe pattern. Each node stores a

graph with the topology of the network; the search

of content is topic based and the range in which the

search is applied is the set of neighborhood nodes

reachable. While these papers present interesting so-

lutions, they do not apply to our idea of building a

peer-to-peer network of services using the Internet for

communication.

Among the solutions designed for the infrastruc-

ture networking mode, many solutions use some form

of proprietary protocols for sharing contents (Kel

enyi

et al., 2007)(Hulbert, 2006) (Kotilainen et al., 2005)

(Molnr et al., 2007) (Horozov et al., 2002). Other ar-

ticles in he literature have explored the possibility of

publishing traditional web services on mobile phones

(Srirama et al., 2006). Some optimization have been

applied to reduce consumption of resources on the de-

vices; as an example, the Wireless SOAP (WSOAP)

http://sip2share.googlecode.com/svn/trunk/Sip2Share

Figure 1: Communication stack.

protocol (Apte et al., 2005) reduces the dimension of

the message from 3 to 12 times with respect to SOAP.

The PeerDroid project (Picone et al., 2010) imple-

ments the JXTA (Gong, 2001) stack on the Android

platform. PeerDroid has a hybrid peer-to-peer archi-

tecture, with a rendez-vous super-peer for the initial-

ization of the communication; the JXTA standard al-

lows for exchanging data among peers independently

of the underlying hardware structure. However, the

compliance to the standard and the xml-based ﬁle ex-

changed tend to be too heavy for many smartphones.

An alternative is to use use the SIP proto-

col,(Rosenberg et al., 2002) as in the case of Sip2Peer

(Picone, 2011), which exploits a simple SIP datagram

to exchange text-based messages among Android

peers. Sip2Peer implements mechanisms to exchange

messages, including JSON-like messages,(Crockford,

2006) between peers with known addresses in a peer-

to-peer network. It also provides a bootstrap peer that

stores the addresses of all the peers registered in the

network. Our work builds on top of the communica-

tion mechanisms of Sip2Peer and adds the additional

resources needed for discovery, publishing and using

services in a network of Android devices.

3 Sip2Share

The main idea of our work is to share services among

peers using the Android platform, and to provide

application developers with an API for remote ser-

vices that resembles the native Android API for inter-

application communication on a single device. In par-

ticular, we use an extension of the intent mechanism

for communication among services on remote peers

in a way that is transparent to both the programmer

and the users.

Figure 1 shows the layers of communication com-

prised in our middleware. An IP network is at the bot-

tom level of the stack; over this layer, there is the SIP

session control, needed for identifying the nodes over

the network. Next layer is Sip2Peer, that uses the SIP

ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends

446

protocol to send data. Our middleware is positioned

on the top of this stack, and manages the overlay net-

work, with a full duplex communication and the abil-

ity to deploy, publish discover and invoke services on

mobile devices.

The network is hybrid, with peers and super-peers.

The purpose of super-peers is to decouple the peers

from each other by implementing a publish/subscribe

pattern. Peers are associated to service descriptions

that are stored and managed by super-peers; in this

way, a peer that needs to connect to the network of

services only have to send a request to the super-peer

with a description of the services it seeks. The super-

peer will return the addresses of the peers in the spe-

ciﬁc overly network related to the request.

3.1 Communication among Services

using Intents

Sip2Share uses intents as a mechanism for commu-

nication among services on remote peers. To help

understanding our communication mechanism, we

brieﬂy recall how native Android intents work in the

local scenario.

Android allows applications on a device to com-

municate with each other by means of Intents, i.e. ab-

stract descriptions of an operations to be performed

on some pieces of data

. This mechanism is halfway

between message passing and publish-subscribe and

provides a facility for performing late runtime binding

between different applications. An application that

desires to communicate with other applications pre-

pares an intent with the data and the action to be en-

acted on those data, and sends the Intent to Android,

which will search, among the registered applications,

those that can satisfy the request. BroadcastReceivers

are used to receive intents sent by other applications,

and bind the abstract operation to an actual piece of

code that implements it. Intents are ﬁltered by An-

droid based on the action they request; only match-

ing actions are sent to the respective receiver. In this

way, the applications are loosely coupled because the

developer does not need to know which applications

are installed on a device; she only sends an Intent to

whom can handle it, and the target application is dis-

covered at execution time.

We adopted the same philosophy in our middle-

ware. Sip2Share uses remote intents for discovery

and invocation of services. A peer prepares the in-

tent and, through Sip2Share, sends it in broadcast to

the peers in the network; if the sending peer already

http://developer.android.com/guide/topics/intents/inten

ts-ﬁlters.html

Class_middleware_simplepackage Data [ ]

Activity

BroadcastContentPeer

ServiceDescriptor

RemoteBroadcaster

GenericRemote

ResultReceiver

FactoryRemote

Peer

ServiceInfo

Converter

SuperPeer

˙use¨

0..*

Figure 2: Sip2Share main classes.

knows the address of other peers that can respond to

the particular request, then it can send it directly. Oth-

erwise, it has to send some data (the service descrip-

tor) to the super-peer, and to wait for a reply with the

addresses of the peers to contact. All the commu-

nications are asynchronous and the peers are alerted

by push notiﬁcations. Our aim is that, if a devel-

oper is already skilled in Android development, she

does not have to learn another technology, because

Sip2Share uses the same Android’s patterns for re-

mote communications among devices as for commu-

nication among applications on the same device.

3.2 Architecture

Figure 2 shows the main classes of the middleware; its

boundaries are marked by the Activity and the Peer

classes, the ﬁrst belongs to the user application, the

second one to the Sip2Peer middleware.

The developer is provided with a class,

RemoteBroadcaster, that has the methods for

sending intents across the networks of peers, using

the same signature of the local method. The rest

of the classes and operations are hidden from the

developer, that will be notiﬁed asynchronously

when a request is completed. The core classes

are two: BroadcastContentPeer and Converter.

BroadcastContentPeer is the part of the middleware

responsible for communication; it uses the Converter

for marshaling and un-marshaling the messages.

When a request is dispatched, ResultReceiver is

responsible for collecting the results and delivering

them to the service that originated the request.

Services are modeled by a ServiceDescriptor, which

Sip2Share-AMiddlewareforMobilePeer-to-PeerComputing

447

is a nested class of ServiceInfo. Based on this

informations the super-peer can seek the right peer,

comparing the requested and published actions.

3.3 Application Interface

For a developer, it is easy to migrate a local applica-

tions to a peer-to-peer architecture using Sip2Share.

In fact, there are very few additional actions to

be performed with respect to the local scenario.

First, the current implementation of our middleware

needs a peer for initializing the connections; we pro-

vide a super-peer implementing a syntactic match-

ing among actions, and the pattern for push notiﬁ-

cations, all for the standard Java environment. Once

set up the super-peer, the developer has to create a

RemoteBroadcaster, using FactoryRemote. Then she

can send the Intent. An example is in the following

fragments of code, that compare the local scenario

with the remote one.

LOCAL

1. I n t e nt in t en t =

=new In t e n t ( " o rg . u ni s a n ni o . s o m e t h i n g h a p p e n s " );

2. i n t e nt . p u t Ex t r a (" m y L ab e l " , " th e V a lu e " );

3. this. s e n d O r d er ed Br oa dc a s t ( i n tent , null,

my Br o a d ca st R e c ei ve r ,null, Ac t iv i t y . RE S ULT _ OK , null,

null);

REMOTE

1. I n t e nt in t en t =

=new In t e n t ( " o rg . u ni s a n ni o . s o m e t h i n g h a p p e n s " );

2. i n t e nt . p u t Ex t r a (" m y L ab e l " , " th e V a lu e " );

3. R e m o t e B r o a d c a st r e m o t e B r o a d c a s t e r =(new Fa c t o r y R e m o te () )

. g et Re m o t e B r o a d c a s t e r (this);

4. r e m o t e B r o a d c a s t e r . s e n d R e m o te Or d e r e d B r o a dc as t ( i n t ent ,

null, my B r o a d ca st R e c ei ve r , null, Ac t iv it y . RE S UL T _OK ,

null, null ) ;

It is evident that local and remote broadcasting of

events use the same approach, although there are lit-

tle differences between the two fragments of codes, in

line 3 and 4. Also the remote publication of a service

is very similar to the local scenario, requiring only

the deﬁnition of the actions that the device can man-

age. The following fragment of code shows how a

peer publishes its own service, which will be reach-

able in response to the particular action deﬁned in the

descriptor.

1. R e m o t e B r o a d c a st r e m o t e B r o a d c a s t e r =(new Fa c t o r y R e m o te () )

. g et Re m o t e B r o a d c a s t e r (this);

2. S er vi ce I n f o si n fo =new S e r vi ce In f o ();

3. s i nf o . a d d D e s c r i p to r ( " org . u n i sa n n i o . s o m e t h i n g h a p p e n s " ,

null, null , null);

4. r e m o t e B r o a d c a s t e r . s en dT oS up er Pe er ( s info ,

Co nv e r t er . PU B LI SH );

3.4 Super-peers and Service Discovery

In addition to the middleware, we provide a super-

peer that can handle several types of messages,

needed for discovering and publishing services. Our

super-peer is an abstract class that needs to be imple-

mented, either in Android or standard Java, to imple-

ment speciﬁc matching and discovery algorithms. A

peer that is seeking some service sends a request to the

super-peer; this returns the data needed by the peer to

contact the other devices that offers services eligible

for satisfying the peer request.

Figure 3: High level operations.

Figure 3 shows an an example. A peer is looking

for a service in a new network; it sends a subscribe

request to the super-peer (1), if there are some peers

that can handle the request the super-peer returns their

addresses (2), and the peer can contact them directly

(3). Otherwise, the peer request will be stored on the

super-peer, and the peer will be notiﬁed when another

peer will have published the requested service.

A peer can publish a service by sending a message

to the super-peer with its service descriptor. A service

descriptor is a structure in which are stored the action

and tags; the action is the same as the Android actions,

the tags are possibly used by the super-peer to match-

ing requests against available services. The message

sent to the super-peer may differ, according to the pur-

pose of the communication: publishing or retracting

a service, subscribe or unsubscribe a service or a cat-

egory of services.

Figure 4: Possible interactions.

As an example, Figure 4 depicts an interaction

scenario between two requesting peers, a super-peer

ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends

448

and a peer that offers a service that march the requests.

The main steps are: (a) peer A subscribes for a service

x; (b) the super-peer looks for a match, there are no

results for that request, then no address is returned;

x; (d) the super-peer ﬁnds a match and notiﬁes peer

A with the address of B; (e) A and B communicate

using Sip2Share; (f) a new peer, C, subscribes for x;

(g) the super-peer ﬁnds a match and notiﬁes C with

the address of B; (h) C and B communicate using

Sip2Share. If the peers which offer services match-

ing the request of the requesting peer are more than

one, steps (e) and (h) use an ordered broadcast to send

the message; all responses are addressed only to the

original requester.

4 AN EXAMPLE OF

APPLICATION: HelpMe!

In this section we describe a simple application that

exploits the Sip2Share middleware to publish human-

based services. The basic idea is to help people to

share knowledge with other members of a thematic

network. Knowledge sharing happens in the form of

threads of queries and answers. As an example, a

user, globally connected, is in a shopping mall to buy

a camera and, in front of several offers, she needs a

suggestion from an expert to make a decision. She

can use HelpMe! to broadcast a query on the topic

Photography; all the peers that have registered as ex-

perts on the same topic will receive the query, and can

answer it. All the answers will be collected by the

original requester device and the user will be alerted

using notiﬁcations.

Figure 5 illustrates an example of use of HelpMe!

The ﬁrst peer submit a query to the peers network on a

particular topic, in this case Photography [5(a)]. The

scenario assumes that there are no peers registered on

the topic. Later, peer B publishes services for two

topics, Computer and Photography [5(b)]; the super-

peer checks the matches of the new services with the

stored queries, and send a notiﬁcation to peer A. The

middleware component on peers A receives the list

of peers of interest – in this case only peer B – and

sends the query. Peer B receives a notiﬁcation with

the query and can answer it [5(c), 5(d)]. In case of

multiple peers that match a query, each answer pro-

duces a notiﬁcation on peer A, and all the answers are

shown in a list below the correspondent query [5(e),

5(f)].

Figure 6 shows the structure of the application.

Thanks to RemoteBroadcaster, the application needs

only the main Activity and the speciﬁc receivers: the

(a) A

. (b) B

. (c) B

(d) B

. (e) A

. (f) A

Figure 5: Simple question and answers.

middleware hides from the developer all the complex-

ity of discovery, notiﬁcation and communication.

The application, while simple, illustrates the typi-

cal structure of a Sip2Share application, which com-

prises middleware components on the devices and a

super-peer, deployed in a remote machine reachable

by an IP connection. On the device, the application

provides users with the possibility of: setting manu-

ally the bootstrap super-peer address, sending a query,

reading the answers, registering as an expert for a

given topic, answering queries. We have implemented

a simple super-peer, using standard Java, MySql

and

the Hibernate framework

, that implements a pub-

lish/subscribe model where look up and matching is

performed syntactically upon topics.

Architecturepackage HelpMe[ ]

RemoteBroadcaster

ResponseReceiverQuestionReceiver

HelpMeActivity

0..* 0..*

Figure 6: HelpMe structure.

5 CONCLUSIONS

The paper has introduced a middleware, named

Sip2Share, for peer-to-peer computing in a network

of mobile devices running Android. The middleware

allows discovery, publishing and invoking remote ser-

vices using the same native mechanisms of the An-

droid platform, i.e. intent, manifests and broadcast

receivers. The use of the middleware has been illus-

trated with a simple application, HelpMe!, that sup-

http://www.mysql.com/

http://www.hibernate.org/

Sip2Share-AMiddlewareforMobilePeer-to-PeerComputing

449

ports knowledge sharing within a thematic network.

Whilst HelpMe! uses human-based services, the mid-

dleware can be used to publish automated services:

for example, in a war game on a closed ﬁeld, the ap-

plication can query the devices of its own team, to

know the GPS positions.

In the current implementation, data items are ex-

changed using JSON based messages; for the future,

we are working towards providing developers with

methods for sending large-size data. In particular,

we are exploring two directions: (i) using TCP based

communication, which implies bypassing Sip2Peer

communication and developing a proprietary low-

level communication layer; (ii) fragmenting the data

to be sent into several chunks, and implementing a

layer to reconstruct the original data onto the receiver

device. Another area of investigating is binary object

management, such as images or videos. Currently, the

exchange of binary ﬁles is handled outside the mid-

dleware, and diverges slightly from the Android ap-

proach. In fact, on a single device, Android does not

need to transfer the whole ﬁle, but only its reference,

which is stored in the device. In the remote scenario,

the middleware needs to transfer the ﬁle, or to upload

it on some server known to the network of peers.

In the current version of the middleware we have

neglected the privacy aspect of peer-to-peer for the

future, the middleware will need to support privacy

and security policies for peer interactions. We in-

tend to include in Sip2Share a trust component that

can block some peers, and in general assigns ranks to

peers, based on past activities; e.g. in the HelpMe!

example a particular peer that sends a lot of spam for

many different topics.

REFERENCES

Apte, N., Deutsch, K., and Jain, R. (2005). Wireless SOAP:

Optimizations for Mobile Wireless Web Services. In

Proceedings of the 14th international conference on

World Wide Web, Chiba, Japan, pages 1178–1179.

ComScore (2012). 2012 Mobile future

in focus. WhitePaper Available at

http://www.comscore.com/Press Events/Presentations

Whitepapers/2012/2012 Mobile Future in Focus

(last checked: 24/04/2012.

Crockford, D. (2006). RFC 4627 - The application/json

Media Type for JavaScript Object Notation (JSON).

In Internet Engineering Task Force IETF Request for

Comments, pages 1–11. Internet Engineering Task

Force.

Gong, L. (2001). Industry report: Jxta: A network pro-

gramming environment. IEEE Internet Computing,

5(3):88–95.

Horozov, T., Grama, A., Vasudevan, V., and Landis, S.

(2002). Moby - a mobile peer-to-peer service and data

network. In 31st International Conference on Paral-

lel Processing (ICPP 2002), Vancouver, BC, Canada,

pages 437–444.

Hulbert, D. (2006). Wizbit: A bittorrent client for

s60 symbian smartphones using python. [Avail-

able at https://sites.google.com/site/dave1010/wizbit]

(Last checked: 20/04/2012).

Juszczyk, L. and Dustdar, S. (2008). A middleware for

service-oriented communication in mobile disaster re-

sponse environments. In 6th International Workshop

on Middleware for Pervasive and Ad-hoc Computing,

December 1-5, 2008, Leuven, Belgium, pages 37–42.

Kel

enyi, I., Cs

ucs, G., Forstner, B., and Charaf, H. (2007).

Peer-to-Peer File Sharing for Mobile Devices. In

Fitzek, F. and Reichert, F., editors, Mobile Phone

Programming, chapter 15, pages 311–324. Springer

Netherlands.

Kotilainen, N., Weber, M., Vapa, M., and Vuori, J. (2005).

Mobile chedar - a peer-to-peer middleware for mo-

bile devices. In 3rd IEEE Conference on Pervasive

Computing and Communications Workshops (PerCom

2005 Workshops), HI, USA, pages 86–90.

Maier, D. (2011). Sales of Smartphones and

Tablets to Exceed PCs. Available at

http://www.practicalecommerce.com/articles/3069-

Sales-of-Smartphones-and-Tablets-to-Exceed-PCs-

(last checked: 24/04/2012).

Molnr, B., Forstner, B., and Kelnyi, I. (2007). Symella 1.40.

Available at http://symella.aut.bme.hu (last checked:

23/04/2012).

Nordstr

om, E., Gunningberg, P., and Rohner, C. (2009).

A search-based network architecture for mobile

devices. Department of Information Technol-

ogy, Uppsala University, Tech. Rep [Available at

http://www.it.uu.se/research/publications/reports/200

9-003/2009-003-nc.pdf] (last checked: 24/04/1012).

Pettey, C. (2011). Gartner Says Android to Command

Nearly Half of Worldwide Smartphone Operating

System Market by Year-End 2012. [Available at

http://www.gartner.com/it/page.jsp?id=1622614]

(Last checked: 20/04/2012).

Picone, M. (2011). sip2peer Tutorial An-

droid Example Outline. [Available at

http://code.google.com/p/sip2peer/wiki/sip2peerTu

torial] (Last checked: 20/04/2012).

Picone, M., Farber, B., and Hu, L. (2010). In-

troduction to Peerdroid. [Available at

http://dsg.ce.unipr.it/userﬁles/ﬁle/peerdroid/

PeerdroidPresentation 03 2010.pdf] (Last checked:

20/04/2012).

Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,

Peterson, J., Sparks, R., Handley, M., and Schooler, E.

(2002). SIP: Session Initiation Protocol. RFC 3261.

Internet RFCs.

Srirama, S. N., Jarke, M., and Prinz, W. (2006). Mo-

bile web service provisioning. In Advanced Inter-

national Conference on Telecommunications and In-

ternational Conference on Internet and Web Applica-

tions and Services (AICT/ICIW 2006), 19-25 Febru-

ary 2006, Guadeloupe, French Caribbean, page 120.

ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends

450