|
|
United States-English | |
|
|
 |
|
HP-UX IP Address and Client Management Administrator’s Guide: HP-UX 11i v2, HP-UX 11i v3 > Chapter 1 Overview
SLP Overview |
|
|
The Service Location Protocol (SLP) framework simplifies the discovery and use of network resources such as printers, web servers, fax machines, video cameras, file systems, backup devices (tape drives), databases, directories, mail servers, and calendars. Typically, 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 offered by the network. The user is required to specify the following details pertaining to the desired service:
Based on this information, SLP resolves the network address of the host that supports the service. It uses Uniform Resource Locators (URLs) to locate the services. See “SLP Attributes” for more information. SLP facilitates the following:
SLP implementation on HP-UX is based on OpenSLP Version 0.8.0, developed by Caldera Systems, Inc. This section containes the following topics: This section describes the salient features of SLP. When service instances like printers or fax machines are added to a network, they are quickly visible to clients. When they are removed from the network, they are no longer visible to the clients. You can describe a service by configuring values for the attributes that are possible for that service. Clients can detect the entry and exit of services faster. For example, you can describe a printer as a PostScript® printer, a printer that has blue paper available, or a printer on the same floor as the user’s office. You can track a service by specifying the values of the attributes if services are replaced or removed from the network; user agents discover alternate or replicated servers and continue to operate. The SLP framework comprises the following agents and processes: The User Agent (UA) issues a service request on behalf of the client application, specifying the characteristics of the service that the client requires. The user agent can directly issue a multicast request to Service Agents. The Service Agent (SA) works on behalf of one or more services to advertise the service on the network. Service agents advertise their service through service agent advertisements. In the absence of Directory Agents (DAs), the SA responds to multicast requests sent by the User Agents. If a DA is available, the SA registers and, optionally, withdraws services with DAs that support its scopes. All the network services are grouped together by using scopes that indicate a particular location, administrative grouping, and proximity in a network topology or any other category. For more information about scopes, see “Assigning Scopes”. The HP-UX implementation of SLP includes a Service Agent Server, with which the services register their service information. Therefore, instead of having multiple individual Service Agents running on a host, there is only one Service Agent Server advertising multiple services. The Directory Agent (DA) is an optional SLP agent that maintains a cache of service advertisements sent by the SA. The DA provides this information to the clients that are trying to discover the services. A DA sends periodic unsolicited advertisements through which SAs and UAs discover the DA within shared scopes. SLP uses UDP and multicast ports in the following scenarios:
The SLP architecture, at its most basic level, includes the following players in a typical service location problem:
At the simplest level, an architecture for service location must provide a way for the UA to obtain a set of services having particular characteristics from SAs advertising those services. The information provided by SAs describing services is called a service advertisement. A service advertisement is a URL and a collection of attribute-list pairs that describe a service. All service advertisements have a valid lifetime. Upon expiry of this lifetime, the service advertisements become invalid, unless they are reregistered. Service advertisements characterize an instance of a service through a collection of attributes that describe the service. One of those attributes is the type of service being offered, known as the service type. The service type attribute describes a class of services that share the same attributes. It also includes information about what protocol clients must use when contacting the service. The service advertisement also contains another important piece of information: the service access point, which helps the UA to access the service. Normally, the service access point encapsulates the machine’s host name or IP address and perhaps a port number. Figure 1-6 illustrates SLP architecture for a network. In Figure 1-6, SAs contain service advertisements describing the services they represent. The advertisement consists of service type, attributes, and service access point. UAs transmit queries to the network about what services their clients require. The SAs intercept these queries and return the service access point information if the query matches the service type and attributes of the services they represent. The UA clients then utilize the services through the service access point information. Attributes in SLP are transmitted in text string lists. The lists contain parenthesized expressions assigning an attribute tag to a value or a set of values. The syntax for the attribute string list is as follows:
Attributes are formed into a list consisting of comma-separated expressions. The assignment expressions contain the attribute tag, followed by "=", followed by a comma-separated list of one or more values. An example of attribute list is as follows:
In this list, the submission day is assigned a string value of wednesday; the month attribute is assigned a list of integer values. The new_copy attribute is a keyword attribute and is not part of an attribute assignment expression. SAs send attribute lists in this format to DAs in response to a UA request for attribute values. Following are the different ways in which UAs and SAs find DAs:
Figure 1-7 illustrates how active and passive DA discovery work. The UA and SA at the top of the figure have initiated active discovery by multicasting a service request (SrvRqst) with service type service:directory-agent. The DA at the bottom of the figure responds by unicasting a DA advertisement (DAAdvert) with its URL and the list of scopes that it supports. At the bottom of the figure, the DA periodically multicasts a DAAdvert with its URL and scope list. The UA and SA listen on port 427 for the unsolicited DAAdvert and add the DA to their list of active DAs. Consider the example of a user who needs to use the printer services on a network. The following series of events occur at the server and the client side:
Figure 1-8 illustrates this process. Table 1-20 describes the files used by SLP. Table 1-20 SLP Files
SLP is a string protocol. Every SLP message consists of a header and a body. The body contains both string and binary fields. All the SLP messages are prefixed by a common header. The header contains the type, length, and other related information about the message. Table 1-21 describes the SLP message types. Table 1-21 Message Types
A scope is a cluster of services that allows the services to be associated with a set of users administratively. A scope indicates a particular location, administrative grouping, and proximity in a network topology or any other category. SAs and DAs are always assigned a scope string. The UA is normally assigned a scope string, through which it discovers that particular group of services. This allows a network administrator to provide the desired service to users. If the UA is configured with no scope, it discovers all available scopes and allows the client application to issue requests for any service available on the network. There are no hard and fast rules for the assignment of scopes. They may be assigned by geographical location or by logical or administrative groupings. For example, you can assign the administrative scope of “Marketing” to a scanner. It is also possible for the same scanner to be advertised within the local scope “Engineers,” if all engineers must have access to the resource as well. Following is an example of how to configure scopes:.
You can use scopes for the physical location of services. You can also use a physical location attribute within a particular service with scopes. Following is an example of expanded scope associated with a service:
This configuration allows services to be advertised to users that are in the Building-5 scope, as well as to users that are assigned to Building-12 scope. This is a logical configuration for physically dependent services, such as scanners or printers. Table 1-22 describes the APIs that the SLP software contains. Table 1-22 SLP APIs
The slpd daemon process acts as either a DA or an SA server. Service processes on a host register their service advertisements with slpd. These service processes contain an SA client library that communicates with slpd, acting as the SA server. slpd forwards all service registrations and withdrawals to DAs and times out invalid or expired service advertisements. The SLP library (libslp.sl) provides the UA functionality on a per-process basis without the need to communicate with slpd running on local machines. This means that in certain cases, you do not have to load the SLP daemon on every machine. This helps to minimize the overhead for SLP for those machines that need only UA capabilities. slpd must be running on all the machines that need to register services. In other words, slpd is required on all machines that run applications and make calls to either SLPReg() orSLPDeReg() APIs. slpd accepts registration requests for services from SAs and maintains this information internally. It shares this information with clients represented by their UAs when queried. In addition, slpd allows older applications that are not SLP-enabled to advertise the services offered by them. You can use the -r option to specify the file that contains static registrations. By default, slpd reads static registrations from the file /etc/slp.reg. You need to run slpd in order to make the registrations for the /etc/slp.reg file available to other machines. Additionally, slpd must be running for automatic DA and scope discovery to work correctly. If slpd is not running, then DAs and scopes can be discovered only via DHCP or the /etc/slp.conf file. You can invoke slpd with various options. Run the following command on the command line to invoke slpd:
Table 1-23 contains the list of command-line options that SLP supports at startup. Table 1-23 Startup Options
You can use the slpdc script to start, stop, and restart slpdcand also to dump the database. Table 1-24 contains the list of commands that slpdc supports. Table 1-24 slpdc Commands
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
