client/server messaging protocols in serverless environments
TRANSCRIPT
Journal of Network and Computer Applications 34 (2011) 1366–1379
Contents lists available at ScienceDirect
Journal of Network and Computer Applications
1084-80
doi:10.1
� Corr
E-m1 ht2 ht
journal homepage: www.elsevier.com/locate/jnca
Client/server messaging protocols in serverless environments
Justin Dean b, Andrew Harrison c, Robert N. Lass a, Joe Macker b, David Millar a, Ian Taylor c,�
a Department of Computer Science, Drexel University, USAb Naval Research Lab, Washington DC, USAc School of Computer Science, Cardiff University, Cardiff, UK
a r t i c l e i n f o
Article history:
Received 14 October 2010
Received in revised form
21 January 2011
Accepted 10 March 2011Available online 17 March 2011
Keywords:
XMPP
Serverless chat
WS-Notification
SLP
JmDNS
Peer-to-Peer
Multicast
NORM
45/$ - see front matter & 2011 Elsevier Ltd. A
016/j.jnca.2011.03.021
esponding author.
ail address: [email protected] (I. Ta
tp://www.pidgin.im/
tp://www.igniterealtime.org/projects/spark/i
a b s t r a c t
In this paper we discuss the adaptation of TCP transport-oriented client–server messaging protocols to
many-to-many peer-to-peer networking environments more suitable for deployment in dynamic
wireless networks capable of multicast forwarding. We describe four main issues in adapting such
protocols: exposing a network server for receiving TCP session data; the creation of server-side
semantic proxies to process the messages and adapt to a serverless environment; service discovery to
enable the discovery of necessary services on the network and to maintain the network state; and
finally support for multicast interfaces for the transportation of messages amongst peers. We show that
our system, called GUMP, can be used to support such protocol adaptations and to illustrate we use
GUMP to implement an XMPP proxy allowing existing off-the-shelf XMPP client software to
dynamically create and operate multi-user chat sessions in a serverless network environment. We
then present two sets of results that show how appropriate discovery systems and transport protocols
can dramatically increase the success of protocols, such as XMPP, within a mobile wireless networked
environment. Specifically, we first demonstrate that a GUMP supported discovery system, INDI, can
significantly increase the success rates and decrease latency of discovering services through profiles,
caching and retrying schemes. Second, we show that success rates for XMPP transmission of messages
can be vastly improved through the use of multicast as apposed to TCP within the mobile environment.
These two factors provide strong empirical support for the justification of GUMP in its ability to adapt
between a client–server and serverless world.
& 2011 Elsevier Ltd. All rights reserved.
1. Introduction
XML-based standardized messaging protocols (e.g., XMPP,Saint-Andre, 2004a,b, WS-Notification, Graham et al., 2006 andWS-Eventing, Box et al., 2004) typically assume dependence on anunderlying TCP transport stack for achieving a reasonable level ofreliability across wide area networks. It follows therefore thatapplication clients (e.g., for XMPP, Pidgin1 and Spark2) that usethese protocols are also tied into TCP, often needing to make aclient–server connection to a gateway or management server inorder to join and use the network. This dependency does not workwell when the group application moves into a more dynamicenvironment, such as a wireless mobile ad-hoc network (MANET,Corson and Macker, 1999), where server location and availabilityis in flux and where TCP transport effectiveness may be reducedand even render the application unusable. One issue is that TCPcongestion control can often overreact to temporal disruptions
ll rights reserved.
ylor).
ndex.jsp
(e.g., wireless link errors, collisions, routing dynamics) not indi-cative of queue congestion and reduce the rate or stall transportconnections.
UDP and transport enhancements (e.g., reliability) built aboveUDP, on the other hand, have historically had a more restrictedportfolio of conventional Internet usages, such as real-timeapplications requiring low latency, real-time delivery, e.g., videoor audio streaming. However, given that design and performanceissues can be quite different in highly dynamic and disruptivenetwork environments, such as MANET, UDP-based algorithmscan often provide more effective results. Dynamic, wirelessnetworking environments are also often less suitable for centra-lized server deployment due to potential server disruptions andmobility. Another point is that multicast or group-oriented net-work transport and delivery is often more suitable in wirelessenvironments and therefore collaborative applications may oftenemploy forms of UDP-based transport protocols or transportPerformance enhancing proxies (PEPs), rather than pure end-to-end TCP.
The Extensible Messaging and Presence Protocol (XMPP) is aset of open XML-based standardized messaging technologies forpresence and real-time communication developed by the Jabber
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–1379 1367
open-source community. It is an example of a standardizedtechnology that has mostly been developed for TCP and client/server operation scenarios. XMPP is a good example to discusssince it is an open and flexible messaging protocol standard thatcan be adapted in a variety of ways. Whilst XMPP is a verysuccessful open technology, its related standards and presentimplementations are server and TCP transport dependent. Evenits earlier serverless standard extensions provide discovery vialink local multicast only to setup TCP-based point-to-pointmessaging connections. For more mobile ad-hoc group deploy-ments there is value in extending the features of discovery andmessage forwarding to be serverless and group-oriented. Further,other XML-based technologies, such as the WS-n suite from W3Cand Oasis, are typically deployed on stacks built on HTTP, whichalso has TCP dependencies and a client/server orientation. Themediation of such protocols into more group-oriented or server-less network deployments is non-trivial because often theprotocols leverage the features of the underlying network stackand/or the availability of fixed network servers in their designs,and therefore often do not translate well without significantmodification.
In this paper, we present a toolkit, called the Generic Unicastto Multicast Proxy (GUMP) (Lass et al., 2010), which supports thecreation of semantic server proxies that are able to mediate aprotocol from a client–server TCP connection conversation onto aone-to-many multicast environment that supports a conversationwith many users at the same time. To support the development ofsuch semantic server proxies, GUMP provides a collection of toolsthat enable TCP application connectivity at the input and providesgateways to underlying multicast technologies and service dis-covery subsystems for discovering the available resources andcommunicating with the many participants in a session, allowingthe server proxies to intelligently negotiate protocol-specificadapting issues and maintain the underlying network state withina serverless environment.
For example, in the case of a multi-user chat (MUC) applicationa typical usage pattern for XMPP is for a client to make a TCPconnection to an XMPP management server that is capable ofcreating MUC rooms, e.g., OpenFire.3 The XMPP managementserver will then create the desired room and coordinate thecommunication (chat messages) between all the participants inthat room thereafter by providing brokering service to relay themessages. In GUMP this scenario works as follows. A clientapplication would make a TCP connection to GUMP (a localloopback connection to the semantic proxy server). The proxyserver would consume each XMPP command and reply as anormal management server would. It would have the capabilityof creating a MUC room and allowing people to join. However,rather than storing this state information centrally at one pointeach participant has a copy of it. This is achieved by using adiscovery subsystem, e.g., bonjour, to advertise a MUC room, sothat when it is created all of the other participants are aware of itsexistence. Also, when passing the messages to all other partici-pants in the MUC room, a user would use multicast to a definedmulticast group address/port to communicate the messages toparticipants rather than coordinating this centrally and commu-nicating the message to all participants using multiple connec-tions. Multicast is far more efficient at group communication inmany wireless environments but also in mobile environments,other standard transport protocols, e.g., NORM, can be used to addhigher levels of reliability, congestion control, and source order-ing to the UDP data transport sessions.
3 http://www.igniterealtime.org/projects/openfire/index.jsp
In this paper therefore, we attempt to prove the followingresearch hypothesis:
Through the use of semantic proxy servers, client–server TCP-based group messaging protocols can be mediated to workeffectively and efficiently into a serverless environment with-out application modification
To fulfill this aim, we need to provide empirical evidencedemonstrating that the group discovery and communicationprotocols that GUMP exposes can provide increased robustnessover TCP and server centric conventional deployments withinmobile wireless networks. To this end, we present our require-ments, architecture, design and implementation for GUMP andshow that different communication protocols and discoverysystems can have a dramatic performance improvement withina mobile wireless environment.
The next section provides a context for GUMP by describingsome motivational messaging protocols that we wish to adapt intoa serverless environment. Section 3 provides an architecture for thesystem; Section 3.1 providing an overview of the current imple-mentation status and Section 3.2 illustrating its typical operationthrough a usage scenario. Section 4 discusses the underlyingtechnologies that GUMP uses for discovery (Section 4.1), commu-nication (Section 4.2) and XMPP (Section 4.3). Section 5 describesthe steps necessary in order to create an XMPP server-side proxyusing GUMP.
In Sections 6 and 7, we give empirical evidence for discoveryand communication protocol considerations when deployingproxies into a mobile environment, which proves that the flexibleconfiguration that GUMP provides is a requirement in suchenvironments. In Section 8 we provide conclusions for the paperand in Section 9, we discuss our future directions for this work.Finally, we acknowledge our collaborators.
2. GUMP motivation and relevance
This work is motivated by distributed messaging standards,such as XMPP, WS-Notification and WS-Eventing, which focus onproviding functionality broadly based around chat, presence orasynchronous messaging. These XML-based messaging protocolsare based around a client–server concept using managementservers for maintaining the state of the network (e.g., for settingup sessions, keep track of which users are logged on, maintainingmulti-user chat (MUC) rooms, etc.). Such a model does nottranslate well to more transient network deployments as a singlepoint of contact for initiating or managing sessions generallycannot be relied upon. It is, therefore, advantageous to considerthe use of many-to-many transport protocols, such as multicast,in such deployment environments.
However, currently it is quite difficult to adapt applications foruse in more mobile, distributed environments because the TCPand client/server dependencies are generally inherent. For exam-ple, XMPP can clearly be very useful as a flexible messagingprotocol in a mobile application setting to enhance chat function-ality, pub/sub capabilities, XML streaming, and presence features.As XMPP is written to be extensible, an extension has beencreated to allow serverless one-on-one chat over a link localconnection (Link-Local Messaging—XEP-0174). However, at pre-sent, there is not a convenient method for mediating group chattechnology into a more distributed wireless environment. Either anew standard would need to be developed or a mapping layerwould be needed in order to adapt the protocol for deployment tothe underlying transport stacks and discovery methodologies.Further, both WS-Eventing and WS-Notification have similarissues because of their deployment dependency to HTTP and
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–13791368
fixed network addresses. The ability to transcend network infra-structure and to connect grid and mobile hybrid applicationstransparently in order to run such applications is a goal that spansa number of applications in healthcare, the military, emergencyresponse to name a few, where data is either generated, collected,or exchanged between static nodes and mobile entities.
To realize this potential, we need a capability to supporttransparent and dynamic access to ‘‘serverless’’ peer-to-peerenvironments for communication with the mobile domain. Thiswould typically require adapting from a one-to-one connection(TCP) to one-to-many (and many-to-many) relationships, usingprotocols such as multicast. Such a self-adaptive mechanism israther complex, involving more than a simple transport mapping,because it involves the distributed management of session infor-mation across all the peers in the network. Thus, an intelligentself-adaptive mechanism coupled with a supporting underlyingadaptive service discovery infrastructure is needed in order tosupport the discovery of the current state of the network allowinga server proxy to intelligently respond to clients operating withina more connectionless network domain. Such an infrastructurewould then enable a XML-based protocol server proxy to answerquestions such as ‘‘who is around?’’, ‘‘what XMPP MUC groups areavailable to join?’’ and ‘‘what WS-Notification topics are avail-able?’’, using standardized discovery protocols, such as the multi-cast Domain Name Service with Service Discovery extensions(mDNS-SD or Apple bonjour) (Giordano, 2005; Steinberg andCheshirethe), Service Location Protocol Version 2 (SLPv2)(Guttman et al., 1999), the Simple Service Discovery Protocol(SSDP) in Microsoft’s Universal Plug n’ Play (UPnP) standard(Helal, 2002), and Bluetooth’s Service Discovery Protocol (SDP)(Gryazin).
3. GUMP architecture
In this section we describe a system that we have developed,which address these issues, called GUMP. The Generic Unicast toMulticast Protocol (GUMP) toolkit maps intelligently betweenUnicast Messaging Protocols and Multicast and has the followingkey features:
�
Allows the creation of smart server proxies that consume unicastmessages (e.g., XMPP, WS-Notification, etc.) and semantically mapApplication
GUMP (Generic Unicast to
GUMP Packet (Raw Data with
TCP Server (XMPP)
GUMP Proxy Inte
XMPP catio
ProtoSD
INDImDNS
Session Message
Fig. 1. GUMP archit
these into a serverless multicast environment, e.g., adapt from TCPtransport-oriented client–server sessions to many-to-many peer-to-peer networking environments.
� Smart server proxies discovery — multiple discovery systemsthrough the use of ProtoSD, a discovery subsystem, e.g., to findchat users or MUC chat rooms
� Smart server proxies communication — multiple multicastprotocols, e.g., multicast and NORM supported.
� Web GUI. ProtoSDOs Web interface can be used to dynamicallydisplay entities as they are discovered on the serverlessnetwork.
GUMP provides a convenient framework for allowing devel-opers to create network agnostic server-side proxies for messa-ging protocols. It provides an environment that allows thedeveloper to focus on the development and detail of the proxywithout being tied down to the specifics of how its correspondingentities are to be discovered nor how messages are to be sentbetween those entities. GUMP also provides multiple entry pointsinto the system through multiple input bindings of the system,such as TCP and HTTP, and in the future it will also support thedirect integration through the socket layer of languages such asJava. Figure 1 shows an overview of the GUMP architecture. At ahigh conceptual level, GUMP is divided into four main areas:
1.
Application connectivity addresses how applications connect toGUMP through GUMP’s Input Binding. There are a number ofways of achieving this. Here, we focus on adapting to GUMP atthe network level, by exposing GUMP as a network server thataccepts arbitrary connections from applications using HTTP orTCP. It is also possible to have GUMP embedded into a Javaapplication and auto-swap out the default TCP implementa-tion with a GUMP input binding, using the SocketImpl class. SeeSection 3.1 for more information.2.
Server proxy provides a pluggable interface to multiple messa-ging protocol server proxies, each addressing a specific proto-col, e.g., XMPP, WS-Notification and so forth. A protocol serverproxy translates from a client request into a multicast back-bone through the use of the underlying discovery subsystemand GUMP’s interface to multicast.3.
Session messaging provides an interface to various discoverysubsystems through the ProtoSD subsystem (see Section 4.1).ProtoSD has bindings for JmDNS and INDI (a modified SLP) forMulticast Adapter)
Sender IP, Port, etc)
UDP (Raw Data, Video)
rface
Other ...n
GUMP Multicast Interface
NORMMulticast
Data Message
ecture.
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–1379 1369
use by the proxy to be able to advertise and subsequentlydiscover entities on the network.
4.
XMPP Application
socket write socket readsocket connect
socket read socket writesocket accept
process messageconnection request
TCP Proxy 127.0.0.1:5222
GUMP Proxy Interface
Fig. 2. GUMP input flow.
Data messaging provides an interface to various underlyingmulticast implementations. Primarily we are focusing oninvestigating two implementations here: the default Javamulticast implementation and NORM (NACK-Oriented ReliableMulticast) (Adamson et al., 2004) transport for reliable multi-cast delivery.
Together these interfaces provide a strong development envir-onment for creating server proxies for messaging protocols. Theyallow the adaption of the deployment of a messaging server proxyby facilitating the switching of application connectivity, theability to employ the use of different discovery algorithms andmultiple multicast implementations. This provides the flexibilityto be able to experiment with different run-time deploymentconditions when applied to different wireless networks. Forexample, in a non-mobile, relatively benign wireless network,group messaging applications based upon server/client TCP mes-sage transport and JmDNS discovery might form an effectivesolution in terms of overhead and success rates, whereas inMANET environments, some improved multi-hop multicast for-warding combined with reliable UDP-based NORM transportwould likely to result in a more robust dynamic, distributeddeployment. The ability to experiment with different configura-tions is a necessity when dealing with distributed, wirelessnetworks because often the rate of disruption and mobilitydetermines which algorithms are more applicable and one cannotsimply apply a one-size-fits-all mentality as one might in morestatic networks.
The protocol server proxy’s role is to translate protocol-specific messages from a client, e.g., connect, user arrived, userleft, create MUC group, etc. into a serverless environment, andsubsequently provide an appropriate response back to the clientupon completion of its request. The client, therefore, thinks it istalking to a server using a client/server relationship but in fact forexample, it could be talking to a TCP GUMP server that isdelegating the requests to a GUMP XMPP protocol server proxy,which is in fact using SLP and NORM to discover entities on thenetwork and pass messages reliably between them, respectively.An example of how a proxy operates in such an environment isprovided in the next section.
3.1. Implementation status
GUMP is written in Java and provides a collection of interfacesand factory-based implementations for the various adapters forGUMP’s input, discovery and multicast subsystems. Currently, wehave implemented a TCP binding for the GUMP input adapter,which addresses the requirement for the current XMPP proxyintegration. We also have a UDP input server integrated andalongside our simple repeater proxy, we can use GUMP to providesimplistic non-semantic server transport proxies for NORM. Forexample, we can use the UDP port to stream video data from asthe VideoLAN Client (VLC) or similar into GUMP and then streamthis across a network using NORM for reliable multicast transportfor video transmission. In a similar fashion, we can have GUMPact as a video receiver by receiving data packets from the networkusing NORM and specifying a destination address for the receivedpackets (using TCP or UDP) and have GUMP feed data to areceiving server. Within the context of VLC, we can set up aUDP server to receive a video stream from GUMP and display it inthe VLC viewer.
From the protocol server proxy aspect, we currently have theXMPP server-side proxy implementation integrated. For theunderlying implementations, we have both SLP and JmDNS
integrated within our ProtoSD discovery subsystem (see Section4.1) for use by the proxies. For multicast, we have a binding toJava multicast and one for NORM, using the NORM Java Nativeinterface API. We are also investigating the possibility of integrat-ing different unicast algorithms for satellite networks connectionsfor more reliable one-to-one connections, such as R-UDP (ReliableUDP), which forms part of a number of Java Internet applications,including Limewire. NORM itself can also supports a number ofprofiles for effective reliable unicast transport of UDP whensensible.
3.2. GUMP operation
Focusing at the network level and as shown in Fig. 1, GUMPcan adapt applications at their transport level either through theuse of a locally deployed HTTP or TCP server. For example,rather than an application connecting to an XMPP server,such as OpenFire, the user would type in a local address(127.0.0.1:5222), which would re-route the message via this localnetwork GUMP proxy server. The incoming connection requestsand messages are then sent directly to the proxy chosen for thisinstance of GUMP, e.g., an XMPP proxy.
The semantics of how the connection messages and socketread and write packets are sent and processed by the proxy areprovided in Fig. 2. Messages sent to the network by the applica-tion and received by the GUMP server are wrapped within aGUMP message and relayed to the GUMP protocol proxy. A GUMPmessage contains a byte array for the data packet, along withinformation about the sender (host, port) and other relatedmetadata, such as message receiver ID (for supporting multipleconnections) and so forth. The Proxy consumes the message anduses the underlying discovery subsystem and multicast to processthe message and translate the request into behavior suitable forthe underlying serverless peer-to-peer network.
For example, the request could be an XMPP ‘‘create MUCgroup’’. The proxy would first search to see if such a groupexisted (by using the discovery subsystem for example to queryfor ‘‘MUC Groups’’). If a group does not exist, then it would createa MUC group and allocate an underlying multicast group to dealwith this traffic. It would then advertise this group to thenetwork, again using the discovery subsystem. Thereafter, if theproxy received a message to be sent to this newly created MUCgroup, it would look up the multicast address assigned to thisgroup or topic for the various subscribers, and then it would sendthe message to this group using the GUMP multicast interface,which in turn, would use the underlying multicast transport tosend the data onto the network.
Fig. 3. GUMP service view using the ProtoSD web interface.
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–13791370
4. Underlying technologies
In this section we provide detail about the underlying toolkitsand technology bindings that make up the two key areas of theGUMP system, discovery and communication. We also provide abrief overview of XMPP, to provide some background for ourXMPP GUMP implementation that is described in the next section.
4.1. ProtoSD discovery subsystem
ProtoSD primarily is an interface to service discovery. At itscore, it has an interface, implemented in Java that defines servicespecifications according to common format that is modeled onthe bonjour (mDNS) service type specification. In other words,ProtoSD service specifications are completely interoperable withbonjour or mDNS service types. This was defined this way for tworeasons:
�
To provide a familiar interface to service registration anddiscovery. � To be fully interoperable with the existing service discoveryinfrastructure that is ubiquitous on current local networks.
However, the interface is completely abstract from any parti-cular implementation and services are stored using ProtoSDinternal object format. ProtoSD currently has two bindings to thishigh level interface:
�
Java Multicast Domain Name Server (JmDNS) (van Hoff) is animplementation of multicast DNS in Java. It currently supportsservice discovery and service registration and it is fullyinteroperable with Apple’s Bonjour. �4 http://www.jstree.com/
INDI: INDI is our own internal extensions to the ServiceLocation Protocol (SLP) (Guttman et al., 1999) that allowservices to be deployed and discovered with minimal config-uration. SLP was a design predecessor of widely deployed
protocols (e.g., Apple Bonjour) and is one of the severalstandardized protocols for service discovery. We discuss howINDI provides more robust service discovery within MANETnetworks in more detail in Section 6.
The main difference between SLP and Bonjour is that SLP isURL based and Bonjour is DNS based. However, in ProtoSD wemap between these different semantics: mDNS service types canbe mapped directly to SLP service types simply by changingsyntax; with some care, the mDNS domain, for most purposes,can be mapped to SLP scopes; likewise, although SLP does notreally have the notion of a service name—it defines a unique URLfor that service to identify it—we can use the URL path to map theBonjour name onto the SLP URL. Finally, both bonjour and SLP uselists of key, value pairs for attributes so this is a relativelystraightforward conversion.
One of the most flexible aspects of ProtoSD is that a GUMPdeveloper can use is the back-end Web site that exposes thediscovered services using a REST-based API. This API is accessed inseveral ways within ProtoSD itself but one immediate use for theGUMP developers is the dynamic Web site rendering of the datathat acts as a service browser and a debugging tool. Internally,ProtoSD exposes two URLs that provide different views of the datain JSON or in HTML. So, for example, we show in Fig. 3 ascreenshot of the WebSD interface, where ProtoSD has discoveredsix service types and displayed them in its tree view. For thecreation of this Web page, Javascript on the client makes an AJAXasynchronous get on the JSON http URL to fetch the data and thenpasses this to a JsTree4 (JQuery tree structure) for displaying tothe users. Using the Search textfield at the top right allowspruning of this list to match only the provided String. Again,internally this involves an asynchronous AJAX call to the search
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–1379 1371
URL and a fetch for the JSON dataset update for displaying in theJsTree.
For a MUC session, the ProtoSD browser provides a similarmechanism to what centralized XMPP management serversprovide for administrators. For example, on OpenFire, an admin-istrator can view the current MUC rooms created by users that arecurrently connected to this server. For ProtoSD, the MUC roomsthat are created by its users appear as adverts on the multicastnetwork and are discovered by ProtoSD and listed accordingly.The result is the same.
4.2. Multicast protocols
Internet Protocol multicast (Deering, 1989) delivers UDPpackets (data) to multiple receivers that have previously joineda multicast group, by efficiently routing and duplicating data atspecific routers (chosen algorithmically depending on the parti-cular scheme) that identify more than one receiver downstreamin their tree. NORM (an IETF RFC, Adamson et al., 2004) providesfault tolerance to standard multicast by providing end-to-endreliable transport of bulk data objects or streams over generic IPmulticast routing and forwarding services. NORM uses a selective,negative acknowledgement (NACK) mechanism for transportreliability and using limited ‘‘a priori’’ coordination among sen-ders and receivers, it offers additional protocol mechanisms toconduct reliable multicast sessions. NORM incorporates a con-gestion control algorithm to share available network bandwidthfairly alongside other transport protocols, such as TCP. It is alsocapable of operating in a unicast mode, which is also of interest toGUMP for allowing the proxies to adapt to other transientconnectivity environment that do not support multicast (e.g., forsome satellite or cellular connections).
4.3. XMPP and related work
At its core, the Extensible Messaging and Presence Protocol(XMPP) defines a protocol streaming of XML messages. It supportsnear-real-time messaging, presence, and request-response ser-vices and is a derivation of the work performed within the Jabberopen-source community but later became an IETF standard(Saint-Andre, 2004a). XMPP was designed to be suitable instantmessaging (IM) and presence technology. XMPP defines specifictypes of messages (stanzas) for binding, exchanging or publishinginformation. XMPP employs the use of the simple authenticationand security layer (SASL) to provide generalized authenticationsupport for connection-oriented protocols. It can also use trans-port layer security for on-the-wire message security and uses TCPfor the underlying transport. XMPP requires that an implementa-tion supports bi-directional TCP sockets so that a server allowsthe client to share a single connection and allows multiplebindings on the XMPP default port, which is 5222.
XEP-0174 is a Standard of the XMPP Standards Foundation thatspecifies a link-local messaging protocol defining how XMPP-likecommunications can be accomplished using zero-configurationnetworking. This method uses mDNS for service discovery ofnetwork entities that support the protocol, including their IPaddresses and preferred ports. Any two entities can then negotiatea serverless connection and using XML streams, exchange XMPPIQ stanzas and messages. IQ stanzas are info/query (request/response) interactions and messages contain the chat payload.XEP-0174 is similar to GUMP in that it provides access to under-lying discovery protocols but this is achieved through extensionsand it is only used to establish one-to-one TCP connectionsthereafter for the actual communication, i.e. a chat.
Jingle (XEP-0166) is a related specification that defines an exten-sion to the XMPP protocol for initiating and managing peer-to-peer
media sessions between two XMPP entities. The protocol providescore session management semantics (SIP) to be used for a widevariety of application types (e.g., voice chat, video chat, file transfer)and with a wide variety of transport methods (e.g., TCP, UDP, ICE,application-specific transports). The actual data transfer is delegatedto the underlying protocols and therefore message exchange does notform part of the XML XMPP stream.
XEP-0045 describes the XMPP Multi-User Chat (MUC) proto-col. This protocol allows clients to create, discover, join and leavegroup-oriented MUC rooms. The rooms are associated with aserver, and all messages addressed to the room are sent to theserver. The server then resends the messages out to all ofthe members of the room through their existing connection tothe server. The main difference between this and XO is therequirement of the server, and the multiple server-client unicastconnections required vs. the multicast approach to transportingmessages among peers.
Among the XMPP extensions XEP-0166, XEP-0174, and XEP-0045, none address how the TCP-oriented connection paradigmmight apply to a multicast setting and therefore do not offerserverless group-based messaging. XEP-0174 specifies serverlessdiscovery over a link-local connection, but then delegates allsubsequent interactions to a unicast TCP connection. With theother two extensions, all communications pass through an XMPPserver which multiplexes messages over TCP connections witheach of the various chat room members. XO is capable of not onlyinitiating an XMPP session, but it can also utilize underlying out-of-band protocols for the communication of actual XMPP stanzas,such as chat messages and so forth. GUMP is capable of not onlyinitiating an XMPP session, as in XEP-0174, but it can also utilizeunderlying out-of-band protocols for the communication ofactual XMPP stanzas, such as chat messages and so forth, unlikeXEP-0166.
XEP-0100 specifies XMPP gateway interaction. The specifica-tion defines this to mean gateways that proxy XMPP clients ontonon-XMPP servers, such as IRC. This is similar to what is occurringwith the XO (described in the next section), in that it receivesXMPP packets and translates them into another protocol. How-ever, there are two main differences. First, the XEP requires aclient that implements the XEP registering with a gateway, mostlikely on an XMPP server such as OpenFire, that has alsoimplemented the XEP. XO does not require a client or server withthese features. Second, the XEP does not support MUC, only one-to-one messaging.
There are a number of middleware solutions for supportingTCP-oriented protocols on dynamic wireless networks, of whichSpines is one of the more well-known examples. It works bycreating an overlay routing network and providing a mechanismfor hop-by-hop reliability that has been shown to increasereliability and decrease jitter over more traditional overlay rout-ing approaches. This approach differs from GUMP in that it doesnot modify the protocol itself, it instead makes the existingprotocol work better in a dynamic environment.
5. A serverless XMPP server proxy using GUMP
As an example of a GUMP plugin for converting a client–serverprotocol into a peer-to-peer protocol, we present the XMPPOverlay (XO) Proxy. The XO is written to allow group commu-nications using standard XMPP clients with a peer-to-peer pro-tocol on a mobile ad-hoc network (MANET). The clients are‘‘tricked’’ into thinking that they are communicating with astandard XMPP server that supports multi-user chat (MUC) whenthey connect to the proxy on their local machine. The proxytranslates the XMPP messages into XMPP MUC Using Multicast
5 http://www.pidgin.im/6 http://www.igniterealtime.org/projects/spark/index.jsp
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–13791372
(XMUM), an XMPP-like protocol designed for MANETs, and multi-casts them over the network. An XMPP Overlay Gateway (XOG),running on a node which is able to communicate on the MANETand a more traditional network, can transform these XMUMmessages back into XMPP MUC messages and relay them to astandard XMPP server somewhere on the traditional network.
The intended use of the XO is to act as a proxy for an XMPPclient located on the same machine. However, it is designed suchthat it could be used as a proxy for several different clients, soseveral applications on a node could all use XMPP for commu-nications and share the same XO instance. Furthermore, in somecases it may make sense for multiple nodes to connect to aremote XO instance. An example use of this would be cellularphones which connect to an XO instance located at a mobile basestation which is part of a multicast group.
5.1. Connecting the client to the proxy
To connect to the proxy, the user configures his/her client touse localhost rather than an XMPP server. The client–serverconnection usually uses TCP, although the GUMP input bindingcould be swapped out with a, for example, UDP binding if a UDPXMPP client existed (or was created by embedding GUMP withthe client). Once the socket has been created, a client sets up astream the same as it would with a server. After this, the proxyprocesses any presence, iq or message messages it receives fromthe client until the stream is closed.
5.2. Data messaging
When the proxy receives a message or presence stanza from theclient, it passes it to the packet router. The packet router is anapplication level XMPP stanza/packet router, which routes incom-ing packets to their representative software endpoints. Examplesof endpoints include users locally logged into the XO instance, aMUC component or other such component, etc. When entitiesconnect to the XO, the packet router stores routes to them. Thepacket router determines if the destination is local (a connectedentity) or remote. If it is local, it forwards it to the connectedentity, otherwise it forwards it to the GUMP multicast interface.Finally, GUMP sends the message out using whatever protocol(UDP multicast, NORM, etc.) it is currently configured to use.
For receiving packets, the XO creates a GUMP multicast socketto listen for incoming packets. Incoming packets are sent to thepacket router, which then forwards them to the appropriateconnected entity, if any. The transport mechanism for incomingpackets is determined by the GUMP configuration, the XMPPcomponent responsible for listening for packets on the networkhas no need to know the specific protocol being used.
5.3. Session messaging
When the proxy receives an iq stanza from the client, it againpasses it to the packet router. If it is local, it is forwarded to theconnected entity, otherwise it passes it to the IQManager compo-nent of the XMPP proxy, which updates a context object ifnecessary. The context object is intended to help manage thestate of the proxy. Keep in mind that with no server, some of thestate needs to be managed by the proxy. The context is not usedat this point, but could be used in the future, for example to cacherequest/response pairs. Finally, the IQManager performs theappropriate action (advertise service, reply to the sender with‘‘server information’’, query for available services, etc.) usingGUMP’s discovery system. GUMP then performs whatever actionis needed for the currently configured discovery protocol (SLP,
mDNS, etc.), and returns an appropriate response to the client ifnecessary.
The XO registers a listener with the GUMP discovery interfacewhen it starts up. When a discovery-related event occurs, the XOformulates an iq packet and forwards it to the packet router fordelivery to the appropriate entity, or updates the state eg: adds aMUC room to the available rooms.
5.4. Gatewaying
If the proxy is running on a node with two network interfaces,it can be setup as an XOG. If setup, the XOG can act as a bridgebetween the peer-to-peer XMUM protocol and the client-to-server XMPP-MUC protocol. The XOG establishes a connectionwith an XMPP server where the MUC lives using server dialback(see Section 8 of Saint-Andre, 2004a), and translates packetsbetween XMUM and XMPP. If a packet arrives on the GUMPdiscovery interface, the XOG translates it into an iq packet andsends it to the receiving server. Likewise, if it receives a presenceor message packet from the GUMP multicast interface it forwardsit. Vice versa, when an XMPP packet arrives from the receivingserver, either the appropriate functions are called in the GUMPdiscovery interface, or the packets are converted to XMUM andhanded to the GUMP multicast interface.
5.5. Theory of operation
There are several ways the XO could potentially be used. Thefirst is chat on a MANET, with no external servers. There are onlyMANET nodes, and they wish to chat as though they wereconnected to an XMPP MUC server. The XO provides a way forthem to do this with standard XMPP clients.
Another way to use the XO is for chat on a MANET with a linkto a server using the XOG. This allows for a number of MANETnodes to chat with nodes that are not on a MANET, but aretraditionally connected to an XMPP MUC chatroom. It also allowsfor groups on entirely different MANETs but with XOGs linkingthem to the same XMPP server to chat with each other as thoughthey were all in the same MUC room.
As an extension of the previous case, the XO could also handlecases with a transient connection to the server, providing gracefuldegradation of capabilities as network capabilities decrease. If thelink between the XOG and the server fails, rather than the entirechat infrastructure failing, as would happen with a standardXMPP MUC, the nodes on the MANET will still be able tocommunicate with each other. The only capability lost is theability to communicate with the nodes external to the MANETand vice versa.
5.6. Implementation status
The gatewaying portion of the XO is still a work in progress.The other features have undergone preliminary testing with bothPidgin5 and Spark.6 Both are able to initiate their connections, andsend messages as though they were connected to an XMPP server,and the users’ experiences should feel no different than whenconnected to an XMPP server.
6. Two studies into discovery techniques
In this section, we discuss two experiments we have per-formed recently using the Independent Network Discovery
Table 1NS-2 simulation settings.
Variable Value Description
val(chan) Channel/WirelessChannel Channel type
val(prop) Propagation/TwoRayGround Radio propagation model
val(netif) Phy/WirelessPhy Network interface type
val(mac) Mac/802_11 MAC type
val(ifq) Queue/DropTail/PriQueue Interface queue type
val(ll) LL Link layer type
val(ant) Antenna/OmniAntenna Antenna model
val(ifqlen) 50 Max packet in ifq
val(nn) 50 Number of nodes
val(x) 1500 Length in meters
val(y) 300 Width in meters
val(time) 600 Simulation time in seconds
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–1379 1373
Interface (INDI), which ProtoSD and therefore GUMP supports forservice discovery in mobile wireless networks. INDI aims todirectly address some of the inadequacies for discovery in bothMANET and other types of multi-hop wireless mesh networks. Italso provides a flexible research system tool for investigatingexisting multiple operational modes and new protocol designs.The INDI implementation is written in Java supporting numerousoperating systems and network stacks. INDI also uses the AgentJ(Taylor et al., 2006; Naval Research Lab) toolkit to allow us toexecute the INDI Java service discovery code (e.g., threadingsupport/socket adaptations) in the NS-2 (McCanne et al., 2000)simulation environment. AgentJ differs from other approaches inthat it allows the execution of unmodified Java code by bindingthe Java VM to NS-2, rather than discretizing and simulating theabstracted approach, i.e. we measured the actual INDI code.
The two experiments described below illustrate two areaswhere success rates for service discovery can be significantlyimproved in MANET networks:
�
Multicast forwarding: Although our service discovery exten-sions are independent of any particular multicast forwardingapproach, forwarding of multicast in highly mobile ad-hocnetworks is often designed to work differently thanapproaches deployed in fixed or wired infrastructures. MobileAd hoc Network (MANET) standard protocols may employ theuse of various flooding and optimized relay set techniques tocalculate a distributed connected dominating set (CDS) formulticast forwarding in multi-hop networks. � Discovery system reliability: Discovery protocols, such as Bon-jour, and those used in popular middleware stacks, such as Jini,Jxta and so forth, typically make assumptions on the under-lying multicast protocol delivers messaging relatively robustly.Whilst this assumption is satisfactory for the fixed Internet orlocal interfaces, when faced with mobile network multicastscenarios, service discovery-level reliability and different cach-ing modes can prove effective mechanisms for increasingdiscovery success rates.
6.1. Multicast forwarding
In a MANET, it is common for the wireless nodes to work in ad-hoc mode and connect to neighbors that are within their rangeand then use neighboring nodes to act as forwarders to reachnodes further away in the network. Each time a packet isforwarded on a wireless network, it increase the wireless ‘‘hops’’,i.e. decreases the TTL.
In these experiments, we use the simplified Multicast For-warding (SMF) (Macker and DesignTeam, 2010) to forwardbetween wireless hops and then vary the underlying algorithmto calculate the connected dominating set (CDS). The conven-tional Classical Flooding (CF) approach was used as a baselinewith S_MPR (The NRL-OLSR Routing Protocol Implementation)and ECDS (Clausen and Jacquet, 2003) being the two other relayset optimization methods used. While request delivery wasalways performed using multicast, simulations were performedusing both multicast and unicast methods for server to clientreplies. Where unicast communication was used, NRLOLSR (TheNRL-OLSR Routing Protocol Implementation), an NRL developedOLSR implementation (Clausen and Jacquet, 2003) provided uni-cast network functionality. Multicast replies used the samemethod as discovery in a given simulation.
SLP event generation and motion paths were predeterminedfor each simulation run. SLP events were generated with a Poissondistribution with an average interval of 6 seconds per client.Simulations were run with 10 clients, and 1–3 servers to illustrate
any trends due to differing network deployments. Node motionwas generated to reflect similar models used in Kozat andTassiulas (2004). Maximum nodal speeds were varied between1, 2, 4, 8, 12 and 20 to demonstrate network mobility convergencetrends between the various discovery methods simulated. Net-work analysis was performed on all generated motion files toguarantee full connectivity throughout each run, assuminginstantaneous network convergence were possible. This was doneto avoid fragmentation events from artificially skewing results.For each data point, we averaged 10 distinct NS-2 simulationsusing the common settings listed in Table 1.
Figure 4 shows the average successful INDI request rate withdiffering underlying multicast routing algorithms and varyingINDIs reply delivery methods; unicast or multicast. ECDS usingmulticast replies is the top performer. Using multicast replies,instead of unicast, increased success rates when ECDS was usedbut decreased success rates when classical and SMPR wereenabled. The reason for this decrease differed however. Classicalflooding causes intermittent congestion and resulting in packetcollisions. SMPR flooding provides no better routing performancedue to the underlying unicast routing protocol, OLSR, being basedon SMPR link state information (i.e. the same critical path to adestination would be used by the SMPR multicast protocol as theOLSR protocol, only with more unnecessary forwarding). BothSMPR multicast and the OLSR unicast routing protocol experi-enced lower success rates vs. ECDS due to their selection ofshortest hop paths. These shortest hop paths are quite unstablewith the tested mobility patterns and results in a greater numberof invalid next hop routes.
During these tests we also tested the INDI retries. An INDI UserAgent (UA) performs a query in a standard fashion for a decen-tralized network, i.e. using multicast, and then performs aretransmission backoff algorithm defined by the timeouts para-meter. For these experiments the initial wait time is set to 100 ms(set to around twice a typical response delay in our test environ-ment) and exponential retransmission backoff is performedbeyond this using a maximum retries setting of 5. This mechanismis analogous to the convergence algorithm used by SLPv2 andsupports the inclusion of ‘‘previous responders’’ in the query,allowing providers to know whether a consumer has alreadyreceived a response from them. In addition, INDI supports a retry
field representing the times the consumer has attempted arequest within a single retransmission session. This allows pro-viders to not re-send a response to a particular retry even if theconsumer never received their response and was therefore unableto insert them as a previous responder.
Figure 5 demonstrates successful discovery rates of the samesimulation runs as Fig. 4, but using the exponential timer retry
Fig. 4. A comparison of the different SMF routing algorithms operating with nodes moving at six different speeds and with both unicast and multicast responses.
Fig. 5. The different SMF routing algorithms coupled with SLP convergence algorithm.
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–13791374
service requests. Success rates improved across the board withboth classical and ECDS using multicast replies maintaining anaverage of approximately 99% across all runs, which is an averageof a 22% improvement over Fig. 4. INDI retries are covered in moredetail in the next section.
6.2. Discovery system reliability
In this experiment, we studied the use of INDI with respect tonetwork mobility, various producer-consumer distributions, andvariable network connectivity scenarios. By varying connectivitycoefficients as an independent variable from mobility rates wefound there is a trade-off between the following discoveryapproaches:
�
Reactive provides the common query and response style ofservice discovery. � Proactive where the providers periodically send out theirservice adverts using multicast to anyone that is listening onthe system.
� Opportunistic caching is based on the idea that if a consumerqueries for a service then perhaps other consumers canopportunistically cache responses or adverts from providers,especially when multicast is used for the service transmission.
Where the modes are constrained by a few importantparameters:
�
Timeouts: A list of exponentially increasing wait intervals, asdiscussed in the previous section. � Required results: The number of results the UA requires. � Retries: The number of retries to attempt.For mobility, we define a normalized measure of networkconnectivity to categorize different random mobility scenarios. Atime snapshot of the mobile network is taken at regular intervalsand is represented by the undirected graph G. Mobile networkconnectivity (Nc) metric is defined within as the expected fractionof the network reachable from any randomly selected nodemeasured as an average across topological time intervals withinthe trial as follows:
Nc ¼XT
t ¼ 1
XN
n ¼ 1
jCntj
! !�N2=T ð1Þ
where jCntj is the order of the connected component in G contain-ing node n at time t. T is the number of uniform time intervalswithin the mobility scenario (600 in our case), and N is thenumber of nodes or vertices, V, within G.
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–1379 1375
A Nc value of 1.0 (100%) indicates that the network is fullyconnected at all times. For a network of nodes, the smallestpossible Nc value is 1/N since nodes are considered self-connectedat all times. It should be noted that the Nc value multiplied by thenetwork size represents an estimate of the sample mean of thesize of connected components that comprise the entire mobilenetwork over the course of the scenario. We feel this metric ismore effective in analyzing disconnection events vs. a simplecount of the number of partitions since it accounts for averageexpected partition size.
Using the Nc metric and we generated ten separate randommobility scenarios with resulting connectivity coefficients of 60, 70,80, 90, and 100. All generated test cases consist of N¼50. We chose amodified Random Walk motion model in which limited node speedand directional heading adjustments are independently generated ateach selected time interval. This approach tends to maintain a moreuniform distribution of nodes within in a bounded grid space overoften-used random motion techniques like the random vector way-point model (Bettstetter et al., 2003; Camp et al., 2002).
An NS-2 simulation takes a tcl (Tool Command Language) fileas input defining events at particular time steps that NS-2 willtrigger. In order to run a large amount of simulations — theresults in this paper represent analysis of around 4000 separatesimulations — a mechanism for automating tcl file generation isneeded. We have developed a Java simulation generation packagethat generates sets of tcl files, log files and result analysis files,while allowing flexible control over the individual simulationparameters.
Each set of simulations is determined by the contents of theproperties file and the number of UAs, Service Agents (SA) andDiscovery Agents (DA). For each single simulation description, sixmobility scenarios are used, and for each mobility scenario, thereare ten mobility variations. Hence, for a single simulation, say forexample, a simulation of 25 consumers and 1 providers, 60mobility files are used.
OppCacheOppCache54
Proactive3secProactive18sec
ReactiveOppCache Delay
OppCache54 DelayProactive3sec Delay
Proactive18sec DelayReactive Delay
Fig. 6. Legend for Figs. 7 and 8.
50
60
70
80
90
100
8090100
Ave
rage
Suc
cess
Rat
e P
erce
ntag
e
Average Connecti
25-1 Discovery Only Suc
Fig. 7. Discovery success and delay
To capture the effects of different deployments, the number ofconsumers and providers were each varied between 1, 3, 9 and25. In the simulations, nodes never hosted both consumers andservices and the selection of services and consumers is consistentacross scenarios regardless of motion scenarios and servicediscovery settings.
�
vity
ces
(25
Opp cache: Opportunistic caching with the service lifetime setto 9 s.
� Opportunistic cache54 s: Opportunistic caching with the servicelifetime set to 54 s.
� Proactive cache3 s: Proactive mode where each node multicaststheir service onto the network every 3 s. The service lifetimeset to 9 s.
� Proactive cache18 s: Proactive mode where each node multi-casts their service into the network every 18 s. The servicelifetime is set to 54 s.
� Reactive: Reactive mode. We also ran a full set of reactivemode with zero retries and five retries. There are no servicelifetime settings in reactive mode.
For Proactive, the service lifetime is set to three times theperiodicity of the service pushes onto the network. Therefore, theopportunistic caching and proactive schemes employ the sameservice lifetime for comparison; that is, 9 and 54 s (Fig. 6).
In all the experiments and as expected, varying the number ofproviders made a significant impact on the degree of averagesuccess rates for discovery across all examples. Figures 7 and 8illustrate this through the use of two examples: one network with25 services and 1 consumer (25–1); and another network with1 service and 25 consumers (1–25). The two extremes show howadditional service availability provides more redundancy andhence far more efficiency for all of the protocols tested.
Figures 7 and 8 show the summary of the comparison of thesediscovery schemes for 25–1 and 1–25. For the 25 service case,shown in Fig. 7, there is little significant difference between thediscovery schemes. The service availability is so high that thechance of finding one of them in a network containing 25 is prettyhigh even in the more fragmented cases. For the 100% connectiv-ity case, all protocols perform about the same. For the mostseverely disconnected network (60%), the opportunistic cachingand proactive protocols with the longest lifetime (54 s) performedthe highest. This might be illustrative of a highly mobile networkwhere services frequently go out of range and then come backinto range later in the simulation.
For the one provider case (in Fig. 8), the availability is very lowand the opportunistic caching mode with the longer lifetimevastly outperforms the rest for discovery across all of the
6070 0
2
4
6
8
10
12
14
16
18
Ave
rage
Del
ay (m
sec)
Percentage
s Rate and Delay
providers and 1 consumer).
50
60
70
80
90
100
60708090100 0
20
40
60
80
100
120
140
160
Ave
rage
Suc
cess
Rat
e P
erce
ntag
e
Ave
rage
Del
ay (m
sec)
Average Connectivity Percentage
1-25 Discovery Only Success Rate and Delay
Fig. 8. Discovery success and delay (1 provider and 25 consumers).
Table 2A comparison of running with or without retries for the 80% connectivity case.
Type Retries No retries
1–25 67.23 54.9
25–1 95.3 93.0
3–25 90.51 81.04
25–3 98.05 96.87
Table 3Parameters used to generate mobility scenarios.
Parameter Value
Number of groups 1
Nodes per group 11
Reference point (RP) separation 50
Node separation from RP Varied
Max X 1800
Max Y 1800
End time 300
Speed mean 30
Speed delta 5
Pause time 2
Pause delta 2
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–13791376
connectivity cases. The discovery success rates using opportunis-tic caching and a longer lifetime, show a high degree of resiliencewhen faced with few provider sources. At the same time though,the proactive protocol with 18 s intervals performs equally aswell overall as the other two high scoring discovery schemes(opportunistic caching with 9 s lifetime and proactive for 3 sintervals) in all cases. The reactive mode performs poorly incomparison. We can conclude therefore that for limited serviceprovider availability, the reactive approach does not compete wellagainst more proactive schemes or opportunistic caching.
Further results, shown in Table 2 further illustrate the effective-ness of INDI retries, as discussed in Section 6.1. The table shows thedifference in results for four provider-consumer combinations: 1 ser-vice provider, 25 consumers; 25 providers, 1 consumer; 3 providers,25 consumers; and 25 providers, 3 consumers.
For low numbers of providers, it can be clearly seen that thereis a significant gain in successful discovery rates when usingretries as opposed to not providing additional fault tolerance.Therefore, the difference that retries make is a function ofavailability of providers. For, 1–25 there is a 13% performancegain and for 3–25 there is an 9% gain. For higher numbers ofproviders, and hence higher available of possible locations forservices, the results therefore show a lower gain but still a notabledifference. For 25–1 there is a 2% gain and for 25–3 there isaround a 1% gain.
7. Message overheads for TCP and multicast for XMPPdeployment in a MANET
In the experiments described in the section, we use our GUMPsemantic server proxy implementation, described in Section 5 andperform emulations within the Common Open Research Emulator(CORE) environment running on FreeBSD. CORE (Ahrenholz et al.,2008) allows for low-fidelity emulation of wired and wirelessnetworks between virtual machines. These virtual machines canbe distributed across multiple machines running CORE, and alsoconnected to real non-virtualized network interfaces.
The scenarios used in our basic experiments were notionalrepresentation of platoon level mobility over an area. Mobile entitiescontinuously communicate XMPP message stanzas and additionaltext chats amongst mobile peer network nodes. A testbed was alsoestablished to demonstrate that the MUC sessions can also be back-hauled to a centralized MUC server over an emulated long-haulwireless link using XOG. In the scenario the backhaul connection canbe removed and platoon level network mobility allows for fragmen-tation to demonstrate the ability to maintain autonomous messaginglocally when operating in a disconnected manner. To study statisti-cally the performance message delivery an XMPP MUC traffic gen-erator was used to automate evaluations of distributed MUCperformance. In our experiment, each node uses a traffic generatorto send traffic, which is written using the Ignite Realtime Smacklibrary, and therefore can send traffic to a room with or without theXO proxy.
The nodes in the platoon move based on the reference pointgroup mobility model (RPGM), using the Colorado School ofMines mobility generation tool (Camp et al., 2002). This modelis a generalized case of the most commonly used group mobilitymodels. The experimental parameters appear in Table 3:
The only parameter varied was the node separation from thereference point (SRP), which allowed for nodes to roam closer orfarther away from the reference point, creating different densityincluding variable probability of fragmentation. The three valuesused had the following qualitative descriptions:
�
Low connectivity: SRP was set to 400. The nodes frequentlyspread out into networks of four to six hops in diameter.Disconnects were common.
0
20
40
60
80
100
0 5000 10000 15000 20000
Per
cent
age
of M
essa
ges
Del
iver
ed
Latency (ms)
XOXMPP
XOXMPP
XOXMPP
XOXMPP
0
20
40
60
80
100
0 5000 10000 15000 20000
Per
cent
age
of M
essa
ges
Del
iver
ed
Latency (ms)
0
20
40
60
80
100
0 5000 10000 15000 20000
Per
cent
age
of M
essa
ges
Del
iver
ed
Latency (ms)
0
20
40
60
80
100
0 5000 10000 15000 20000
Per
cent
age
of M
essa
ges
Del
iver
ed
Latency (ms)
Fig. 9. Latency results for XMPP and XO in the four scenarios. Solid lines represent XO and dashed lines represent XMPP. The y-axis indicates the percentage of messages
delivered at the corresponding time on the x-axis, truncated at 20 s of delay. The XMPP CDF tail continued changing well past this delay, but not significantly. (a) Results
from high-connectivity scenario. (b) Results from medium-connectivity scenario. (c) Results from low-connectivity scenario. (d) Results from high-connectivity scenario
with bit error.
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–1379 1377
�
Medium connectivity: SRP was set to 320. The network was twoor three hops in diameter most of the time, and disconnectsoccurred less frequently. � High connectivity: SRP was set to 230. The network was tightlyclustered, usually within one or two hops. Disconnectswere rare.
These three mobility scenarios are the scenarios used for theexperiments. There is also a fourth scenario, which the same asthe high connectivity scenario except that a probability of biterror, Pb¼10�5, was added to the emulated wireless networkchannel. Five instances of each of the four types was created, andone experiment using XO and one experiment using XMPP wasdone with each instance. Each messages sent was one sentencefrom the declaration of independence. The intra-message sendingtimes were exponentially distributed with l¼ 0:2. Each of the 10nodes in the experiments were configured to both send andreceive messages.
7.1. Baseline
As a baseline for comparison, all of the experiments were firstrun configured as XMPP clients communicating with the XMPP-MUC server in the standard manner. Each of the nodes ran theQuagga OSPF routing suite7 to transport packets to the gateway(node with the link to the infrastructure network), which routesthem to the server. This was accomplished in CORE using an RJ45connection to a LAN with an OpenFire XMPP server running on it.
7 http://www.quagga.net/
This configuration presented some problems in this environ-ment, because the nodes become disconnected from the server attimes, which often cause the TCP sockets to close. This was handledby attempting to re-open the TCP socket if it was not open and amessage was ready to be sent. If that failed, it would wait onesecond and try again, repeating until it was successful. In the XOconfiguration, nothing was changed except that all of the nodes ranSMF and the XMPP traffic generators were configured to use the XOproxy rather than directly connecting with the sever.
7.2. Results
Figure 9 shows basic results from multiple scenario trials as aseries of cumulative density function (CDF) graphs. The y axesrepresent the cumulative message delivery ratio vs. messagedelivery delay represented on the x-axis. In all cases, XO sig-nificantly outperforms the conventional XMPP client/serverapproach in terms of both message delivery ratio and overallmessage delay. This effect is further amplified when the emulatedlink conditions are degraded by included statistical channel lossin addition to mobility induced dynamics. Under all scenarioconditions the conventional XMPP MUC operating in MANETenvironments has significantly skewed message delay statisticswith a long tail. In many cases, there is no message delivery to aclient due to socket failures and TCP issues. We attempt to be fairto XMPP operation and provide a reasonable short term reconnecttime. While XO suffers from some message loss as expected inthis dynamic environment, the collection of XO message delayCDFs demonstrates a low overall message delivery delay statisticwhich is highly encouraging. XO delivered more messages, andthe distribution of the latencies has relatively low variance withthe vast majority of the messages delivered in less than a second.
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–13791378
8. Conclusions
The two previous sections clearly demonstrate that theMANET environment requires a certain level of configurabilityfor deployment that is impacted by the degree of connectivity andmobility of the nodes in the network. In Section 6.2, we showedthat there are three levels of configuration that impact the successrates for a discovery system when operating in a MANET: choiceof multicast forwarding scheme; choice of discovery mode; andchoice parameters for retrying discovery queries. Such configura-tion is generally not available to existing discovery systems, andtherefore the ability of plugging in something like INDI intoGUMP via ProtoSD is essential for deployment into a MANETsetting.
Also, as we demonstrated in Section 5, even using standardnon-optimized multicast, there are significant gains when usingthe GUMP XMPP server proxy and multicast over TCP runningwith TCP and a server-based management of networkedresources.
We have, therefore, demonstrated that GUMP can be used toprovide a server-side proxy for XMPP, which can adapt between aTCP client connection from an existing XMPP client GUI-basedapplication (Pidgin and Spark have been successfully tested) intoa serverless backbone across a wireless network. The power ofsuch a mapping by addressing the mapping at the protocol layer,reduces a potential n-squared application-based approach into aone time protocol mapping, which can support many more client-side protocol compliant applications. The alternative wouldinevitably lead to the development of further GUIs for specificapplications or deployments, which would not only lead toduplication of effort but would result in a far longer developmenttime in the long term.
9. Future work
GUMP was designed from requirements gathering analysis ofanalyzing architectural and deployment considerations of deploy-ing XMPP and WS messaging protocols (WS-Eventing and WS-Notification) onto wireless networks. The resulting frameworkoffers us the ability to not only implement server-side proxies forthese protocols but it also allows us to compare different multi-cast algorithms (Java multicast and NORM) and discovery sub-systems (SLP and JmDNS) when applied to different mobileenvironments. The impact of serverless discovery subsystemswhen applied to frequent mobility or disruption of wireless nodeshas strong interdependencies with the underlying multicastalgorithms they employ. Further, we would like to investigatehow much protocols such as NORM impact the reliability of themessage delivery compared to the standard multicast approach.
As mentioned in the text, we are now looking at integratingWS-Notification into GUMP. For this integration, the underlyingmulticast and discovery subsystems can be reused and modeledon the XO implementation, since they are collecting similarinformation about the participants that are available on thenetwork. We also can reuse the connectivity scheme throughthe use of the GUMP TCP input proxy and extend this to processHTTP headers. We will, however, need to write a GUMP messageproxy for WS-Notification. This will involve parsing the actualcontent of the incoming messages from WS-Notification intocommands that can be realised on the underlying multicastbackbone; that is, we will need to convert the client–server WS-Notification model to a one-to-many protocol for distributingonto a serverless network. The process is very similar to XMPPsince both XMPP and WS-Notification both use managementservers to keep tracks of XMPP groups, or WS-Notification topics.
A similar approach would be taken for further messagingprotocols.
We are also looking into the possibility of making GUMPcompletely self-adaptive by using heuristic measurements toanalyze/predict the mobility of the nodes in the network at thattime and to automatically choose the appropriate deploymentstack to address the needs of the network at that time. Through aprocess of experimentation we hope to extract which protocolsare suitable for the various modes and levels of mobility, whichcan lead directly into a self-adapting system for deployment intomultiple network environments.
For the XMPP proxy, we also noted that for scenarios wherethe link between the XOG and the server was anticipated to phasein and out, some caching feature would be required at the XOGand on the server to store messages meant to go over the linkwhen it is down. This additional persistence of messages isslightly more complicated than the other cases, and from ahuman–computer interaction perspective it may be useful toprovide cues to the user about what the connection status issince there may be a great deal of delay after which a largenumber of messages would flood the user’s screen. This isdifferent from the other intended use cases, which aim to providean interface for the user that is identical to a standard XMPP MUCexperience.
Acknowledgments
GUMP has been developed by the Networks and Communica-tion Systems Branch of the IT Division at NRL. On-going modifica-tions and experiments with the core system have been funded bythe Office of Naval Research Service-Oriented Networking OverMANET (SONOMA) project. We thank Brian Adamson for hisguidance and input into the NORM protocol and its integrationand David Talmage for helping stress test and debug GUMPduring its development phase.
References
Adamson B, Bormann C, Handley M, Macker J. Negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocol, RFC 3940 (Experimental), obso-leted by RFC 5740, URL /http://www.ietf.org/rfc/rfc3940.txtS; November2004.
Ahrenholz J, Danilov C, Henderson TR, Kim JH. CORE: a real-time networkemulator. In: IEEE Military Communications Conference; 2008. p. 1–7.
Bettstetter C, Resta G, Santi P. The node distribution of the random waypointmobility model for wireless ad hoc networks. IEEE Transactions on MobileComputing 2003;2(3):257–69.
Box D, Cabrera LF, Critchley C, Curbera F, Ferguson D, Geller A, et al. Web serviceseventing (WS-Eventing). Technical Report, W3C, URL /http://www.w3.org/Submission/WS-Eventing/S; August 2004.
Camp T, Boleng J, Davies V. A survey of mobility models for ad hoc networkresearch. Wireless Communications and Mobile Computing 2002;2(5):483–502.
Clausen T, Jacquet P. Optimized link state routing protocol (OLSR), RFC 3626(Experimental), URL /http://www.ietf.org/rfc/rfc3626.txtS; October 2003.
Corson S, Macker J. Mobile ad hoc networking (MANET): routing protocolperformance issues and evaluation considerations, RFC 2501 (Informational),URL /http://www.ietf.org/rfc/rfc2501.txtS; January 1999.
Deering S. Host extensions for IP multicasting, RFC 1112 (Standard), updated byRFC 2236, URL /http://www.ietf.org/rfc/rfc1112.txtS; August 1989.
Gateway Interaction—XEP-0100. URL /http://xmpp.org/extensions/xep-0100.htmlS.Giordano M. DNS-based discovery system in service oriented programming.
Lecture Notes in Computer Science 2005;3470:840.Graham S, Hull D, Murray B. Web services base notification 1.3 3 (WS-Base-
Notification), OASIS standard, URL /http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdfS; 2006.
Gryazin E. Service discovery in bluetooth. Group for robotics and virtual reality.Helsinki, Finland: Department of Computer Science, Helsinki University ofTechnology. Published at NEC CiteSeer, Scientific Literature Digital Library;2006.
Guttman E, Perkins C, Veizades J, Day M. Service Location Protocol, version 2, RFC2608 (proposed standard), updated by RFC 3224, URL /http://www.ietf.org/rfc/rfc2608.txtS; June 1999.
J. Dean et al. / Journal of Network and Computer Applications 34 (2011) 1366–1379 1379
Helal S. Standards for service discovery and delivery. IEEE Pervasive Computing2002:95–100.
Jingle—XEP-0166. URL /http://xmpp.org/extensions/xep-0166.htmlS.Kozat UC, Tassiulas L. Service discovery in mobile ad hoc networks: an overall
perspective on architectural choices and network layer support issues. Ad HocNetworks 2004;2(1):23–44.
Lass RN, Macker J, Millar D, Taylor IJ. GUMP: adapting client/server messagingprotocols into peer-to-peer serverless environments. In: International con-ference on autonomic computing; 2010. p. 39–46. URL /http://portal.acm.org/citation.cfm?id=1809026S.
LimeWire. URL /http://www.limewire.comS.Link-Local Messaging—XEP-0174. URL /http://xmpp.org/protocols/linklocal/S.Macker J, DesignTeam S. Simplified multicast forwarding for MANET, MANET WG.
URL /https://datatracker.ietf.org/doc/draft-ietf-manet-smf/S; 2010.McCanne S, Floyd S, Fall K, Varadhan K, et al. Network simulator ns-2, 2000.Multi User Chat (MUC)—XEP-0045. URL /http://xmpp.org/extensions/xep-0045.
htmlS.Naval Research Lab. AgentJ: Java network simulations ins NS-2. An installation and
user manual and source code. URL /http://cs.itd.nrl.navy.mil/work/agentj/S.
Saint-Andre P. Extensible messaging and presence protocol (XMPP): core, RFC3920 (proposed standard), URL /http://www.ietf.org/rfc/rfc3920.txtS; Octo-ber 2004a.
Saint-Andre P. Extensible messaging and presence protocol (XMPP): instantmessaging and presence, RFC 3921 (proposed standard), URL /http://www.ietf.org/rfc/rfc3921.txtS; October 2004b.
Steinberg D, Cheshire S. Zero configuration networking: the definitive guide.O’Reilly Media, Inc; 2005.
Taylor I, Downard I, Adamson B, Macker J. AgentJ: enabling Java NS-2 simulationsfor large scale distributed multimedia applications. In: Second internationalconference on distributed frameworks for multimedia DFMA 2006. Penang,Malaysia, 2006.
The Java OpenFire XMPP Server. URL /http://www.openfire.orgS.The NRL-OLSR Routing Protocol Implementation. Naval Research Lab Website, URL
/http://cs.itd.nrl.navy.mil/work/olsr/index.phpS.The Spines Messaging System. URL /http://www.spines.org/S.Tool Command Language. URL /http://www.tcl.tk/S.van Hoff A. Java implementation of multicast DNS, URL /http://jmdns.sourceforge.
net/S.