Service Discovery Architecture and Protocol Design for Pervasive Computing - Advanced Design Approaches to Emerging Software Systems - page 92

Service Selection Anycast. A set of similar services all may

meet a client's request. The service request sent
to one of the set of services is known as anycast.
For instance, INS uses overlay network anycast,
so its anycast is at the application layer. In INS, a
client's request goes to a directory. After searching
that directory, INS routes the request to a service
based on the application-defined service weight.
Thus, a client request goes to a service with the
best service weight.
Multicast. The drawback of unicast is that
the network address needs to be configured or
known ahead of time. On the contrary, in many
situations, the addresses are unknown. A solution
is that clients, service, and directories use mul-
ticast addresses for announcements and queries.
For example, SLP uses TCP/IP network layer
multicast addresses. It is simpler for mobile clients
and will be automatically compatible when new
services or directories are added later, because
global multicast addresses are used. Nevertheless,
there are very limited globally multicast addresses
at the network layer. Moreover, multicast is not
allowed on some routers even though the routers
have multicast capabilities. Using multicast also
introduces more communication overhead com-
pared to unicast, since more nodes are involved
in the communication.
Broadcast. Sometimes broadcast is used in
service discovery protocols. For example, Blue-
tooth Service Discovery Protocol uses broadcast
to find other services. In Bluetooth, as other com-
munication techniques are based on broadcast,
it is simpler to use broadcast directly. Another
example is that Salutation can utilize broadcast if
underlying protocols support broadcast. Regard-
less, data link layer broadcast is usually limited
to its subnet.
Using unicast usually saves much communi-
cation traffic; using anycast simplifies client side
processing; using multicast saves administrative
overhead; and using broadcast is sometimes more
efficient.

While many similar services are available to a
client, which service should the client use? It is
challenging to find services for users efficiently
and accurately.
User vs. Protocol Selection. Service discovery
protocols may select services for a user. In INS,
for example, the protocol decides which service
a client should use. For most service discovery
protocols, client programs or users choose from a
matched list of services. The advantage of protocol
selection is that it simplifies client programs or
little user involvement is needed. On the other
hand, protocol selection may not select the proper
service that a user wants. Predefined selection
criteria may not apply to all cases. Alternatively,
too much user involvement causes inconvenience.
It may be tedious for a user to examine many
services and compare them. A balance between
protocol selection and user selection is preferred.
Service Matching. Some service discovery
protocols match one of the services for a client. In
Matchmaking, a classified advertisement match-
making framework, client requests are matched to
services and one of the matched services is selected
for a user (Raman, Livny, & Solomon, 1998). In
INS, the service discovery protocol matches the
best service based on application defined metrics.
Most protocols match all the services and let the
user choose.
Context-awareness. Context information is
useful in selecting services. For example, when
Bob drives on the highway, his cell phone uses a
Bluetooth connection to find his earphone. While
he wants to access his email, his cell phone uses
a 3G connection. In the above two scenarios, se-
lections of the connections for the cell phone are
based on context information. Either intelligence
should be built in his cell phone or user involve-
ment is necessary for better service discoveries. So
far, only a few projects use location information
as a kind of context information to help service
selection.