A Service Discovery Architecture based on Anycast in Pervasive Computing
Environments *
ZHANG Li
School of Software
Engineering
Beijing University of
Technology, China
zl_hlj@126.com
SHI Zhen-lian
School of Software
Engineering
Beijing University of
Technology, China
zshi@bjut.edu.cn
Abstract
Service discovery is very useful in pervasive
computing environments. A service discovery
architecture based on anycast is proposed. A wellknown anycast address is defined first, which stands
for a group of directory servers supporting service
discovery. Each node in pervasive environment
determines whether it is qualified to be a directory
server in accordance with its capability, such as its
memory, energy, or location stability. Qualified node
announces that it serves the well-known anycast
address and then begins to listen and cache service
register messages from other nodes. A node supplying
a service sends register messages to the well-known
anycast address. The message is routed the nearest
one of directory servers by an underlying anycast
routing protocol. When a node wants to get some
service information, it sends query messages to the
anycast address, too. The message is also routed to the
nearest directory. The directory replies in accordance
with the information cached or obtained from other
directories. With anycast, network load caused by
service discovery is reduced dramatically, which
results in scalability. The architecture is fully
distributed, which does not depend on any central
point. Therefore the architecture is a good candidate
solution for service discovery in pervasive environment.
1. Introduction
Pervasive computing environments are comprised
of handheld, wearable, embedded computers, and
regular desktop and servers. The devices are connected
by some combination of wireless ad hoc networks and
SHEN Qi
School of Software
Engineering
Beijing University of
Technology, China
shenq@bjut.edu.cn
wireless infrastructure-based networks, such as
WLANs[1].
Many services can be supplied in pervasive
computing environments, such as online game, music
downloading, domain name resolving, gateway service,
and mobile business, printer sharing etc.
Changing is a most important feature of pervasive
environments. Some devices may move around in the
network. Sometimes they may go out of the network.
Some devices may disappear in the network because of
no power. Therefore, the number and location of nodes
in the network are changing. And the network
topology is also changing. For services, it means that
servers and clients are all changeful. And network
connections are also changeful. Change makes it
difficult for a client to locate a server. This brings a
requirement for a facility to help clients to find servers.
Service discovery is such a powerful mechanism for
clients to obtain service information automatically[2].
Service discovery can help devices to get the
current status of the network, and find services needed.
It can also enable servers to advertise their services in
the network. For example, through service discovery,
passengers can find and share music or movies to kill
time with handheld devices when they are waiting for
trains or flights[3]. People can use mobile devices to
find the nearest saving spots in a disaster area.
Service discovery has attracted many researchers.
Considerable academic and industrial research efforts
have been devoted. Many successful solutions to the
service discovery problem are proposed in wired
network, such as Jini[4], Salution of IBM[5], SLP[6]
etc. In wireless network, particularly in ad hoc network,
there are also many solutions, such as GSD[1],
Konark[3], Splendor[7] etc. Most of the solutions
The research is supported by Youth Grant of Beijing University of Technology, China (97025001200601).
31st Annual International Computer Software and Applications Conference(COMPSAC 2007)
0-7695-2870-8/07 $25.00 © 2007
consider all nodes in the network are the same.
However, device types in pervasive environments are
diverse. The abilities of diverse devices are different.
For example, some devices move frequently, e.g.
PDAs or mobile phones in a shopping center. Some
devices’ locations are static, e.g. projector in an office
or conference room, point of sale terminals. Some
devices have stronger processing ability and larger
memory, e.g. servers, while some only possess smaller
memory, poor processing ability and the energy is also
limited, e.g. mobile phones. Therefore, these solutions
proposed without considering such feature of
pervasive environment can not supply good service
discovery in such situation.
With respect to the situation, we propose a Service
Discovery architecture based on Anycast in pervasive
computing environments, which is called SDA in the
paper. In SDA, service discovery tasks are undertaken
by the devices with stronger processing abilities and
less mobility. Therefore, weaker devices are released
of service discovery burden.
Anycast is one of communication model of IP, just
like unicast and multicast. One anycast address
corresponds to a group of nodes. The packet whose
destination is an anycast address is delivered to the
nearest one (according to the metric of routing protocol)
of the nodes serving the anycast address. Anycast is
good at selecting the best server among replicas[8].
Some well-known anycast addresses have been defined.
With anycast, SDA reduces the cost caused by service
discovery dramatically, and bootstrap problem which
exists in most P2P solutions is also solved.
SDA is a thorough distributed architecture,
independent of any central node, which makes it a
good candidate solution for service discovery in
pervasive computing environments.
The rest of the paper is organized as follows. The
architecture of SDA is described in detail in Section 2.
Features of SDA are analyzed in Section 3. Section 4
introduces the related research works. Our future
works is discussed in Section 5. A simple summary is
given finally.
2. Architecture of SDA
SDA utilizes directory servers to support service
discovery. These directories are responsible to cache
service information, give responses to service
discovery queries. However, only powerful nodes
undertake service discovery tasks in SDA, which is
consistent with the devices diversity and different
capabilities of the devices in pervasive computing
environments, and different from that every node acts
as a directory server in most P2P mechanisms. That is,
directory servers are nodes that have stronger
processing ability and do not move frequently. Each
node determines whether or not to be a directory in
accordance with its status. Therefore, although only
parts of nodes are directories, no more cost is
introduced in directories selection.
SDA uses anycast to deliver service registers and
service queries to decrease message cost. The key of
SDA is a well-known anycast address, which is
defined to support service discovery. The anycast
address is called service discovery (anycast) address,
which stands for a group of nodes supporting service
discovery.
Anycast is a new communication mode. The most
important function of anycast is to select the best
server among replicas for clients. Using replicated
severs is a common technology to increase the
availability and efficiency of network services. There
are many examples of replicated servers, such as NTP,
network game server etc. If replicas use a same anycast
address, client software can access the best server by
connecting to the address simply. For example,
Server1 and Server2 in Figure1 supply a same service
with a same anycast address x.y.z.p. When Client1
connects server with the anycast address x.y.z.p, its
message is directed to Server1 by the underlying
routing protocol. However, the request of Client2 is
routed to Server2 because Server2 is nearer to Client2
than Server1.
IPv6 defines subnet anycast address for all subnet
routers, and reserves address 7E in subnet as anycast
address of home agent. Thus, mobile host can connect
to one of home agents in its original network through
the anycast address. Supporting auto-configuration is
another motivation to propose anycast. For example,
defining an anycast address for DNS service, clients
send a query to the well-known anycast address, the
result of address resolution can be obtained. Thus,
users need not configure DNS server address any
more[9].
In SDA, each node in pervasive environments
determines whether it is qualified to be a directory
server in accordance with its capability, such as its
memory, energy, or location stability. Qualified node
announces that it serves the well-known anycast
address and then begins to listen and cache service
register messages from other nodes, e.g. Directory1
and Directory2 in Figure2. Every node supplying
certain service sends a register message to the wellknown anycast address. The message is routed the
nearest one of directory servers by an underlying
anycast routing protocol. For example, the service
register message of server with an address s.r.t.q in
31st Annual International Computer Software and Applications Conference(COMPSAC 2007)
0-7695-2870-8/07 $25.00 © 2007
Figure2 is routed to Directory2. The directory
receiving the register caches the information and gives
a response to the registering server. When a node
wants to get some service information, it sends a query
message to the anycast address, too. The message is
also routed to the nearest directory. For example, the
query of Client1 is routed to Directory1 while the one
of Client2 is route to Directory2 in Figure2. The
directory replies in accordance with the information
cached or obtained from other directories. For instance,
Directory2 gives response to Client2 with the register
information it receives, and Directory1 replies Client1
with information got from Directory2 through their
collaboration in Figure2.
Server2
x.y.z.p
Besides qualified servers, there is another type of
directory that we leave to be discussed later.
Register to x.y.z.p
Service: FAX
Address: s.r.t.q
Directory1
x.y.z.p
Server
s.r.t.q
Directory2
x.y.z.p
Query to x.y.z.p
: FAX?
Query to x.y.z.p
: FAX?
Server2
x.y.z.p
Client1
Client2
Anycast address: x.y.z.p
Figure2. SDA architecture
Message
to x.y.z.p
Message
to x.y.z.p
2.2. Service registering
The following discusses SDA in detail in respects
of the creation of directory server, service registering,
collaboration of directories, and service querying etc.
If the node supplying a certain service wants the
help of directories, it sends a service register message
with the service discovery anycast address. The
underlying anycast routing protocol routes the message
to the nearest directory. The directory caches the
service information and replies the registering server.
After that, the directory is called the supervisor server
of the registering node, and the registering node is
called a staff of the supervisor server. To grantee the
availability of the service, staff sends heartbeat
messages with the unicast address of the supervisor
server periodically to declare it is alive.
2.1. Creation of directory server
2.3. Collaboration of directories
In SDA, directory servers are powerful nodes in the
network. Each node determines whether it is capable
of being a directory in accordance with the predefined
metrics, such as memory capacity, processing ability,
and mobility etc. This determination is independent
completely. No negotiation is needed. If a node
reckons itself having the qualification to be a directory,
then it announces that it serves the well-known service
discovery (anycast) address and becomes a directory.
All directories in the network form a directories
group. To share server information and supply a quick
response, SDA takes advantage of multicast to
implement the collaboration of directories. Once a
node joins in the anycast group, it joins in a multicast
group at the same time.
A directory multicasts information to other
directories when a new service is registered. When a
supervisor directory can not receive heartbeat message
from a staff any more, it multicasts a service-withdraw
message to other directories to inform they should
delete the service information.
To reduce message cost, heartbeat message is sent
only to the supervisor server periodically. Therefore,
the information about one server is multicast only
twice. One is for adding and the other is for deleting.
Only the service information of staff is multicast by a
directory instead of all service information it has.
In order to synchronize the service information
among directories, synchronize messages can be
multicast by a directory to request the service
information of other directories’ staff. The directory
Client2
Client1
Figure1. Anycast communication model
31st Annual International Computer Software and Applications Conference(COMPSAC 2007)
0-7695-2870-8/07 $25.00 © 2007
receiving the synchronize message sends the service
information of its staff to the request node.
Synchronize response messages are sent by unicasting
instead of multicasting.
All the service information of the directory’s staff is
deleted by other directories when the directory stops
the service discovery task because of any reasons.
2.4. Temporary directory
If a registering server has not received any response
for a certain time after it sends a register message,
which hints that no directory exists in the network,
then the server join in the anycast and multicast group
to announce itself a directory despite its poor
capability. Such directory is called temporary directory
in order to be distinguished from other qualified
directories.
When a temporary directory receives a multicast
message, which means there is another directory in the
network, it multicasts a message to ask whether it can
stop the directory service because it is not qualified. If
there is a qualified directory in the network, it replies
the temporary directory. Then, the temporary directory
leaves the anycast group and sends register to anycast
address to find supervisor again.
2.5. Service querying
When a node needs some service, it sends a request
to the anycast address to query whether there is a
server which can supply such service. The underlying
anycast routing protocol routes the message to the
nearest directory. The directory receiving the request
searches the service in its staff information at first. If
no staff can meet the requirement, then it seeks in the
service information received from other directories.
Thereafter it replies the querying node with the result.
This can tell clients to connect to the nearest servers to
some extent.
2.6. Management of supervisor servers
Though a supervisor server is a powerful device, it
may also be failed for some reasons, e.g. no energy,
hardware failure etc. Therefore, when a staff sends
heartbeat message to its supervisor server but does not
receive any response, the staff restarts a new register
process to search a new supervisor.
3. Features of SDA
Based on the descriptions above, the features of
SDA are summarized as follows.
z Smaller message cost
Compared with the broadcast-based solution which
has been predominantly used in ad hoc network,
message cost of SDA is smaller. First, a service
registering message is only delivered to the nearest
directory other than all nodes in the network. Second, a
directory only multicast message to the directory group
other than the whole network nodes. In addition, a staff
sends heartbeat message only to its supervisor server
other than all directories. Instead of refreshing its staff
information to others periodically, a supervisor server
informs other directory servers only when a staff is not
active. In this way, cost can be reduced sharply and at
the same time service availability and advertisement
scope of service information also can be guaranteed.
Similarly, the querying message of service is sent only
to the nearest directory instead of being broadcast in
the network. The message cost can be reduced while
the efficiency of service discovery is not lost.
z Shorter Response time
Directory may be closer than the server providing
the service to the querying client. Therefore, the
response time for querying service information is faster
than that of broadcast-based solution in which
responses are sent by server providing the service.
z Higher reliability
Service discovery task is undertaken by powerful
devices in SDA. Therefore, the burdens of weaker
devices are smaller, which is helpful to improve the
availability of the network.
SDA is a fully distributed architecture, and different
from the regular central architecture. There is no
bottle-neck in SDA although directories are used.
Selection of directories is a complete dynamic process
because directory server is determined by a device
itself other than being pre-assigned. In addition, the
temporary directory resolves the availability problems
in some extreme situation.
z Bootstrap
Bootstrap problem can be resolved by using anycast
communication. Except broadcast-based mechanism,
query message must be with an address of a directory.
Service discovery anycast address can be defined and
preconfigured in OS. This solves the bootstrap
problem while it is consistent with the definition and
usage of anycast.
4. Related work
Current service discovery research efforts focus on
two aspects. One is the service description and
31st Annual International Computer Software and Applications Conference(COMPSAC 2007)
0-7695-2870-8/07 $25.00 © 2007
matching mechanism, the other is service discovery
architecture.
Service description languages can be divided into
the following categories. They are what is based on
service attribute/value pair, what is based on interface,
what is based on form grammar, and what is based on
XML etc[10]. Service description language based on
attribute/value pair has been adopted by IBM
Salutation, MIT INS, and Bluetooth SDP etc.
Description language used by Jini is based on interface.
While the languages in SLP and IBM DEAPspace are
based on form grammar. Konark, UPnP, WSDL, and
SSDS select languages based on XML. This paper
focuses on topics related to service discovery
architecture, therefore no more discussion on
description language.
There are three dominant kinds of service discovery
architecture proposed. One is directory-based
architecture in which there is one directory server or a
group of directories which support service discovery.
The server supplying some service registers to
directories, while clients who require some service
send queries to directories and then access server. Jini,
SLP, Salutation, UCberkeley SSDS, Bluetooth SDP,
and MIT INS all fall into this category. In this
architecture, directories cause bottle-neck problem.
Therefore, the architecture is more efficient in a static
environment, and widely deployed in wired network at
present. Since directory may be closer to clients than
the server supplying real service, so query response
time is shorter in the directory-based architecture.
The second type of architecture is called broadcastbased mechanism that is fully distributed. In this
architecture, a client broadcasts a service discovery
request in the network whenever it needs a service.
The server providing the required service replies the
client. Then the client connects to the server. This
architecture has been predominantly used in the
wireless network because it adapts to the dynamic
environments. Servers reply clients directly, therefore,
the availability of service is higher than the directorybased architecture. Similarly, there is another form of
this architecture. Servers broadcast service information
in the network periodically. Clients receiving the
message cache it and retrieve it when the clients need
the service. UPnP of Microsoft and Konark are
examples of the broadcast-based architecture.
The third type is hybrid architecture. Hybrid
architecture still uses directories. Service provider
needs to register to directories. A client needing the
service first proposes a request to directories. If the
request does not receive any response, then it
broadcasts the request in the whole network. This
architecture does well in the wireless networks in
which proactive routing protocol is used[11].
How to reduce the message cost is also a research
point. A common technique is to organize services into
groups. Service name and group information supplied
in both service query and service register message.
Each directory server only stores service information
in its domain. For the service supplied by nodes out of
its domain, directory server stores the group name and
an entry to other directory which may have the service
information of the service group. This is similar to the
mechanism of routing protocol. Intra-AS routing
protocol maintains detail routes to the domain nodes,
and only stores summary routing information of nodes
out of AS. GSD uses this technique.
To control the forward behavior of query can also
reduce message cost, for example, using flexible
forward probability strategy to forward query. That is,
probability of query message being forwarded
decreases with the distance that the message has
traveled. This strategy can not only reduce the amount
of repeat service requests received by the nodes, but
also keep the service protocol performance[2].
5. Future work
Simulation of SDA is the next work, which can
demonstrate the features and advantages of SDA by
experimental data. Shortcomings of SDA can also be
exposed, and then improvement can be made. Before
that we are going to evaluate multicast and anycast
routing protocols in wireless network, to select or
design multicast and anycast routing algorithms that
are appropriate for pervasive computing environments
and our SDA.
After that we are going to design a better
collaboration mechanism among directories. Multicast
is a simple collaborating way while it brings much
message cost to manage multicast group and
multicasting service information. We may take
advantage of current technologies, or find better
collaborating mechanisms.
Finally, we plan to review service description
languages to find a suitable one for SDA.
Implementing a prototype system is our goal. We are
going to reference some excellent ideas, such as,
service grouping in GSD and probability forwarding
strategy, to enhance performance of our prototype
system.
6. Summary
31st Annual International Computer Software and Applications Conference(COMPSAC 2007)
0-7695-2870-8/07 $25.00 © 2007
A service discovery architecture based on anycast in
pervasive computing environments is proposed in the
paper. This architecture takes the features of pervasive
computing environments and anycast into account. It
implements service discovery with shorter response
time, lower message cost, and no bootstrap problem.
The architecture is fully distributed, which makes the
architecture a good candidate solution for service
discovery in pervasive environment.
7. References
[1] D.Chakraborty, A.Joshi, Y.Yesha, T.Finin, “Toward
Distributed Service Discovery in Pervasive Computing
Environments”, Mobile Computing, IEEE Transactions on
Volume 5, Issue 2, March-April 2006, pp. 97 – 112.
[2] Z.Gao, X.Yang, S.Cai, “Flexible forward probability
based service discovery protocol for MANETs”, Journal of
Harbin Institute of Technology, Vol.37 No.9, Sep. 2005,
pp.1256-1260.
[3] S.Helal, N. Desai, V.Verma, Choonhwa Lee, “Konark - a
service discovery and delivery protocol for ad-hoc networks”,
Wireless Communications and Networking, 2003, WCNC
2003 IEEE, Volume 3, 16-20, March 2003, pp. 2107 - 2113
vol.3
[5] “The Salutation Consortium Salutation Architecture
Specification. (Version2.0)”, 1999-06-01.
[6] E.Guttman, “Service Location Protocol: Automatic
Discovery of IP Network Service”, IEEE Internet Computing,
1999-07, pp.71-80.
[7] T.M.Patel, G.E.Kaiser, “The SPLENDORS real time
portfolio management system”, Artificial Intelligence on
Wall Street, 1991, Proceedings, First International
Conference on 9-11, Oct. 1991, pp.73 – 78.
[8] C.Partridge, T.Mendez, and W.Milliken,
Anycasting Service”, RFC 1546 (1993).
“Host
[9] L.Zhang, W.Yan, X.Li, “anycast - another
communication model for IP”, Journal of computer research
and development, Vol140, No16, June 2003, pp. 785-790.
[10] Z.Gao, X.Yang, “problems to be considered in server
discovery technologies design”, computer Engineering, Oct.
2005, Vol.31 No.19, pp.127-129.
[11] P.E.Engelstad, Y.Zheng, “Evaluation of Service
Discovery Architectures for Mobile Ad Hoc Networks”,
Wireless On-demand Network Systems and Services, 2005,
WONS 2005, Second Annual Conference on, 19-21 Jan.
2005, pp.2 – 15.
[4] “SUN.Jini, Technology Core Platform Specification
(Version1.1)”, 2000-05.
31st Annual International Computer Software and Applications Conference(COMPSAC 2007)
0-7695-2870-8/07 $25.00 © 2007