Service Location Protocol Administration Guide

How SLP Is Implemented

In the Solaris SLP implementation, the SLP SAs, UAs, DAs, SA servers, scopes, and other architectural components (listed in Table 1-1) are mapped partially into slpd and partially into application processes. The SLP daemon, slpd, organizes certain off-host SLP interactions. The SLP daemon:

For more information about the SLP daemon, see slpd(1M).

In addition to slpd, the UA and SA client libraries (libslp.so for C/C++ and slp.jar for Java) provide UA and SA clients with access to the SLP framework. The client libraries:

In the following figure, the SLP client library in the Service Provider Program implements SA functionality. The Service Provider Program uses the SLP client library to register services with slpd, and to deregister them. The SLP client library in the Service Client Program implements UA functionality. The Service Client Program uses the SLP client library to issue multicast and unicast (to DAs) service requests and to query slpd for information on DAs. The slpd process takes care of all SA functionality, such as answering multicast requests, registering with DAs, and so on.

Figure 1-3 SLP Implementation

Graphic

Enabling SLP

SLP is enabled by running the SLP daemon, slpd. The supported interface for starting slpd is the /etc/init.d/slpd script, which starts the daemon only if the SLP configuration file, /etc/inet/slp.conf, exists. The Solaris operating environment includes the file /etc/inet/slp.conf.example. Rename this file to /etc/inet/slp.conf to enable SLP at boot time.