Service Location Protocol Administration Guide

Chapter 7 Incorporating Legacy Services

Servers that can use SLP to advertise contain an internal SA that advertises their service and attributes to either the UA directly, or to the DA, if any. Legacy services are network services that pre-date the development and implementation of SLP. For example, Solaris services, such as the line printer daemon (lpsched), NFS file service, and NIS/NIS+ name service, do not contain internal SAs for SLP. This chapter describes when and how to advertise legacy services.

When to Advertise Legacy Services

Legacy service advertising might be required if applications with SLP UAs are deployed in your network and one of the following is true:

Hardware devices without SLP built in, such as printers, are available on your network; applications with SLP UAs need to be able to find them.
Software services without SLP built in, such as databases, are available on your network; applications with SLP UAs need to be able to find them.

How to Advertise Legacy Services

You can advertise legacy services in the following ways:

Modify the service to incorporate an SLP SA.
Write a small program that functions as an SLP SA to advertise the service.
Use proxy advertising to have slpd advertise the service.

Modifying the Service

If the service is a software server and the source code is available, you can modify the source code to incorporate an SLP SA into the server. The C and Java APIs for SLP are relatively straightforward to use (see the man pages for the C API and Javadoc pages for the Java API). If the service is a hardware device, the manufacturer might have an updated PROM that incorporates SLP. Contact the device manufacturer for more information.

Writing an SLP SA to Advertise the Service

If the source code or an updated PROM with SLP is not available, you can write a small SLP SA that advertises the service. The SA can function as a small daemon that is started from the same shell script as the service itself. Similarly, the service control shell script can also stop the SA. Again, the SLP APIs for C and Java provide programmatic access to SLP.

Using SLP Proxy Registration

Solaris slpd supports advertising of legacy services using a proxy registration file. A proxy registration file is a list of service advertisements in a portable format.

A service advertisement consists of a service URL line, an optional scope line, and a series of attribute definitions. slpd reads proxy advertisements from the file, registers the advertisements, and maintains them exactly like an SA client would. The following listing shows an example of a proxy registration file. Line numbers have been added for description purposes and are not part of the file.

1  #Advertise legacy printer. 
2
3  service:lpr://bizserver/mainspool,en,65535
4  scope=eng,corp
5  make-model=Laserwriter II
6  location-description=B16-2345
7  color-supported=monochromatic
8  fonts-supported=Courier,Times,Helvetica 9 10
9 
10 #Advertise FTP server
11
12 ftp://archive/usr/src/public,en,65535,src-server
13 content=Source code for projects
14

In this example, a legacy printer supporting the LPR protocol and an FTP server are being advertised.

Lines 1 and 10	Comment lines begin with a cross-hatch symbol (#) and do not affect the file's operation. Everything up through the end of a comment line is ignored.
Blank lines at 2, 9, and 14	Delimit the advertisements
Line 3 and 12	Service URLs
Line 4	Scope designation
Lines 5-8 and 13	Attribute definitions

Service URL

A service URL line has three required fields and one optional field, separated by commas:

First field - This field contains the service URL to be advertised. The service URL can be either a generic URL or a service: URL. See RFC 2609 for the specification of how to form a service: URL.
Second field - This field designates the language of the advertisement. In the previous example, the field designated English, en. The language is an RFC 1766 language tag.
Third field - This field establishes the lifetime of the registration, measured in seconds. The lifetime is restricted to an unsigned 16 bit-integer. If the lifetime is less than the maximum, 65535, slpd times out the advertisement like any other advertisement. If the lifetime is 65535, slpd refreshes the advertisement periodically, and the lifetime is considered permanent, until slpd exits.

Note -
As a practical matter, nonpermanent proxy registrations are of limited usefulness, because once slpd removes the advertisement, it is no longer accessible to UAs. Both advertisements in the example are permanent.
Service type field (optional) - If used, this field defines the service type. If the service URL is a generic URL, then it is possible to change the service type under which the URL is advertised. In the previous example of a proxy registration file, line 12 contains a generic FTP URL, and the optional type field causes it to be advertised under the service type name src-server. The service: prefix is not added by default to the type name.

Scope Designation

After the URL line, an optional scope line can appear. The scope line consists of the token scope followed by an equal sign, followed by a comma-separated list of scope names defined by the net.slp.useScopes configuration property. Only scopes that are part of the list of configured scopes for the host should appear in the scope list. If the scope line does not appear, the registration is made in all scopes with which slpd is configured. The scope line must appear immediately after the URL line; otherwise, it is recognized as an attribute.

Attribute Definitions

After the optional scope line, the bulk of the service advertisement contains attribute/value list pair lines. Each pair consists of the attribute tag, followed by an equal sign, followed by a comma-separated list of attribute values, or a single value if the attribute is single valued. In the previous example of a proxy registration file, line 8 illustrates a value list with multiple values; all other value lists have single values. The format for the attribute names and values is the same as on-the-wire SLP messages.

For a description of the format see RFC 2608. The proxy registration file supports the same convention for escaping non-ASCII characters as the configuration file. For more information about the proxy registration file format, see RFC 2614.

Enabling Proxy Registration

The first step in enabling proxy registration is to create a proxy registration file. You can locate the file anywhere on the host's file system, or anywhere else on the network that is accessible by HTTP. Use the net.slp.serializedRegURL property in the slp.conf file in the /etc/inet directory to locate it (see slp.conf(4)).

When creating proxy registrations, you should check whether a service type template exists for the service. A service type template is a description of the service URL and attributes for a service type. Templates enable UAs and SAs to interoperate, because they define what constitutes a service advertisement for a particular service type. If a service type template exists, you should use the template to construct the proxy registration. See RFC 2609 for more information on service type templates.

If a service type template is not available for the service, then you should select a collection of attributes that precisely describe the service. In addition, you should use a naming authority, other than the default, for the advertisement, because the default naming authority is only allowed for service types that have been standardized. See RFC 2609 for more information on naming authorities.

For example, suppose a company called BizApp has a local software defect database that they would like to advertise. They make a URL with the service type service:bugdb.bizapp and advertise that. In this case, the naming authority is bizapp.

When the proxy registration file is complete, you need to configure slpd to read it. Edit the slp.conf file and add the following line:

net.slp.serializedRegURL=<proxy registration file URL>

You do not add the file name here. Instead, you add a URL giving the location of the file. For example, if the serialized registration file is named slp.reg, and it is in the local /net/inet directory, you configure the following the URL property:

net.slp.serializedRegURL=file:/etc/inet/slp.reg

Considerations When Advertising Legacy Services

Generally, modifying the source code to add SLP is preferable to either writing a stand-alone SA or using proxy registration. By modifying the source code, it is possible to add service-specific features and to closely track service availability. If the source code is unavailable, writing a stand-alone SA is preferable to using proxy registration. A stand-alone SA allows the SA to track service availability by being integrated into the service start/stop procedure. Proxy advertising is generally the third choice, when no source code is available and writing a stand-alone SA is impractical.

Proxy advertisements are maintained only as long as slpd that reads the proxy registration file is running. If an advertisement times out or slpd is halted, the proxy advertisement is no longer available. Conversely, there is no direct connection between the proxy advertisement and the service itself.

If the service is brought down, slpd must be brought down, the serialized registration file edited to comment out or remove the proxy advertisement, and slpd brought up again. You must follow the same procedure when the service is restarted or reinstalled. The lack of connection between the proxy advertisement and the service is a major drawback of proxy advertisements, in comparison with the two other techniques of legacy advertising.