SLP Features

This chapter discusses the features, benefits, components, and working of SLP.

SLP Overview

The ‘Service Location Protocol’ (SLP) is an emerging Internet standard network protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks. This protocol is designed to simplify the discovery and use of network resources such as printers, Web servers, fax machines, video cameras, files systems, backup devices (tape drives), databases, directories, mail servers, calendars.

Traditionally, in order to locate services on the network, users of network applications are required to supply the host name or network address of the machine that supplies a desired service. SLP eliminates the need for a user to know the name of a network host supporting a service. Rather, the user supplies the desired type of service and set of attributes or keywords, which describe the service. Based on that description, the Service Location Protocol resolves the network address of the service of the user. slp uses Uniform Resources Locators (URL’s) to locate services.

SLP implementation on HP-UX is based on OpenSLP version 0.8.0 developed by Caldera Systems, Inc.

Benefits of using SLP

The following are the key benefits of using SLP:

Dynamic Services Tracking
When service instances are added on a network, they are quickly visible to clients. When they are removed they are no longer visible. For example, when a printer or a fax machine is added to a network, they are quickly visible to the clients. When these devices are removed, it is no longer visible. Services are described by configuring values for the attributes, which are possible for that service.For instance, a printer can be described as a Postscript printer, a printer that has blue paper available, or a printer on the same floor as the user’s office. A service may be tracked by specifying the values of the attributes. As services are replaced or taken out of service, User Agents will discover alternate or replicated servers and continue operation.
Ease of Administration
Administrators do not need to help clients find new services or to remove services when they no longer are available. As services are replaced or taken out of service, User Agents will discover alternate or replicated servers and continue operation.
Ease of Development
SLP’s well defined APIs and protocol semantics allow service developers to rapidly provide network services.

SLP Components

Basically, the SLP product consists of three components. They are:

Service Agents (SA)
The applications that provide services, need to register information regarding the services they provide with the service agents and directory agents if they exist on the network.
Directory Agents (DA)
This is a process, which collects service advertisements from the SA’s or applications providing the services and stores them in it’s local database. The DA can provide this service information to the clients trying to discover this service information.
User Agents (UA)
The SLP User Agent is a software entity that is looking for the location of one or more services. SLP can eliminate the need for users to know the names of network hosts. With SLP, the user only needs to know the description of the service they are interested in. Based on this description, SLP is then able to return the URL of the desired service.

How SLP Works

Consider the example of a user wanting to use the Printer services on a network.

The following events occur on the server side:

As the printer is initialized and is in the ready mode the printer’s URL is registered with the SA server and the DA server. The URL can have an IP address or the domain name. Services advertise themselves by registering with a Directory Agent. They can include in the registration, a list of all the key-words and attribute value pairs that describe their service. The registrations include a lifetime after which the service information is to be removed by the Directory Agent. This is done in order to avoid cases, where service hardware breaks but the service continues to be advertised forever.

Explicit deregistration can also remove service information as part of a Service Agent’s orderly shutdown procedure. Finally, Service Agents may register current attribute information periodically, allowing User Agents to ascertain their status, load, temperature, or other dynamic characteristics.

The following events occur on the client side:

The client can query for a printer service with particular attributes, such as Postscript printer, including the scope information. The client then connects to the printer with the chosen attribute values within the scope defined and processes the print instruction.

Defining Scopes

Services are grouped together using ‘scopes’. These are strings, which identify services that are administratively identified. A scope could indicate a location, administrative grouping, and proximity in a network topology or any other category. Service Agents and Directory Agents are always assigned a scope string. A User Agent is normally assigned a scope string, through which the User Agent will be able to discover that particular grouping of services. This allows a network administrator to ‘provision’ service to users. If the User Agent is configured with no scope, it will discover all available scopes and allow the client application to issue requests for any service available on the network.

slp daemon

