Mini Service Location Protocol Configuration

There are two components in the Mini Service Location implementation: The mslpd and mslplib.

Configuration properties which are implemented in Mini SLP are:

Configuration Property Value Type Default Definition
net.slp.useScopes String List default The scope list (see below).
net.slp.locale String (Language Tag) en The language tag for requests.
net.slp.multicastMaximumWait Integer (milliseconds) 15000 Max blocking time during the multicast convergence algorithm.
net.slp.MTU Integer (# of bytes) 1400 The largest UDP message to send.
net.slp.multicastTTL Byte (1-255) 32 The range of multicast messages.
net.slp.isBroadcastOnly Boolean False Use Broadcast not Multicast.
net.slp.DAAddresses Address List   A list of DAs (see below).
net.slp.typeHint Service Type   An optimization for SA discovery.
net.slp.interfaces Address List   Interfaces to listen and send on.
net.slp.traceDrops Boolean False Log all dropped messages.
com.sun.slp.minRefreshInterval Integer 900 Seconds until reregistration done.
com.sun.slp.traceAll Boolean False Activate all logging.
com.sun.slp.noSA Boolean   For testing - as if no SAs exist.
com.sun.slp.noDA Boolean   For testing - as if no DAs exist.

Properties which begin with "com.sun" are not part of the SLP API.

Logging of Errors occurs whether or not the logging properties have been set.

Note that Boolean properties are False if they are not defined. They are only True if the property has been defined to be "TRUE".

For the mslpd, net.slp.useScopes may either be left as "default" or given a specific value. For mslplib, it is different - see below.

The mslpd is the SA, a network daemon. It loads with a serialized registration file and optionally a configuration file. Both the serialized registration file and the configuration file conform to the format specified in the API Internet Draft. The configuration file is further described in the source code modules where they used:

  • mslpd.c describes the configuration properties which are understood by the mslpd.
  • mslplib_int.c describes the configuration properties which are used by the mslplib.
  • mslpd_reader.c describes the serialized registration files which are read in as service advertisements.

The mslpd is configured by providing it with a command line option pointing it to the configuration file:
% mslpd ./slp.reg -f ./slp.conf
In this example, the slp.reg is the registration file and slp.conf is the configuration file.

An example configuration file follows:

net.slp.useScopes=SALES,ADMIN
net.slp.DAAddresses=da1.foo.org(SALES),da2.foo.org(sales,ADMIN),da3.foo.org(ADMIN)

This would be a useful configuration file for a 'remote client' which is not able to discover DAs using multicast. The DAs are labeled according to the scopes they support. A request specifying the SALES scopes would be sent to da1 or da2 but not da3.

The registration file could be:

#
# Sample serialized registration file
#
service:printer:lpr://pr.foo.org,en,9999
scopes=sales
media-size=na-letter
protocol=lpr

service:fingerd://pr.foo.org,en,9999
scopes=eng
users=dog,cat

http://pr.foo.org/phonelist.html,en,9999

service:phonelist.foo.org
scopes=NY
protocol=http

imap://pr.foo.org,en,9999
scopes=eng,west coast
user=sam,louis,dog,mary,ratbert

This configuration file advertises four services for the host pr.foo.org. It has lpr, fingerd, imap services and a phone list that can be accessed through http.

Note that the lpr service is registered as an abstract printer service type. It can be discovered by requesting a printer that supports the LPR protocol and has na-letter sized paper, in the scopes supported by the mslpd that reads this file.

The fingerd service is explicitely registered in the 'eng' scope. The mslpd would have to be configured with at least this scope or else it would reject this non-default scope registration.

A phone list is available using http, but is advertised using a service type with a private naming authority (foo.org). The scope is NY, for folks looking for a phone list in the New York office.

An IMAP server is advertised here. Any of the users on the list could find this server by searching for IMAP servers which support them, for example "(user=ratbert)" would find this server.

The mslplib is configured using the SLP API, which includes three functions for this purpose:

void         SLPSetProperty(const char *pcKey, const char *pcValue); 
const char * SLPGetProperty(const char *pcKey);
SLPError     SLPReadConfigFile(const char *pcFileName);

The final interface is not part of the SLP API Internet Draft, but I added it since it was useful to me and I already had the code.

The SLPSetProperty interface can be used to clear a property. To do this simply pass NULL to the pcValue parameter.

Caution: Clearing arbitrary configuration properties can make the implementation crash. There are some safeguards against this, but there are some properties which must be set. These include net.slp.MTU, net.slp.multicastMaximumWait, net.slp.multicastTTL and net.slp.locale.

Configuration options which have been implemented for the mslplib is the same as for the mslpd, with the exception of the net.slp.useScopes property.

net.slp.useScopes can be defined in three ways:

  1. Default: The default value is "default". SLPFindScopes() returns "default".
  2. Preconfigured: The configuration file (or API) supplies a comma delimited list, such as "engineering,sales". In this case, SLPFindScopes() returns "engineering,sales".
  3. 'User' scope model: The configuration file or API explicitely clears the scope value ("net.slp.useScopes=""). This is illegal for the mslpd (such a configuration is rejected by the mslpd automatically). For the mslplib, however, it allows the library to discover the scopes available on the network. The SLPFindScopes() API will return different things depending on the following rules:
    1. The scopes of DAs that are preconfigured with the net.slp.DAAddresses property.
    2. The scopes of DAs that have been discovered on the network.
    3. If there are no DAs, either preconfigured or discovered, the mslplib does SA discovery when SLPFindScopes() is called. This will return the aggregation of all scopes for SAs on the network.

The 'User' scope model allows SLPv2 to have the same behavior as the Macintosh chooser, when it lists the available AppleTalk zones, or the Windows LanManager browsers, which list available workgroups and domains.

The default behavior of SLP is to allow UAs to discover only a subset of services on the network. This is controlled by setting the scope to equal those services a user is intended to be able to make use of. The 'User' scope model, on the other hand, provides the user with the ability to see all scopes on the network and select services from them.

Note: Support for user configurable scopes is optional and by default it is not compiled when mslplib is built. See Mini Service Location Protocol Building Instructions.

One important thing to note about mslplib's configuration is that it is per process. That is, if one process opens SLPHandles with the SLPOpen API, all configuration changes made for any one of the handles applies to all of them. For example, the following effectively changes the scopes of the UA as a whole.

SLPSetProperty("net.slp.useScopes","one,two,three");
Future DA discovery, for example, will be done with this scope list.

© Sun Microsystems, 1998. Send comments to: Erik Guttman