1slp(7P) Protocols slp(7P)
2
3
4
6 slp - Service Location Protocol
7
9 The Service Location Protocol (SLP) is a dynamic service discovery pro‐
10 tocol that runs on top of the Internet Protocol (IP). The protocol is
11 specified by the IETF standard-track documents RFC 2165, RFC 2608, RFC
12 2609; the API is documented in RFC 2614. .
13
14
15 There are two components to the SLP technology. The first is a daemon,
16 slpd(1M), which coordinates SLP operations. The second is a software
17 library, slp_api(3SLP), through which processes access a public API.
18 Both components are configured by means of the SLP configuration file,
19 slp.conf(4).
20
21
22 The SLP API is useful for two types of processes:
23
24 Client Applications Services and service information can be
25 requested from the API. Clients do not need to
26 know the location of a required service, only
27 the type of service, and optionally, the service
28 characteristics. SLP will supply the location
29 and other information to the client through the
30 API.
31
32
33 Server Processes Programs that offer network services use the SLP
34 API to advertise their location as well as other
35 service information. The advertisement can
36 optionally include attributes describing the
37 service. Advertisements are accompanied by a
38 lifetime; when the lifetime expires, the adver‐
39 tisement is flushed, unless it is refreshed
40 prior to expiration.
41
42
43
44 API libraries are available for both the C and Java languages.
45
46
47 SLP provides the following additional features:
48
49 o slpd(1M) can be configured to function as a transparent
50 directory agent. This feature makes SLP scalable to the
51 enterprise. System administrators can configure directory
52 agents to achieve a number of different strategies for scal‐
53 ability.
54
55 o SLP service advertising and discovery is performed in
56 scopes. Unless otherwise configured, all discovery and all
57 advertisements are in the scope default. In the case of a
58 larger network, scopes can be used to group services and
59 client systems so that users will only find those services
60 which are physically near them, belong to their department,
61 or satisfy the specified criteria. Administrators can con‐
62 figure these scopes to achieve different service provider
63 strategies.
64
65 o Services may be registered by proxy through a serialized
66 registration file. This is an alternative to registering
67 services through the API. See slpd.reg(4) for more informa‐
68 tion.
69
71 See attributes(5) for descriptions of the following attributes:
72
73
74
75
76 ┌─────────────────────────────┬─────────────────────────────┐
77 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
78 ├─────────────────────────────┼─────────────────────────────┤
79 │Availability │SUNWslpu │
80 ├─────────────────────────────┼─────────────────────────────┤
81 │CSI │CSI-enabled │
82 ├─────────────────────────────┼─────────────────────────────┤
83 │Interface Stability │Standard │
84 ├─────────────────────────────┼─────────────────────────────┤
85 │MT-Level │MT-Safe │
86 └─────────────────────────────┴─────────────────────────────┘
87
89 slpd(1M), slp_api(3SLP), slp.conf(4), slpd.reg(4), attributes(5)
90
91
92 Guttman, E., Perkins, C., Veizades, J., and Day, M., RFC 2608, Service
93 Location Protocol, Version 2, The Internet Society, June 1999.
94
95
96 Guttman, E., Perkins, C., and Kempf, J., RFC 2609, Service Templates
97 and Service: Schemes, The Internet Society, June 1999.
98
99
100 Kempf, J. and Guttman, E., RFC 2614, An API for Service Location, The
101 Internet Society, June 1999.
102
103
104 Veizades, J., Guttman, E., Perkins, C., and Kaplan, S., RFC 2165, Ser‐
105 vice Location Protocol, Network Working Group, 1997.
106
107
108
109SunOS 5.11 17 Nov 1999 slp(7P)