slpd provides the Service Agent and the Directory Agent functionality along with the ability to maintain a consistent state with respect to the locations of other SLP agents on the network. The SLP library (libslp.sl) provides UA functionality internally on a per process basis without the need to communicate with slpd running on local machines. This means that in certain cases, the slp daemon does not always have to be loaded on every machine. This helps to minimize the overhead for SLP for those machines that will only need UA capabilities.

slpd must be running on all machines that will be registering services. In other words, slpd is required on all machines that run applications and make calls to one of the following SLP APIs: SLPReg(), SLPDeReg().

slpd is the process that accepts registration requests for services from Service Agents and maintains this information internally. It then provides this service information to the clients UA’s when queried. slpd also allows older applications which are not SLP-enabled to advertise the services. An option is provided to specify the file which contains the static registrations. By defaults it reads static registrations from the /etc/slp.reg file. If you expect the registrations for this file to be available to other machines, you must run slpd. slpd is required for automatic DA and scope discovery to work correctly. If you do not run slpd, then DA’s and scopes can only be discovered via DHCP or the /etc/slp.conf file.




	NOTE: Due to lack of a standard DHCP API, DA discovery via DHCP is not yet supported.

slpd is not needed if a machine will only be requesting services. In other words, slpd does is not required on machines if a call will never be made to SLPReg(), SLPDeReg(). slpd is not needed on a machine if manual or DHCP DA or scope discovery is sufficient.

Configuring SLP

The options required for configuring slp daemon "slpd" are provided through a configuration file. By default /etc/slp.conf is the configuration file used by SA and DA. These options basically include: DA configuration, Static Scope Configuration, UA Configuration, and Tracing options. These options determine the behavior of "slpd" and UA to an extent.




	NOTE: An example SLP configuration file is available in `/etc/slp.conf` with the SLP distribution. See the man page `slp.conf(4)` for explanations of the various options and it’s semantics. Also see the `slpd` man page for overview of slpd functionality.

Options provided for starting the SLP daemon

Currently the SLP daemon (slpd) accepts several useful command line options as listed below:

slpd [-d] [-c config file] [-r registration file] [-l log file] [-p pid file]

Table 1-1 Options

`[-d]`	Don’t detach from the controlling tty
`[-c config file]`	Option to change the file that slpd uses to read configuration information. Defaults to /etc/slp.conf.
`[-r registration file]`	Option to change the file that slpd reads to obtain static registrations.Defaults to /etc/slp.conf.
`[-l log file]`	Option to change the file that receives slpd log messages. Defaults to /var/log/slpd.log.
`[-p pid file]`	Option to change the file that holds the slpd process id. Defaults to /var/run/slpd.pid

A script has been provided to start, stop and restart slpd and also to dump the database. The usage of this script is described below:

Table 1-2 Script Usage

`slpdc start`	Starts the `slpd`. The command line options to be passed to slpd can be specified as: slpdc <options>
`slpdc stop`	Stops the `slpd`
`slpdc restart`	Restarts the `slpd`
`slpdc dump`	Dumps the database.

Static Registration

The SLP implementation allows legacy service applications that are not SLP-enabled (i.e. applications that were not compiled to use the SLP library) to participate in the SLP framework. Thereby allowing UAs to dynamically discover these legacy services. A file is used to provide the service information of these non-SLP-enabled applications. The default file being,/etc/slp.reg. This default file is read during the start-up by slpd, and is re-read when ever a SIGHUP signal is received. The default file can be overwritten via the “-r" command line option of the slpd command.




	NOTE: For more information on how to set up the static registration file, see man page `slp.reg (4)`.

Troubleshooting

The log information by default is written by slpd into /var/run/slpd.log file. The log file can be specified during slpd start time using "-l " command line option. Options are provided in the slp.conf file to specify the various information that can be logged in the slp.log file.

The Configuration file options for logging are:

Table 1-3 Options for Logging

net.slp.traceDATraffic	To control controlling printing of messages about traffic with DAs.
net.slp.traceMsg	To control printing of details on SLP messages.
net.slp.traceReg	To control printing of dumps of all registered services upon registration and deregistration.
net.slp.traceDrop	To control printing details when a SLP message is dropped.