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:
Employs passive and active directory agent discovery for all UAs and SAs on the local host
Maintains a table of DAs and keeps it current for the use of the UAs and SAs on the local host
Acts as a proxy SA server for legacy service advertisements (proxy registration)
Can be configured to act as a DA
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:
Provide communication to register and deregister service advertisements between SA clients and slpd
Provide UA clients with the capability to make UA requests
Provide communication of DA accessibility information between slpd and UA clients
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.
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.