The Mesh-enhanced Service Location Protocol (mSLP) enhances SLP
with a fully-meshed peering DA architecture. Peer DAs
exchange service registration states when they set up a peer relationship
and continue to exchange new service registration updates during the entire
peering period so as to maintain the same consistent data for shared
scopes. mSLP improves the reliability and consistency of SLP directory
services. It also simplifies SA registrations in systems with multiple
DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally.
Figure 1. mSLP System Architecture
Figure 1 shows the mSLP architecture. In general, mSLP is a lightweight
protocol for dynamic directory replication. It has the following main
- Peer Relationship Management: there is a peering connection between each
pair of peers. A DA learns about its peers in several ways, such as
exchanging peer information via DAAdverts.
- Registration Update Propagation: mSLP uses direct forwarding (push model)
and anti-entropy (pull model) to propagate registration updates and new
states (via SrvRegs and SrvDeRegs).
- Version Resolution: mSLP uses the Version Timestamp from Service
Agents (SAs) to resolve the different versions of the same registration.
- Handling Deleted States: a deleted registration is not removed right away,
instead, a deletion flag is set. A registration is purged (whether deleted
or not) when it expires.
- Failure Detection: mSLP uses the heat-beat mechanism (keepalive) to detect
peer DA failures and network partitions.
mSLP defined two new SLP message types: (1) Data Request (DataRqst),
which is used to request new registration states that have an Accept ID
greater the specified Accept ID; (2) Data Reply Complete
(DataRplyCmpl), which is used by a mesh-enhanced DA to notify
a peer that the replies (via SrvReg/SrvDeReg messages) to a
corresponding DataRqst from the peer have been completed. A DataRplyCmpl
and its corresponding DataRqst carry the same Accept ID.
mSLP also defined a new SLP extension: Mesh Forwarding (MeshFwd),
which is used to carry the Version Timestamp and the Accept ID
of a registration update. Two Forwarding IDs (FwdIDs) are defined:
RqstFwd and Fwded.
We implemented mSLP in Java 1.3. It is fully compatible with SLPv2,
but with added mesh-enhancement functions. Our implementation has the
The following SLP standard functions are supported:
- It is delivered as two separate programs: one for server
(DA), one for client (a combination of UA/SA). As we focus on DA
interactions, we do not provide a separate SA program to work as a server.
- Both client and server have an easy to use Java GUI.
- A DA uses an internal database to store service registrations
for simplicity and efficiency.
- A DA can work as a mesh-enhanced or non-mesh-enhanced DA. The
default is mesh-enhanced.
- A DA can be configured to (or not to) multicast DAAdvert
messages. The default is to multicast.
Added mesh-enhancement functions:
- All SLP messages except SAAdvert (as an SA in our system
works as a client to DAs, not a server for UAs): SrvReg,
SrvDeReg, SrvAck, SrvRqst, SrvRply,
SrvTypeRqst, SrvTypeRply, AttrRqst, AttrRply,
- Both fresh and incremental service registrations (SrvReg).
- De-registration of individual attributes (handling the tag list in
SrvDeReg messages) and removal of a whole service
- The use of different languages in service registrations, requests,
and replies. The same service URL can be registered in two different
languages (this leads to two different entries in the database). The
language tag is enforced in all matches.
- The use of naming authority in service registrations and service type
requests. Note that if the length of the naming authority string
(in SrvTypeRqst messages) is -1 (0xFFFF), it indicates a
'wildcard' service type request (over all naming authorities).
- Obtaining attributes for service type as well as for URLs. The tag list in
AttrRqst messages is supported.
- For service request (SrvRqst), only simple predicates are supported,
such as (a=1) and (&(a=1)(b=2)). This conforms to
slpv2bis. Complex predicates are not supported.
- A UA/SA can choose UDP or TCP to communicate with a DA.
- All string comparisons are case insensitive, except for URLs.
- A UA/SA uses the response timeout from a DA to handle the DA failure and
- Peer relationship management:
- exchange peer information via DAAdverts,
- use the heat-beat mechanism (keepalive) to handle peer failures
and network partitions.
- Registration propagation:
- Direct Forwarding: forward SrvReg
and SrvDeReg messages that have the MeshFwd extension
(FwdID = RqstFwd).
- Anti-Entropy: use the DataRqst message to pull new
registration states, and use the DataRplyCmpl message to notify
the end of replies to a corresponding DataRqst.