RFC2614 日本語訳
2614 An API for Service Location. J. Kempf, E. Guttman. June 1999. (Format: TXT=164002 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Kempf
Request for Comments: 2614 E. Guttman
Category: Informational Sun Microsystems
June 1999
Network Working Group J. Kempf Request for Comments: 2614 E. Guttman Category: Informational Sun Microsystems June 1999
An API for Service Location
An API for Service Location
Status of This Memo
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Abstract
Abstract
The Service Location Protocol (SLP) provides a new way for clients to dynamically discovery network services. With SLP, it is simple to offer highly available services that require no user configuration or assistance from network administrators prior to use. This document describes standardized APIs for SLP in C and Java. The APIs are modular and are designed to allow implementations to offer just the feature set needed. In addition, standardized file formats for configuration and serialized registrations are defined, allowing SLP agents to set network and other parameters in a portable way. The serialized file format allows legacy services to be registered with SLP directory agents in cases where modifying the legacy service program code is difficult or impossible, and to portably exchange a registration database.
The Service Location Protocol (SLP) provides a new way for clients to dynamically discovery network services. With SLP, it is simple to offer highly available services that require no user configuration or assistance from network administrators prior to use. This document describes standardized APIs for SLP in C and Java. The APIs are modular and are designed to allow implementations to offer just the feature set needed. In addition, standardized file formats for configuration and serialized registrations are defined, allowing SLP agents to set network and other parameters in a portable way. The serialized file format allows legacy services to be registered with SLP directory agents in cases where modifying the legacy service program code is difficult or impossible, and to portably exchange a registration database.
Table of Contents
Table of Contents
1. Introduction 4
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . 4
2. File Formats 7
2.1. Configuration File Format . . . . . . . . . . . . . . 8
2.1.1. DA configuration . . . . . . . . . . . . . . 9
2.1.2. Static Scope Configuration . . . . . . . . . . 9
2.1.3. Tracing and Logging . . . . . . . . . . . . . 11
2.1.4. Serialized Proxy Registrations . . . . . . . . 11
2.1.5. Network Configuration Properties . . . . . . . 12
2.1.6. SA Configuration . . . . . . . . . . . . . . . 14
2.1.7. UA Configuration . . . . . . . . . . . . . . . 14
2.1.8. Security . . . . . . . . . . . . . . . . . . 15
2.2. Multihomed Machines. . . . . . . . . . . . . . . . . . 16
2.3. Serialized Registration File . . . . . . . . . . . . . 16
1. Introduction 4 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . 4 2. File Formats 7 2.1. Configuration File Format . . . . . . . . . . . . . . 8 2.1.1. DA configuration . . . . . . . . . . . . . . 9 2.1.2. Static Scope Configuration . . . . . . . . . . 9 2.1.3. Tracing and Logging . . . . . . . . . . . . . 11 2.1.4. Serialized Proxy Registrations . . . . . . . . 11 2.1.5. Network Configuration Properties . . . . . . . 12 2.1.6. SA Configuration . . . . . . . . . . . . . . . 14 2.1.7. UA Configuration . . . . . . . . . . . . . . . 14 2.1.8. Security . . . . . . . . . . . . . . . . . . 15 2.2. Multihomed Machines. . . . . . . . . . . . . . . . . . 16 2.3. Serialized Registration File . . . . . . . . . . . . . 16
Kempf & Guttman Informational [Page 1] RFC 2614 Service Location API June 1999
Kempf & Guttman Informational [Page 1] RFC 2614 Service Location API June 1999
2.4. Processing Serialized Registration and Configuration
Files . . . . . . . . . . . . . . . . . . . . . . . . 18
3. Binding Independent Implementation Considerations 18
3.1. Multithreading . . . . . . . . . . . . . . . . . . . . 18
3.2. Asynchronous and Incremental . . . . . . . . . . . . . 19
3.3. Type Checking for Service Types. . . . . . . . . . . . 19
3.4. Refreshing Registrations . . . . . . . . . . . . . . . 19
3.5. Configuration File Processing . . . . . . . . . . . . 19
3.6. Attribute Types . . . . . . . . . . . . . . . . . . . 20
3.7. Removal of Duplicates . . . . . . . . . . . . . . . . 20
3.8. Character Set Encoding . . . . . . . . . . . . . . . . 20
3.9. Error Semantics . . . . . . . . . . . . . . . . . . . 20
3.10. Modular Implementations . . . . . . . . . . . . . . . 24
3.11. Handling Special Service Types . . . . . . . . . . . . 24
3.12. Scope Discovery and Handling . . . . . . . . . . . . . 24
4. C Language Binding 25
4.1. Constant Types . . . . . . . . . . . . . . . . . . . . 26
4.1.1. URL Lifetimes. . . . . . . . . . . . . . . . . 26
4.1.2. Error Codes. . . . . . . . . . . . . . . . . . 26
4.1.3. SLPBoolean . . . . . . . . . . . . . . . . . . 27
4.2. Struct Types . . . . . . . . . . . . . . . . . . . . 28
4.2.1. SLPSrvURL . . . . . . . . . . . . . . . . . . 28
4.2.2. SLPHandle . . . . . . . . . . . . . . . . . . 29
4.3. Callbacks . . . . . . . . . . . . . . . . . . . . . . 29
4.3.1. SLPRegReport . . . . . . . . . . . . . . . . 30
4.3.2. SLPSrvTypeCallback . . . . . . . . . . . . . . 30
4.3.3. SLPSrvURLCallback . . . . . . . . . . . . . . 31
4.3.4. SLPAttrCallback . . . . . . . . . . . . . . . 33
4.4. Opening and Closing an SLPHandle . . . . . . . . . . . 34
4.4.1. SLPOpen. . . . . . . . . . . . . . . . . . . . 34
4.4.2. SLPClose . . . . . . . . . . . . . . . . . . . 35
4.5. Protocol API . . . . . . . . . . . . . . . . . . . . 36
4.5.1. SLPReg . . . . . . . . . . . . . . . . . . . . 36
4.5.2. SLPDereg . . . . . . . . . . . . . . . . . . . 37
4.5.3. SLPDelAttrs . . . . . . . . . . . . . . . . . 38
4.5.4. SLPFindSrvTypes. . . . . . . . . . . . . . . . 39
4.5.5. SLPFindSrvs . . . . . . . . . . . . . . . . . 41
4.5.6. SLPFindAttrs . . . . . . . . . . . . . . . . . 42
4.6. Miscellaneous Functions . . . . . . . . . . . . . . . 43
4.6.1. SLPGetRefreshInterval . . . . . . . . . . . . 44
4.6.2. SLPFindScopes . . . . . . . . . . . . . . . . 44
4.6.3. SLPParseSrvURL . . . . . . . . . . . . . . . . 45
4.6.4. SLPEscape . . . . . . . . . . . . . . . . . . 46
4.6.5. SLPUnescape . . . . . . . . . . . . . . . . . 47
4.6.6. SLPFree . . . . . . . . . . . . . . . . . . . 48
4.6.7. SLPGetProperty . . . . . . . . . . . . . . . . 48
4.6.8. SLPSetProperty . . . . . . . . . . . . . . . . 49
4.7. Implementation Notes . . . . . . . . . . . . . . . . 49
2.4. Processing Serialized Registration and Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . 18 3. Binding Independent Implementation Considerations 18 3.1. Multithreading . . . . . . . . . . . . . . . . . . . . 18 3.2. Asynchronous and Incremental . . . . . . . . . . . . . 19 3.3. Type Checking for Service Types. . . . . . . . . . . . 19 3.4. Refreshing Registrations . . . . . . . . . . . . . . . 19 3.5. Configuration File Processing . . . . . . . . . . . . 19 3.6. Attribute Types . . . . . . . . . . . . . . . . . . . 20 3.7. Removal of Duplicates . . . . . . . . . . . . . . . . 20 3.8. Character Set Encoding . . . . . . . . . . . . . . . . 20 3.9. Error Semantics . . . . . . . . . . . . . . . . . . . 20 3.10. Modular Implementations . . . . . . . . . . . . . . . 24 3.11. Handling Special Service Types . . . . . . . . . . . . 24 3.12. Scope Discovery and Handling . . . . . . . . . . . . . 24 4. C Language Binding 25 4.1. Constant Types . . . . . . . . . . . . . . . . . . . . 26 4.1.1. URL Lifetimes. . . . . . . . . . . . . . . . . 26 4.1.2. Error Codes. . . . . . . . . . . . . . . . . . 26 4.1.3. SLPBoolean . . . . . . . . . . . . . . . . . . 27 4.2. Struct Types . . . . . . . . . . . . . . . . . . . . 28 4.2.1. SLPSrvURL . . . . . . . . . . . . . . . . . . 28 4.2.2. SLPHandle . . . . . . . . . . . . . . . . . . 29 4.3. Callbacks . . . . . . . . . . . . . . . . . . . . . . 29 4.3.1. SLPRegReport . . . . . . . . . . . . . . . . 30 4.3.2. SLPSrvTypeCallback . . . . . . . . . . . . . . 30 4.3.3. SLPSrvURLCallback . . . . . . . . . . . . . . 31 4.3.4. SLPAttrCallback . . . . . . . . . . . . . . . 33 4.4. Opening and Closing an SLPHandle . . . . . . . . . . . 34 4.4.1. SLPOpen. . . . . . . . . . . . . . . . . . . . 34 4.4.2. SLPClose . . . . . . . . . . . . . . . . . . . 35 4.5. Protocol API . . . . . . . . . . . . . . . . . . . . 36 4.5.1. SLPReg . . . . . . . . . . . . . . . . . . . . 36 4.5.2. SLPDereg . . . . . . . . . . . . . . . . . . . 37 4.5.3. SLPDelAttrs . . . . . . . . . . . . . . . . . 38 4.5.4. SLPFindSrvTypes. . . . . . . . . . . . . . . . 39 4.5.5. SLPFindSrvs . . . . . . . . . . . . . . . . . 41 4.5.6. SLPFindAttrs . . . . . . . . . . . . . . . . . 42 4.6. Miscellaneous Functions . . . . . . . . . . . . . . . 43 4.6.1. SLPGetRefreshInterval . . . . . . . . . . . . 44 4.6.2. SLPFindScopes . . . . . . . . . . . . . . . . 44 4.6.3. SLPParseSrvURL . . . . . . . . . . . . . . . . 45 4.6.4. SLPEscape . . . . . . . . . . . . . . . . . . 46 4.6.5. SLPUnescape . . . . . . . . . . . . . . . . . 47 4.6.6. SLPFree . . . . . . . . . . . . . . . . . . . 48 4.6.7. SLPGetProperty . . . . . . . . . . . . . . . . 48 4.6.8. SLPSetProperty . . . . . . . . . . . . . . . . 49 4.7. Implementation Notes . . . . . . . . . . . . . . . . 49
Kempf & Guttman Informational [Page 2] RFC 2614 Service Location API June 1999
Kempf & Guttman Informational [Page 2] RFC 2614 Service Location API June 1999
4.7.1. Refreshing Registrations . . . . . . . . . . . 49
4.7.2. Syntax for String Parameters . . . . . . . . . 49
4.7.3. Client Side Syntax Checking . . . . . . . . . 50
4.7.4. System Properties . . . . . . . . . . . . . . 50
4.7.5. Memory Management . . . . . . . . . . . . . . 51
4.7.6. Asynchronous and Incremental Return Semantics. 51
4.8. Example. . . . . . . . . . . . . . . . . . . . . . . . 52
5. Java Language Binding 56
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 56
5.2. Exceptions and Errors . . . . . . . . . . . . . . . . 56
5.2.1. Class ServiceLocationException . . . . . . . . 57
5.3. Basic Data Structures . . . . . . . . . . . . . . . . 58
5.3.1. Interface ServiceLocationEnumeration . . . . . 58
5.3.2. Class ServiceLocationAttribute . . . . . . . 58
5.3.3. Class ServiceType . . . . . . . . . . . . . . 61
5.3.4. Class ServiceURL . . . . . . . . . . . . . . 63
5.4. SLP Access Interfaces . . . . . . . . . . . . . . . . 67
5.4.1. Interface Advertiser . . . . . . . . . . . . . 67
5.4.2. Interface Locator . . . . . . . . . . . . . . 69
5.5. The Service Location Manager . . . . . . . . . . . . . 72
5.5.1. Class ServiceLocationManager . . . . . . . . . 72
5.6. Service Template Introspection . . . . . . . . . . . . 74
5.6.1. Abstract Class TemplateRegistry . . . . . . . 74
5.6.2. Interface ServiceLocationAttributeVerifier . . 77
5.6.3. Interface ServiceLocationAttributeDescriptor . 79
5.7. Implementation Notes . . . . . . . . . . . . . . . . . 81
5.7.1. Refreshing Registrations . . . . . . . . . . . 81
5.7.2. Parsing Alternate Transports in ServiceURL . . 81
5.7.3. String Attribute Values . . . . . . . . . . . 82
5.7.4. Client Side Syntax Checking. . . . . . . . . . 82
5.7.5. Language Locale Handling . . . . . . . . . . . 82
5.7.6. Setting SLP System Properties. . . . . . . . . 83
5.7.7. Multithreading . . . . . . . . . . . . . . . . 83
5.7.8. Modular Implementations . . . . . . . . . . . 83
5.7.9. Asynchronous and Incremental Return Semantics. 84
5.8. Example. . . . . . . . . . . . . . . . . . . . . . . . 85
6. Internationalization Considerations 87
6.1. service URL. . . . . . . . . . . . . . . . . . . . . . 87
6.2. Character Set Encoding . . . . . . . . . . . . . . . . 87
6.3. Language Tagging . . . . . . . . . . . . . . . . . . 88
7. Security Considerations 88
8. Acknowledgements 88
9. References 89
10. Authors' Addresses 90
11. Full Copyright Statement 91
4.7.1. Refreshing Registrations . . . . . . . . . . . 49 4.7.2. Syntax for String Parameters . . . . . . . . . 49 4.7.3. Client Side Syntax Checking . . . . . . . . . 50 4.7.4. System Properties . . . . . . . . . . . . . . 50 4.7.5. Memory Management . . . . . . . . . . . . . . 51 4.7.6. Asynchronous and Incremental Return Semantics. 51 4.8. Example. . . . . . . . . . . . . . . . . . . . . . . . 52 5. Java Language Binding 56 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 56 5.2. Exceptions and Errors . . . . . . . . . . . . . . . . 56 5.2.1. Class ServiceLocationException . . . . . . . . 57 5.3. Basic Data Structures . . . . . . . . . . . . . . . . 58 5.3.1. Interface ServiceLocationEnumeration . . . . . 58 5.3.2. Class ServiceLocationAttribute . . . . . . . 58 5.3.3. Class ServiceType . . . . . . . . . . . . . . 61 5.3.4. Class ServiceURL . . . . . . . . . . . . . . 63 5.4. SLP Access Interfaces . . . . . . . . . . . . . . . . 67 5.4.1. Interface Advertiser . . . . . . . . . . . . . 67 5.4.2. Interface Locator . . . . . . . . . . . . . . 69 5.5. The Service Location Manager . . . . . . . . . . . . . 72 5.5.1. Class ServiceLocationManager . . . . . . . . . 72 5.6. Service Template Introspection . . . . . . . . . . . . 74 5.6.1. Abstract Class TemplateRegistry . . . . . . . 74 5.6.2. Interface ServiceLocationAttributeVerifier . . 77 5.6.3. Interface ServiceLocationAttributeDescriptor . 79 5.7. Implementation Notes . . . . . . . . . . . . . . . . . 81 5.7.1. Refreshing Registrations . . . . . . . . . . . 81 5.7.2. Parsing Alternate Transports in ServiceURL . . 81 5.7.3. String Attribute Values . . . . . . . . . . . 82 5.7.4. Client Side Syntax Checking. . . . . . . . . . 82 5.7.5. Language Locale Handling . . . . . . . . . . . 82 5.7.6. Setting SLP System Properties. . . . . . . . . 83 5.7.7. Multithreading . . . . . . . . . . . . . . . . 83 5.7.8. Modular Implementations . . . . . . . . . . . 83 5.7.9. Asynchronous and Incremental Return Semantics. 84 5.8. Example. . . . . . . . . . . . . . . . . . . . . . . . 85 6. Internationalization Considerations 87 6.1. service URL. . . . . . . . . . . . . . . . . . . . . . 87 6.2. Character Set Encoding . . . . . . . . . . . . . . . . 87 6.3. Language Tagging . . . . . . . . . . . . . . . . . . 88 7. Security Considerations 88 8. Acknowledgements 88 9. References 89 10. Authors' Addresses 90 11. Full Copyright Statement 91
Kempf & Guttman Informational [Page 3] RFC 2614 Service Location API June 1999
Kempf & Guttman Informational [Page 3] RFC 2614 Service Location API June 1999
1. Introduction
1. Introduction
The Service Location API is designed for standardized access to the Service Location Protocol (SLP). The APIs allow client and service programs to be be written or modified in a very simple manner to provide dynamic service discovery and selection. Bindings in the C and Java languages are defined in this document. In addition, standardized formats for configuration files and for serialized registration files are presented. These files allow SLP agents to configure network parameters, to register legacy services that have not been SLP enabled, and to portably exchange registration databases.
The Service Location API is designed for standardized access to the Service Location Protocol (SLP). The APIs allow client and service programs to be be written or modified in a very simple manner to provide dynamic service discovery and selection. Bindings in the C and Java languages are defined in this document. In addition, standardized formats for configuration files and for serialized registration files are presented. These files allow SLP agents to configure network parameters, to register legacy services that have not been SLP enabled, and to portably exchange registration databases.
1.1. Goals
1.1. Goals
The overall goal of the API is to enable source portability of applications that use the API between different implementations of SLP. The result should facilitate the adoption of SLP, and conversion of clients and service programs to SLP.
The overall goal of the API is to enable source portability of applications that use the API between different implementations of SLP. The result should facilitate the adoption of SLP, and conversion of clients and service programs to SLP.
The goals of the C binding are to create a minimal but complete access to the functionality of the SLP protocol, allowing for simple memory management and limited code size.
The goals of the C binding are to create a minimal but complete access to the functionality of the SLP protocol, allowing for simple memory management and limited code size.
The Java API provides for modular implementations (where unneeded features can be omitted) and an object oriented interface to the complete set of SLP data and functionality.
The Java API provides for modular implementations (where unneeded features can be omitted) and an object oriented interface to the complete set of SLP data and functionality.
The standardized configuration file and serialized file formats provide a simple syntax with complete functional coverage of the protocol, but without system dependent properties and secure information.
The standardized configuration file and serialized file formats provide a simple syntax with complete functional coverage of the protocol, but without system dependent properties and secure information.
1.2. Terminology
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
Service Location Protocol (SLP)
Service Location Protocol (SLP)
The underlying protocol allowing dynamic and scalable service
discovery. This protocol is specified in the Service Location
Protocol Version 2 [7].
The underlying protocol allowing dynamic and scalable service discovery. This protocol is specified in the Service Location Protocol Version 2 [7].
Kempf & Guttman Informational [Page 4] RFC 2614 Service Location API June 1999
Kempf & Guttman Informational [Page 4] RFC 2614 Service Location API June 1999
SLP framework
SLP framework
When a 'Service Location framework' is mentioned, it refers to
both the SLP implementation and interface implementation; i.e.
whatever provides the SLP functionality to user level programs.
This includes remote agents.
When a 'Service Location framework' is mentioned, it refers to both the SLP implementation and interface implementation; i.e. whatever provides the SLP functionality to user level programs. This includes remote agents.
Directory Agent (DA)
Directory Agent (DA)
A service that automatically gathers service advertisements
from SAs in order to provide them to UAs.
A service that automatically gathers service advertisements from SAs in order to provide them to UAs.
User Agent (UA)
User Agent (UA)
This is the Service Location process or library that allows SLP
requests to be made on behalf of a client process. UAs
automatically direct requests to DAs when they exist. In their
absence, UAs make requests to SAs.
This is the Service Location process or library that allows SLP requests to be made on behalf of a client process. UAs automatically direct requests to DAs when they exist. In their absence, UAs make requests to SAs.
Service Agent (SA)
Service Agent (SA)
This is the Service Location process or library that allows
service software to register and deregister itself with the SLP
framework. SAs respond to UA service requests, detect DAs and
register service advertisements with them.
This is the Service Location process or library that allows service software to register and deregister itself with the SLP framework. SAs respond to UA service requests, detect DAs and register service advertisements with them.
SA Server
SA Server
Many operating system platforms only allow a single process to
listen on a particular port number. Since SAs are required to
listen on a multicast address for SLP service requests,
implementations of the SLP framework on such platforms that
want to support multiple SAs on one machine need to arrange for
a single process to do the listening while the advertising SAs
communicate with that process through another mechanism. The
single listening process is called an SA server. SA servers
share many characteristics with DAs, but they are not the same.
Many operating system platforms only allow a single process to listen on a particular port number. Since SAs are required to listen on a multicast address for SLP service requests, implementations of the SLP framework on such platforms that want to support multiple SAs on one machine need to arrange for a single process to do the listening while the advertising SAs communicate with that process through another mechanism. The single listening process is called an SA server. SA servers share many characteristics with DAs, but they are not the same.
Service Advertisement
Service Advertisement
A URL possibly combined with service attributes. These are
made available to UAs by SAs, either directly or via a DA.
A URL possibly combined with service attributes. These are made available to UAs by SAs, either directly or via a DA.
Locale
Locale
The language localization that applies to strings passed into
or returned from the SLP API. The Locale is expressed using a
Language Tag [6]. All attribute strings are associated with a
The language localization that applies to strings passed into or returned from the SLP API. The Locale is expressed using a Language Tag [6]. All attribute strings are associated with a
Kempf & Guttman Informational [Page 5] RFC 2614 Service Location API June 1999
Kempf & Guttman Informational [Page 5] RFC 2614 Service Location API June 1999
particular locale. The locale is completely orthogonal to the
ANSI C locale. The SLP locale is mapped into the Java locale
in the Java API.
particular locale. The locale is completely orthogonal to the ANSI C locale. The SLP locale is mapped into the Java locale in the Java API.
Service Template
Service Template
A document that describes the syntax of the URL for a given
service type and a definition of all service attributes
including the meaning, defaults, and constraints on values the
attributes may take. See [8] for more information on service
templates.
A document that describes the syntax of the URL for a given service type and a definition of all service attributes including the meaning, defaults, and constraints on values the attributes may take. See [8] for more information on service templates.
The service: URL
The service: URL
A service of a particular type announces its availability with
a service: URL that includes its service access point (domain
name or IP address, and possibly its port number) and
optionally basic configuration parameters. The syntax of the
service: URL is defined in the service template. Other URL's
can be used in service advertisements if desired.
A service of a particular type announces its availability with a service: URL that includes its service access point (domain name or IP address, and possibly its port number) and optionally basic configuration parameters. The syntax of the service: URL is defined in the service template. Other URL's can be used in service advertisements if desired.
Service Attributes
Service Attributes
The attributes associated with a given service. The values
that can be assigned to service attributes are defined by the
service template.
The attributes associated with a given service. The values that can be assigned to service attributes are defined by the service template.
Scope
Scope
A string used to control the availability of service
advertisements. Every SLP Agent is configured with one or more
scope strings. Scopes are assigned by site administrators to
group services for many purposes, but chiefly as a means of
scalability. DAs store only services advertised having a scope
string matching the scopes with which they are configured.
A string used to control the availability of service advertisements. Every SLP Agent is configured with one or more scope strings. Scopes are assigned by site administrators to group services for many purposes, but chiefly as a means of scalability. DAs store only services advertised having a scope string matching the scopes with which they are configured.
Naming Authority (NA)
Naming Authority (NA)
This is a 'suffix' to the service type string. It completely
changes the meaning of the service type. NAs are used for
private definitions of well known Service Types and
experimental Service Type extensions. The default NA is
"IANA", which must not be explicitly included. Service types
with the IANA naming authority are registered with the Internet
Assigned Numbers Authority (see [8] for more information on the
registration procedure).
This is a 'suffix' to the service type string. It completely changes the meaning of the service type. NAs are used for private definitions of well known Service Types and experimental Service Type extensions. The default NA is "IANA", which must not be explicitly included. Service types with the IANA naming authority are registered with the Internet Assigned Numbers Authority (see [8] for more information on the registration procedure).
Kempf & Guttman Informational [Page 6] RFC 2614 Service Location API June 1999
Kempf & Guttman Informational [Page 6] RFC 2614 Service Location API June 1999
2. File Formats
2. File Formats
This section describes the configuration and serialized registration file formats. Both files are defined in the UTF-8 character set [3].
This section describes the configuration and serialized registration file formats. Both files are defined in the UTF-8 character set [3].
Attribute tags and values in the serialized registration file require
SLP reserved characters to be escaped. The SLP reserved characters
are `(', `)', `,', `\', `!', `<', `=', `>', `~' and control
characters (characters with UTF codes less than 0x0020 and the
character 0x007f, which is US-ASCII DEL). The escapes are formed
exactly as for the wire protocol, i.e. a backslash followed by two
hex digits representing the character. For example, the escape for '
,' is '\2c'. In addition, the characters `\n', `\r', `\t', and `_'
are prohibited from attribute tags by the SLP wire syntax grammar.
[7]
Attribute tags and values in the serialized registration file require SLP reserved characters to be escaped. The SLP reserved characters are `(', `)', `,', `\', `!', `<', `=', `>', `~' and control characters (characters with UTF codes less than 0x0020 and the character 0x007f, which is US-ASCII DEL). The escapes are formed exactly as for the wire protocol, i.e. a backslash followed by two hex digits representing the character. For example, the escape for ' ,' is '\2c'. In addition, the characters `\n', `\r', `\t', and `_' are prohibited from attribute tags by the SLP wire syntax grammar. [7]
In serialized registration files, escaped strings beginning with `\ff`, an encoding for a nonUTF-8 character, are treated as opaques. Exactly as in the wire protocol, syntactically correct opaque encodings consist of a string beginning with `\ff` and containing *only* escaped characters that are transformed to bytes. Such strings are only syntactically correct in the serialized registration file as attribute values. In other cases, whenever an escape is encountered and the character is not an SLP reserved character, an error is signaled.
In serialized registration files, escaped strings beginning with `\ff`, an encoding for a nonUTF-8 character, are treated as opaques. Exactly as in the wire protocol, syntactically correct opaque encodings consist of a string beginning with `\ff` and containing *only* escaped characters that are transformed to bytes. Such strings are only syntactically correct in the serialized registration file as attribute values. In other cases, whenever an escape is encountered and the character is not an SLP reserved character, an error is signaled.
Escaped characters in URLs in serialized registration files use the URL escape convention. [2].
Escaped characters in URLs in serialized registration files use the URL escape convention. [2].
Property names and values in the configuration file have a few
reserved characters that are involved in file's lexical definition.
The characters '.' and '=' are reserved in property names and must
be escape. The characters ',', '(', and ')' are reserved in property
values and must be escaped. In addition, scope names in the
net.slp.useScopes property use the SLP wire format escape convention
for SLP reserved characters. This simplifies implementation, since
the same code can be used to unescape scope names as is used in
processing the serialized registration file or for formatting wire
messages.
Property names and values in the configuration file have a few reserved characters that are involved in file's lexical definition. The characters '.' and '=' are reserved in property names and must be escape. The characters ',', '(', and ')' are reserved in property values and must be escaped. In addition, scope names in the net.slp.useScopes property use the SLP wire format escape convention for SLP reserved characters. This simplifies implementation, since the same code can be used to unescape scope names as is used in processing the serialized registration file or for formatting wire messages.
On platforms that only support US-ASCII and not UTF-8, the upper bit of bytes incoming from the configuration and registration files determines whether the character is US-ASCII or not US-ASCII. According to the standard UTF-8 encoding, the upper bit is zero if the character is US-ASCII and one if the character is multibyte and thus not US-ASCII. Platforms without intrinsic UTF-8 support are required to parse the multibyte character and store it in an appropriate internal format. Support for UTF-8 is required to
On platforms that only support US-ASCII and not UTF-8, the upper bit of bytes incoming from the configuration and registration files determines whether the character is US-ASCII or not US-ASCII. According to the standard UTF-8 encoding, the upper bit is zero if the character is US-ASCII and one if the character is multibyte and thus not US-ASCII. Platforms without intrinsic UTF-8 support are required to parse the multibyte character and store it in an appropriate internal format. Support for UTF-8 is required to
Kempf & Guttman Informational [Page 7] RFC 2614 Service Location API June 1999
Kempf & Guttman Informational [Page 7] RFC 2614 Service Location API June 1999
implement the SLP protocol (see [7]), and can therefore be used in file processing as well.
implement the SLP protocol (see [7]), and can therefore be used in file processing as well.
The location and name of the configuration file is system-dependent, but implementations of the API are encouraged to locate it together with other configuration files and name it consistently.
The location and name of the configuration file is system-dependent, but implementations of the API are encouraged to locate it together with other configuration files and name it consistently.
2.1. Configuration File Format
2.1. Configuration File Format
The configuration file format consists of a newline delimited list of zero or more property definitions. Each property definition corresponds to a particular configurable SLP, network, or other parameter in one or more of the three SLP agents. The file format grammar in ABNF [5] syntax is:
The configuration file format consists of a newline delimited list of zero or more property definitions. Each property definition corresponds to a particular configurable SLP, network, or other parameter in one or more of the three SLP agents. The file format grammar in ABNF [5] syntax is:
config-file = line-list
line-list = line / line line-list
line = property-line / comment-line
comment-line = ( "#" / ";" ) 1*allchar newline
property-line = property newline
property = tag "=" value-list
tag = prop / prop "." tag
prop = 1*tagchar
value-list = value / value "," value-list
value = int / bool /
"(" value-list ")" / string
int = 1*DIGIT
bool = "true" / "false" / "TRUE" / "FALSE"
newline = CR / ( CRLF )
string = 1*stringchar
tagchar = DIGIT / ALPHA / tother / escape
tother = %x21-%x2d / %x2f /
%x3a / %x3c-%x40 /
%x5b-%x60 / %7b-%7e
; i.e., all characters except `.',
; and `='.
stringchar = DIGIT / ALPHA / sother / escape
sother = %x21-%x29 / %x2a-%x2b /
%x2d-%x2f / %x3a-%x40 /
%x5b-%x60 / %7b-%7e
; i.e., all characters except `,'
allchar = DIGIT / ALPHA / HTAB / SP
escape = "\" HEXDIG HEXDIG
; Used for reserved characters
config-file = line-list line-list = line / line line-list line = property-line / comment-line comment-line = ( "#" / ";" ) 1*allchar newline property-line = property newline property = tag "=" value-list tag = prop / prop "." tag prop = 1*tagchar value-list = value / value "," value-list value = int / bool / "(" value-list ")" / string int = 1*DIGIT bool = "true" / "false" / "TRUE" / "FALSE" newline = CR / ( CRLF ) string = 1*stringchar tagchar = DIGIT / ALPHA / tother / escape tother = %x21-%x2d / %x2f / %x3a / %x3c-%x40 / %x5b-%x60 / %7b-%7e ; i.e., all characters except `.', ; and `='. stringchar = DIGIT / ALPHA / sother / escape sother = %x21-%x29 / %x2a-%x2b / %x2d-%x2f / %x3a-%x40 / %x5b-%x60 / %7b-%7e ; i.e., all characters except `,' allchar = DIGIT / ALPHA / HTAB / SP escape = "\" HEXDIG HEXDIG ; Used for reserved characters
With the exception of net.slp.useScopes, net.slp.DAAddresses, and net.slp.isBroadcastOnly, all other properties can be changed through property accessors in the C and Java APIs. The property accessors
With the exception of net.slp.useScopes, net.slp.DAAddresses, and net.slp.isBroadcastOnly, all other properties can be changed through property accessors in the C and Java APIs. The property accessors
Kempf & Guttman Informational [Page 8] RFC 2614 Service Location API June 1999
Kempf & Guttman Informational [Page 8] RFC 2614 Service Location API June 1999
only change the property values in the running agent program and do not affect the values in the configuration file. The net.slp.useScopes and net.slp.DAAddresses properties are read-only because they control the agent's view of the scopes and DAs and are therefore critical to the function of the API scope discovery algorithm. Attempts to modify them are unlikely to yield productive results, and could harm the ability of the agent to find scopes and use DAs. The net.slp.isBroadcastOnly property is read-only because the API library needs to configure networking upon start up and changing this property might invalidate the configuration. Whether the local network uses broadcast or multicast is not likely to change during the course of the program's execution.
only change the property values in the running agent program and do not affect the values in the configuration file. The net.slp.useScopes and net.slp.DAAddresses properties are read-only because they control the agent's view of the scopes and DAs and are therefore critical to the function of the API scope discovery algorithm. Attempts to modify them are unlikely to yield productive results, and could harm the ability of the agent to find scopes and use DAs. The net.slp.isBroadcastOnly property is read-only because the API library needs to configure networking upon start up and changing this property might invalidate the configuration. Whether the local network uses broadcast or multicast is not likely to change during the course of the program's execution.
The properties break down into the following subsections describes an area and its properties.
The properties break down into the following subsections describes an area and its properties.
2.1.1. DA configuration
2.1.1. DA configuration
Important configuration properties for DAs are included in this section. These are:
Important configuration properties for DAs are included in this section. These are:
net.slp.isDA
net.slp.isDA
A boolean indicating if the SLP server is to act as a DA. If
false, not run as a DA. Default is false.
A boolean indicating if the SLP server is to act as a DA. If false, not run as a DA. Default is false.
net.slp.DAHeartBeat
net.slp.DAHeartBeat
A 32 bit integer giving the number of seconds for the
DA heartbeat. Default is 3 hours (10800 seconds). This
property corresponds to the protocol specification parameter
CONFIG_DA_BEAT [7]. Ignored if isDA is false.
A 32 bit integer giving the number of seconds for the DA heartbeat. Default is 3 hours (10800 seconds). This property corresponds to the protocol specification parameter CONFIG_DA_BEAT [7]. Ignored if isDA is false.
net.slp.DAAttributes
net.slp.DAAttributes
A comma-separated list of parenthesized attribute/value list
pairs that the DA must advertise in DAAdverts. The property
must be in the SLP attribute list wire format, including
escapes for reserved characters. [7]
A comma-separated list of parenthesized attribute/value list pairs that the DA must advertise in DAAdverts. The property must be in the SLP attribute list wire format, including escapes for reserved characters. [7]
2.1.2. Static Scope Configuration
2.1.2. Static Scope Configuration
These properties allow various aspects of scope handling to be configured.
These properties allow various aspects of scope handling to be configured.
Kempf & Guttman Informational [Page 9] RFC 2614 Service Location API June 1999
Kempf & Guttman Informational [Page 9] RFC 2614 Service Location API June 1999
net.slp.useScopes
net.slp.useScopes
A value-list of strings indicating the only scopes a UA or SA
is allowed to use when making requests or registering, or the
scopes a DA must support. If not present for the DA and SA,
then in the absence of scope information from DHCP, the default
scope "DEFAULT" is used. If not present for the UA, and there
is no scope information available from DHCP, then the user
scoping model is in force. Active and passive DA discovery
or SA discovery are used for scope discovery, and the scope
"DEFAULT" is used if no other information is available. If a
DA or SA gets another scope in a request, a SCOPE_NOT_SUPPORTED
error should be returned, unless the request was multicast, in
which case it should be dropped. If a DA gets another scope in
a registration, a SCOPE_NOT_SUPPORTED error must be returned.
Unlike other properties, this property is "read-only", so
attempts to change it after the configuration file has been
read are ignored. See Section 3.12 for the algorithm the API
uses in determining what scope information to present.
A value-list of strings indicating the only scopes a UA or SA is allowed to use when making requests or registering, or the scopes a DA must support. If not present for the DA and SA, then in the absence of scope information from DHCP, the default scope "DEFAULT" is used. If not present for the UA, and there is no scope information available from DHCP, then the user scoping model is in force. Active and passive DA discovery or SA discovery are used for scope discovery, and the scope "DEFAULT" is used if no other information is available. If a DA or SA gets another scope in a request, a SCOPE_NOT_SUPPORTED error should be returned, unless the request was multicast, in which case it should be dropped. If a DA gets another scope in a registration, a SCOPE_NOT_SUPPORTED error must be returned. Unlike other properties, this property is "read-only", so attempts to change it after the configuration file has been read are ignored. See Section 3.12 for the algorithm the API uses in determining what scope information to present.
net.slp.DAAddresses
net.slp.DAAddresses
A value-list of IP addresses or DNS resolvable host names
giving the SLPv2 DAs to use for statically configured UAs and
SAs. Ignored by DAs (unless the DA is also an SA server).
Default is none. Unlike other properties, this property is
"read-only", so attempts to change it after the configuration
file has been read are ignored.
IPアドレスかDNSの溶解性のホストの値リストは静的に構成されたUAsの使用へのSLPv2 DAsに与えて、SAsを命名します。 DAs(また、DAがSAサーバでないなら)によって無視されます。 デフォルトはなしです。 他の特性と異なった、この特性が「書き込み禁止」であるので、構成ファイルを読んである後にそれを変える試みは無視されます。
The following grammar describes the property:
以下の文法は特性について説明します:
addr-list = addr / addr "," addr-list
addr = fqdn / hostnumber
fqdn = ALPHA / ALPHA *[ anum / "-" ] anum
anum = ALPHA / DIGIT
hostnumber = 1*3DIGIT 3("." 1*3DIGIT)
アルファ/ケタアルファ/アルファ*[anum/「-」]「addr-リスト=addr / addr」、」 addr-リストaddr=fqdn / hostnumber fqdn=anum anum=hostnumberは1*3DIGIT3と等しいです。(「. 」 1*3DIGIT、)
An example is:
例は以下の通りです。
sawah,mandi,sambal
sawah、mandi、sambal
IP addresses can be used instead of host names in networks
where DNS is not deployed, but network administrators are
reminded that using IP addresses will complicate machine
DNSが配布されませんが、ネットワーク管理者がIPアドレスを使用するとマシンが複雑にされるのを思い出させられているネットワークにおけるホスト名の代わりにIPアドレスを使用できます。
Kempf & Guttman Informational [Page 10] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[10ページ]のRFC2614はAPI1999年6月に位置を修理します。
renumbering, since the SLP configuration property files
in statically configured networks will have to be changed.
Similarly, if host names are used, implementors must be careful
that a name service is available before SLP starts, in other
words, SLP cannot be used to find the name service.
SLP構成の特性が静的に列を作って繰り込むので番号を付け替えるのは、ネットワークが変えられなければならないのを構成しました。 ホスト名が使用されているなら、同様に、作成者がSLPが始まる前に名前サービスが利用可能であるのに慎重でなければならない、言い換えれば、サービスという名前を見つけるのにSLPを使用できません。
2.1.3. Tracing and Logging
2.1.3. たどるのと伐採
This section allows tracing and logging information to be printed by the various agents.
様々なエージェントによって印刷されるように、このセクションは、情報をたどって、登録させます。
net.slp.traceDATraffic
net.slp.traceDATraffic
A boolean controlling printing of messages about traffic with
DAs. Default is false.
DAsと共にトラフィックに関するメッセージの印刷を制御する論理演算子。 デフォルトは誤っています。
net.slp.traceMsg
net.slp.traceMsg
A boolean controlling printing of details on SLP messages.
The fields in all incoming messages and outgoing replies are
printed. Default is false.
SLPメッセージに関する詳細の印刷を制御する論理演算子。 すべての入力メッセージと外向的な回答における分野は印刷されます。 デフォルトは誤っています。
net.slp.traceDrop
net.slp.traceDrop
A boolean controlling printing details when a SLP message is
dropped for any reason. Default is false.
印刷を制御する論理演算子は、SLPメッセージがいつ何か理由で下げられるかを詳しく述べます。 デフォルトは誤っています。
net.slp.traceReg
net.slp.traceReg
A boolean controlling dumps of all registered services upon
registration and deregistration. If true, the contents
of the DA or SA server are dumped after a registration or
deregistration occurs. Default is false.
すべての憂鬱を制御する論理演算子は登録と反登録にサービスを登録しました。 本当に、DAかSAサーバの内容が登録の後にどさっと落とされるか、そして、反登録が現れます。 デフォルトは誤っています。
2.1.4. Serialized Proxy Registrations
2.1.4. 連載されたプロキシ登録証明書
These properties control the reading and writing of serialized registrations.
これらの特性は連載された登録証明書の読み書きを制御します。
net.slp.serializedRegURL
net.slp.serializedRegURL
A string containing a URL pointing to a document containing
serialized registrations that should be processed when the DA
or SA server starts up. Default is none.
ドキュメント含有を示すURLを含む五弦がDAかSAサーバが始動するとき処理されるべきである登録証明書を連載しました。 デフォルトはなしです。
Kempf & Guttman Informational [Page 11] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[11ページ]のRFC2614はAPI1999年6月に位置を修理します。
2.1.5. Network Configuration Properties
2.1.5. ネットワーク・コンフィギュレーションの特性
The properties in this section allow various network configuration properties to be set.
このセクションの特性は、様々なネットワーク・コンフィギュレーションの特性が設定されるのを許容します。
net.slp.isBroadcastOnly
net.slp.isBroadcastOnly
A boolean indicating if broadcast should be used instead of
multicast. Like the net.slp.useScopes and net.slp.DAAddresses
properties, this property is "read-only", so attempts to change
it after the configuration file has been read are ignored.
Default is false.
放送がマルチキャストの代わりに使用されるべきであるかどうかを示す論理演算子。 net.slp.useScopesとnet.slp.DAAddressesの特性のように、この特性が「書き込み禁止」であるので、構成ファイルを読んである後にそれを変える試みは無視されます。 デフォルトは誤っています。
net.slp.passiveDADetection
net.slp.passiveDADetection
A boolean indicating whether passive DA detection should be
used. Default is true.
受け身のDA検出が使用されるべきであるかどうかを示す論理演算子。 デフォルトは本当です。
net.slp.multicastTTL
net.slp.multicastTTL
A positive integer less than or equal to 255, giving the
multicast TTL. Default is 255.
マルチキャストTTLに与える255以下の正の整数。 デフォルトは255です。
net.slp.DAActiveDiscoveryInterval
net.slp.DAActiveDiscoveryInterval
A 16 bit positive integer giving the number of seconds
between DA active discovery queries. Default is 900 seconds
(15 minutes). This property corresponds to the protocol
specification parameter CONFIG_DA_FIND [7]. If the property is
set to zero, active discovery is turned off. This is useful
when the DAs available are explicitly restricted to those
obtained from DHCP or the net.slp.DAAddresses property.
DAの活発な発見質問の間の秒数を与える16ビットの正の整数。 デフォルトは900秒(15分)です。 この特性はプロトコル仕様パラメタCONFIG_DA_FIND[7]に対応しています。 特性がゼロに設定されるなら、活発な発見はオフにされます。 利用可能なDAsが明らかにDHCPかnet.slp.DAAddressesの特性から得られたものに制限されるとき、これは役に立ちます。
net.slp.multicastMaximumWait
net.slp.multicastMaximumWait
A 32 bit integer giving the maximum amount of time to perform
multicast, in milliseconds. Default is 15000 ms (15 sec.).
This property corresponds to the CONFIG_MC_MAX parameter in the
protocol specification [7].
ミリセカンドでマルチキャストを実行する最大の時間を与える32ビットの整数。 デフォルトは15000ms(15秒)です。 この特性はプロトコル仕様[7]による_MAXパラメタCONFIG_M.C.に対応しています。
net.slp.multicastTimeouts
net.slp.multicastTimeouts
A value-list of 32 bit integers used as timeouts, in
milliseconds, to implement the multicast convergence
algorithm. Each value specifies the time to wait before
sending the next request, or until nothing new has
been learned from two successive requests. Default
is: 3000,3000,3000,3000,3000. In a fast network the
マルチキャスト集合アルゴリズムを実装するのにタイムアウトとしてミリセカンドで使用される32ビットの整数の値リスト。 各値は次の要求を送る前か新しいものは何も2つの連続した要求から学習されていないことまで待つ時間を指定します。 デフォルトは以下の通りです。 3000,3000,3000,3000,3000. 速いネットワーク
Kempf & Guttman Informational [Page 12] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[12ページ]のRFC2614はAPI1999年6月に位置を修理します。
aggressive values of 1000,1250,1500,2000,4000 allow better
performance. This property corresponds to the CONFIG_MC_RETRY
parameter in the protocol specification [7]. Note that the
net.slp.DADiscoveryTimeouts property must be used for active DA
discovery.
2000、4000 1500、年の1250、1000、攻撃的な値は、より良い性能を許容します。 この特性はプロトコル仕様[7]による_RETRYパラメタCONFIG_M.C.に対応しています。 活発なDA発見にnet.slp.DADiscoveryTimeoutsの特性を使用しなければならないことに注意してください。
net.slp.DADiscoveryTimeouts
net.slp.DADiscoveryTimeouts
A value-list of 32 bit integers used as timeouts, in
milliseconds, to implement the multicast convergence algorithm
during active DA discovery. Each value specifies the time
to wait before sending the next request, or until nothing
new has been learned from two successive requests. This
property corresponds to the protocol specification parameter
CONFIG_RETRY [7]. Default is: 2000,2000,2000,2000,3000,4000.
活発なDA発見の間、マルチキャスト集合アルゴリズムを実装するのにタイムアウトとしてミリセカンドで使用される32ビットの整数の値リスト。 各値は次の要求を送る前か新しいものは何も2つの連続した要求から学習されていないことまで待つ時間を指定します。 この特性はプロトコル仕様パラメタCONFIG_RETRY[7]に対応しています。 デフォルトは以下の通りです。 2000,2000,2000,2000,3000,4000.
net.slp.datagramTimeouts
net.slp.datagramTimeouts
A value-list of 32 bit integers used as timeouts, in
milliseconds, to implement unicast datagram transmission to
DAs. The nth value gives the time to block waiting for a reply
on the nth try to contact the DA. The sum of these values is
the protocol specification property CONFIG_RETRY_MAX [7].
ユニキャストデータグラム送信をDAsに実装するのにタイムアウトとしてミリセカンドで使用される32ビットの整数の値リスト。 n番目の値はn番目で回答の待ちを妨げるのがDAに連絡しようとする時を与えます。 これらの値の合計はプロトコル仕様特性のCONFIG_RETRY_MAX[7]です。
net.slp.randomWaitBound
net.slp.randomWaitBound
A 32 bit integer giving the maximum value for all random
wait parameters, in milliseconds. Default is 1000 (1
sec.). This value corresponds to the protocol specification
parameters CONFIG_START_WAIT, CONFIG_REG_PASSIVE, and
CONFIG_REG_ACTIVE [7].
すべての無作為の待ちパラメタのためにミリセカンドで最大値を与える32ビットの整数。 デフォルトは1000(1秒)です。 この値はプロトコル仕様パラメタのCONFIG_START_WAIT、CONFIG_レッジ_PASSIVE、およびCONFIG_レッジ_ACTIVE[7]に対応しています。
net.slp.MTU
net.slp.MTU
A 16 bit integer giving the network packet MTU, in bytes.
This is the maximum size of any datagram to send, but the
implementation might receive a larger datagram. The maximum
size includes IP, and UDP or TCP headers. Default is 1400.
バイトでネットワークパケットMTUに与える16ビットの整数。 これは送るどんなデータグラムの最大サイズですがも、実装は、より大きいデータグラムを受けるかもしれません。 最大サイズはIPと、UDPかTCPヘッダーを含んでいます。 デフォルトは1400です。
net.slp.interfaces
net.slp.interfaces
Value-list of strings giving the IP addresses of network
interfaces on which the DA or SA should listen on port 427 for
multicast, unicast UDP, and TCP messages. Default is empty,
i.e. use the default network interface. The grammar for this
property is:
DAかSAがマルチキャスト、ユニキャストUDP、およびTCPメッセージのためにポート427の上で聴くはずであるネットワークのIPアドレスを与えるストリングの値リストは連結します。 デフォルトは空であり、すなわち、使用はデフォルトネットワーク・インターフェースです。 この特性のための文法は以下の通りです。
Kempf & Guttman Informational [Page 13] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[13ページ]のRFC2614はAPI1999年6月に位置を修理します。
addr-list = hostnumber / hostnumber "," addr-list
hostnumber = 1*3DIGIT 3("." 1*3DIGIT)
」 「addr-リスト=hostnumber / hostnumber」、addr-リストhostnumber=1*3DIGIT3(「. 」 1*3DIGIT、)
An example is:
例は以下の通りです。
195.42.42.42,195.42.142.1,195.42.120.1
195.42.42.42,195.42.142.1,195.42.120.1
The example machine has three interfaces on which the DA should
listen.
例のマシンには、DAが聴くはずである3つのインタフェースがあります。
Note that since this property only takes IP addresses, it will
need to be changed if the network is renumbered.
ネットワークが番号を付け替えられるとこの特性がIPアドレスを取るだけであるので変えられるのが必要であることに注意してください。
2.1.6. SA Configuration
2.1.6. SA構成
This section contains configuration properties for the SA. These properties are typically set programmatically by the SA, since they are specific to each SA.
このセクションはSAのための構成の特性を含みます。 それらが各SAに特定であるので、これらの特性はSAによってプログラムに基づいて通常設定されます。
net.slp.SAAttributes
net.slp.SAAttributes
A comma-separated list of parenthesized attribute/value list
pairs that the SA must advertise in SAAdverts. The property
must be in the SLP attribute list wire format, including
escapes for reserved characters. [7]
SAがSAAdvertsに広告を出さなければならないparenthesized属性/値のリスト組のコンマで切り離されたリスト。 控え目なキャラクタのためのエスケープを含むSLP属性リストワイヤ形式には特性があるに違いありません。 [7]
2.1.7. UA Configuration
2.1.7. UA構成
This section contains configuration properties for the UA. These properties can be set either programmatically by the UA or in the configuration file.
このセクションはUAのための構成の特性を含みます。 UAの近く、または、構成ファイルにプログラムに基づいてこれらの特性を設定できます。
net.slp.locale
net.slp.locale
A RFC 1766 Language Tag [6] for the language locale. Setting
this property causes the property value to become the default
locale for SLP messages. Default is "en". This property is
also used for SA and DA configuration.
言語現場へのRFC1766Language Tag[6]。 この特性を設定することによって、資産価値はSLPメッセージのためのデフォルト現場になります。 デフォルトは「アン」です。 また、この特性はSAとDA構成に使用されます。
net.slp.maxResults
net.slp.maxResults
A 32 bit integer giving the maximum number of results to
accumulate and return for a synchronous request before the
timeout, or the maximum number of results to return through a
callback if the request results are reported asynchronously.
要求結果が非同期に報告されるなら、32は、コールバックを通して戻るためにタイムアウトの前に同期要求のために蓄積して、返す結果の最大数、または結果の最大数を与えながら、整数に噛み付きました。
Kempf & Guttman Informational [Page 14] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[14ページ]のRFC2614はAPI1999年6月に位置を修理します。
Positive integers and -1 are legal values. If -1, indicates
that all results should be returned. Default value is -1.
正の整数と-1は正当な値です。 -1であるなら示す、すべての結果が返されるべきであるのを示します。 デフォルト値は-1です。
DAs and SAs always return all results that match the
request. This configuration value applies only to UAs, that
filter incoming results and only return as many values as
net.slp.maxResults indicates.
DAsとSAsはいつも要求に合っているすべての結果を返します。 この構成値がUAsだけに適用されて、そのフィルタが入って来る結果であり、唯一のリターンはnet.slp.maxResultsが示すのと同じくらい多くの値です。
net.slp.typeHint
net.slp.typeHint
A value-list of service type names. In the absence of any
DAs, UAs perform SA discovery for finding scopes. These SA
discovery requests may contain a request for service types as
an attribute.
サービス型名の値リスト。 どんなDAsが不在のとき、UAsは範囲を見つけるためのSA発見を実行します。 これらのSA発見要求は属性としてサービスタイプを求める要求を含むかもしれません。
The API implementation will use the service type names supplied
by this property to discover only those SAs (and their scopes)
which support the desired service type or types. For example,
if net.slp.typeHint is set to "service:imap,service:pop3" then
SA discovery requests will include the search filter:
API実行はこの特性によって供給された、必要なサービスタイプかタイプをサポートするそれらのSAs(そして、彼らの範囲)だけを発見したサービス型名を使用するでしょう。 例えば、net.slp.typeHintがそうなら、「サービス: imap、サービス: pop3"の当時のSA発見要求は検索フィルタを含むこと」にセットしてください。
(|(service-type=service:imap)(service-type=service:pop3))
(| (サービスタイプ=サービス: imap)(サービスタイプ=サービス: pop3))
The API library can also use unicast to contact the discovered
SAs for subsequent requests for these service types, to
optimize network access.
また、APIライブラリは、これらのサービスタイプを求めるその後の要求のために発見されたSAsに連絡して、ネットワークアクセサリーを最適化するのにユニキャストを使用できます。
2.1.8. Security
2.1.8. セキュリティ
The property in this section allows security for all agents to be set on or off. When the property is true, then the agent must include security information on all SLP messages transacted by that agent. Since security policy must be set network wide to be effective, a single property controls security for all agents. Key management and management of SLP SPI strings [7] are implementation and policy dependent.
このセクションの特性は、すべてのエージェントがオンかオフに用意ができるためにセキュリティを許容します。 特性が本当であると、エージェントはそのエージェントによって商取引されたすべてのSLPメッセージのセキュリティ情報を入れなければなりません。 安全保障政策が有効になるように広いセットネットワークであるに違いないので、ただ一つの特性はすべてのエージェントのためにセキュリティを制御します。 SLP SPIストリング[7]のかぎ管理と管理は実装と方針に依存しています。
net.slp.securityEnabled
net.slp.securityEnabled
A boolean indicating whether the agent should enable
security for URLs, attribute lists, DAAdverts, and SAAdverts.
Each agent is responsible for interpreting the property
appropriately. Default is false.
論理演算子が、エージェントがURLのためにセキュリティを可能にするべきであるかどうかを示して、リスト、DAAdverts、およびSAAdvertsを結果と考えてください。 それぞれのエージェントは適切に特性を解釈するのに責任があります。 デフォルトは誤っています。
Kempf & Guttman Informational [Page 15] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[15ページ]のRFC2614はAPI1999年6月に位置を修理します。
2.2. Multihomed Machines
2.2. マシンをMultihomedしました。
On multihomed machines, the bandwidth and latency characteristics on different network interfaces may differ considerably, to the point where different configuration properties are necessary to achieve optimal performance. The net.slp.interfaces property indicates which network interfaces are SLP enabled. An API library implementation may support configuration customization on a per network interface basis by allowing the interface IP address to be appended to the property name. In that case, the values of the property are only used for that particular interface, the generic property (or defaults if no generic property is set) applies to all others.
「マルチ-家へ帰」っているマシンの上では、異なったネットワーク・インターフェースの帯域幅と潜在の特性はかなり異なるかもしれません、異なった構成の特性が最適の性能を達成するのに必要であるポイントに。 net.slp.interfacesの特性は、どのネットワーク・インターフェースが有効にされたSLPであるかを示します。 インタフェースIPアドレスが特性の名に追加されるのを許容することによって、APIライブラリ実装はネットワーク・インターフェース基礎あたりのaで構成改造をサポートするかもしれません。 その場合、特性の値はその特定のインタフェース(特性(または、ジェネリックの特性が全く設定されないなら、デフォルトとする)がすべての他のものに適用するジェネリック)に使用されるだけです。
For example, if a configuration has the following properties:
構成に以下の特性が例えばあるなら:
net.slp.interfaces=125.196.42.41,125.196.42.42,125.196.42.43
net.slp.multicastTTL.125.196.42.42=1
net.slp.interfacesが等しい、125.196 .42 .41 125.196 .42 .42、125.196、.42、.43net.slp.multicastTTL.125.196.42.42=1
then the network interface on subnet 42 is restricted to a TTL of 1, while the interfaces on the other subnets have the default multicast radius, 255.
次に、サブネット42のネットワーク・インターフェースは1のTTLに制限されます、他のサブネットのインタフェースには、デフォルトマルチキャスト半径、255がありますが。
The net.slp.interfaces property must only be set if there is no routing between the interfaces. If the property is set, the DA (if any) and SAs should advertise with the IP address or host name appropriate to the interface on the interfaces in the list. If packets are routed between the interfaces, then the DA and SAs should only advertise on the default interface. The property should also be set if broadcast is used rather than multicast on the subnets connected to the interfaces. Note that even if unicast packets are not routed between the interfaces, multicast may be routed through another router. The danger in listening for multicast on multiple interfaces when multicast packets are routed is that the DA or SA may receive the same multicast request via more than one interface. Since the IP address is different on each interface, the DA or SA cannot identify the request as having already being answered via the previous responder's list. The requesting agent will end up getting URLs that refer to the same DA or service but have different addresses or host names.
インタフェースの間で掘ってはいけなければ、net.slp.interfacesの特性を設定するだけでよいです。 特性が設定されるなら、DA(もしあれば)とSAsはリストのインタフェースのインタフェースに適切なIPアドレスかホスト名で広告を出すはずです。 パケットがインタフェースの間に発送されるなら、DAとSAsはデフォルトインタフェースに広告を出すだけであるはずです。 また、放送がインタフェースに接続されたサブネットでマルチキャストよりむしろ使用されるなら、特性は設定されるべきです。 ユニキャストパケットがインタフェースの間に発送されないでも、マルチキャストが別のルータを通して発送されるかもしれないことに注意してください。 マルチキャストパケットが発送されるとき複数のインタフェースでマルチキャストの聞こうとすることにおける危険はDAかSAが1つ以上のインタフェースを通して同じマルチキャスト要求を受け取るかもしれないということです。 IPアドレスが各インタフェースで異なっているので、DAかSAが、要求が前の応答者のリストで既に答えたことにされるのであると認識できません。 要求しているエージェントは結局、同じDAかサービスについて言及しますが、異なったアドレスかホスト名を持っているURLを得るでしょう。
2.3. Serialized Registration File
2.3. 連載された登録ファイル
The serialized registration file contains a group of registrations that a DA or SA server (if one exists) registers when it starts up. These registrations are primarily for older service programs that do not internally support SLP and cannot be converted, and for portably
始動するとき、連載された登録ファイルはDAかSAサーバ(1つが存在しているなら)が登録する登録証明書のグループを含みます。 これらの登録証明書は、主として内部的にSLPをサポートしないより古いサービス・プログラムのためにあって、変換される、およびportablyのためのものであるはずがありません。
Kempf & Guttman Informational [Page 16] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[16ページ]のRFC2614はAPI1999年6月に位置を修理します。
exchanging registrations between SLP implementations. The character encoding of the registrations is required to be UTF-8.
SLP実装の間で登録証明書を交換します。 登録証明書の文字符号化が、UTF-8になるのに必要です。
The syntax of the serialized registration file, in ABNF format [5], is as follows:
ABNF形式[5]では、連載された登録ファイルの構文は以下の通りです:
ser-file = reg-list
reg-list = reg / reg reg-list
reg = creg / ser-reg
creg = comment-line ser-reg
comment-line = ( "#" / ";" ) 1*allchar newline
ser-reg = url-props [slist] [attr-list] newline
url-props = surl "," lang "," ltime [ "," type ] newline
surl = ;The registration's URL. See
; [8] for syntax.
lang = 1*8ALPHA [ "-" 1*8ALPHA ]
;RFC 1766 Language Tag see [6].
ltime = 1*5DIGIT
; A positive 16-bit integer
; giving the lifetime
; of the registration.
type = ; The service type name, see [7]
; and [8] for syntax.
slist = "scopes" "=" scope-list newline
scope-list = scope-name / scope-name "," scope-list
scope = ; See grammar of [7] for
; scope-name syntax.
attr-list = attr-def / attr-def attr-list
attr-def = ( attr / keyword ) newline
keyword = attr-id
attr = attr-id "=" attr-val-list
attr-id = ;Attribute id, see [7] for syntax.
attr-val-list = attr-val / attr-val "," attr-val-list
attr-val = ;Attribute value, see [7] for syntax.
allchar = char / WSP
char = DIGIT / ALPHA / other
other = %x21-%x2f / %x3a-%x40 /
%x5b-%x60 / %7b-%7e
; All printable, nonwhitespace US-ASCII
; characters.
newline = CR / ( CRLF )
「reg / reg reg-リストser-ファイル=reg-リストreg-リスト=reg=creg / ser-reg cregが注釈行ser-reg注釈行=と等しい、(「#」/、」、;、」、)、1*allcharニューラインser-レッジ=url-支柱[slist][attr-リスト]ニューラインurl-支柱がsurlと等しい、」、」 ラング、」、」 ltime、[「」 タイプ] ニューラインは=をsurlします; 登録のURL 見てください。 [8] 構文lang=1*8ALPHA[「-」1*8ALPHA]のために; 1766年のRFC言語タグは[6]を見ます。ltimeは1*5DIGITと等しいです。 陽の16ビットの整数。 生涯を与えます。 登録タイプ=。 サービスは名前をタイプして、[7]を見てください。 「そして、構文slist=のための[8]は、「= 」 範囲リストニューライン範囲リストは範囲範囲名/名と等しいです」と「見」」という範囲リスト範囲が等しい、。 [7]の文法を見る、。 scope-name syntax. attr-list = attr-def / attr-def attr-list attr-def = ( attr / keyword ) newline keyword = attr-id attr = attr-id "=" attr-val-list attr-id = ;Attribute id, see [7] for syntax. attr-val-list = attr-val / attr-val "," attr-val-list attr-val = ;Attribute value, see [7] for syntax. allchar = char / WSP char = DIGIT / ALPHA / other other = %x21-%x2f / %x3a-%x40 / %x5b-%x60 / %7b-%7e ; すべての印刷可能な「非-空白」米国-ASCII。 キャラクタニューライン=CR/(CRLF)
The syntax for scope names, attribute tags, and attribute values requires escapes for special characters as specified in [7]. DAs and SA servers that process serialized registrations must handle them exactly as if they were registered by an SA. In the url-props
範囲名、属性タグ、および属性値のための構文は[7]の指定されるとしての特殊文字のためのエスケープを必要とします。 まるでちょうどそれらがSAによって登録されるかのように連載された登録証明書を処理するDAsとSAサーバはそれらを扱わなければなりません。 url-支柱で
Kempf & Guttman Informational [Page 17] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[17ページ]のRFC2614はAPI1999年6月に位置を修理します。
production, the type token is optional. If the type token is present for a service: URL, a warning is signaled and the type name is ignored. If the maximum lifetime is specified (65535 sec.), the registration is taken to be permanent, and is continually refreshed by the DA or SA server until it exits. Scopes can be included in a registration by including an attribute definition with tag "scopes" followed by a comma separated list of scope names immediately after the url-props production. If the optional scope list is present, the registrations are made in the indicated scopes; otherwise, they are registered in the scopes with which the DA or SA server was configured through the net.slp.useScopes property.
生産、タイプトークンは任意です。 タイプトークンがサービスのために存在しているなら: URL、警告は合図されます、そして、型名は無視されます。 最大の寿命が(65535秒)指定されるなら、登録は、永久的になるように取られて、DAかSAサーバによって出るまで絶えずリフレッシュされます。 登録に範囲名のコンマの切り離されたリストがurl-支柱生産直後タグ「範囲」のあとに続いている属性定義を含んでいることによって、範囲を含むことができます。 任意の範囲リストが存在しているなら、示された範囲で登録証明書をします。 さもなければ、それらはDAかSAサーバがnet.slp.useScopes所有地を通して構成された範囲に登録されます。
If the scope list contains scopes that are not in the net.slp.useScopes property (provided that property is set) or are not specified by DHCP, the API library should reject the registration and issue a warning message.
範囲リストがnet.slp.useScopes所有地(特性が設定されれば)にないか、またはDHCPによって指定されない範囲を入れてあるなら、APIライブラリは、登録を拒絶して、警告メッセージを発行するべきです。
2.4. Processing Serialized Registration and Configuration Files
2.4. 処理は登録と構成ファイルを連載しました。
Implementations are encouraged to make processing of configuration and serialized files as transparent as possible to clients of the API. At the latest, errors must be caught when the relevant configuration item is used. At the earliest, errors may be caught when the relevant file is loaded into the executing agent. Errors should be reported by logging to the appropriate platform logging file, error output, or log device, and the default value substituted. Serialized registration file entries should be caught and reported when the file is loaded.
実装で構成と連載されたファイルの処理ができるだけAPIのクライアントには透明になるよう奨励されます。 関連コンフィギュレーション品目が使用されているとき、遅くとも、誤りを捕らえなければなりません。 関連ファイルが実行しているエージェントにロードされるとき、最も早いところでは、誤りは捕らえられるかもしれません。 誤りは適切なプラットホーム伐採ファイル、エラー出力、またはログデバイスへの伐採で報告されるべきでした、そして、デフォルト値は代理をしました。 ファイルがロードされているとき、連載された登録ファイル項目は、捕らえられて、報告されるべきです。
Configuration file loading must be complete prior to the initiation of the first networking connection. Serialized registration must be complete before the DA accepts the first network request.
構成ファイルローディングは最初のネットワーク接続の開始の前に完全であるに違いありません。 DAが最初のネットワーク要求を受け入れる前に連載された登録は完全であるに違いありません。
3. Binding Independent Implementation Considerations
3. 拘束力がある独立している実装問題
This section discusses a number of implementation considerations independent of language binding, with language specific notes where applicable.
このセクションは適切であるところで言語の特定の注意で付く言語の如何にかかわらず多くの実装問題について論じます。
3.1. Multithreading
3.1. マルチスレッド化
Implementations of both the C and Java APIs are required to make API calls thread-safe. Access to data structures shared between threads must be co-ordinated to avoid corruption or invalid access. One way to achieve this goal is to allow only one thread at a time in the implementing library. Performance in such an implementation suffers, however. Therefore, where possible, implementations are encouraged to allow multiple threads within the SLP API library.
CとJava APIの両方の実装が、API電話をスレッド・セーフにかけるのに必要です。 不正か無効のアクセサリーを避けるためにスレッドの間で共有されたデータ構造へのアクセスを調整しなければなりません。 この目標を達成する1つの方法は一度に実装する図書館に1つのスレッドだけを許容することです。 しかしながら、そのような実装におけるパフォーマンスに苦しみます。したがって、可能であるところでは、実装がSLP API図書館の中の複数のスレッドを許容するよう奨励されます。
Kempf & Guttman Informational [Page 18] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[18ページ]のRFC2614はAPI1999年6月に位置を修理します。
3.2. Asynchronous and Incremental
3.2. 非同期であって、増加です。
The APIs are designed to encourage implementations supporting asynchronous and incremental client interaction. The goal is to allow large numbers of returned service URLs, service types, and attributes without requiring the allocation of huge chunks of memory. The particular design features to support this goal differ in the two language bindings.
APIは、非同期で増加のクライアントとの対話をサポートする実装を奨励するように設計されています。 目標はメモリの巨大な塊の配分を必要としないで返されたサービスURL、サービスタイプ、および多くの属性を許容することです。 この目標をサポートする特定の設計上の特徴は2つの言語結合において異なります。
3.3. Type Checking for Service Types
3.3. サービスのためにチェックするタイプがタイプします。
Service templates [8] allow SLP registrations to be type checked for correctness. Implementations of the API are free to make use of service type information for type checking, but are not required to do so. If a type error occurs, the registration should terminate with TYPE_ERROR.
サービステンプレート[8]は、SLP登録証明書が正当性がないかどうかチェックされたタイプであることを許容します。 APIの実装は、サービスタイプ情報のタイプの使用をチェックするようにするのにおいて自由ですが、そうするのに必要ではありません。 タイプ誤りが発生するなら、登録はTYPE_ERRORと共に終わるべきです。
3.4. Refreshing Registrations
3.4. 壮快な登録証明書
SLP advertisements carry an explicit lifetime with them. After the lifetime expires, the DA flushes the registration from its cache. In some cases, an application may want to have the URL continue being registered for the entire time during which the application is executing. The API includes provision for clients to indicate whether they want URLs to be automatically refreshed. Implementations of the SA API must provide this automatic refreshing capability. Note that a client which uses this facility should explicitly deregister the service URL before exiting, since the API implementation may not be able to assure that the URL is deregistered when the application exits, although it will time out in the DA eventually.
SLP広告はそれらで明白な生涯を載せます。 寿命が期限が切れた後に、DAはキャッシュから登録を洗い流します。 いくつかの場合、URLは、アプリケーションでアプリケーションが実行である全体の時間に登録され続けたがっているかもしれません。 クライアントが、彼らが自動的にURLをリフレッシュして欲しいかどうかを示すように、APIは支給を含んでいます。 SA APIの実装はこの自動壮快な能力を提供しなければなりません。 URLがAPI実行以来出る前のサービスURLが保証できないかもしれない「反-レジスタ」ですが、それですが、アプリケーションが出るとき、反登録されて、この施設が明らかにそれの用途をそうするはずであるクライアントが結局DAのタイムアウトを望んでいることに注意してください。
3.5. Configuration File Processing
3.5. 構成ファイル処理
DAs, SAs and UAs processing the configuration file, and DAs and SA servers processing the serialized registration file are required to log any errors using whatever underlying error mechanism is appropriate for the platform. Examples include writing error messages to the standard output, writing to a system logging device, or displaying the errors to a logging window. After the error is reported, the offending property must be set to the default and program execution continued. An agent MUST NOT fail if a file format error occurs.
連載された登録ファイルを処理するDAs、SAs、構成ファイルを処理するUAs、DAs、およびSAサーバが、どんなプラットホームに、適切な基本的な誤りメカニズムも使用することでどんな誤りも登録するのに必要です。 例は、標準の出力にエラーメッセージを書くのを含んでいます、システム伐採デバイスに書くか、または伐採ウィンドウに誤りを表示して。 誤りが報告された後に、怒っている特性をデフォルトに設定しなければなりませんでした、そして、プログラム実行は続きました。 ファイル形式誤りが発生するなら、エージェントは失敗してはいけません。
Kempf & Guttman Informational [Page 19] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[19ページ]のRFC2614はAPI1999年6月に位置を修理します。
3.6. Attribute Types
3.6. 属性タイプ
String encoded attribute values do not include explicit type information. All UA implementations and those SA and DA implementations that choose to support type checking should use the type rules described in [8] in order to convert from the string representation on the wire to an object typed appropriately.
ストリングのコード化された属性値は明白なタイプ情報を含んでいません。 タイプの照合をサポートするのを選ぶそれらのすべてのUA実装、SA、およびDA実装はワイヤにおけるストリング表現から適切にタイプされたオブジェクトまで変換するために[8]で説明されたタイプ規則を使用するべきです。
3.7. Removal of Duplicates
3.7. 写しの取り外し
The UA implementation SHOULD always collate results to remove duplicates during synchronous operations and for the Java API. During asynchronous operation in C, the UA implementation SHOULD forgo duplicate elimination to reduce memory requirements in the library. This allows the API library to simply take the returned attribute value list strings, URL strings, or service type list strings and call the callback function with it, without any additional processing. Naturally, the burden of duplicate elimination is thrown onto the client in this case.
UA実装SHOULDは、同期操作とJava APIのために写しを取り除くためにいつも結果を照合します。 Cの非同期動作の間、UA実装SHOULDは、図書館のメモリ要件を減らすために写し除去を差し控えます。 これで、APIライブラリは、単に返された属性値リストストリング、URLストリング、またはサービス型の並びストリングを取って、それでコールバック機能を呼びます、少しも追加処理なしで。 当然、写し除去の負担はこの場合クライアントに投げられます。
3.8. Character Set Encoding
3.8. 文字コードコード化
Character string parameters in the Java API are all represented in Unicode internally because that is the Java-supported character set. Characters buffer parameters in the C API are represented in UTF-8 to maintain maximum compatibility on platforms that only support US- ASCII and not UTF-8. API functions are still required to handle the full range of UTF-8 characters because the SLP protocol requires it, but the API implementation can represent the characters internally in any convenient way. On the wire, all characters are converted to UTF-8. Inside URLs, characters that are not allowed by URL syntax [2] must be escaped according to the URL escape character convention. Strings that are included in SLP messages may include SLP reserved characters and can be escaped by clients through convenience functions provided by the API. The character encoding used in escapes is UTF-8.
それがJavaによってサポートされた文字集合であるので、Java APIの文字列パラメタはユニコードですべて内部的に表されます。 C APIのキャラクターバッファパラメタは、UTF-8ではなく、米国ASCIIをサポートするだけであるプラットホームで最大の互換性を維持するためにUTF-8に表されます。 SLPプロトコルがそれを必要とするので、API関数が最大限の範囲のUTF-8キャラクタを扱うのにまだ必要ですが、API実行は内部的にどんな便利な方法でもキャラクタの代理をすることができます。 ワイヤの上では、すべてのキャラクタがUTF-8に変換されます。 URLの中では、URL拡張文字コンベンションによると、URL構文[2]で許容されていないキャラクタから逃げなければなりません。 SLPメッセージに含まれているストリングを、SLPの控え目なキャラクタを入れるかもしれなくて、クライアントはAPIによって提供された簡易関数を通して逃げることができます。 エスケープで使用される文字符号化はUTF-8です。
Due to constraints in SLP, no string parameter passed to the C or Java API may exceed 64K bytes in length.
SLPでの規制のため、CかJava APIに通過されなかったストリングパラメタは全く長さにおける64Kのバイトを超えるかもしれません。
3.9. Error Semantics
3.9. 誤り意味論
All errors encountered processing SLP messages should be logged. For synchronous calls, an error is only reported on a call if no successful replies were received from any SLP framework entity. If an error occurred among one of several successful replies, then the error should be logged and the successful replies returned. For asynchronous calls, an error occurring during correspondence with a
SLPメッセージを処理しながら遭遇するすべての誤りが登録されるべきです。 同期呼び出しにおいて、どんなSLPフレームワーク実体からもどんなうまくいっている回答も受け取らなかった場合にだけ、呼び出しに関して誤りを報告します。 誤りがいくつかのうまくいっている回答の1つの中に発生するなら、誤りは登録されるでしょうに、そして、うまくいっている回答は戻りました。 非同期な呼び出し、aとの通信の間に発生する誤りのために
Kempf & Guttman Informational [Page 20] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[20ページ]のRFC2614はAPI1999年6月に位置を修理します。
particular remote SLP agent is reported through the first callback (in the C API) or enumeration method invocation (in the Java API) after the error occurs, which would normally report the results of the correspondence. This allows the callback or client code to determine whether the operation should be terminated or continue. In some cases, the error returned from the SLP framework may be fatal (SLP_PARSE_ERROR, etc.). In these cases, the API library terminates the operation.
誤り(通常通信の結果を報告する)が発生した後に特定のリモートSLPエージェントは最初のコールバック(C APIの)か列挙メソッド実施(Java APIの)を通して報告されます。 これで、コールバックかクライアントコードが、操作が終えられるべきであるかどうか決定するか、または続きます。 いくつかの場合、SLPフレームワークから返された誤りは致命的であるかもしれません(SLP_PARSE_ERRORなど)。 これらの場合では、APIライブラリは操作を終えます。
Both the Java and C APIs contain language specific error code mechanisms for returning error information. The names of the error codes are consistent between the two implementations, however.
JavaとC APIの両方が戻っているエラー情報のための言語の特定のエラーコードメカニズムを含んでいます。 しかしながら、エラーコードの名前は2つの実装の間で一貫しています。
The following error codes are returned from a remote agent (DA or SA server):
以下のエラーコードはリモートエージェント(DAかSAサーバ)から返されます:
LANGUAGE_NOT_SUPPORTED
どんな_もサポートしなかった言語_
No DA or SA has service advertisement or attribute information
in the language requested, but at least one DA or SA indicated,
via the LANGUAGE_NOT_SUPPORTED error code, that it might have
information for that service in another language.
どんなDAもSAも_SUPPORTEDエラーコードではなく、それには別の言語におけるそのサービスのための情報があるかもしれないという要求されるのにもかかわらずの、少なくとも1DAかSAがLANGUAGE_を通して示した言語のサービス広告か属性情報を出していません。
PARSE_ERROR
_誤りを分析してください。
The SLP message was rejected by a remote SLP agent. The API
returns this error only when no information was retrieved, and
at least one SA or DA indicated a protocol error. The data
supplied through the API may be malformed or a may have been
damaged in transit.
SLPメッセージはリモートSLPエージェントによって拒絶されました。 情報が全く検索されなかったときだけ、APIはこの誤りを返します、そして、少なくとも1SAかDAがプロトコル誤りを示しました。 APIを通して提供されたデータが奇形であったかもしれません、またはaはトランジットで破損したかもしれません。
INVALID_REGISTRATION
無効の_登録
The API may return this error if an attempt to register a
service was rejected by all DAs because of a malformed URL or
attributes. SLP does not return the error if at least one DA
accepted the registration.
サービスを登録する試みが奇形のURLか属性ですべてのDAsによって拒絶されたなら、APIはこの誤りを返すかもしれません。 少なくとも1DAが登録を受け入れたなら、SLPは誤りを返しません。
AUTHENTICATION_ABSENT
認証_休みます。
If the SLP framework supports authentication, this error arises
when the UA or SA failed to send an authenticator for requests
or registrations in a protected scope.
UAかSAが要求か登録証明書のために保護された範囲で固有識別文字を送らなかったとき、SLPフレームワークが認証をサポートするなら、この誤りは起こります。
Kempf & Guttman Informational [Page 21] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[21ページ]のRFC2614はAPI1999年6月に位置を修理します。
INVALID_UPDATE
無効の_アップデート
An update for a non-existing registration was issued, or the
update includes a service type or scope different than that in
the initial registration, etc.
非既存の登録のためのアップデートが発行されたか、またはアップデートは新規登録におけるそれなどと異なったサービスタイプか範囲を含んでいます。
The following errors result from interactions with remote agents or can occur locally:
以下の誤りは、リモートエージェントとの相互作用から生じるか、または局所的に発生できます:
AUTHENTICATION_FAILED
認証_は失敗しました。
If the SLP framework supports authentication, this error arises
when a authentication on an SLP message failed.
SLPメッセージにおける認証が失敗したとき、SLPフレームワークが認証をサポートするなら、この誤りは起こります。
SCOPE_NOT_SUPPORTED
どんな_もサポートしなかった範囲_
The API returns this error if the SA has been configured with
net.slp.useScopes value-list of scopes and the SA request did
not specify one or more of these allowable scopes, and no
others. It may be returned by a DA or SA if the scope included
in a request is not supported by the DA or SA.
SAが範囲のnet.slp.useScopes値リストによって構成されたなら、APIはこの誤りを返します、そして、SA要求はこれらの許容できる範囲にもかかわらず、他のものがないより多くのひとりを指定しませんでした。 要求に含まれていた範囲がDAかSAによって支えられないなら、それはDAかSAによって返されるかもしれません。
REFRESH_REJECTED
拒絶された_をリフレッシュしてください。
The SA attempted to refresh a registration more frequently
than the minimum refresh interval. The SA should call the
appropriate API function to obtain the minimum refresh interval
to use.
SAは、最小限が間隔をリフレッシュするより頻繁に登録をリフレッシュするのを試みました。 SAは、好個をAPI関数と呼ぶはずです。最小限を得るのは費やす間隔をリフレッシュします。
The following errors are generated through a program interacting with the API implementation. They do not involve a remote SLP agent.
以下の誤りはAPI実行と対話するプログラムで生成されます。 彼らはリモートSLPエージェントにかかわりません。
NOT_IMPLEMENTED
実装された_でない
If an unimplemented feature is used, this error is returned.
非実装している特徴が使用されているなら、この誤りは返されます。
NETWORK_INIT_FAILED
ネットワーク_イニット_は失敗しました。
If the network cannot initialize properly, this error is
returned.
適切にネットワークは初期設定にされできないなら、この誤りが返されます。
NETWORK_TIMED_OUT
_外で調節されたネットワーク_
When no reply can be obtained in the time specified by the
configured timeout interval for a unicast request, this error
is returned.
構成されたタイムアウト間隔でユニキャスト要求に指定された時間回答を全く得ることができないとき、この誤りを返します。
Kempf & Guttman Informational [Page 22] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[22ページ]のRFC2614はAPI1999年6月に位置を修理します。
NETWORK_ERROR
ネットワーク_誤り
The failure of networking during normal operations causes this
error to be returned.
通常操作の間のネットワークの失敗で、この誤りを返します。
BUFFER_OVERFLOW
バッファ_オーバーフロー
An outgoing request overflowed the maximum network MTU size.
The request should be reduced in size or broken into pieces and
tried again.
送信する要求を最大のネットワークMTUサイズからはみ出させました。 要求は、サイズを縮小されて、ばらばらに知らせられて、再び試みられるべきです。
MEMORY_ALLOC_FAILED
メモリ_ALLOC_は失敗しました。
If the API fails to allocate memory, the operation is aborted
and returns this.
APIがメモリを割り当てないなら、操作は、中止されて、これを返します。
PARAMETER_BAD
パラメタ_悪いです。
If a parameter passed into an interface is bad, this error is
returned.
インタフェースに通過されたパラメタが悪いなら、この誤りは返されます。
INTERNAL_SYSTEM_ERROR
内部の_システム_誤り
A basic failure of the API causes this error to be returned.
This occurs when a system call or library fails. The operation
could not recover.
APIの基本的な失敗で、この誤りを返します。 システムコールかライブラリが行き詰まると、これは起こります。 操作は回復できませんでした。
HANDLE_IN_USE
_使用で_を扱ってください。
In the C API, callback functions are not permitted to
recursively call into the API on the same SLPHandle, either
directly or indirectly. If an attempt is made to do so, this
error is returned from the called API function.
C APIでは、コールバック機能が同じSLPHandleに直接か間接的にAPIに再帰的にちょっと立ち寄ることが許可されていません。 そうするのを試みをするなら、呼ばれたAPI関数からこの誤りを返します。
TYPE_ERROR
_誤りをタイプしてください。
If the API supports type checking of registrations against
service type templates, this error can arise if the attributes
in a registration do not match the service type template for
the service.
APIがサービスタイプテンプレートに対して登録証明書のタイプの照合をサポートして、登録における属性がサービスのためのサービスタイプテンプレートに合っていないなら、この誤りは起こることができます。
Some error codes are handled differently in the Java API. These differences are discussed in Section 5.
いくつかのエラーコードがJava APIで異なって扱われます。 セクション5でこれらの違いについて議論します。
The SLP protocol errors OPTION_NOT_UNDERSTOOD, VERSION_NOT_SUPPORTED, INTERNAL_ERROR, MSG_NOT_SUPPORTED, AUTHENTICATON_UNKNOWN, and DA_BUSY_NOW should be handled internally and not surfaced to clients through the API.
__UNDERSTOODでなく、__バージョンSUPPORTEDでなく、INTERNAL_ERROR、__エムエスジーSUPPORTEDでなく、AUTHENTICATON_UNKNOWN、およびDA_BUSY_が現在そうするべきであるSLPプロトコル誤りOPTIONは内部的に扱われて、APIを通してクライアントに表面化しませんでした。
Kempf & Guttman Informational [Page 23] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[23ページ]のRFC2614はAPI1999年6月に位置を修理します。
3.10. Modular Implementations
3.10. モジュールの実装
Subset implementations that do not support the full range of functionality are required to nevertheless support every interface in order to maintain link compatibility between compliant API implementations and applications. If a particular operation is not supported, a NOT_IMPLEMENTED error should be returned. The Java API has some additional conventions for handling subsets. Applications that are expected to run on a wide variety of platforms should be prepared for subset API implementations by checking returned error codes.
最大限の範囲の機能性をサポートしない部分集合実装が、それにもかかわらず、対応するAPI実行とアプリケーションとのリンクの互換性を維持するためにあらゆるインタフェースをサポートするのに必要です。 _特定の操作がサポートされないなら、IMPLEMENTEDではありません誤りが返されるべきである。 Java APIは取り扱い部分集合のためのいくつかの追加コンベンションを開きます。 さまざまなプラットホームで走ると予想されるアプリケーションは、部分集合API実行のために返されたエラーコードをチェックすることによって、準備されるべきです。
3.11. Handling Special Service Types
3.11. 特別なサービスを扱うのはタイプされます。
The service types service:directory-agent and service:service-agent are used internally in the SLP framework to discover DAs and SAs. The mechanism of DA and SA discovery is not normally exposed to the API client; however, the client may have interest in discovering DAs and SAs independently of their role in discovering other services. For example, a network management application may want to determine which machines are running SLP DAs. To facilitate that, API implementations must handle requests to find services and attributes for these two service types so that API clients obtain the information they expect.
サービスはサービスをタイプします: サービス: ディレクトリエージェントとサービスエージェントは、DAsとSAsを発見するのにSLPフレームワークに内部的に使用されます。 通常、DAとSA発見のメカニズムはAPIクライアントに暴露されません。 しかしながら、クライアントは他のサービスを発見することにおける彼らの役割の如何にかかわらずDAsとSAsを発見するのに関心を持っているかもしれません。 例えば、ネットワークマネージメントアプリケーションは、どのマシンが実行しているSLP DAsであるかを決定したがっているかもしれません。 それを容易にするために、API実行がこれらの2つのサービスタイプに関してサービスと属性を見つけるという要求を扱わなければならないので、APIクライアントは彼らが予想する情報を得ます。
In particular, if the UA is using a DA, SrvRqst and AttrRqst for these service types must be multicast and not unicast to the DA, as is the case for other service types. If the requests are not multicast, the DA will respond with an empty reply to a request for services of type service:service-agent and with its URL only to a request for services of type service:directory-agent. The UA would therefore not obtain a complete picture of the available DAs and SAs.
UAがDAを使用しているなら、これらのサービスタイプのためのSrvRqstとAttrRqstはDAへのユニキャストではなく、特に、マルチキャストであるに違いありません、他のサービスタイプのためのケースのように。 要求がマルチキャストでないなら、DAはタイプサービス: サービスエージェントのサービスを求める要求に関する空の回答とそのURLでタイプサービスのサービスを求める要求だけに応じるでしょう: ディレクトリエージェント。 したがって、UAは利用可能なDAsとSAsの完全な画像を得ないでしょう。
3.12. Scope Discovery and Handling
3.12. 範囲発見と取り扱い
Both APIs contain an operation to obtain a list of currently known scope names. This scope information comes from a variety of places: DHCP, the net.slp.useScopes property, unicast to DAs configured via DHCP or the net.slp.DAAddresses property, and active and passive discovery.
両方のAPIは現在知られている範囲名のリストを得る操作を含んでいます。 この範囲情報はさまざまな場所から来ます: DHCPかnet.slp.useScopesの特性かDHCPを通して構成されたDAsへのユニキャストかnet.slp.DAAddressesの特性と、アクティブで受け身の発見。
The API is required to be implemented in a way that re-enforces the administrative and user scoping models described in [7]. SA clients only support the administrative scoping model. SAs must know a priori what DAs they need to register with since there is typically no human intervention in scope selection for SAs. UAs must support both administrative and user scoping because an application may require human intervention in scope selection.
APIによってモデルが[7]で説明した管理とユーザ見ることを再実施する方法で実装されなければなりません。 SAクライアントは管理見ているモデルをサポートするだけです。 SAsのための範囲選択における人間の介入が全く通常ないので、SAsは、彼らが、どんなDAsについてともに記名する必要であるかを先験的に知らなければなりません。 アプリケーションが範囲選択における人間の介入を必要とするかもしれないので、UAsはともに管理とユーザ見ることをサポートしなければなりません。
Kempf & Guttman Informational [Page 24] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[24ページ]のRFC2614はAPI1999年6月に位置を修理します。
API implementations are required to support administrative scoping in the following way. Scopes configured by DHCP and scopes of DAs configured by DHCP have first priority (in that order) and must be returned if they are available. The net.slp.useScopes property has second priority, and scopes discovered through the net.slp.useScopes property must be returned if this property is set and there are no scopes available from DHCP. If scopes are not available from either of these sources and the net.slp.DAAddresses property is set, then the scopes available from the configured DAs must be returned. Note that if both DAs and scopes are configured, the scopes of the configured DAs must match the configured scope list; otherwise and error is signaled and agent execution is terminated. If no configured scope information is available, then an SA client has default scope, "DEFAULT", and a UA client employs user scoping.
API実行が、以下の方法で管理見ることをサポートするのに必要です。 DHCPによって構成されたDAsのDHCPと範囲によって構成された範囲を、最優先(そのオーダーにおける)を持って、彼らが利用可能であるなら、返さなければなりません。 net.slp.useScopesの特性に、2番目の優先権があります、そして、この特性が設定されて、DHCPから利用可能などんな範囲もなければ、net.slp.useScopes所有地を通して発見された範囲を返さなければなりません。 範囲がこれらのソースのどちらかから利用可能でなく、net.slp.DAAddressesの特性を設定するなら、構成されたDAsから利用可能な範囲を返さなければなりません。 DAsと範囲の両方が構成されるなら、構成されたDAsの範囲が構成された範囲リストに合わなければならないことに注意してください。 そして、そうでなさ、誤りは合図されて、エージェント実行は終えられます。 どんな構成された範囲情報も利用可能でないなら、SAクライアントには、デフォルト範囲、「デフォルト」があります、そして、Uaのクライアントはユーザの見ることを使います。
User scoping is supported in the following way. Scopes discovered from active DA discovery, and from passive DA discovery all must be returned. If no information is available from active and passive DA discovery, then the API library may perform SA discovery, using the service types in the net.slp.typeHint property to limit the search to SAs supporting particular service types. If no net.slp.typeHint property is set, the UA may perform SA discovery without any service type query. In the absence of any of the above sources of information, the API must return the default scope, "DEFAULT". Note that the API must always return some scope information.
ユーザの見ることは以下の方法でサポートされます。 範囲は、活発なDA発見と、そして、受け身のDA発見からすべてを返さなければならないと発見しました。 どんな情報もアクティブで受け身のDA発見によって利用可能でないなら、APIライブラリはSA発見を実行するかもしれません、検索をSAsに制限するのに特定のサービスタイプをサポートしながらnet.slp.typeHint所有地でサービスタイプを使用して。 net.slp.typeHintの特性が全く設定されないなら、UAは少しもサービスタイプ質問なしでSA発見を実行するかもしれません。 上の情報筋のどれかが不在のとき、APIはデフォルト範囲、「デフォルト」を返さなければなりません。 APIがいつも何らかの範囲情報を返さなければならないことに注意してください。
SLP requires that SAs must perform their operations in all scopes currently known to them. [7]. The API enforces this constraint by not requiring the API client to supply any scopes as parameters to API operations. The API library must obtain all currently known scopes and use them in SA operations. UA API clients should use a scope obtained through one of the API operations for finding scopes. Any other scope name may result in a SCOPE_NOT_SUPPORTED error from a remote agent. The UA API library can optionally check the scope and return the error without contacting a remote agent.
SLPは、SAsが現在それらにおいて知られているすべての範囲で彼らの操作を実行しなければならないのを必要とします。 [7]. APIクライアントがパラメタとしてどんな範囲もAPI操作に供給するのを必要としないことによって、APIはこの規制を実施します。 APIライブラリは、すべての現在知られている範囲を入手して、SA操作にそれらを使用しなければなりません。 UA APIクライアントは範囲を見つけるためのAPI操作の1つで入手された範囲を使用するべきです。 いかなる他の範囲名も_SUPPORTED誤りではなく、リモートエージェントからのSCOPE_をもたらすかもしれません。 リモートエージェントに連絡しないで、UA APIライブラリは、任意に範囲をチェックして、誤りを返すことができます。
4. C Language Binding
4. C言語結合
The C language binding presents a minimal overhead implementation that maps directly into the protocol. There is one C language function per protocol request, with the exception of the SLPDereg() and SLPDelAttrs() functions, which map into different uses of the SLP deregister request. Parameters are for the most part character buffers. Memory management is kept simple by having the client allocate most memory and requiring that client callback functions copy incoming parameters into memory allocated by the client code. Any memory returned directly from the API functions is deallocated using the SLPFree() function.
C言語結合はそれが直接プロトコルに写像する最小量の頭上の実装を提示します。 プロトコル要求あたり1つのC言語機能があります、SLPDereg()とSLPDelAttrs()機能を除いて。(機能はSLP deregister要求の用途を異なるのに写像します)。 パラメタはだいたい文字バッファです。 クライアントにほとんどのメモリを割り当てさせて、クライアントコールバック機能がクライアントコードによって割り当てられたメモリに入って来るパラメタをコピーするのを必要とすることによって、メモリ管理は簡単に保たれます。 直接API関数から返されたどんなメモリも、SLPFree()機能を使用することで「反-割り当て」られます。
Kempf & Guttman Informational [Page 25] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[25ページ]のRFC2614はAPI1999年6月に位置を修理します。
To conform with standard C practice, all character strings passed to and returned through the API are null terminated, even though the SLP protocol does not use null terminated strings. Strings passed as parameters are UTF-8 but they may still be passed as a C string (a null terminated sequence of bytes.) Escaped characters must be encoded by the API client as UTF-8. In the common case of US-ASCII, the usual one byte per character C strings work. API functions assist in escaping and unescaping strings.
一般的なC習慣に従うために、文字列が通過されて、APIを通して返したすべてが終えられた状態でヌルです、SLPプロトコルはヌル終えられたストリングを使用しませんが。 ストリングはパラメタがUTF-8であるので、通りましたが、それらはCストリング(バイトのヌル終えられた系列)としてまだ通過されているかもしれません。 APIクライアントはUTF-8として逃げられたキャラクタをコード化しなければなりません。 米国-ASCIIのよくある例では、普通のキャラクタCあたり1バイトは仕事を結びます。 API関数は、逃げて、ストリングを非エスケープさせるのを助けます。
Unless otherwise noted, parameters to API functions and callbacks are non-NULL. Some parameters may have other restrictions. If any parameter fails to satisfy the restrictions on its value, the operation returns a PARAMETER_BAD error.
別の方法で注意されない場合、API関数とコールバックへのパラメタは非NULLです。 いくつかのパラメタには、他の制限があるかもしれません。 何かパラメタが値における制限を満たさないなら、操作はPARAMETER_BAD誤りを返します。
4.1. Constant Types
4.1. 一定のタイプ
4.1.1. URL Lifetimes
4.1.1. URL生涯
4.1.1.1. Synopsis
4.1.1.1. 構文
typedef enum {
SLP_LIFETIME_DEFAULT = 10800,
SLP_LIFETIME_MAXIMUM = 65535
} SLPURLLifetime;
typedef enum、SLP_LIFETIME_DEFAULT=10800、SLP_LIFETIME_MAXIMUM=65535、SLPURLLifetime。
4.1.1.2. Description
4.1.1.2. 記述
The SLPURLLifetime enum type contains URL lifetime values, in seconds, that are frequently used. SLP_LIFETIME_DEFAULT is 3 hours, while SLP_LIFETIME_MAXIMUM is about 18 hours and corresponds to the maximum size of the lifetime field in SLP messages.
SLPURLLifetime enumタイプは秒の頻繁に使用されるURL生涯値を含んでいます。 SLP_LIFETIME_DEFAULTは3時間です、SLP_LIFETIME_MAXIMUMがおよそ18時間であり、SLPメッセージの生涯分野の最大サイズに対応していますが。
4.1.2. Error Codes
4.1.2. エラーコード
4.1.2.1. Synopsis
4.1.2.1. 構文
typedef enum {
SLP_LAST_CALL = 1,
SLP_OK = 0,
SLP_LANGUAGE_NOT_SUPPORTED = -1,
SLP_PARSE_ERROR = -2,
SLP_INVALID_REGISTRATION = -3,
SLP_SCOPE_NOT_SUPPORTED = -4,
SLP_AUTHENTICATION_ABSENT = -6,
SLP_AUTHENTICATION_FAILED = -7,
typedef enum、SLP_LAST_CALL=1、SLP_OK=0、_SUPPORTED=-1ではなく、SLP_LANGUAGE_、SLP_PARSE_ERROR=-2、SLP_INVALID_REGISTRATION=-3、_SUPPORTED=-4ではなく、SLP_SCOPE_、SLP_AUTHENTICATION_ABSENTは-6と等しいです、SLP_AUTHENTICATION_FAILED=-7
Kempf & Guttman Informational [Page 26] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[26ページ]のRFC2614はAPI1999年6月に位置を修理します。
SLP_INVALID_UPDATE = -13,
SLP_REFRESH_REJECTED = -15,
SLP_NOT_IMPLEMENTED = -17,
SLP_BUFFER_OVERFLOW = -18,
SLP_NETWORK_TIMED_OUT = -19,
SLP_NETWORK_INIT_FAILED = -20,
SLP_MEMORY_ALLOC_FAILED = -21,
SLP_PARAMETER_BAD = -22,
SLP_NETWORK_ERROR = -23,
SLP_INTERNAL_SYSTEM_ERROR = -24,
SLP_HANDLE_IN_USE = -25,
SLP_TYPE_ERROR = -26
} SLPError ;
無効..アップデート..リフレッシュ..拒絶..実装する..バッファ..オーバーフロー..ネットワーク..調節..外..ネットワーク..イニット..失敗..メモリ..失敗..パラメタ..悪い..ネットワーク..誤り..内部..システム..誤り..ハンドル..使用..タイプ..誤り SLPError。
4.1.2.2. Description
4.1.2.2. 記述
The SLPError enum contains error codes that are returned from API functions.
SLPError enumはAPI関数から返されるエラーコードを含んでいます。
The SLP_OK code indicates that the no error occurred during the operation.
SLP_OKコードがそれを示す、誤りは全く操作の間、発生しませんでした。
The SLP_LAST_CALL code is passed to callback functions when the API library has no more data for them and therefore no further calls will be made to the callback on the currently outstanding operation. The callback can use this to signal the main body of the client code that no more data will be forthcoming on the operation, so that the main body of the client code can break out of data collection loops. On the last call of a callback during both a synchronous and asynchronous call, the error code parameter has value SLP_LAST_CALL, and the other parameters are all NULL. If no results are returned by an API operation, then only one call is made, with the error parameter set to SLP_LAST_CALL.
APIライブラリにそれらのためのそれ以上のデータが全くないと、SLP_LAST_CALLコードをコールバック機能に通過します、そして、したがって、現在傑出している操作のときにさらなる電話を全くコールバックにかけないでしょう。 コールバックはそれ以上のデータが操作のときに用意しないとクライアントコードの本体に合図するのにこれを使用できます、クライアントコードの本体がデータ収集輪から抜け出すことができるように。 同時の、そして、非同期な呼び出し、コード・パラメータでSLP_LAST_CALLを評価する誤りと他のパラメタの両方の間のコールバックの最後の呼び出しには、すべてのNULLがあります。 API操作で結果を全く返さないなら、1つの電話だけをかけます、SLP_LAST_CALLに設定されたエラー・パラメータで。
4.1.3. SLPBoolean
4.1.3. SLPBoolean
4.1.3.1. Synopsis
4.1.3.1. 構文
typedef enum {
SLP_FALSE = 0,
SLP_TRUE = 1
typedef enum、SLP_FALSEは0、SLP_TRUE=1と等しいです。
} SLPBoolean;
} SLPBoolean。
Kempf & Guttman Informational [Page 27] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[27ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.1.3.2. Description
4.1.3.2. 記述
The SLPBoolean enum is used as a boolean flag.
SLPBoolean enumは論理演算子旗として使用されます。
4.2. Struct Types
4.2. Structはタイプします。
4.2.1. SLPSrvURL
4.2.1. SLPSrvURL
4.2.1.1. Synopsis
4.2.1.1. 構文
typedef struct srvurl {
char *s_pcSrvType;
char *s_pcHost;
int s_iPort;
char *s_pcNetFamily;
char *s_pcSrvPart;
} SLPSrvURL;
typedef struct srvurl炭*s_pcSrvType; _炭*s pcHost; int s_iPort; 炭*のs_pcNetFamily; *s_pcSrvPartを炭にする;SLPSrvURL。
4.2.1.2. Description
4.2.1.2. 記述
The SLPSrvURL structure is filled in by the SLPParseSrvURL() function with information parsed from a character buffer containing a service URL. The fields correspond to different parts of the URL. Note that the structure is in conformance with the standard Berkeley sockets struct servent, with the exception that the pointer to an array of characters for aliases (s_aliases field) is replaced by the pointer to host name (s_pcHost field).
情報がサービスURLを含む文字バッファから分析されている状態で、SLPSrvURL構造はSLPParseSrvURL()機能によって記入されます。 分野はURLの異なった部分に対応しています。 構造が標準のバークレーソケットstruct serventとの順応中であることに注意してください、そして、接待する指針に取り替えて、別名(別名がさばくs_)のためのキャラクタの配列への指針がそうである例外で、(pcHostがさばくs_)を命名してください。
s_pcSrvType
s_pcSrvType
A pointer to a character string containing the service
type name, including naming authority. The service type
name includes the "service:" if the URL is of the service:
scheme. [7]
権威を命名するのを含むサービス型名を含む文字列への指針。 サービス型名が含んでいる、「サービス:」 URLが役に立つなら: 計画してください。 [7]
s_pcHost
s_pcHost
A pointer to a character string containing the host
identification information.
ホスト識別情報を含む文字列への指針。
s_iPort
s_iPort
The port number, or zero if none. The port is only available
if the transport is IP.
なにもであるなら、ポートは、付番するか、またはゼロに合わせます。 ポートは輸送がIPである場合にだけ利用可能です。
Kempf & Guttman Informational [Page 28] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[28ページ]のRFC2614はAPI1999年6月に位置を修理します。
s_pcNetFamily
s_pcNetFamily
A pointer to a character string containing the network address
family identifier. Possible values are "ipx" for the IPX
family, "at" for the Appletalk family, and "" (i.e. the empty
string) for the IP address family.
ネットワーク・アドレスファミリー識別子を含む文字列への指針。 そして、可能な値はIPXファミリーのための"ipx"です、Appletalkファミリーのための“at"、「「IPアドレスファミリーのための(すなわち、空のストリング)。」
s_pcSrvPart
s_pcSrvPart
The remainder of the URL, after the host identification.
ホスト識別の後のURLの残り。
The host and port should be sufficient to open a socket to the machine hosting the service, and the remainder of the URL should allow further differentiation of the service.
ホストとポートがサービスを主催するマシンにソケットを開けることができるべきであるくらいURLの残りはさらなるサービスの分化を許容するべきです。
4.2.2. SLPHandle
4.2.2. SLPHandle
4.2.2.1. Synopsis
4.2.2.1. 構文
typedef void* SLPHandle;
typedef空間*SLPHandle。
The SLPHandle type is returned by SLPOpen() and is a parameter to all SLP functions. It serves as a handle for all resources allocated on behalf of the process by the SLP library. The type is opaque, since the exact nature differs depending on the implementation.
SLPHandleタイプは、SLPOpen()によって返されて、すべてのSLP機能へのパラメタです。 それはSLP図書館のそばのプロセスを代表して割り当てられたすべてのリソースのためのハンドルとして機能します。 実装によって、正確な自然が異なって、タイプは分っています。
4.3. Callbacks
4.3. コールバック
A function pointer to a callback function specific to a particular API operation is included in the parameter list when the API function is invoked. The callback function is called with the results of the operation in both the synchronous and asynchronous cases. The memory included in the callback parameters is owned by the API library, and the client code in the callback must copy out the contents if it wants to maintain the information longer than the duration of the current callback call.
API関数が呼び出されるとき、特定のAPI操作に特定のコールバック機能への機能指針はパラメータ・リストに含まれています。 コールバック機能は両方の同時の、そして、非同期な場合における、操作の結果で呼ばれます。 コールバックパラメタにメモリを含んでいるのはAPIライブラリによって所有されています、そして、現在のコールバック呼び出しの持続時間より長い間情報を保守したいなら、コールバックにおけるクライアントコードはコンテンツを全部写さなければなりません。
In addition to parameters for reporting the results of the operation, each callback parameter list contains an error code parameter and a cookie parameter. The error code parameter reports the error status of the ongoing (for asynchronous) or completed (for synchronous) operation. The cookie parameter allows the client code that starts the operation by invoking the API function to pass information down to the callback without using global variables. The callback returns an SLPBoolean to indicate whether the API library should continue processing the operation. If the value returned from the callback is
操作の結果を報告するためのパラメタに加えて、それぞれのコールバックパラメータ・リストは誤りコード・パラメータとクッキーパラメタを含んでいます。 誤りコード・パラメータが進行中のエラー状況を報告する、(非同期である、)、完成される、(同期、)、操作。 クッキーパラメタで、大域変数を使用しないで、API関数を呼び出すことによって操業を開始するクライアントコードは情報をコールバックまで通過できます。 コールバックは、APIライブラリが、操作を処理し続けるべきであるかどうかを示すためにSLPBooleanを返します。 コールバックから返された値がそうなら
Kempf & Guttman Informational [Page 29] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[29ページ]のRFC2614はAPI1999年6月に位置を修理します。
SLP_TRUE, asynchronous operations are terminated, synchronous operations ignore the return (since the operation is already complete).
SLP_TRUE、非同期動作が終えられる、同期操作はリターンを無視します(操作が既に完全であるので)。
4.3.1. SLPRegReport
4.3.1. SLPRegReport
4.3.1.1. Synopsis
4.3.1.1. 構文
typedef void SLPRegReport(SLPHandle hSLP,
SLPError errCode,
void *pvCookie);
typedefの空のSLPRegReport(SLPHandle hSLP(SLPError errCode)は*pvCookieを欠如させます)。
4.3.1.2. Description
4.3.1.2. 記述
The SLPRegReport callback type is the type of the callback function to the SLPReg(), SLPDereg(), and SLPDelAttrs() functions.
SLPRegReportコールバックタイプはSLPReg()、SLPDereg()、およびSLPDelAttrs()機能へのコールバック機能のタイプです。
4.3.1.3. Parameters
4.3.1.3. パラメタ
hSLP
hSLP
The SLPHandle used to initiate the operation.
SLPHandleは以前はよく操作を開始していました。
errCode
errCode
An error code indicating if an error occurred during the
operation.
誤りが操作の間、発生したかどうかを示すエラーコード。
pvCookie
pvCookie
Memory passed down from the client code that called the
original API function, starting the operation. May be NULL.
メモリはクライアントコードから操業を開始して、元のAPI関数と呼ばれるそれを伝えました。 NULLはそうです。
4.3.2. SLPSrvTypeCallback
4.3.2. SLPSrvTypeCallback
4.3.2.1. Synopsis
4.3.2.1. 構文
typedef SLPBoolean SLPSrvTypeCallback(SLPHandle hSLP,
const char* pcSrvTypes,
SLPError errCode,
void *pvCookie);
typedef SLPBoolean SLPSrvTypeCallback(SLPHandle hSLP(const炭*pcSrvTypes、SLPError errCode)は*pvCookieを欠如させます)。
Kempf & Guttman Informational [Page 30] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[30ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.3.2.2. Description
4.3.2.2. 記述
The SLPSrvTypeCallback type is the type of the callback function parameter to SLPFindSrvTypes() function. If the hSLP handle parameter was opened asynchronously, the results returned through the callback MAY be uncollated. If the hSLP handle parameter was opened synchronously, then the returned results must be collated and duplicates eliminated.
SLPSrvTypeCallbackタイプはSLPFindSrvTypes()機能へのコールバック関数パラメータのタイプです。 hSLPハンドルパラメタが非同期に開かれたなら、コールバックを通して返された結果は非照合されるかもしれません。 hSLPハンドルパラメタが同時開かれたなら、返された結果を照合しなければなりませんでした、そして、写しは排泄されました。
4.3.2.3. Parameters
4.3.2.3. パラメタ
hSLP
hSLP
The SLPHandle used to initiate the operation.
SLPHandleは以前はよく操作を開始していました。
pcSrvTypes
pcSrvTypes
A character buffer containing a comma separated, null
terminated list of service types.
サービスのコンマ切り離されて、ヌルの終えられたリストを含む文字バッファはタイプされます。
errCode
errCode
An error code indicating if an error occurred during the
operation. The callback should check this error code before
processing the parameters. If the error code is other than
SLP_OK, then the API library may choose to terminate the
outstanding operation.
誤りが操作の間、発生したかどうかを示すエラーコード。 パラメタを処理する前に、コールバックはこのエラーコードをチェックするべきです。 SLP_OKを除いて、エラーコードがあるなら、APIライブラリは、傑出している操作を終えるのを選ぶかもしれません。
pvCookie
pvCookie
Memory passed down from the client code that called the
original API function, starting the operation. May be NULL.
メモリはクライアントコードから操業を開始して、元のAPI関数と呼ばれるそれを伝えました。 NULLはそうです。
4.3.2.4. Returns
4.3.2.4. リターン
The client code should return SLP_TRUE if more data is desired, otherwise SLP_FALSE.
_より多くのデータが望まれているなら、クライアントコードはSLP_TRUEを返すべきであり、そうでなければ、SLPはFALSEです。
4.3.3. SLPSrvURLCallback
4.3.3. SLPSrvURLCallback
4.3.3.1. Synopsis
4.3.3.1. 構文
typedef SLPBoolean SLPSrvURLCallback(SLPHandle hSLP,
const char* pcSrvURL,
unsigned short sLifetime,
SLPError errCode,
void *pvCookie);
typedef SLPBoolean SLPSrvURLCallback(SLPHandle hSLP(const炭の*pcSrvURL、未署名の短いsLifetime、SLPError errCode)は*pvCookieを欠如させます)。
Kempf & Guttman Informational [Page 31] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[31ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.3.3.2. Description
4.3.3.2. 記述
The SLPSrvURLCallback type is the type of the callback function parameter to SLPFindSrvs() function. If the hSLP handle parameter was opened asynchronously, the results returned through the callback MAY be uncollated. If the hSLP handle parameter was opened synchronously, then the returned results must be collated and duplicates eliminated.
SLPSrvURLCallbackタイプはSLPFindSrvs()機能へのコールバック関数パラメータのタイプです。 hSLPハンドルパラメタが非同期に開かれたなら、コールバックを通して返された結果は非照合されるかもしれません。 hSLPハンドルパラメタが同時開かれたなら、返された結果を照合しなければなりませんでした、そして、写しは排泄されました。
4.3.3.3. Parameters
4.3.3.3. パラメタ
hSLP
hSLP
The SLPHandle used to initiate the operation.
SLPHandleは以前はよく操作を開始していました。
pcSrvURL
pcSrvURL
A character buffer containing the returned service URL.
返されたサービスURLを含む文字バッファ。
sLifetime
sLifetime
An unsigned short giving the life time of the service
advertisement, in seconds. The value must be an unsigned
integer less than or equal to SLP_LIFETIME_MAXIMUM.
秒のサービス広告の寿命時間の未署名の短い付与。 値は符号のない整数SLP_LIFETIME_よりMAXIMUM以下でなければなりません。
errCode
errCode
An error code indicating if an error occurred during the
operation. The callback should check this error code before
processing the parameters. If the error code is other than
SLP_OK, then the API library may choose to terminate the
outstanding operation.
誤りが操作の間、発生したかどうかを示すエラーコード。 パラメタを処理する前に、コールバックはこのエラーコードをチェックするべきです。 SLP_OKを除いて、エラーコードがあるなら、APIライブラリは、傑出している操作を終えるのを選ぶかもしれません。
pvCookie
pvCookie
Memory passed down from the client code that called the
original API function, starting the operation. May be NULL.
メモリはクライアントコードから操業を開始して、元のAPI関数と呼ばれるそれを伝えました。 NULLはそうです。
4.3.3.4. Returns
4.3.3.4. リターン
The client code should return SLP_TRUE if more data is desired, otherwise SLP_FALSE.
_より多くのデータが望まれているなら、クライアントコードはSLP_TRUEを返すべきであり、そうでなければ、SLPはFALSEです。
Kempf & Guttman Informational [Page 32] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[32ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.3.4. SLPAttrCallback
4.3.4. SLPAttrCallback
4.3.4.1. Synopsis
4.3.4.1. 構文
typedef SLPBoolean SLPAttrCallback(SLPHandle hSLP,
const char* pcAttrList,
SLPError errCode,
void *pvCookie);
typedef SLPBoolean SLPAttrCallback(SLPHandle hSLP(const炭*pcAttrList、SLPError errCode)は*pvCookieを欠如させます)。
4.3.4.2. Description
4.3.4.2. 記述
The SLPAttrCallback type is the type of the callback function parameter to SLPFindAttrs() function.
SLPAttrCallbackタイプはSLPFindAttrs()機能へのコールバック関数パラメータのタイプです。
The behavior of the callback differs depending on whether the attribute request was by URL or by service type. If the SLPFindAttrs() operation was originally called with a URL, the callback is called once regardless of whether the handle was opened asynchronously or synchronously. The pcAttrList parameter contains the requested attributes as a comma separated list (or is empty if no attributes matched the original tag list).
属性要求がURLかサービスタイプであったかによって、コールバックの振舞いは異なります。 SLPFindAttrs()操作が元々URLで呼ばれたなら、ハンドルが非同期か同時開けられたかどうかにかかわらずコールバックは一度呼ばれます。 pcAttrListパラメタはコンマの切り離されたリスト(または、どんな属性もオリジナルのタグリストに合っていなかったなら、空である)として要求された属性を含んでいます。
If the SLPFindAttrs() operation was originally called with a service type, the value of pcAttrList and calling behavior depend on whether the handle was opened asynchronously or synchronously. If the handle was opened asynchronously, the callback is called every time the API library has results from a remote agent. The pcAttrList parameter MAY be uncollated between calls. It contains a comma separated list with the results from the agent that immediately returned results. If the handle was opened synchronously, the results must be collated from all returning agents and the callback is called once, with the pcAttrList parameter set to the collated result.
SLPFindAttrs()操作が元々、サービスタイプ、pcAttrListの値で呼ばれたか、そして、呼びかけ行動はハンドルが非同期か同時開けられたかどうかによります。 ハンドルが非同期に開けられたなら、APIライブラリにリモートエージェントからの結果があるときはいつも、コールバックは呼ばれます。 pcAttrListパラメタは呼び出しの間で非照合されるかもしれません。 それはすぐに結果を返したエージェントからの結果があるコンマの切り離されたリストを含んでいます。 ハンドルが同時開けられたなら、すべての戻っているエージェントから結果を照合しなければなりません、そして、コールバックは一度呼ばれます、照合された結果に設定されたpcAttrListパラメタで。
4.3.4.3. Parameters
4.3.4.3. パラメタ
hSLP
hSLP
The SLPHandle used to initiate the operation.
SLPHandleは以前はよく操作を開始していました。
pcAttrList
pcAttrList
A character buffer containing a comma separated, null
terminated list of attribute id/value assignments, in SLP wire
format; i.e. "(attr-id=attr-value-list)" [7].
SLPワイヤ形式における属性イド/価値の課題のコンマの切り離されて、ヌルの終えられたリストを含む文字バッファ。 すなわち「(attr-イドはattr-値リストと等しいです)」という、[7]。
Kempf & Guttman Informational [Page 33] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[33ページ]のRFC2614はAPI1999年6月に位置を修理します。
errCode
errCode
An error code indicating if an error occurred during the
operation. The callback should check this error code before
processing the parameters. If the error code is other than
SLP_OK, then the API library may choose to terminate the
outstanding operation.
誤りが操作の間、発生したかどうかを示すエラーコード。 パラメタを処理する前に、コールバックはこのエラーコードをチェックするべきです。 SLP_OKを除いて、エラーコードがあるなら、APIライブラリは、傑出している操作を終えるのを選ぶかもしれません。
pvCookie
pvCookie
Memory passed down from the client code that called the
original API function, starting the operation. May be NULL.
メモリはクライアントコードから操業を開始して、元のAPI関数と呼ばれるそれを伝えました。 NULLはそうです。
4.3.4.4. Returns
4.3.4.4. リターン
The client code should return SLP_TRUE if more data is desired, otherwise SLP_FALSE.
_より多くのデータが望まれているなら、クライアントコードはSLP_TRUEを返すべきであり、そうでなければ、SLPはFALSEです。
4.4. Opening and Closing an SLPHandle
4.4. SLPHandleを開いて、閉じます。
4.4.1. SLPOpen
4.4.1. SLPOpen
4.4.1.1. Synopsis
4.4.1.1. 構文
SLPError SLPOpen(const char *pcLang, SLPBoolean isAsync, SLPHandle *phSLP);
SLPError SLPOpen(const炭*pcLang、SLPBoolean isAsync、SLPHandle*phSLP)。
4.4.1.2. Description
4.4.1.2. 記述
Returns a SLPHandle handle in the phSLP parameter for the language locale passed in as the pcLang parameter. The client indicates if operations on the handle are to be synchronous or asynchronous through the isAsync parameter. The handle encapsulates the language locale for SLP requests issued through the handle, and any other resources required by the implementation. However, SLP properties are not encapsulated by the handle; they are global. The return value of the function is an SLPError code indicating the status of the operation. Upon failure, the phSLP parameter is NULL.
言語現場のためのphSLPパラメタのSLPHandleハンドルがpcLangパラメタとして通用したリターン。 クライアントは、ハンドルにおける操作がisAsyncパラメタを通して同時であるか、または非同期であるかことであることを示します。 ハンドルはハンドルを通して出されたSLP要求のために言語現場をカプセル化します、そして、いかなる他のリソースも実装が必要です。 しかしながら、SLPの特性はハンドルによってカプセル化されません。 それらはグローバルです。 機能のリターン値は操作の状態を示すSLPErrorコードです。 失敗では、phSLPパラメタはNULLです。
An SLPHandle can only be used for one SLP API operation at a time. If the original operation was started asynchronously, any attempt to start an additional operation on the handle while the original operation is pending results in the return of an SLP_HANDLE_IN_USE error from the API function. The SLPClose() API function terminates any outstanding calls on the handle. If an implementation is unable to support a asynchronous( resp. synchronous) operation, due to memory constraints or lack of threading support, the SLP_NOT_IMPLEMENTED flag may be returned when the isAsync flag is
一度に、1つのSLP API操作にSLPHandleを使用できるだけです。 オリジナルの操業が非同期に開始されたなら、オリジナルの操作が未定である間に兼業をハンドルに始めるどんな試みもAPI関数からのSLP_HANDLE_IN_USE誤りの復帰をもたらします。 SLPClose()API関数はハンドルにおけるどんな傑出している呼び出しも終えます。 aサポートに非同期な状態で実装であることができません。(resp、同期、)、操作、isAsync旗が返すとき、縫うように通るサポートのメモリ規制か不足のため、IMPLEMENTEDが旗を揚げさせる_ではなく、SLP_を返すかもしれません。
Kempf & Guttman Informational [Page 34] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[34ページ]のRFC2614はAPI1999年6月に位置を修理します。
SLP_TRUE (resp. SLP_FALSE).
SLP、_本当に。(resp。 SLP_偽).
4.4.1.3. Parameters
4.4.1.3. パラメタ
pcLang
pcLang
A pointer to an array of characters containing the RFC 1766
Language Tag [6] for the natural language locale of requests
and registrations issued on the handle.
ハンドルの上に出された要求と登録証明書の自然言語現場へのRFC1766Language Tag[6]を含むキャラクタの配列への指針。
isAsync
isAsync
An SLPBoolean indicating whether the SLPHandle should be opened
for asynchronous operation or not.
SLPHandleが非同期動作のために開かれるべきであるかどうかを示すSLPBoolean。
phSLP
phSLP
A pointer to an SLPHandle, in which the open SLPHandle is
returned. If an error occurs, the value upon return is NULL.
SLPHandleへの指針。そこでは、開いているSLPHandleが返されます。 誤りが発生するなら、リターンの値はNULLです。
4.4.2. SLPClose
4.4.2. SLPClose
4.4.2.1. Synopsis
4.4.2.1. 構文
void SLPClose(SLPHandle hSLP);
SLPClose(SLPHandle hSLP)を欠如させてください。
4.4.2.2. Description
4.4.2.2. 記述
Frees all resources associated with the handle. If the handle was invalid, the function returns silently. Any outstanding synchronous or asynchronous operations are cancelled so their callback functions will not be called any further.
ハンドルに関連しているすべてのリソースを解放します。 ハンドルが無効であったなら、機能は静かに戻ります。 どんな傑出している同期や非同期動作も中止されるので、それらのコールバック機能はこれ以上呼ばれないでしょう。
4.4.2.3. Parameters
4.4.2.3. パラメタ
SLPHandle
SLPHandle
A SLPHandle handle returned from a call to SLPOpen().
SLPHandleハンドルは呼び出しからSLPOpen()まで戻りました。
Kempf & Guttman Informational [Page 35] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[35ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.5. Protocol API
4.5. プロトコルAPI
4.5.1. SLPReg
4.5.1. SLPReg
4.5.1.1. Synopsis
4.5.1.1. 構文
SLPError SLPReg(SLPHandle hSLP,
const char *pcSrvURL,
const unsigned short usLifetime,
const char *pcSrvType,
const char *pcAttrs
SLPBoolean fresh,
SLPRegReport callback,
void *pvCookie);
SLPError SLPReg(SLPHandle hSLP、const炭*pcSrvURL、constの未署名の短いusLifetime、const炭*pcSrvType(新鮮なconst炭*pcAttrs SLPBoolean SLPRegReportコールバック)は*pvCookieを欠如させます)。
4.5.1.2. Description
4.5.1.2. 記述
Registers the URL in pcSrvURL having the lifetime usLifetime with the attribute list in pcAttrs. The pcAttrs list is a comma separated list of attribute assignments in the wire format (including escaping of reserved characters). The usLifetime parameter must be nonzero and less than or equal to SLP_LIFETIME_MAXIMUM. If the fresh flag is SLP_TRUE, then the registration is new (the SLP protocol FRESH flag is set) and the registration replaces any existing registrations. The pcSrvType parameter is a service type name and can be included for service URLs that are not in the service: scheme. If the URL is in the service: scheme, the pcSrvType parameter is ignored. If the fresh flag is SLP_FALSE, then an existing registration is updated. Rules for new and updated registrations, and the format for pcAttrs and pcScopeList can be found in [7]. Registrations and updates take place in the language locale of the hSLP handle.
属性リストがpcAttrsにある状態で生涯usLifetimeを持ちながら、pcSrvURLにURLを登録します。 pcAttrsリストはワイヤ形式における属性課題のコンマの切り離されたリスト(控え目なキャラクタに逃げるのを含んでいて)です。 _usLifetimeパラメタは非零であるに違いなく、よりSLP_LIFETIMEはMAXIMUMです。 新鮮な旗がSLP_TRUEであるなら、登録は新しいです、そして、(SLPプロトコルFRESH旗は設定されます)登録はどんな既存の登録証明書にも取って代わります。 pcSrvTypeパラメタは、サービス型名であり、サービス中でないサービスURLのために含むことができます: 計画してください。 URLがサービス中であるなら: 計画してください、そして、pcSrvTypeパラメタは無視されます。 新鮮な旗がSLP_FALSEであるなら、既存の登録をアップデートします。 [7]でpcAttrsとpcScopeListを見つけることができるので、新しくてアップデートされた登録証明書、および形式のために統治します。 登録証明書とアップデートはhSLPハンドルの言語現場で行われます。
The API library is required to perform the operation in all scopes obtained through configuration.
APIライブラリは構成を通して入手されたすべての範囲で操作を実行しなければなりません。
4.5.1.3. Parameters
4.5.1.3. パラメタ
hSLP
hSLP
The language specific SLPHandle on which to register the
advertisement.
広告を登録する言語の特定のSLPHandle。
pcSrvURL
pcSrvURL
The URL to register. May not be the empty string.
登録するURL。 空のストリングでないかもしれません。
Kempf & Guttman Informational [Page 36] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[36ページ]のRFC2614はAPI1999年6月に位置を修理します。
usLifetime
usLifetime
An unsigned short giving the life time of the service
advertisement, in seconds. The value must be an unsigned
integer less than or equal to SLP_LIFETIME_MAXIMUM and greater
than zero.
秒のサービス広告の寿命時間の未署名の短い付与。 値はゼロよりSLP_LIFETIME_MAXIMUMの、そして、大きい符号のない整数でなければなりません。
pcSrvType
pcSrvType
The service type. If pURL is a service: URL, then this
parameter is ignored.
サービスタイプ。 pURLがサービスであるなら: URL、次にこのパラメタは無視されます。
pcAttrs
pcAttrs
A comma separated list of attribute assignment expressions for
the attributes of the advertisement. Use empty string, "" for
no attributes.
コンマは広告の属性のための属性代入式のリストを切り離しました。 空のストリングを使用してください、「「どんな属性のためにもそうしない、」
fresh
新鮮
An SLPBoolean that is SLP_TRUE if the registration is new or
SLP_FALSE if a reregistration.
再登録であるなら登録が新しいかSLP_FALSEであるならSLP_TRUEであるSLPBoolean。
callback
コールバック
A callback to report the operation completion status.
操作完成状態を報告するコールバック。
pvCookie
pvCookie
Memory passed to the callback code from the client. May be
NULL.
メモリはクライアントよりコールバックコードに移りました。 NULLはそうです。
4.5.1.4. Returns
4.5.1.4. リターン
If an error occurs in starting the operation, one of the SLPError codes is returned.
誤りが操業を開始する際に発生するなら、SLPErrorコードの1つを返します。
4.5.2. SLPDereg
4.5.2. SLPDereg
4.5.2.1. Synopsis
4.5.2.1. 構文
SLPError SLPDereg(SLPHandle hSLP,
const char *pcURL,
SLPRegReport callback,
void *pvCookie);
SLPError SLPDereg(SLPHandle hSLP(const炭*pcURL、SLPRegReportコールバック)は*pvCookieを欠如させます)。
Kempf & Guttman Informational [Page 37] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[37ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.5.2.2. Description
4.5.2.2. 記述
Deregisters the advertisement for URL pcURL in all scopes where the service is registered and all language locales. The deregistration is not just confined to the locale of the SLPHandle, it is in all locales. The API library is required to perform the operation in all scopes obtained through configuration.
サービスが登録されているところで全部でURL pcURLのための広告が見るDeregistersとすべての言語現場。 反登録はただSLPHandleの現場に閉じ込められないで、それはすべての現場にあります。 APIライブラリは構成を通して入手されたすべての範囲で操作を実行しなければなりません。
4.5.2.3. Parameters
4.5.2.3. パラメタ
hSLP
hSLP
The language specific SLPHandle to use for deregistering.
反登録する使用への言語の特定のSLPHandle。
pcURL
pcURL
The URL to deregister. May not be the empty string.
「反-レジスタ」へのURL。 空のストリングでないかもしれません。
callback
コールバック
A callback to report the operation completion status.
操作完成状態を報告するコールバック。
pvCookie
pvCookie
Memory passed to the callback code from the client. May be
NULL.
メモリはクライアントよりコールバックコードに移りました。 NULLはそうです。
4.5.2.4. Returns
4.5.2.4. リターン
If an error occurs in starting the operation, one of the SLPError codes is returned.
誤りが操業を開始する際に発生するなら、SLPErrorコードの1つを返します。
4.5.3. SLPDelAttrs
4.5.3. SLPDelAttrs
4.5.3.1. Synopsis
4.5.3.1. 構文
SLPError SLPDelAttrs(SLPHandle hSLP,
const char *pcURL,
const char *pcAttrs,
SLPRegReport callback,
void *pvCookie);
SLPError SLPDelAttrs(SLPHandle hSLP(const炭*pcURL、const炭*pcAttrs、SLPRegReportコールバック)は*pvCookieを欠如させます)。
Kempf & Guttman Informational [Page 38] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[38ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.5.3.2. Description
4.5.3.2. 記述
Delete the selected attributes in the locale of the SLPHandle. The API library is required to perform the operation in all scopes obtained through configuration.
SLPHandleの現場で選択された属性を削除してください。 APIライブラリは構成を通して入手されたすべての範囲で操作を実行しなければなりません。
4.5.3.3. Parameters
4.5.3.3. パラメタ
hSLP
hSLP
The language specific SLPHandle to use for deleting attributes.
属性を削除する使用への言語の特定のSLPHandle。
pcURL
pcURL
The URL of the advertisement from which the attributes should
be deleted. May not be the empty string.
属性が削除されるべきである広告のURL。 空のストリングでないかもしれません。
pcAttrs
pcAttrs
A comma separated list of attribute ids for the attributes to
deregister. See Section 9.8 in [7] for a description of the
list format. May not be the empty string.
コンマは属性のために属性イドのリストを「反-レジスタ」に切り離しました。 リスト形態の記述のための[7]でセクション9.8を見てください。 空のストリングでないかもしれません。
callback
コールバック
A callback to report the operation completion status.
操作完成状態を報告するコールバック。
pvCookie
pvCookie
Memory passed to the callback code from the client. May be
NULL.
メモリはクライアントよりコールバックコードに移りました。 NULLはそうです。
4.5.3.4. Returns
4.5.3.4. リターン
If an error occurs in starting the operation, one of the SLPError codes is returned.
誤りが操業を開始する際に発生するなら、SLPErrorコードの1つを返します。
4.5.4. SLPFindSrvTypes
4.5.4. SLPFindSrvTypes
4.5.4.1. Synopsis
4.5.4.1. 構文
SLPError SLPFindSrvTypes(SLPHandle hSLP,
const char *pcNamingAuthority,
const char *pcScopeList,
SLPSrvTypeCallback callback,
void *pvCookie);
SLPError SLPFindSrvTypes(SLPHandle hSLP(const炭*pcNamingAuthority、const炭*pcScopeList、SLPSrvTypeCallbackコールバック)は*pvCookieを欠如させます)。
Kempf & Guttman Informational [Page 39] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[39ページ]のRFC2614はAPI1999年6月に位置を修理します。
The SLPFindSrvType() function issues an SLP service type request for service types in the scopes indicated by the pcScopeList. The results are returned through the callback parameter. The service types are independent of language locale, but only for services registered in one of scopes and for the indicated naming authority.
SLPFindSrvType()機能はpcScopeListによって示された範囲でタイプがサービスのために要求するSLPサービスにタイプを発行します。 結果はコールバックパラメタを通して返されます。 サービスタイプは、言語現場から独立していますが、範囲の1つに登録されたサービスだけと示された命名権威のために独立しています。
If the naming authority is "*", then results are returned for all naming authorities. If the naming authority is the empty string, i.e. "", then the default naming authority, "IANA", is used. "IANA" is not a valid naming authority name, and it is a PARAMETER_BAD error to include it explicitly.
命名権威が「*」であるなら、結果はすべての命名当局のために返されます。 命名権威がすなわち、空のストリングである、「「次に、デフォルトが権威を命名することでの"IANA"は使用されています」。 "IANA"は妥当な命名権威名ではありません、そして、それは明らかにそれを含むPARAMETER_BAD誤りです。
The service type names are returned with the naming authority intact. If the naming authority is the default (i.e. empty string) then it is omitted, as is the separating ".". Service type names from URLs of the service: scheme are returned with the "service:" prefix intact. [7] See [8] for more information on the syntax of service type names.
命名権威が完全な状態でサービス型名を返します。 「命名権威がデフォルト(すなわち、空のストリング)であるなら、それは分離のように省略される」、」 サービスのURLから型名を修理してください: 体系がともに帰られる、「サービス:」 接頭語完全です。 [7] サービス型名の構文に関する詳しい情報のための[8]を見てください。
4.5.4.2. Parameters
4.5.4.2. パラメタ
hSLP
hSLP
The SLPHandle on which to search for types.
どれが探されるかのSLPHandleはタイプします。
pcNamingAuthority
pcNamingAuthority
The naming authority to search. Use "*" for all naming
authorities and the empty string, "", for the default naming
authority.
探す命名権威。 すべての命名当局と空のストリングに「*」を使用してください、「「権威を命名するデフォルトのために」
pcScopeList
pcScopeList
A pointer to a char containing comma separated list of scope
names to search for service types. May not be the empty
string, "".
コンマを含む炭への指針は、サービスタイプを捜し求めるために範囲名のリストを切り離しました。 空のストリングでないかもしれない、「「.」
callback
コールバック
A callback function through which the results of the operation
are reported.
操作の結果が報告されるコールバック機能。
pvCookie
pvCookie
Memory passed to the callback code from the client. May be
NULL.
メモリはクライアントよりコールバックコードに移りました。 NULLはそうです。
Kempf & Guttman Informational [Page 40] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[40ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.5.4.3. Returns
4.5.4.3. リターン
If an error occurs in starting the operation, one of the SLPError codes is returned.
誤りが操業を開始する際に発生するなら、SLPErrorコードの1つを返します。
4.5.5. SLPFindSrvs
4.5.5. SLPFindSrvs
4.5.5.1. Synopsis
4.5.5.1. 構文
SLPError SLPFindSrvs(SLPHandle hSLP,
const char *pcServiceType,
const char *pcScopeList,
const char *pcSearchFilter,
SLPSrvURLCallback callback,
void *pvCookie);
SLPError SLPFindSrvs(SLPHandle hSLP(const炭*pcServiceType、const炭*pcScopeList、const炭*pcSearchFilter、SLPSrvURLCallbackコールバック)は*pvCookieを欠如させます)。
4.5.5.2. Description
4.5.5.2. 記述
Issue the query for services on the language specific SLPHandle and return the results through the callback. The parameters determine the results
言語の特定のSLPHandleでサービスのための質問を発行してください、そして、コールバックを通して結果を返してください。 パラメタは結果を決定します。
4.5.5.3. Parameters
4.5.5.3. パラメタ
hSLP
hSLP
The language specific SLPHandle on which to search for
services.
サービスを捜し求める言語の特定のSLPHandle。
pcServiceType
pcServiceType
The Service Type String, including authority string if any, for
the request, such as can be discovered using SLPSrvTypes().
This could be, for example "service:printer:lpr" or
"service:nfs". May not be the empty string.
SLPSrvTypes()を使用していると発見できるような要求のためにもしあれば権威ストリングを含むService Type String。 これは、例えば、「: プリンタ: lprを調整してください」ということであるか「: nfsを調整するかもしれません」。 空のストリングでないかもしれません。
pcScopeList
pcScopeList
A pointer to a char containing comma separated list of scope
names. May not be the empty string, "".
コンマを含む炭への指針は範囲名のリストを切り離しました。 空のストリングでないかもしれない、「「.」
pcSearchFilter
pcSearchFilter
A query formulated of attribute pattern matching expressions in
the form of a LDAPv3 Search Filter, see [4]. If this filter
is empty, i.e. "", all services of the requested type in the
質問がLDAPv3検索Filterの形で属性パターン・マッチング式について定式化されて、[4]を見てください。 このフィルタがすなわち、空である、「「要求のサービスがタイプするすべて、」
Kempf & Guttman Informational [Page 41] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[41ページ]のRFC2614はAPI1999年6月に位置を修理します。
specified scopes are returned.
指定された範囲を返します。
callback
コールバック
A callback function through which the results of the operation
are reported.
操作の結果が報告されるコールバック機能。
pvCookie
pvCookie
Memory passed to the callback code from the client. May be
NULL.
メモリはクライアントよりコールバックコードに移りました。 NULLはそうです。
4.5.5.4. Returns
4.5.5.4. リターン
If an error occurs in starting the operation, one of the SLPError codes is returned.
誤りが操業を開始する際に発生するなら、SLPErrorコードの1つを返します。
4.5.6. SLPFindAttrs
4.5.6. SLPFindAttrs
4.5.6.1. Synopsis
4.5.6.1. 構文
SLPError SLPFindAttrs(SLPHandle hSLP,
const char *pcURLOrServiceType,
const char *pcScopeList,
const char *pcAttrIds,
SLPAttrCallback callback,
void *pvCookie);
SLPError SLPFindAttrs(SLPHandle hSLP(const炭*pcURLOrServiceType、const炭*pcScopeList、const炭*pcAttrIds、SLPAttrCallbackコールバック)は*pvCookieを欠如させます)。
4.5.6.2. Description
4.5.6.2. 記述
This function returns service attributes matching the attribute ids for the indicated service URL or service type. If pcURLOrServiceType is a service URL, the attribute information returned is for that particular advertisement in the language locale of the SLPHandle.
この機能は示されたサービスURLかサービスタイプのために属性イドに合っているサービス属性を返します。 pcURLOrServiceTypeがサービスURLであるなら、情報が返した属性はその特定の広告のためにSLPHandleの言語現場にあります。
If pcURLOrServiceType is a service type name (including naming authority if any), then the attributes for all advertisements of that service type are returned regardless of the language of registration. Results are returned through the callback.
pcURLOrServiceTypeがサービス型名(もしあれば権威を命名するのを含んでいる)であるなら、そのサービスタイプのすべての広告のための属性は登録の言語にかかわらず返されます。 結果はコールバックを通して返されます。
The result is filtered with an SLP attribute request filter string parameter, the syntax of which is described in [7]. If the filter string is the empty string, i.e. "", all attributes are returned.
結果はSLP属性要求フィルタストリングパラメタでフィルターにかけられます。その構文は[7]で説明されます。 フィルタストリングがすなわち、空のストリングである、「「すべての属性が返される、」
Kempf & Guttman Informational [Page 42] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[42ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.5.6.3. Parameters
4.5.6.3. パラメタ
hSLP
hSLP
The language specific SLPHandle on which to search for
attributes.
属性を捜し求める言語の特定のSLPHandle。
pcURLOrServiceType
pcURLOrServiceType
The service URL or service type. See [7] for URL and service
type syntax. May not be the empty string.
サービスURLかサービスタイプ。 URLとサービスのための[7]が構文をタイプするのを見てください。 空のストリングでないかもしれません。
pcScopeList
pcScopeList
A pointer to a char containing a comma separated list of scope
names. May not be the empty string, "".
コンマを含む炭への指針は範囲名のリストを切り離しました。 空のストリングでないかもしれない、「「.」
pcAttrIds
pcAttrIds
The filter string indicating which attribute values to return.
Use empty string, "", to indicate all values. Wildcards
matching all attribute ids having a particular prefix or suffix
are also possible. See [7] for the exact format of the filter
string.
どの属性値を返したらよいかを示すフィルタストリング。 空のストリングを使用してください、「「すべての値を示すために」 また、特定の接頭語か接尾語を持っているすべての属性イドに合っているワイルドカードも可能です。 フィルタストリングの正確な形式のための[7]を見てください。
callback
コールバック
A callback function through which the results of the operation
are reported.
操作の結果が報告されるコールバック機能。
pvCookie
pvCookie
Memory passed to the callback code from the client. May be
NULL.
メモリはクライアントよりコールバックコードに移りました。 NULLはそうです。
4.5.6.4. Returns
4.5.6.4. リターン
If an error occurs in starting the operation, one of the SLPError codes is returned.
誤りが操業を開始する際に発生するなら、SLPErrorコードの1つを返します。
4.6. Miscellaneous Functions
4.6. 補助機能
4.6.1. SLPGetRefreshInterval
4.6.1. SLPGetRefreshInterval
4.6.1.1. Synopsis
4.6.1.1. 構文
unsigned short SLPGetRefreshInterval();
未署名の短いSLPGetRefreshInterval()。
Kempf & Guttman Informational [Page 43] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[43ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.6.1.2. Description
4.6.1.2. 記述
Returns the maximum across all DAs of the min-refresh-interval attribute. This value satisfies the advertised refresh interval bounds for all DAs, and, if used by the SA, assures that no refresh registration will be rejected. If no DA advertises a min-refresh- interval attribute, a value of 0 is returned.
分が間隔が壮快な属性のすべてのDAsの向こう側に最大を返します。 広告を出すのは、すべてのDAsのために間隔領域をリフレッシュして、SAによって使用されるなら、いいえが登録をリフレッシュすることを保証します。この値が満足する、拒絶されるでしょう。 どんなDAも分間隔をリフレッシュしている属性の広告を出さないなら、0の値を返します。
4.6.1.3. Returns
4.6.1.3. リターン
If no error, the maximum refresh interval value allowed by all DAs (a positive integer). If no DA advertises a min-refresh-interval attribute, returns 0. If an error occurs, returns an SLP error code.
誤りがない、最大がすべてのDAs(正の整数)によって許容された間隔値をリフレッシュするなら。 どんなDAも分が間隔が壮快な属性の広告を出さないなら、リターン0です。 誤りが発生するなら、SLP誤りがコード化するリターンです。
4.6.2. SLPFindScopes
4.6.2. SLPFindScopes
4.6.2.1. Synopsis
4.6.2.1. 構文
SLPError SLPFindScopes(SLPHandle hSLP,
char** ppcScopeList);
SLPError SLPFindScopes(SLPHandle hSLP、炭の**ppcScopeList)。
4.6.2.2. Description
4.6.2.2. 記述
Sets ppcScopeList parameter to a pointer to a comma separated list
including all available scope values. The list of scopes comes from
a variety of sources: the configuration file's net.slp.useScopes
property, unicast to DAs on the net.slp.DAAddresses property, DHCP,
or through the DA discovery process. If there is any order to the
scopes, preferred scopes are listed before less desirable scopes.
There is always at least one name in the list, the default scope,
"DEFAULT".
すべての利用可能な範囲値を含むコンマの切り離されたリストへの指針にppcScopeListパラメタを設定します。 範囲のリストはさまざまなソースから来ます: 構成ファイルのnet.slp.useScopesの特性、DHCP、または終えたnet.slp.DAAddresses所有地の上のDAsへのユニキャスト、DA発見プロセス。 何か範囲へのオーダーがあれば、都合のよい範囲はそれほど望ましくない範囲の前に記載されます。 少なくとも1つの名前がいつもリスト、デフォルト範囲、「デフォルト」であります。
4.6.2.3. Parameters
4.6.2.3. パラメタ
hSLP
hSLP
The SLPHandle on which to search for scopes.
範囲を捜し求めるSLPHandle。
ppcScopeList
ppcScopeList
A pointer to char pointer into which the buffer pointer is
placed upon return. The buffer is null terminated. The memory
should be freed by calling SLPFree().
リターンに置かれた状態でバッファ指針がある指針を炭にする指針。 バッファは終えられた状態でヌルです。 SLPFree()と呼ぶことによって、メモリは解放されるべきです。
Kempf & Guttman Informational [Page 44] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[44ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.6.2.4. Returns
4.6.2.4. リターン
If no error occurs, returns SLP_OK, otherwise, the appropriate error code.
起こって、そうでなければ、どんな誤りもSLP_OKを返さないなら、適切なエラーコードです。
4.6.3. SLPParseSrvURL
4.6.3. SLPParseSrvURL
4.6.3.1. Synopsis
4.6.3.1. 構文
SLPError SLPParseSrvURL(char *pcSrvURL
SLPSrvURL** ppSrvURL);
SLPError SLPParseSrvURL(炭*pcSrvURL SLPSrvURL**ppSrvURL)。
4.6.3.2. Description
4.6.3.2. 記述
Parses the URL passed in as the argument into a service URL structure and returns it in the ppSrvURL pointer. If a parse error occurs, returns SLP_PARSE_ERROR. The input buffer pcSrvURL is destructively modified during the parse and used to fill in the fields of the return structure. The structure returned in ppSrvURL should be freed with SLPFreeURL(). If the URL has no service part, the s_pcSrvPart string is the empty string, "", i.e. not NULL. If pcSrvURL is not a service: URL, then the s_pcSrvType field in the returned data structure is the URL's scheme, which might not be the same as the service type under which the URL was registered. If the transport is IP, the s_pcTransport field is the empty string. If the transport is not IP or there is no port number, the s_iPort field is zero.
サービスURL構造に議論として通過されたURLを分析して、ppSrvURL指針でそれを返します。 aが分析されるなら、誤りは発生して、リターンはSLP_PARSE_ERRORです。 入力バッファpcSrvURLが破壊的に変更される、分析して、以前は中によくリターン構造の分野をいっぱいにしていました。 ppSrvURLで返された構造はSLPFreeURL()と共に解放されるべきです。 URLにサービス部分が全くないなら、s_pcSrvPartストリングが空のストリングである、「「すなわち、ヌルでない、」 pcSrvURLがサービスでないなら: URL、そして、返されたデータ構造におけるs_pcSrvType分野はURL体系です。(その体系はURLが登録されたサービスタイプと同じでないかもしれません)。 輸送がIPであるなら、s_pcTransport分野は空のストリングです。 輸送がIPでないポートナンバーが全くなければ、s_iPort分野はゼロです。
4.6.3.3. Parameters
4.6.3.3. パラメタ
pcSrvURL
pcSrvURL
A pointer to a character buffer containing the null terminated
URL string to parse. It is destructively modified to produce
the output structure.
ヌルを含む文字バッファへの指針は、分析するためにURLストリングを終えました。 出力構造を発生させるのは破壊的に変更されています。
ppSrvURL
ppSrvURL
A pointer to a pointer for the SLPSrvURL structure to receive
the parsed URL. The memory should be freed by a call to
SLPFree() when no longer needed.
分析されたURLを受けるSLPSrvURL構造への指針への指針。 もう必要でないと、メモリはSLPFree()への呼び出しで解放されるべきです。
4.6.3.4. Returns
4.6.3.4. リターン
If no error occurs, the return value is SLP_OK. Otherwise, the appropriate error code is returned.
誤りが全く発生しないなら、リターン値は_OKにSLPです。 さもなければ、適切なエラーコードは返されます。
Kempf & Guttman Informational [Page 45] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[45ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.6.4. SLPEscape
4.6.4. SLPEscape
4.6.4.1. Synopsis
4.6.4.1. 構文
SLPError SLPEscape(const char* pcInbuf,
char** ppcOutBuf,
SLPBoolean isTag);
SLPError SLPEscape(const炭*のpcInbuf、炭の**ppcOutBuf、SLPBoolean isTag)。
4.6.4.2. Description
4.6.4.2. 記述
Process the input string in pcInbuf and escape any SLP reserved characters. If the isTag parameter is SLPTrue, then look for bad tag characters and signal an error if any are found by returning the SLP_PARSE_ERROR code. The results are put into a buffer allocated by the API library and returned in the ppcOutBuf parameter. This buffer should be deallocated using SLPFree() when the memory is no longer needed.
pcInbufで入力ストリングを処理してください、そして、あらゆるSLPの控え目なキャラクタから逃げてください。 isTagパラメタがSLPTrueであるなら、悪いタグキャラクタを探してください、そして、いずれかSLP_PARSE_ERRORコードを返すことによって見つけられるなら、誤りに合図してください。 APIライブラリによって割り当てられて、ppcOutBufパラメタで返されたバッファに結果を入れます。 このバッファは、メモリがもう必要でないときに、SLPFree()を使用することで「反-割り当て」られるべきです。
4.6.4.3. Parameters
4.6.4.3. パラメタ
pcInbuf
pcInbuf
Pointer to he input buffer to process for escape characters.
指針、彼は、拡張文字のために処理するためにバッファを入力しました。
ppcOutBuf
ppcOutBuf
Pointer to a pointer for the output buffer with the SLP
reserved characters escaped. Must be freed using SLPFree()
when the memory is no longer needed.
SLPの控え目なキャラクタを伴う出力バッファのための指針への指針は逃げられました。 メモリはもう必要でないときに、SLPFree()を使用して、解放しなければなりません。
isTag
isTag
When true, the input buffer is checked for bad tag characters.
本当であるときに、入力バッファは悪いタグキャラクタがないかどうかチェックされます。
4.6.4.4. Returns
4.6.4.4. リターン
Return SLP_PARSE_ERROR if any characters are bad tag characters and the isTag flag is true, otherwise SLP_OK, or the appropriate error code if another error occurs.
別の誤りが発生するなら、何かキャラクタが悪いタグキャラクタであり、isTag旗が本当であるか、そして、そうでなければ、SLP_OKか適切なエラーコードをSLP_PARSE_ERRORに返してください。
Kempf & Guttman Informational [Page 46] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[46ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.6.5. SLPUnescape
4.6.5. SLPUnescape
4.6.5.1. Synopsis
4.6.5.1. 構文
SLPError SLPUnescape(const char* pcInbuf,
char** ppcOutBuf,
SLPBoolean isTag);
SLPError SLPUnescape(const炭*のpcInbuf、炭の**ppcOutBuf、SLPBoolean isTag)。
4.6.5.2. Description
4.6.5.2. 記述
Process the input string in pcInbuf and unescape any SLP reserved characters. If the isTag parameter is SLPTrue, then look for bad tag characters and signal an error if any are found with the SLP_PARSE_ERROR code. No transformation is performed if the input string is an opaque. The results are put into a buffer allocated by the API library and returned in the ppcOutBuf parameter. This buffer should be deallocated using SLPFree() when the memory is no longer needed.
pcInbufで入力ストリングを処理してください。そうすれば、「非-エスケープ」はどんなSLPの控え目なキャラクタも処理します。 isTagパラメタがSLPTrueであるなら、悪いタグキャラクタを探してください、そして、いずれかSLP_PARSE_ERRORコードで見つけられるなら、誤りに合図してください。 変換は全く入力ストリングが不透明なものであるなら実行されません。 APIライブラリによって割り当てられて、ppcOutBufパラメタで返されたバッファに結果を入れます。 このバッファは、メモリがもう必要でないときに、SLPFree()を使用することで「反-割り当て」られるべきです。
4.6.5.3. Parameters
4.6.5.3. パラメタ
pcInbuf
pcInbuf
Pointer to he input buffer to process for escape characters.
指針、彼は、拡張文字のために処理するためにバッファを入力しました。
ppcOutBuf
ppcOutBuf
Pointer to a pointer for the output buffer with the SLP
reserved characters escaped. Must be freed using SLPFree()
when the memory is no longer needed.
SLPの控え目なキャラクタを伴う出力バッファのための指針への指針は逃げられました。 メモリはもう必要でないときに、SLPFree()を使用して、解放しなければなりません。
isTag
isTag
When true, the input buffer is checked for bad tag characters.
本当であるときに、入力バッファは悪いタグキャラクタがないかどうかチェックされます。
4.6.5.4. Returns
4.6.5.4. リターン
Return SLP_PARSE_ERROR if any characters are bad tag characters and the isTag flag is true, otherwise SLP_OK, or the appropriate error code if another error occurs.
別の誤りが発生するなら、何かキャラクタが悪いタグキャラクタであり、isTag旗が本当であるか、そして、そうでなければ、SLP_OKか適切なエラーコードをSLP_PARSE_ERRORに返してください。
Kempf & Guttman Informational [Page 47] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[47ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.6.6. SLPFree
4.6.6. SLPFree
4.6.6.1. Synopsis
4.6.6.1. 構文
void SLPFree(void* pvMem);
SLPFree(空間*pvMem)を欠如させてください。
4.6.6.2. Description
4.6.6.2. 記述
Frees memory returned from SLPParseSrvURL(), SLPFindScopes(), SLPEscape(), and SLPUnescape().
SLPParseSrvURL()、SLPFindScopes()、SLPEscape()、およびSLPUnescape()から返されたメモリを解放します。
4.6.6.3. Parameters
4.6.6.3. パラメタ
pvMem
pvMem
A pointer to the storage allocated by the SLPParseSrvURL(),
SLPEscape(), SLPUnescape(), or SLPFindScopes() function.
Ignored if NULL.
SLPParseSrvURL()、SLPEscape()、SLPUnescape()、またはSLPFindScopes()機能によって割り当てられたストレージへの指針。 無視されていますが、ヌルです。
4.6.7. SLPGetProperty
4.6.7. SLPGetProperty
4.6.7.1. Synopsis
4.6.7.1. 構文
const char* SLPGetProperty(const char* pcName);
const炭*SLPGetProperty(const炭*pcName)。
4.6.7.2. Description
4.6.7.2. 記述
Returns the value of the corresponding SLP property name. The returned string is owned by the library and MUST NOT be freed.
対応するSLP特性の名の値を返します。 返されたストリングを、ライブラリが所有して、解放してはいけません。
4.6.7.3. Parameters
4.6.7.3. パラメタ
pcName
pcName
Null terminated string with the property name, from
Section 2.1.
ヌルはセクション2.1からの特性の名でストリングを終えました。
4.6.7.4. Returns
4.6.7.4. リターン
If no error, returns a pointer to a character buffer containing the property value. If the property was not set, returns the default value. If an error occurs, returns NULL. The returned string MUST NOT be freed.
誤りでないなら、資産価値を含むキャラクタへの指針がバッファリングするリターンです。 特性が設定されなかったなら、デフォルトが評価するリターンです。 誤りが発生するなら、リターンNULLです。 返されたストリングを解放してはいけません。
Kempf & Guttman Informational [Page 48] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[48ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.6.8. SLPSetProperty
4.6.8. SLPSetProperty
4.6.8.1. Synopsis
4.6.8.1. 構文
void SLPSetProperty(const char *pcName,
const char *pcValue);
SLPSetProperty(const炭*pcName、const炭*pcValue)を欠如させてください。
4.6.8.2. Description
4.6.8.2. 記述
Sets the value of the SLP property to the new value. The pcValue parameter should be the property value as a string.
新しい値へのSLP属性の価値を設定します。 pcValueパラメタはストリングとして資産価値であるべきです。
4.6.8.3. Parameters
4.6.8.3. パラメタ
pcName
pcName
Null terminated string with the property name, from
Section 2.1.
ヌルはセクション2.1からの特性の名でストリングを終えました。
pcValue
pcValue
Null terminated string with the property value, in UTF-8
character encoding.
ヌルはUTF-8文字符号化における資産価値でストリングを終えました。
4.7. Implementation Notes
4.7. 実装注意
4.7.1. Refreshing Registrations
4.7.1. 壮快な登録証明書
Clients indicate that they want URLs to be automatically refreshed by setting the usLifetime parameter in the SLPReg() function call to SLP_LIFETIME_MAXIMUM. This will cause the API implementation to refresh the URL before it times out. Although using SLP_LIFETIME_MAXIMUM to designate automatic reregistration means that a transient URL can't be registered for the maximum lifetime, little hardship is likely to occur, since service URL lifetimes are measured in seconds and the client can simply use a lifetime of SLP_LIFETIME_MAXIMUM - 1 if a transient URL near the maximum lifetime is desired. API implementations MUST provide this facility.
クライアントは、彼らがSLPReg()ファンクションコールにusLifetimeパラメタをはめ込むことによって自動的にSLP_LIFETIME_MAXIMUMにURLをリフレッシュして欲しいのを示します。 API実行はそれの前にこれでURLをリフレッシュするでしょう。回のアウト。 クライアントは単にSLP_LIFETIME_MAXIMUMの生涯を費やすことができます--SLP_を使用しますが、自動再登録を指定するLIFETIME_MAXIMUMは、最大の生涯に一時的なURLを登録できないことを意味します、そして、少ない苦労が起こりそうです、そして、サービス以来、URL寿命は秒に測定されます、そして、1は最大の生涯頃の一時的なURLであるなら望まれています。 API実行はこの施設を提供しなければなりません。
4.7.2. Syntax for String Parameters
4.7.2. ストリングパラメタのための構文
Query strings, attribute registration lists, attribute deregistration lists, scope lists, and attribute selection lists follow the syntax described in [7] for the appropriate requests. The API directly reflects the strings passed in from clients into protocol requests, and directly reflects out strings returned from protocol replies to
質問ストリング、属性有権者名簿、属性反登録リスト、範囲リスト、および属性選択リストは適切な要求のための[7]で説明された構文に従います。 APIは、直接クライアントより中に移られたストリングをプロトコル要求に反映して、直接ストリングがプロトコル回答から戻ったアウトを反映します。
Kempf & Guttman Informational [Page 49] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[49ページ]のRFC2614はAPI1999年6月に位置を修理します。
clients. As a consequence, clients are responsible for formatting request strings, including escaping and converting opaque values to escaped byte encoded strings. Similarly, on output, clients are required to unescape strings and convert escaped string encoded opaques to binary. The functions SLPEscape() and SLPUnescape() can be used for escaping SLP reserved characters, but perform no opaque processing.
クライアント。 結果として、クライアントは形式要求ストリングに責任がある、逃げて、不透明な値を逃げられたバイトに変換するのを含んでいるのがストリングをコード化しました。 同様に、出力のときにクライアントが「非-エスケープ」のストリングに必要でした、そして、転向者はストリングのコード化された不透明なものからバイナリーに逃げました。 SLPの控え目なキャラクタから逃げるのに機能のSLPEscape()とSLPUnescape()を使用できますが、どんな不透明な処理も実行しないでください。
Opaque values consist of a character buffer containing a UTF-8- encoded string, the first characters of which are the nonUTF-8 encoding '\ff'. Subsequent characters are the escaped values for the original bytes in the opaque. The escape convention is relatively simple. An escape consists of a backslash followed by the two hexadecimal digits encoding the byte. An example is '\2c' for the byte 0x2c. Clients handle opaque processing themselves, since the algorithm is relatively simple and uniform.
'不透明な値はUTF-8でコード化されたストリングを入れてある文字バッファから成ります、それのキャラクタが'\ff'をコード化するnonUTF-8である1番目。 その後のキャラクタは不透明なものの元のバイト単位で逃げられた値です。 エスケープコンベンションは比較的簡単です。 エスケープはバイトをコード化する2つの16進数字があとに続いたバックスラッシュから成ります。 '例はバイト0x2c'\2c'です。 アルゴリズムが比較的簡単であって、一定であるので、クライアントは自分たちで不透明な処理を扱います。
4.7.3. Client Side Syntax Checking
4.7.3. クライアントサイド構文の照合
Client side API implementations may do syntax checking of scope names, naming authority names, and service type names, but are not required to do so. Since the C API is designed to be a thin layer over the protocol, some low memory SA implementations may find extensive syntax checking on the client side to be burdensome. If syntax checking uncovers an error in a parameter, the SLP_PARAMETER_BAD error must be returned. If any parameter is NULL and is required to be nonNULL, SLP_PARAMETER_BAD is returned.
クライアントサイドAPI実行は、名前、およびサービス型名と権威を命名して、範囲名の構文の照合をするかもしれませんが、そうするのに必要ではありません。 C APIがプロトコルの上の薄層になるように設計されているので、いくつかの低いメモリSA実装によって、大規模な構文が重荷になるためにクライアント側について検査しているのがわかるかもしれません。 構文の照合がパラメタで過ちを暴露するなら、SLP_PARAMETER_BAD誤りを返さなければなりません。 何かパラメタをNULLであり、nonNULLになるように必要とするなら、SLP_PARAMETER_BADを返します。
4.7.4. System Properties
4.7.4. 系特性
The system properties established in the configuration file are accessible through the SLPGetProperty() and SLPSetProperty() functions. The SLPSetProperty() function only modifies properties in the running process, not in the configuration file. Properties are global to the process, affecting all threads and all handles created with SLPOpen. Errors are checked when the property is used and, as with parsing the configuration file, are logged. Program execution continues without interruption by substituting the default for the erroneous parameter. With the exception of net.slp.locale, net.slp.typeHint, and net.slp.maxResults, clients of the API should rarely be required to override these properties, since they reflect properties of the SLP network that are not of concern to individual agents. If changes are required, system administrators should modify the configuration file.
構成ファイルに確立された系特性はSLPGetProperty()とSLPSetProperty()機能を通してアクセスしやすいです。 SLPSetProperty()機能は構成ファイルで変更するのではなく、実行しているプロセスで特性を変更するだけです。 SLPOpenと共に作成されたすべてのスレッドとすべてのハンドルに影響して、特性はプロセスにグローバルです。 誤りは、特性が使用されているとき、チェックされて、構成ファイルを分析するように登録されます。 プログラム実行は、デフォルトを誤ったパラメタの代わりに用いることによって、間断ない続きます。 net.slp.locale、net.slp.typeHint、およびnet.slp.maxResultsを除いて、APIのクライアントはこれらの特性を無視するのがめったに必要であるべきではありません、SLPネットワークの個々のエージェントには、重要でない特性を反映するので。 変化が必要であるなら、システム管理者は構成ファイルを変更するべきです。
Kempf & Guttman Informational [Page 50] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[50ページ]のRFC2614はAPI1999年6月に位置を修理します。
4.7.5. Memory Management
4.7.5. メモリ管理
The only API functions returning memory specifically requiring deallocation on the part of the client are SLPParseSrvURL(), SLPFindScopes(), SLPEscape(), and SLPUnescape(). This memory should be freed using SLPFree() when no longer needed. Character strings returned via the SLPGetProperty() function should NOT be freed, they are owned by the SLP library.
クライアント側の明確に反配分を必要とするメモリを返す唯一のAPI関数が、SLPParseSrvURL()と、SLPFindScopes()と、SLPEscape()と、SLPUnescape()です。 このメモリは、もう必要でないとSLPFree()を使用することで解放されるべきです。 SLPGetProperty()機能で返された文字列を解放するべきでなくて、SLPライブラリはそれらを所有しています。
Memory passed to callbacks belongs to the library and MUST NOT be retained by the client code. Otherwise, crashes are possible. Clients are required to copy data out of the callback parameters. No other use of the parameter memory in callback parameters is allowed.
コールバックに通過されたメモリは、ライブラリに属して、クライアントコードによって保有されてはいけません。 さもなければ、クラッシュは可能です。 クライアントはコールバックパラメタからデータをコピーしなければなりません。 コールバックパラメタにおけるパラメタメモリの他の使用は全く許されていません。
4.7.6. Asynchronous and Incremental Return Semantics
4.7.6. 非同期で増加のリターン意味論
If a handle parameter to an API function was opened asynchronously, API function calls on the handle check the other parameters, open the appropriate operation and return immediately. In an error occurs in the process of starting the operation, an error code is returned. If the handle parameter was opened synchronously, the API function call blocks until all results are available, and returns only after the results are reported through the callback function. The return code indicates whether any errors occurred both starting and during the operation.
API関数へのハンドルパラメタが非同期に開かれたなら、ハンドルにおけるAPIファンクションコールは、他のパラメタをチェックして、適切な操作を開いて、すぐに、戻ります。 誤りでは、始めの途中に操作は起こっていて、エラーコードは返されます。 ハンドルパラメタが同時開かれたなら、すべてが結果として生じるまで、APIファンクションコールブロックは有効です、そして、結果がコールバックを通して報告された後にだけリターンは機能します。 復帰コードは、ともに始まって、何か誤りが発生したかどうかを示して、操作の間、そうします。
The callback function is called whenever the API library has results to report. The callback code is required to check the error code parameter before looking at the other parameters. If the error code is not SLP_OK, the other parameters may be invalid. The API library has the option of terminating any outstanding operation on which an error occurs. The callback code can similarly indicate that the operation should be terminated by passing back SLP_FALSE. Callback functions are not permitted to recursively call into the API on the same SLPHandle. If an attempt is made to recursively call into the API, the API function returns SLP_HANDLE_IN_USE. Prohibiting recursive callbacks on the same handle simplifies implementation of thread safe code, since locks held on the handle will not be in place during a second outcall on the handle. On the other hand, it means that handle creation should be fairly lightweight so a client program can easily support multiple outstanding calls.
APIライブラリに報告する結果があるときはいつも、コールバック機能は呼ばれます。 コールバックコードが、他のパラメタを見る前に誤りコード・パラメータをチェックするのに必要です。 エラーコードが_OKにSLPでないなら、他のパラメタは無効であるかもしれません。 APIライブラリには、誤りが発生するどんな傑出している操作も終えるオプションがあります。 コールバックコードは、操作がSLP_FALSEを戻すことによって終えられるべきであるのを同様に示すことができます。 コールバック機能が同じSLPHandleにAPIに再帰的にちょっと立ち寄ることが許可されていません。 APIに再帰的にちょっと立ち寄るのを試みをするなら、API関数はSLP_HANDLE_IN_USEを返します。 同じハンドルの上に再帰的なコールバックを禁止すると、スレッド・セーフコードの実装は簡略化します、ハンドルの上に持たれていた錠がハンドルの上の2番目のアウトコールの間、適所にないので。 他方では、それは、クライアントプログラムが容易に複数の傑出している呼び出しをサポートすることができるようにハンドル作成がかなり軽量であるべきであることを意味します。
The total number of results received can be controlled by setting the net.slp.maxResults parameter.
net.slp.maxResultsパラメタを設定することによって、受け取られた結果の総数を制御できます。
On the last call to a callback, whether asynchronous or synchronous, the status code passed to the callback has value SLP_LAST_CALL. There are four reasons why the call can terminate:
コールバックへの最後の呼び出しのときに、非同期であるか、または同時であることにかかわらずコールバックに通過されたステータスコードは値のSLP_LAST_CALLを持っています。 呼び出しが終えることができる4つの理由があります:
Kempf & Guttman Informational [Page 51] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[51ページ]のRFC2614はAPI1999年6月に位置を修理します。
DA reply received
DA回答は受信されました。
A reply from a DA has been received and therefore nothing more
is expected.
DAからの回答を受け取りました、そして、したがって、それ以上何もを予想します。
Multicast terminated
マルチキャストは終わりました。
The multicast convergence time has elapsed and the API library
multicast code is giving up.
マルチキャスト集合時間は経過しました、そして、APIライブラリマルチキャストコードはあきらめています。
Multicast null results
マルチキャストヌル結果
Nothing new has been received during multicast for a while and
the API library multicast code is giving up on that (as an
optimization).
しばらくマルチキャストの間、新しいものは何も受け取っていません、そして、APIライブラリマルチキャストコードはそれ(最適化としての)に見切りをつけています。
Maximum results
最大の結果
The user has set the net.slp.maxResults property and that
number of replies has been collected and returned
ユーザがnet.slp.maxResultsの特性を設定して、その数の回答を集めて、返しました。
4.8. Example
4.8. 例
This example illustrates how to discover a mailbox.
この例はメールボックスを発見する方法を例証します。
A POP3 server registers itself with the SLP framework. The attributes it registers are "USER", a list of all users whose mail is available through the POP3 server.
POP3サーバはSLPフレームワークにそれ自体を登録します。 それが示す属性は「ユーザ」、メールがPOP3サーバを通して利用可能であるすべてのユーザのリストです。
The POP3 server code is the following:
POP3サーバコードは以下です:
SLPHandle slph; SLPRegReport errCallback = POPRegErrCallback;
SLPHandle slph。 SLPRegReport errCallbackはPOPRegErrCallbackと等しいです。
/* Create an English SLPHandle, asynchronous processing. */
/*はイギリスのSLPHandle、非同期処理を作成します。 */
SLPError err = SLPOpen("en", SLP_TRUE, &slph);
SLPErrorが間違える、=SLPOpen(「アン」、SLP_TRUE、およびslph)。
if( err != SLP_OK ) {
(間違え、=SLP_OK)
/* Deal with error. */
誤りとの/*取引。 */
}
}
/* Create the service: URL and attribute parameters. */
/*はサービスを作成します: URLと属性パラメタ。 */
const char* surl = "service:pop3://mail.netsurf.de"; /* the URL */
const炭*surlは「サービス: pop3://mail.netsurf.de」と等しいです。 /*はURL*/です。
Kempf & Guttman Informational [Page 52] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[52ページ]のRFC2614はAPI1999年6月に位置を修理します。
const char *pcAttrs = "(user=zaphod,trillian,roger,marvin)"
const炭*pcAttrsは「(了解、ユーザ=zaphod、trillian、marvin)」と等しいです。
/* Perform the registration. */
/*は登録を実行します。 */
err = SLPReg(slph,
surl,
SLP_LIFETIME_DEFAULT,
ppcAttrs,
errCallback,
NULL);
間違え、=SLPReg(surlに、SLP_LIFETIME_DEFAULT、ppcAttrs、errCallback、NULLをslphします)。
if (err != SLP_OK ) {
(間違え、=SLP_OK)
/*Deal with error.*/
誤り*/との/*取引
}
}
The errCallback reports any errors:
errCallbackはどんな誤りも報告します:
void
POPRegErrCallback(SLPHandle hSLP,
SLPError errCode,
unsigned short usLifetime,
void* pvCookie) {
POPRegErrCallbackを欠如させてください(SLPHandle hSLP(SLPError errCode、未署名の短いusLifetime)は*pvCookieを欠如させます)。
if( errCode != SLP_OK ) {
(errCode!=SLP_OK)です。
/* Report error through a dialog, message, etc. */
対話、メッセージなどを通した/*レポートエラー */
}
}
/*Use lifetime interval to update periodically. */
/*は定期的にアップデートする生涯間隔を費やします。 */
}
}
The POP3 client locates the server for the user with the following code:
POP3クライアントは以下のコードでユーザのためのサーバの場所を見つけます:
/*
* The client calls SLPOpen(), exactly as above.
*/
クライアントがちょうど同じくらい上のSLPOpen()と呼ぶ/**。 */
const char *pcSrvType = "service:pop3"; /* the service type */
const char *pcScopeList = "default"; /* the scope */
const char *pcFilter = "(user=roger)"; /* the search filter */
SLPSrvURLCallback srvCallback = /* the callback */
POPSrvURLCallback;
const炭*pcSrvTypeは「サービス: pop3"」と等しいです。 サービスタイプ*/がconstする/*は*pcScopeList=「デフォルト」を炭にします。 範囲*/がconstする/*が*pcFilter=を炭にする、「(ユーザ=、了解、)、」、。 /、*検索が*/をフィルターにかける、SLPSrvURLCallback srvCallback=/*コールバック*/POPSrvURLCallback。
Kempf & Guttman Informational [Page 53] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[53ページ]のRFC2614はAPI1999年6月に位置を修理します。
err = SLPFindSrvs(slph,
pcSrvType, pcScopeList, pcFilter,
srvCallback, NULL);
間違え、=SLPFindSrvs(slph、pcSrvType、pcScopeList、pcFilter、srvCallback、NULL)。
if( err != SLP_OK ) {
(間違え、=SLP_OK)
/* Deal with error. */
誤りとの/*取引。 */
}
}
Within the callback, the client code can use the returned POP service:
コールバックの中では、クライアントコードは返されたPOPサービスを利用できます:
SLPBoolean
POPSrvURLCallback(SLPHandle hSLP,
const char* pcSrvURL,
unsigned short sLifetime,
SLPError errCode,
void* pvCookie) {
SLPBoolean POPSrvURLCallback(SLPHandle hSLP(const炭の*pcSrvURL、未署名の短いsLifetime、SLPError errCode)は*pvCookieを欠如させます)
if( errCode != SLP_OK ) {
(errCode!=SLP_OK)です。
/* Deal with error. */
誤りとの/*取引。 */
}
}
SLPSrvURL* pSrvURL;
SLPSrvURL*pSrvURL。
errCode = SLPParseSrvURL(pcSrvURL, &pSrvURL);
errCodeはSLPParseSrvURL(pcSrvURL&pSrvURL)と等しいです。
if (err != SLP_OK ) {
(間違え、=SLP_OK)
/* Deal with error. */
誤りとの/*取引。 */
} else {
ほか
/* get the server's address */
/*はサーバのアドレス*/を得ます。
struct hostent *phe = gethostbyname(pSrvURL.s_pcHost);
struct hostent*pheはgethostbyname(pSrvURL.s_pcHost)と等しいです。
/* use hostname in pSrvURL to connect to the POP3 server
* . . .
*/
/*はPOP3サーバ*に接続するのにpSrvURLのホスト名を使用します… */
SLPFreeSrvURL((void*)pSrvURL); /* Free the pSrvURL storage */
}
SLPFreeSrvURL((空間*)pSrvURL)。 /*はpSrvURLストレージ*/を解放します。
return SLP_FALSE; /* Done! */
SLP_FALSEを返してください。 行われた/*! */
Kempf & Guttman Informational [Page 54] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[54ページ]のRFC2614はAPI1999年6月に位置を修理します。
}
}
A client that wanted to discover all the users receiving mail at the server uses with the following query:
すべてのユーザがサーバでメールを受け取っていると発見したがっていたクライアントは以下の質問と共に以下を使用します。
/*
* The client calls SLPOpen(), exactly as above. We assume the
* service: URL was retrieved into surl.
*/
クライアントがちょうど同じくらい上のSLPOpen()と呼ぶ/**。 私たちは、*がサービスであると思います: URLはsurlに検索されました。 */
const char *pcScopeList = "default"; /* the scope */
const char *pcAttrFilter = "use"; /* the attribute filter */
SLPAttrCallback attrCallBack = /* the callback */
POPUsersCallback
const炭*pcScopeListは「デフォルト」と等しいです。 範囲*/const炭*pcAttrFilter=が「使用する」/*。 /、*属性フィルタ*/SLPAttrCallback attrCallBackが/*と等しい、コールバック*/POPUsersCallback
err =
SLPFindAttrs(slph,
surl,
pcScopeList, pcAttrFilter,
attrCallBack, NULL);
間違え、=SLPFindAttrs(slph、surl、pcScopeList、pcAttrFilter、attrCallBack、NULL)。
if( err != SLP_OK ) {
(間違え、=SLP_OK)
/* Deal with error. */
誤りとの/*取引。 */
}
}
The callback processes the attributes:
コールバックは属性を処理します:
SLPBoolean
POPUsersCallback(const char* pcAttrList,
SLPError errCode,
void* pvCookie) {
SLPBoolean POPUsersCallback(const炭*pcAttrList(SLPError errCode)は*pvCookieを欠如させます)
if( errCode != SLP_OK ) {
(errCode!=SLP_OK)です。
/* Deal with error. */
誤りとの/*取引。 */
} else {
ほか
/* Parse attributes. */
/*は属性を分析します。 */
}
}
return SLP_FALSE; /* Done! */
SLP_FALSEを返してください。 行われた/*! */
}
}
Kempf & Guttman Informational [Page 55] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[55ページ]のRFC2614はAPI1999年6月に位置を修理します。
5. Java Language Binding
5. Java言語結合
5.1. Introduction
5.1. 序論
The Java API is designed to model the various SLP entities in classes and objects. APIs are provided for SA, UA, and service type template access capabilities. The ServiceLocationManager class contains methods that return instances of objects implementing SA and UA capability. Each of these is modeled in an interface. The Locator interface provides UA capability and the Advertiser interface provides SA capability. The TemplateRegistry abstract class contains methods that return objects for template introspection and attribute type checking. The ServiceURL, ServiceType, and ServiceLocationAttribute classes model the basic SLP concepts. A concrete subclass instance of TemplateRegistry is returned by a class method.
Java APIは、クラスとオブジェクトで様々なSLP実体をモデル化するように設計されています。 SA、UA、およびサービスタイプテンプレートアクセス能力にAPIを提供します。 ServiceLocationManagerのクラスはSAとUAが能力であると実装するオブジェクトのインスタンスを返すメソッドを含みます。 それぞれのこれらはインタフェースでモデル化されます。 Locatorインタフェースは能力をUAに供給します、そして、Advertiserインタフェースは能力をSAに供給します。 TemplateRegistry抽象クラスはテンプレート内省と属性タイプの照合のためにオブジェクトを返すメソッドを含んでいます。 ServiceURL、ServiceType、およびServiceLocationAttributeのクラスは基本のSLP概念をモデル化します。 クラスメソッドでTemplateRegistryの具体的なサブクラスインスタンスを返します。
All SLP classes and interfaces are located within a single package. The package name should begin with the name of the implementation and conclude with the suffix "slp". Thus, the name for a hypothetical implementation from the University of Michigan would look like:
すべてのSLPのクラスとインタフェースはただ一つのパッケージの中に位置しています。 パッケージ名は、実装の名前で始まって、接尾語"slp"で締めくくるべきです。 したがって、ミシガン大学からの仮定している実装のための名前に似ているでしょう:
edu.umich.slp
edu.umich.slp
This follows the Java convention of prepending the top level DNS domain name for the organization implementing the package onto the organization's name and using that as the package prefix.
これは組織のために組織名にパッケージを実装して、パッケージ接頭語としてそれを使用することで最高平らなDNSドメイン名をprependingするJavaコンベンションに続きます。
5.2. Exceptions and Errors
5.2. 例外と誤り
Most parameters to API methods are required to be non-null. The API description indicates if a null parameter is acceptable, or if other restrictions constrain a parameter. When parameters are checked for validity (such as not being null) or their syntax is checked, an error results in the RuntimeException subclass IllegalArgumentException being thrown. Clients of the API are reminded that IllegalArgumentException, derived from RuntimeException, is unchecked by the compiler. Clients should thus be careful to include try/catch blocks for it if the relevant parameters could be erroneous.
APIメソッドへのほとんどのパラメタが、非ヌルであるのに必要です。 API記述は、ヌルパラメタが許容できるかどうか、または他の制限がパラメタを抑制するかどうかを示します。 パラメタが正当性(ヌルでないことなどの)がないかどうかチェックされるか、またはそれらの構文がチェックされるとき、誤りは投げられるRuntimeExceptionサブクラスIllegalArgumentExceptionをもたらします。 APIのクライアントはRuntimeExceptionから得られたIllegalArgumentExceptionがコンパイラによってチェックを外されるのを思い出させられています。 その結果、関連パラメタが誤る場合があるなら、クライアントはそれのためのトライ/キャッチブロックを含んでいるのに慎重でしょうに。
Standard Java practice is to encode every exceptional condition as a separate subclass of Exception. Because of the relatively high cost in code size of Exception subclasses, the API contains only a single Exception subclass with different conditions being determined by an integer error code property. A subset, appropriate to Java, of the error codes described in Section 3 are available as constants on the ServiceLocationException class. The subset excludes error codes such
一般的なJava習慣はExceptionの別々のサブクラスとしてあらゆる例外的な状態をコード化することになっています。 Exceptionサブクラスのコードサイズにおける比較的高い費用のために、APIは整数エラーコードの特性による異なった状態が決定しているただ一つのExceptionサブクラスだけを含んでいます。 部分集合、Javaに適切です、誤りでは、セクション3で説明されたコードは定数としてServiceLocationExceptionのクラスで利用可能です。 部分集合がエラーコードを除く、そのようなもの
Kempf & Guttman Informational [Page 56] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[56ページ]のRFC2614はAPI1999年6月に位置を修理します。
as MEMORY_ALLOC_FAILED.
メモリ_ALLOCとして、_は失敗しました。
5.2.1. Class ServiceLocationException
5.2.1. クラスServiceLocationException
5.2.1.1. Synopsis
5.2.1.1. 構文
public class ServiceLocationException extends Exception
公立のクラスServiceLocationExceptionはExceptionを広げています。
5.2.1.2. Description
5.2.1.2. 記述
The ServiceLocationException class is thrown by all methods when exceptional conditions occur in the SLP framework. The error code property determines the exact nature of the condition, and an optional message may provide more information.
例外的な状態がSLPフレームワークで現れるとき、ServiceLocationExceptionのクラスはすべてのメソッドで投げられます。 エラーコードの特性は状態の正確な本質を決定します、そして、任意のメッセージは詳しい情報を提供するかもしれません。
5.2.1.3. Fields
5.2.1.3. 分野
public static final short LANGUAGE_NOT_SUPPORTED = 1 public static final short PARSE_ERROR = 2 public static final short INVALID_REGISTRATION = 3 public static final short SCOPE_NOT_SUPPORTED = 4 public static final short AUTHENTICATION_ABSENT = 6 public static final short AUTHENTICATION_FAILED = 7 public static final short INVALID_UPDATE = 13 public static final short REFRESH_REJECTED = 15 public static final short NOT_IMPLEMENTED = 16 public static final short NETWORK_INIT_FAILED 17 public static final short NETWORK_TIMED_OUT = 18 public static final short NETWORK_ERROR = 19 public static final short INTERNAL_SYSTEM_ERROR = 20 public static final short TYPE_ERROR = 21 public static final short BUFFER_OVERFLOW = 22
1人の__SUPPORTEDでない=公衆の公共の静的な最終的な短いLANGUAGE静的な最終的な短いPARSE_ERRORが4_SUPPORTED=公衆ではなく、3の公共の静的な最終的な短いSCOPE2の公共の静的な最終的な短いINVALID_REGISTRATION=_と静的に等しい、最終的な短いAUTHENTICATION_ABSENTは7の公共の静的な決勝で短いINVALID_UPDATE=13公共の6の公共の静的な最終的な短いAUTHENTICATION_FAILED=静電気と等しいです; 最終的な短いREFRESH_、REJECTEDが急に15の公共の静的な決勝と_IMPLEMENTED=16公共の静的な最終的な短い公共の静的な最終的なNETWORK_INITの短いNETWORK_TIMED_OUT_FAILED17=18公衆静的でなく等しい、最終的である、短さ、19公共の静的な最終的な短いINTERNAL_SYSTEM_ERROR=20公共の静的な最終的な短いTYPE_ERROR=21の公共の静的な最終的な短いBUFFER_OVERFLOW=NETWORK_ERROR=22
5.2.1.4. Instance Methods
5.2.1.4. インスタンスメソッド
public short getErrorCode()
公共の短いgetErrorCode()
Return the error code. The error code takes on one of the static field values.
エラーコードを返してください。 エラーコードは静的な分野値の1つを帯びます。
Kempf & Guttman Informational [Page 57] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[57ページ]のRFC2614はAPI1999年6月に位置を修理します。
5.3. Basic Data Structures
5.3. 基礎データ構造
5.3.1. Interface ServiceLocationEnumeration
5.3.1. インタフェースServiceLocationEnumeration
public interface ServiceLocationEnumeration
extends Enumeration
公共のインタフェースServiceLocationEnumerationはEnumerationを広げています。
5.3.1.1. Description
5.3.1.1. 記述
The ServiceLocationEnumeration class is the return type for all Locator SLP operations. The Java API library may implement this class to block until results are available from the SLP operation, so that the client can achieve asynchronous operation by retrieving results from the enumeration in a separate thread. Clients use the superclass nextElement() method if they are unconcerned with SLP exceptions.
ServiceLocationEnumerationのクラスはすべてのLocator SLP操作のためのリターンタイプです。 結果がSLP操作によって利用可能になるまで、Java APIライブラリは妨げるこのクラスを実装するかもしれません、クライアントが別々のスレッドにおける列挙から結果を検索することによって非同期動作を達成できるように。 彼らがSLP例外に無関心であるなら、クライアントはsuperclass nextElement()メソッドを使用します。
5.3.1.2. Instance Methods
5.3.1.2. インスタンスメソッド
public abstract Object next() throws ServiceLocationException
次の()がServiceLocationExceptionを投げる公共の抽象的なObject
Return the next value or block until it becomes available.
利用可能になるまで次の値かブロックを返してください。
Throws:
一投:
ServiceLocationException
ServiceLocationException
Thrown if the SLP operation encounters an error.
SLP操作が誤りに遭遇するなら、投げられます。
NoSuchElementException
NoSuchElementException
If there are no more elements to return.
返すそれ以上の要素が全くなければ。
5.3.2. Class ServiceLocationAttribute
5.3.2. クラスServiceLocationAttribute
5.3.2.1. Synopsis
5.3.2.1. 構文
public class ServiceLocationAttribute
extends Object implements Serializable
公立のクラスServiceLocationAttributeはObject道具Serializableを広げています。
Kempf & Guttman Informational [Page 58] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[58ページ]のRFC2614はAPI1999年6月に位置を修理します。
5.3.2.2. Description
5.3.2.2. 記述
The ServiceLocationAttribute class models SLP attributes. Instances of this class are returned by Locator.findAttributes() and are communicated along with register/deregister requests.
ServiceLocationAttributeのクラスはSLP属性をモデル化します。 このクラスのインスタンスは、Locator.findAttributes()によって返されて、レジスタ/「反-レジスタ」要求と共に伝えられます。
5.3.2.3. Constructors
5.3.2.3. 建設者
public ServiceLocationAttribute(String id,Vector values)
公共のServiceLocationAttribute(ストリングイド、Vector値)
Construct a service location attribute. Errors in the id or values vector result in an IllegalArgumentException.
サービス位置の属性を構成してください。 イドか値のベクトルにおける誤りはIllegalArgumentExceptionをもたらします。
Parameters:
パラメタ:
id
イド
The attribute name. The String can consist of any Unicode
character.
属性名。 Stringはどんなユニコード文字からも成ることができます。
values
値
A Vector of one or more attribute values. Vector contents
must be uniform in type and one of Integer, String, Boolean,
or byte[]. If the attribute is a keyword attribute, then the
parameter should be null. String values can consist of any
Unicode character.
1つ以上の属性値のVector。 ベクトルコンテンツはタイプとIntegerの1つ、String、ブールかバイト[]で一定であるに違いありません。 属性がキーワード属性であるなら、パラメタはヌルであるべきです。 ストリング値はどんなユニコード文字からも成ることができます。
5.3.2.4. Class Methods
5.3.2.4. クラスメソッド
public static String escapeId(String id)
公共の静的なString escapeId(ストリングイド)
Returns an escaped version of the id parameter, suitable for inclusion in a query. Any reserved characters as specified in [7] are escaped using UTF-8 encoding. If any characters in the tag are illegal, throws IllegalArgumentException.
質問での包含に適したイドパラメタの逃げられたバージョンを返します。 [7]の指定されるとしてのどんな控え目なキャラクタも、UTF-8コード化を使用することで逃げられます。 いずれかであるなら、タグのキャラクタは不法であり、一投はIllegalArgumentExceptionです。
Parameters:
パラメタ:
id
イド
The attribute id to escape. ServiceLocationException is thrown
if any characters are illegal for an attribute tag.
逃げる属性イド。 属性タグに、何かキャラクタが不法であるなら、ServiceLocationExceptionは投げられます。
Kempf & Guttman Informational [Page 59] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[59ページ]のRFC2614はAPI1999年6月に位置を修理します。
public static String escapeValue(Object value)
公共の静的なString escapeValue(オブジェクト値)
Returns a String containing the escaped value parameter as a string, suitable for inclusion in a query. If the parameter is a string, any reserved characters as specified in [7] are escaped using UTF-8 encoding. If the parameter is a byte array, then the escaped string begins with the nonUTF-8 sequence `\ff` and the rest of the string consists of the escaped bytes, which is the encoding for opaques. If the value parameter is a Boolean or Integer, then the returned string contains the object converted into a string. If the value is any type other than String, Integer, Boolean or byte[], an IllegalArgumentException is thrown.
質問での包含に適したストリングとして逃げられた値のパラメタを含むStringを返します。 パラメタがストリングであるなら、[7]の指定されるとしてのどんな控え目なキャラクタも、UTF-8コード化を使用することで逃げられます。 'パラメタがバイト配列であるなら、逃げられたストリングはnonUTF-8系列'\ff'で始まります、そして、ストリングの残りは逃げられたバイトから成ります。(バイトは不透明なもののためのコード化です)。 値のパラメタがaブールであるか、そして、Integer、そして、返されたストリングはストリングに変換されたオブジェクトを含んでいます。 String、Integer、ブールかバイト[]を除いて、値があらゆるタイプであるなら、IllegalArgumentExceptionは投げられます。
Parameters:
パラメタ:
value
値
The attribute value to be converted into a string and escaped.
ストリングに変換された、逃げられるべき属性値。
5.3.2.5. Instance Methods
5.3.2.5. インスタンスメソッド
public Vector getValues()
公共のVector getValues()
Returns a cloned vector of attribute values, or null if the attribute is a keyword attribute. If the attribute is single-valued, then the vector contains only one object.
属性がキーワード属性であるなら属性値、またはヌルのクローンのベクトルを返します。 属性が単一に評価されているなら、ベクトルは1個のオブジェクトだけを含んでいます。
public String getId()
公共のString getId()
Returns the attribute's name.
属性の名前を返します。
public boolean equals(Object o)
公共の論理演算子同輩(オブジェクトo)
Overrides Object.equals(). Two attributes are equal if their identifiers are equal and their value vectors contain the same number of equal values as determined by the Object equals() method. Values having byte[] type are equal if the contents of all byte arrays in both attribute vectors match. Note that the SLP string matching algorithm [7] MUST NOT be used for comparing attribute identifiers or string values.
Object.equals()をくつがえします。 それらの識別子が等しく、それらの値のベクトルがObject同輩()メソッドで決定するように同じ数の等しい値を含んでいるなら、2つの属性が等しいです。 両方の属性ベクトルにおけるすべてのバイト配列の内容が合っているなら、バイト[]タイプがある値は等しいです。 属性識別子かストリング値を比較するのにアルゴリズム[7]に合っているSLPストリングを使用してはいけないことに注意してください。
Kempf & Guttman Informational [Page 60] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[60ページ]のRFC2614はAPI1999年6月に位置を修理します。
public String toString()
公共のString toString()
Overrides Object.toString(). The string returned contains a formatted representation of the attribute, giving the attribute's id, values, and the Java type of the values. The returned string is suitable for debugging purposes, but is not in SLP wire format.
Object.toString()をくつがえします。 返されたストリングは属性のフォーマットされた表現を含んでいます、値の属性のイド、値、およびJavaタイプに与えて。 返されたストリングは、デバッグ目的に適していますが、SLPワイヤ形式にはありません。
public int hashCode()
公共のint hashCode()
Overrides Object.hashCode(). Hashes on the attribute's identifier.
Object.hashCode()をくつがえします。 属性の識別子では、論じ尽くします。
5.3.3. Class ServiceType
5.3.3. クラスServiceType
5.3.3.1. Synopsis
5.3.3.1. 構文
public class ServiceType extends Object implements Serializable
公立のクラスServiceTypeはObject道具Serializableを広げています。
5.3.3.2. Description
5.3.3.2. 記述
The ServiceType object models the SLP service type. It parses a string based service type specifier into its various components, and contains property accessors to return the components. URL schemes, protocol service types, and abstract service types are all handled.
ServiceTypeオブジェクトはSLPサービスタイプをモデル化します。 それは、ストリングのベースのサービス型指定子を様々なコンポーネントに分析して、コンポーネントを返す特性のアクセサを含んでいます。 URL体系、プロトコルサービスタイプ、および抽象的なサービスタイプは皆、扱われます。
5.3.3.3. Constructors
5.3.3.3. 建設者
public ServiceType(String type)
公共のServiceType(ストリングタイプ)
Construct a service type object from the service type specifier. Throws IllegalArgumentException if the type name is syntactically incorrect.
サービス型指定子からサービスタイプオブジェクトを組み立ててください。 型名がシンタクス上不正確であるなら、IllegalArgumentExceptionを投げます。
Parameters:
パラメタ:
type
タイプ
The service type name as a String. If the service type is from
a service: URL, the "service:" prefix must be intact.
Stringとしてのサービス型名。 サービスタイプがサービスから来ているなら: URL、「サービス:」 接頭語は完全であるに違いありません。
Kempf & Guttman Informational [Page 61] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[61ページ]のRFC2614はAPI1999年6月に位置を修理します。
5.3.3.4. Methods
5.3.3.4. メソッド
public boolean isServiceURL()
公共の論理演算子isServiceURL()
Returns true if the type name contains the "service:" prefix.
含有という型名であるなら本当に戻る、「サービス:」 前に置きます。
public boolean isAbstractType()
公共の論理演算子isAbstractType()
Returns true if the type name is for an abstract type.
本当に、型名が抽象型のためのものであるなら、戻ります。
public boolean isNADefault()
公共の論理演算子isNADefault()
Returns true if the naming authority is the default, i.e. is the empty string.
本当に戻る、命名権威がデフォルトであるなら、すなわち、空のことはストリングですか?
public String getConcreteTypeName()
公共のString getConcreteTypeName()
Returns the concrete type name in an abstract type, or the empty string if the service type is not abstract. For example, if the type name is "service:printing:ipp", the method returns "ipp". If the type name is "service:ftp", the method returns "".
サービスタイプが抽象的でないなら具体的なタイプが抽象型、または空のストリングで命名するリターン。 例えば、型名が「サービス:印刷:ipp」であるなら、メソッドは"ipp"を返します。 型名が「サービス: ftp」、メソッドリターンである、「「.」
public String getPrincipleTypeName()
公共のString getPrincipleTypeName()
Returns the abstract type name for an abstract type, the protocol name in a protocol type, or the URL scheme for a generic URL. For example, in the abstract type name "service:printing:ipp", the method returns "printing". In the protocol type name "service:ftp", the method returns "ftp".
抽象型、プロトコルタイプのプロトコル名、またはジェネリックURLのURL体系のために抽象型名を返します。 例えば、「サービス:印刷:ipp」という抽象型名では、メソッドは「印刷」を返します。 プロトコル型名「サービス: ftp」では、メソッドは"ftp"を返します。
public String getAbstractTypeName()
公共のString getAbstractTypeName()
If the type is an abstract type, returns the fully formatted abstract type name including the "service:" and naming authority but without the concrete type name or intervening colon. If not an abstract type, returns the empty string. For example, in the abstract type name "service:printing:ipp", the method returns "service:printing".
タイプが抽象型であり、包含という完全にフォーマットされた抽象型名を返す、「サービス:」 そして、権威にもかかわらず、具体的な型名も介入しているコロンのない命名。 まして、抽象型、空が結ぶリターン。 例えば、「サービス:印刷:ipp」という抽象型名では、メソッドは「サービス: 印刷」を返します。
Kempf & Guttman Informational [Page 62] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[62ページ]のRFC2614はAPI1999年6月に位置を修理します。
public String getNamingAuthority()
公共のString getNamingAuthority()
Return the naming authority name, or the empty string if the naming authority is the default.
命名権威がデフォルトであるなら権威名、または空のストリングを命名に返してください。
public boolean equals(Object obj)
公共の論理演算子同輩(オブジェクトobj)
Overrides Object.equals(). The two objects are equal if they are both ServiceType objects and the components of both are equal.
Object.equals()をくつがえします。 2個のオブジェクトがそれらが両方のServiceTypeオブジェクトであるなら等しいです、そして、両方のコンポーネントは等しいです。
public String toString()
公共のString toString()
Returns the fully formatted type name, including the "service:" if the type was originally from a service: URL.
完全にフォーマットされたタイプが命名するリターン、包含、「サービス:」 タイプが元々サービスからあったなら: URL。
public int hashCode()
公共のint hashCode()
Overrides Object.hashCode(). Hashes on the string value of the "service" prefix, naming authority, if any, abstract and concrete type names for abstract types, protocol type name for protocol types, and URL scheme for generic URLs.
Object.hashCode()をくつがえします。 抽象型にちなんで抽象的で具体的な型名ともしあれば権威を命名して、「サービス」接頭語のストリング値に関するハッシュは、プロトコルタイプのために型名について議定書の中で述べて、ジェネリックURLのためにURL体系について議定書の中で述べます。
5.3.4. Class ServiceURL
5.3.4. クラスServiceURL
5.3.4.1. Synopsis
5.3.4.1. 構文
public class ServiceURL extends Object implements Serializable
公立のクラスServiceURLはObject道具Serializableを広げています。
5.3.4.2. Description
5.3.4.2. 記述
The ServiceURL object models the advertised SLP service URL. It can be either a service: URL or a regular URL. These objects are returned from service lookup requests, and describe the registered services. This class should be a subclass of java.net.URL but can't since that class is final.
ServiceURLオブジェクトは広告を出しているSLPサービスURLをモデル化します。 それはサービスであるかもしれません: URLか通常のURL。 これらのオブジェクトは、サービスルックアップ要求から返されて、登録されたサービスについて説明します。 このクラスは、java.net.URLのサブクラスであるべきですが、そのクラスが最終的であるので、サブクラスであることができません。
Kempf & Guttman Informational [Page 63] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[63ページ]のRFC2614はAPI1999年6月に位置を修理します。
5.3.4.3. Class Variables
5.3.4.3. クラス変数
public static final int NO_PORT = 0
公共の静的な最終的なintいいえ_PORT=0
Indicates that no port information is required or was returned for this URL.
ポート情報が全く必要でなかった、またはこのURLのために返されなかったのを示します。
public static final int LIFETIME_NONE = 0
公共の静的な最終的なint LIFETIME_NONE=0
Indicates that the URL has a zero lifetime. This value is never returned from the API, but can be used to create a ServiceURL object to deregister, delete attributes, or find attributes.
aがURLで生涯のゼロに合っているのを示します。 APIからこの値を決して返しません、ServiceURLオブジェクトを「反-レジスタ」に作成するのに使用されるか、属性を削除するか、または属性を見つけることができるのを除いて。
public static final int LIFETIME_DEFAULT = 10800
公共の静的な最終的なint LIFETIME_DEFAULT=10800
The default URL lifetime (3 hours) in seconds.
(3時間)寿命が中で後援するデフォルトURL。
public static final int LIFETIME_MAXIMUM = 65535
公共の静的な最終的なint LIFETIME_MAXIMUM=65535
The maximum URL lifetime (about 18 hours) in seconds.
秒における(およそ18時間)最大のURL生涯。
public static final int LIFETIME_PERMANENT = -1
公共の静的な最終的なint LIFETIME_PERMANENTは-1と等しいです。
Indicates that the API implementation should continuously re-register the URL until the application exits.
アプリケーションが出るまでAPI実行が絶え間なくURLを再登録するべきであるのを示します。
5.3.4.4. Constructors
5.3.4.4. 建設者
public ServiceURL(String URL,int lifetime)
公共のServiceURL(ストリングURL、int生涯)
Construct a service URL object having the specified lifetime.
指定された生涯を持っているサービスURLオブジェクトを組み立ててください。
Kempf & Guttman Informational [Page 64] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[64ページ]のRFC2614はAPI1999年6月に位置を修理します。
Parameters:
パラメタ:
URL
URL
The URL as a string. Must be either a service: URL or a valid
generic URL according to RFC 2396 [2].
ストリングとしてのURL。 サービスでなければなりません: URLかRFC2396[2]に従った有効なジェネリックURL。
lifetime
生涯
The service advertisement lifetime in seconds. This value may
be between LIFETIME_NONE and LIFETIME_MAXIMUM.
広告寿命が中で後援するサービス。 LIFETIME_NONEとLIFETIME_MAXIMUMの間には、この値はあるかもしれません。
5.3.4.5. Methods
5.3.4.5. メソッド
public ServiceType getServiceType()
公共のServiceType getServiceType()
Returns the service type object representing the service type name of the URL.
URLのサービス型名を表すサービスタイプオブジェクトを返します。
public final void setServiceType(ServiceType type) throws ServiceLocationException
公共の最終的な空のsetServiceType(ServiceTypeはタイプする)はServiceLocationExceptionを投げます。
Set the service type name to the object. Ignored if the URL is a service: URL.
サービス型名をオブジェクトに設定してください。 URLがサービスであるなら、無視されます: URL。
Parameters:
パラメタ:
type
タイプ
The service type object.
サービスタイプは反対します。
public String getTransport()
公共のString getTransport()
Get the network layer transport identifier. If the transport is IP, an empty string, "", is returned.
ネットワーク層輸送識別子を得てください。 輸送がIP、空のストリングである、「「返す、」
public String getHost()
公共のString getHost()
Kempf & Guttman Informational [Page 65] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[65ページ]のRFC2614はAPI1999年6月に位置を修理します。
Returns the host identifier. For IP, this will be the machine name or IP address.
ホスト識別子を返します。 これは、IPにおける、マシン名かIPアドレスになるでしょう。
public int getPort()
公共のint getPort()
Returns the port number, if any. For non-IP transports, always returns NO_PORT.
もしあればポートナンバーを返します。 非IP輸送、いつもリターンいいえ_PORTのために。
public String getURLPath()
公共のString getURLPath()
Returns the URL path description, if any.
もしあればURL経路記述を返します。
public int getLifetime()
公共のint getLifetime()
Returns the service advertisement lifetime. This will be a positive int between LIFETIME_NONE and LIFETIME_MAXIMUM.
広告生涯をサービスに返します。 これはLIFETIME_NONEとLIFETIME_MAXIMUMの間で積極的なintになるでしょう。
public boolean equals(Object obj)
公共の論理演算子同輩(オブジェクトobj)
Compares the object to the ServiceURL and returns true if the two are the same. Two ServiceURL objects are equal if their current service types match and they have the same host, port, transport, and URL path.
オブジェクトをServiceURLと比較して、2が同じであるなら、本当に戻ります。 彼らの当期の勤務タイプが合って、彼らに同じホスト、ポート、輸送、およびURL経路があるなら、2個のServiceURLオブジェクトが等しいです。
public String toString()
公共のString toString()
Returns a formatted string with the URL. Overrides Object.toString(). The returned URL has the original service type or URL scheme, not the current service type.
URLがあるフォーマットされたストリングを返します。 Object.toString()をくつがえします。 返されたURLには、当期の勤務タイプではなく、元のサービスタイプかURL体系があります。
public int hashCode()
公共のint hashCode()
Overrides Object.hashCode(). Hashes on the current service type, transport, host, port, and URL part.
Object.hashCode()をくつがえします。 当期の勤務タイプ、輸送、ホスト、ポート、およびURLのハッシュは離れています。
Kempf & Guttman Informational [Page 66] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[66ページ]のRFC2614はAPI1999年6月に位置を修理します。
5.4. SLP Access Interfaces
5.4. SLPアクセスインタフェース
5.4.1. Interface Advertiser
5.4.1. インタフェース広告主
5.4.1.1. Synopsis
5.4.1.1. 構文
public interface Advertiser
公共のインタフェースAdvertiser
5.4.1.2. Description
5.4.1.2. 記述
The Advertiser is the SA interface, allowing clients to register new service instances with SLP, to change the attributes of existing services, and to deregister service instances. New registrations and modifications of attributes are made in the language locale with which the Advertiser was created, deregistrations of service instances are made for all locales.
AdvertiserはSAインタフェースです、クライアントが既存にサービスの属性を変えるためにSLPがある新しいサービスインスタンスを登録して、「反-レジスタ」サービスインスタンスにそうするのを許容して。 Advertiserが作成された言語現場で属性の新しい登録証明書と変更をして、サービスインスタンスの「反-登録証明書」をすべての現場に作ります。
5.4.1.3. Instance Methods
5.4.1.3. インスタンスメソッド
public abstract Locale getLocale()
公共の抽象的なLocale getLocale()
Return the language locale with which this object was created.
このオブジェクトが作成された言語現場を返してください。
public abstract void register(ServiceURL URL,
Vector attributes)
throws ServiceLocationException
公共の抽象的な空のレジスタ(ServiceURL URL、Vector属性)はServiceLocationExceptionを投げます。
Register a new service with SLP having the given attributes.
与えられた属性を持っているSLPに新しいサービスを登録してください。
The API library is required to perform the operation in all scopes obtained through configuration.
APIライブラリは構成を通して入手されたすべての範囲で操作を実行しなければなりません。
Parameters:
パラメタ:
URL
URL
The URL for the service.
サービスのためのURL。
attributes
属性
A vector of ServiceLocationAttribute objects describing the
service.
サービスについて説明するServiceLocationAttributeオブジェクトのベクトル。
Kempf & Guttman Informational [Page 67] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[67ページ]のRFC2614はAPI1999年6月に位置を修理します。
public abstract void deregister(ServiceURL URL) throws ServiceLocationException
公共の抽象的な空の「反-レジスタ」(ServiceURL URL)はServiceLocationExceptionを投げます。
Deregister a service from the SLP framework. This has the effect of deregistering the service from every language locale. The API library is required to perform the operation in all scopes obtained through configuration.
SLPフレームワークからのDeregister aサービス。 これには、あらゆる言語現場からサービスを反登録するという効果があります。 APIライブラリは構成を通して入手されたすべての範囲で操作を実行しなければなりません。
Parameters:
パラメタ:
URL
URL
The URL for the service.
サービスのためのURL。
public abstract void
addAttributes(ServiceURL URL,
Vector attributes)
throws ServiceLocationException
公共の抽象的な空のaddAttributes(ServiceURL URL、Vector属性)はServiceLocationExceptionを投げます。
Update the registration by adding the given attributes. The API library is required to perform the operation in all scopes obtained through configuration.
与えられた属性を加えることによって、登録をアップデートしてください。 APIライブラリは構成を通して入手されたすべての範囲で操作を実行しなければなりません。
Parameters:
パラメタ:
URL
URL
The URL for the service.
サービスのためのURL。
attributes
属性
A Vector of ServiceLocationAttribute objects to add to the
existing registration. Use an empty vector to update the URL
alone. May not be null.
ServiceLocationAttributeのVectorは、既存の登録の一助となるように反対します。 空のベクトルを使用して、単独でURLをアップデートしてください。 ヌルでないかもしれません。
public abstract void
deleteAttributes(ServiceURL URL,
Vector attributeIds)
throws ServiceLocationException
公共の抽象的な空のdeleteAttributes(ServiceURL URL、Vector attributeIds)はServiceLocationExceptionを投げます。
Delete the attributes from a URL for the locale with which the Advertiser was created. The API library is required to perform the operation in all scopes obtained through configuration.
URLから属性をAdvertiserが作成された現場に削除してください。 APIライブラリは構成を通して入手されたすべての範囲で操作を実行しなければなりません。
Kempf & Guttman Informational [Page 68] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[68ページ]のRFC2614はAPI1999年6月に位置を修理します。
Parameters:
パラメタ:
URL
URL
The URL for the service.
サービスのためのURL。
attributeIds
attributeIds
A vector of Strings indicating the ids of the attributes
to remove. The strings may be attribute ids or they
may be wildcard patterns to match ids. See [7] for the
syntax of wildcard patterns. The strings may include SLP
reserved characters, they will be escaped by the API before
transmission. May not be the empty vector or null.
取り外すために属性のイドを示すStringsのベクトル。 ストリングは属性イドであるかもしれませんかそれらが、イドを合わせるためにはワイルドカードパターンであるかもしれません。 ワイルドカードパターンの構文のための[7]を見てください。 ストリングはSLPの控え目なキャラクタを含むかもしれなくて、彼らトランスミッションの前にAPIによって逃げられるでしょう。 空のベクトルかヌルでないかもしれません。
5.4.2. Interface Locator
5.4.2. インタフェースロケータ
5.4.2.1. Synopsis
5.4.2.1. 構文
public interface Locator
公共のインタフェースLocator
5.4.2.2. Description
5.4.2.2. 記述
The Locator is the UA interface, allowing clients to query the SLP framework about existing service types, services instances, and about the attributes of an existing service instance or service type. Queries for services and attributes are made in the locale with which the Locator was created, queries for service types are independent of locale.
LocatorはUAインタフェースです、クライアントが既存のサービスタイプ、サービスインスタンスの周りと、そして、既存のサービスインスタンスかサービスタイプの属性の周りに関してSLPフレームワークについて質問するのを許容して。 Locatorが作成された現場でサービスと属性のための質問をして、サービスタイプのための質問は現場から独立しています。
5.4.2.3. Instance Methods
5.4.2.3. インスタンスメソッド
public abstract Locale getLocale()
公共の抽象的なLocale getLocale()
Return the language locale with which this object was created.
このオブジェクトが作成された言語現場を返してください。
public abstract ServiceLocationEnumeration
findServiceTypes(String namingAuthority,
Vector scopes)
throws ServiceLocationException
公共の抽象的なServiceLocationEnumeration findServiceTypes(ストリングnamingAuthority、Vector範囲)はServiceLocationExceptionを投げます。
Kempf & Guttman Informational [Page 69] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[69ページ]のRFC2614はAPI1999年6月に位置を修理します。
Returns an enumeration of ServiceType objects giving known service types for the given scopes and given naming authority. If no service types are found, an empty enumeration is returned.
権威を命名するのを与えられた範囲のために知られているサービスにタイプを与えて、考えて、ServiceTypeオブジェクトの列挙を返します。 サービスタイプを全く見つけないなら、空の列挙を返します。
Parameters:
パラメタ:
namingAuthority
namingAuthority
The naming authority. Use "" for the default naming authority
and "*" for all naming authorities.
命名権威。 使用、「「すべての命名のための権威と「*」を当局に任命するデフォルトのために」
scopes
範囲
A Vector of scope names. The vector should be selected from
the results of a findScopes() API invocation. Use "DEFAULT"
for the default scope.
範囲名のVector。 ベクトルはfindScopes()API実施の結果から選択されるべきです。 デフォルト範囲に「デフォルト」を使用してください。
public abstract ServiceLocationEnumeration
findServices(ServiceType type,
Vector scopes,
String searchFilter)
throws ServiceLocationException
公共の抽象的なServiceLocationEnumeration findServices(String searchFilter、VectorはServiceTypeがタイプするのを見る)はServiceLocationExceptionを投げます。
Returns a vector of ServiceURL objects for services matching the query, and having a matching type in the given scopes. If no services are found, an empty enumeration is returned.
ServiceURLオブジェクトのベクトルに、与えられた範囲に質問に合って、合っているタイプがあるサービスのために、返します。 サービスを全く見つけないなら、空の列挙を返します。
Parameters:
パラメタ:
type
タイプ
The SLP service type of the service.
SLPはサービスのタイプにサービスを提供します。
scopes
範囲
A Vector of scope names. The vector should be selected from
the results of a findScopes() API invocation. Use "DEFAULT"
for the default scope.
範囲名のVector。 ベクトルはfindScopes()API実施の結果から選択されるべきです。 デフォルト範囲に「デフォルト」を使用してください。
searchFilter
searchFilter
An LDAPv3 [4] string encoded query. If the filter is empty,
i.e. "", all services of the requested type in the specified
scopes are returned. SLP reserved characters must be escaped
in the query. Use ServiceLocationAttribute.escapeId() and
ServiceLocationAttribute.escapeValue() to construct the query.
LDAPv3[4]ストリングは質問をコード化しました。 フィルタがすなわち、空である、「「指定された範囲での要求されたタイプのすべてのサービスを返す、」 質問でSLPの控え目なキャラクタから逃げなければなりません。 ServiceLocationAttribute.escapeId()とServiceLocationAttribute.escapeValue()を使用して、質問を構成してください。
Kempf & Guttman Informational [Page 70] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[70ページ]のRFC2614はAPI1999年6月に位置を修理します。
public abstract ServiceLocationEnumeration
findAttributes(ServiceURL URL,
Vector scopes,
Vector attributeIds)
throws ServiceLocationException
公共の抽象的なServiceLocationEnumeration findAttributes(ServiceURL URL、Vector範囲、Vector attributeIds)はServiceLocationExceptionを投げます。
For the URL and scope, return a Vector of ServiceLocationAttribute objects whose ids match the String patterns in the attributeIds Vector. The request is made in the language locale of the Locator. If no attributes match, an empty enumeration is returned.
URLと範囲に関しては、イドがattributeIds VectorのStringパターンに合っているServiceLocationAttributeオブジェクトのVectorを返してください。 Locatorの言語現場で要求をします。 属性が全く合っていないなら、空の列挙を返します。
Parameters:
パラメタ:
URL
URL
The URL for which the attributes are desired.
属性が望まれているURL。
scopes
範囲
A Vector of scope names. The vector should be selected from
the results of a findScopes() API invocation. Use "DEFAULT"
for the default scope.
範囲名のVector。 ベクトルはfindScopes()API実施の結果から選択されるべきです。 デフォルト範囲に「デフォルト」を使用してください。
attributeIds
attributeIds
A Vector of String patterns identifying the desired attributes.
An empty vector means return all attributes. As described
in [7], the patterns may include wildcards to match substrings.
The strings may include SLP reserved characters, they will be
escaped by the API before transmission.
StringのVectorは、必要な属性を特定しながら、型に基づいて作ります。 空のベクトルは、すべての属性を返すことを意味します。 [7]で説明されるように、パターンはサブストリングを合わせるためにワイルドカードを含むかもしれません。 ストリングはSLPの控え目なキャラクタを含むかもしれなくて、彼らトランスミッションの前にAPIによって逃げられるでしょう。
public abstract ServiceLocationEnumeration
findAttributes(ServiceType type,
Vector scopes,
Vector attributeIds)
throws ServiceLocationException
公共の抽象的なServiceLocationEnumeration findAttributes(Vector attributeIds、VectorはServiceTypeがタイプするのを見る)はServiceLocationExceptionを投げます。
For the type and scope, return a Vector of all ServiceLocationAttribute objects whose ids match the String patterns in the attributeIds Vector regardless of the Locator's locale. The request is made independent of language locale. If no attributes are found, an empty vector is returned.
タイプと範囲に関しては、イドがLocatorの現場にかかわらずattributeIds VectorのStringパターンに合っているすべてのServiceLocationAttributeオブジェクトのVectorを返してください。 言語現場の如何にかかわらず要求をします。 属性が全く見つけられないなら、空のベクトルは返されます。
Kempf & Guttman Informational [Page 71] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[71ページ]のRFC2614はAPI1999年6月に位置を修理します。
Parameters:
パラメタ:
serviceType
serviceType
The service type.
サービスタイプ。
scopes
範囲
A Vector of scope names. The vector should be selected from
the results of a findScopes() API invocation. Use "DEFAULT"
for the default scope.
範囲名のVector。 ベクトルはfindScopes()API実施の結果から選択されるべきです。 デフォルト範囲に「デフォルト」を使用してください。
attributeIds
attributeIds
A Vector of String patterns identifying the desired
attributes. An empty vector means return all attributes.
As described in [7], the patterns may include wildcards to
match all prefixes or suffixes. The patterns may include SLP
reserved characters, they will be escaped by the API before
transmission.
StringのVectorは、必要な属性を特定しながら、型に基づいて作ります。 空のベクトルは、すべての属性を返すことを意味します。 [7]で説明されるように、パターンはすべての接頭語か接尾語を合わせるためにワイルドカードを含むかもしれません。 パターンはSLPの控え目なキャラクタを含むかもしれなくて、彼らトランスミッションの前にAPIによって逃げられるでしょう。
5.5. The Service Location Manager
5.5. サービスロケーションマネージャ
5.5.1. Class ServiceLocationManager
5.5.1. クラスServiceLocationManager
5.5.1.1. Synopsis
5.5.1.1. 構文
public class ServiceLocationManager
extends Object
公立のクラスServiceLocationManagerはObjectを広げています。
5.5.1.2. Description
5.5.1.2. 記述
The ServiceLocationManager manages access to the service location framework. Clients obtain the Locator and Advertiser objects for UA and SA, and a Vector of known scope names from the ServiceLocationManager.
ServiceLocationManagerはサービス位置のフレームワークへのアクセスを管理します。 クライアントはServiceLocationManagerからUAとSAのためのLocatorとAdvertiserオブジェクト、および知られている範囲名のVectorを入手します。
5.5.1.3. Class Methods
5.5.1.3. クラスメソッド
public static int getRefreshInterval() throws ServiceLocationException
公共の静的なint getRefreshInterval()はServiceLocationExceptionを投げます。
Kempf & Guttman Informational [Page 72] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[72ページ]のRFC2614はAPI1999年6月に位置を修理します。
Returns the maximum across all DAs of the min-refresh-interval attribute. This value satisfies the advertised refresh interval bounds for all DAs, and, if used by the SA, assures that no refresh registration will be rejected. If no DA advertises a min-refresh-interval attribute, a value of 0 is returned.
分が間隔が壮快な属性のすべてのDAsの向こう側に最大を返します。 広告を出すのは、すべてのDAsのために間隔領域をリフレッシュして、SAによって使用されるなら、いいえが登録をリフレッシュすることを保証します。この値が満足する、拒絶されるでしょう。 どんなDAも分が間隔が壮快な属性の広告を出さないなら、0の値を返します。
public static Vector findScopes() throws ServiceLocationException
公共の静的なVector findScopes()はServiceLocationExceptionを投げます。
Returns an Vector of strings with all available scope names. The list of scopes comes from a variety of sources, see Section 2.1 for the scope discovery algorithm. There is always at least one string in the Vector, the default scope, "DEFAULT".
すべての利用可能な範囲名があるストリングのVectorを返します。 セクション2.1は、範囲発見アルゴリズムに関して範囲のリストがさまざまなソースから来るのを見ます。 Vector、デフォルト範囲、「デフォルト」で少なくとも1個のストリングがいつもあります。
public static Locator getLocator(Locale locale) throws ServiceLocationException
公共の静的なLocator getLocator(現場現場)はServiceLocationExceptionを投げます。
Return a Locator object for the given language Locale. If the implementation does not support UA functionality, returns null.
与えられた言語LocaleのためにLocatorオブジェクトを返してください。 実装が、UAが機能性であるとサポートしないなら、リターンヌルです。
Parameters:
パラメタ:
locale
現場
The language locale of the Locator. The default SLP locale is
used if null.
Locatorの言語現場。 中古ですが、デフォルトSLP現場はヌルです。
public static Advertiser getAdvertiser(Locale locale) throws ServiceLocationException
公共の静的なAdvertiser getAdvertiser(現場現場)はServiceLocationExceptionを投げます。
Return an Advertiser object for the given language locale. If the implementation does not support SA functionality, returns null.
与えられた言語現場にAdvertiserオブジェクトを返してください。 実装が、SAが機能性であるとサポートしないなら、リターンヌルです。
Parameters:
パラメタ:
locale
現場
The language locale of the Advertiser. The default SLP locale
is used if null.
Advertiserの言語現場。 中古ですが、デフォルトSLP現場はヌルです。
Kempf & Guttman Informational [Page 73] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[73ページ]のRFC2614はAPI1999年6月に位置を修理します。
5.6. Service Template Introspection
5.6. サービステンプレートイントロスペクション
5.6.1. Abstract Class TemplateRegistry
5.6.1. 抽象クラスTemplateRegistry
5.6.1.1. Synopsis
5.6.1.1. 構文
public abstract class TemplateRegistry
公共の抽象クラスTemplateRegistry
5.6.1.2. Description
5.6.1.2. 記述
Subclasses of the TemplateRegistry abstract class provide access to service location templates [8]. Classes implementing TemplateRegistry perform a variety of functions. They manage the registration and access of service type template documents. They create attribute verifiers from service templates, for verification of attributes and introspection on template documents. Note that clients of the Advertiser are not required to verify attributes before registering (though they may get a TYPE_ERROR if the implementation supports type checking and there is a mismatch with the template).
TemplateRegistry抽象クラスのサブクラスは、位置のテンプレート[8]を調整するためにアクセスを提供します。 TemplateRegistryを実装するクラスがさまざまな機能を実行します。 彼らはサービスタイプテンプレートドキュメントの登録とアクセスを管理します。 彼らは属性と内省の検証のためにサービステンプレートから属性検証をテンプレートドキュメントに作成します。 Advertiserのクライアントが登録する前に属性について確かめる必要はないことに注意してください(実装がタイプの照合をサポートして、テンプレートがあるミスマッチがあれば、TYPE_ERRORを手に入れるかもしれませんが)。
5.6.1.3. Class Methods
5.6.1.3. クラスメソッド
public static TemplateRegistry getTemplateRegistry();
公共の静的なTemplateRegistry getTemplateRegistry()。
Returns the distinguished TemplateRegistry object for performing operations on and with service templates. Returns null if the implementation doesn't support TemplateRegistry functionality.
顕著なTemplateRegistryが操作を実行するためにテンプレートとサービステンプレートで反対させるリターン。 実装が、TemplateRegistryが機能性であるとサポートしないなら、ヌルを返します。
5.6.1.4. Instance Methods
5.6.1.4. インスタンスメソッド
public abstract void
registerServiceTemplate(ServiceType type,
String documentURL,
Locale locale,
String version)
throws ServiceLocationException
公共の抽象的な空のregisterServiceTemplate(ServiceTypeタイプ、String documentURL、Locale現場、Stringバージョン)はServiceLocationExceptionを投げます。
Register the service template with the template registry.
テンプレート登録にサービステンプレートを登録してください。
Kempf & Guttman Informational [Page 74] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[74ページ]のRFC2614はAPI1999年6月に位置を修理します。
Parameters:
パラメタ:
type
タイプ
The service type.
サービスタイプ。
documentURL
documentURL
A string containing the URL of the template document. May not
be the empty string.
テンプレートドキュメントのURLを含む五弦。 空のストリングでないかもしれません。
locale
現場
A Locale object containing the language locale of the template.
テンプレートの言語現場を含むLocaleオブジェクト。
version
バージョン
The version number identifier of template document.
テンプレートドキュメントに関するバージョン数の識別子。
public abstract void
公共の抽象的な空間
deregisterServiceTemplate(ServiceType type,
Locale locale,
String version)
throws ServiceLocationException
deregisterServiceTemplate(ServiceTypeタイプ、Locale現場、Stringバージョン)はServiceLocationExceptionを投げます。
Deregister the template for the service type.
サービスのためのテンプレートがタイプするDeregister。
Parameters:
パラメタ:
type
タイプ
The service type.
サービスタイプ。
locale
現場
A Locale object containing the language locale of the template.
テンプレートの言語現場を含むLocaleオブジェクト。
version
バージョン
A String containing the version number. Use null to indicate
the latest version.
バージョン番号を含むString。 ヌルを使用して、最新版を示してください。
Kempf & Guttman Informational [Page 75] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[75ページ]のRFC2614はAPI1999年6月に位置を修理します。
public abstract
String findTemplateURL(ServiceType type,
Locale locale,
String version)
throws ServiceLocationException
公共の抽象的なString findTemplateURL(ServiceTypeタイプ、Locale現場、Stringバージョン)はServiceLocationExceptionを投げます。
Returns the URL for the template document.
テンプレートドキュメントのためにURLを返します。
Parameters:
パラメタ:
type
タイプ
The service type.
サービスタイプ。
locale
現場
A Locale object containing the language locale of the template.
テンプレートの言語現場を含むLocaleオブジェクト。
version
バージョン
A String containing the version number. Use null to indicate
the latest version.
バージョン番号を含むString。 ヌルを使用して、最新版を示してください。
public abstract ServiceLocationAttributeVerifier attributeVerifier(String documentURL) throws ServiceLocationException
公共の抽象的なServiceLocationAttributeVerifier attributeVerifier(ストリングdocumentURL)はServiceLocationExceptionを投げます。
Reads the template document URL and returns an attribute verifier for the service type. The attribute verifier can be used for verifying that registration attributes match the template, and for introspection on the template definition.
テンプレートドキュメントURLを読んで、サービスタイプのために属性検証を返します。 登録属性がテンプレートに合っていることを確かめる、およびテンプレート定義の内省に属性検証を使用できます。
Parameters:
パラメタ:
documentURL
documentURL
A String containing the template document's URL. May not be the
empty string.
テンプレートドキュメントのURLを含むString。 空のストリングでないかもしれません。
Kempf & Guttman Informational [Page 76] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[76ページ]のRFC2614はAPI1999年6月に位置を修理します。
5.6.2. Interface ServiceLocationAttributeVerifier
5.6.2. インタフェースServiceLocationAttributeVerifier
5.6.2.1. Synopsis
5.6.2.1. 構文
public interface ServiceLocationAttributeVerifier
公共のインタフェースServiceLocationAttributeVerifier
5.6.2.2. Description
5.6.2.2. 記述
The ServiceLocationAttributeVerifier provides access to service templates. Classes implementing this interface parse SLP template definitions, provide information on attribute definitions for service types, and verify whether a ServiceLocationAttribute object matches a template for a particular service type. Clients obtain ServiceLocationAttributeVerifier objects for specific SLP service types through the TemplateRegistry.
ServiceLocationAttributeVerifierは、テンプレートを調整するためにアクセスを提供します。 このインタフェースを実装するクラスは、SLPテンプレート定義を分析して、属性定義の情報をサービスタイプに提供して、特定のサービスタイプのためにServiceLocationAttributeオブジェクトがテンプレートに合っているかどうか確かめます。 クライアントはTemplateRegistryを通して特定のSLPサービスタイプにServiceLocationAttributeVerifierオブジェクトを入手します。
5.6.2.3. Instance Methods
5.6.2.3. インスタンスメソッド
public abstract ServiceType getServiceType()
公共の抽象的なServiceType getServiceType()
Returns the SLP service type for which this is the verifier.
これが検証であるSLPサービスタイプを返します。
public abstract Locale getLocale()
公共の抽象的なLocale getLocale()
Return the language locale of the template.
テンプレートの言語現場を返してください。
public abstract String getVersion()
公共の抽象的なString getVersion()
Return the template version number identifier.
テンプレートバージョン数の識別子を返してください。
public abstract String getURLSyntax()
公共の抽象的なString getURLSyntax()
Return the URL syntax expression for the service: URL.
サービスのためにURL構文式を返してください: URL。
public abstract String getDescription()
公共の抽象的なString getDescription()
Kempf & Guttman Informational [Page 77] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[77ページ]のRFC2614はAPI1999年6月に位置を修理します。
Return the descriptive help text for the template.
テンプレートのために描写的である助けテキストを返してください。
public abstract ServiceLocationAttributeDescriptor getAttributeDescriptor(String attrId)
公共の抽象的なServiceLocationAttributeDescriptor getAttributeDescriptor(ストリングattrId)
Return the ServiceLocationAttributeDescriptor for the attribute having the named id. If no such attribute exists in this template, return null. This method is primarily for GUI tools to display attribute information. Programmatic verification of attributes should use the verifyAttribute() method.
命名されたイドを持っている属性のためにServiceLocationAttributeDescriptorを返してください。 何かそのような属性がこのテンプレートに存在しないなら、ヌルを返してください。 このメソッドはGUIツールが主として属性情報を表示することです。 属性のプログラムに従った検証はverifyAttribute()メソッドを使用するべきです。
public abstract Enumeration getAttributeDescriptors()
公共の抽象的なEnumeration getAttributeDescriptors()
Returns an Enumeration allowing introspection on the attribute definition in the service template. The Enumeration returns ServiceLocationAttributeDescriptor objects for the attributes. This method is primarily for GUI tools to display attribute information. Programmatic verification of attributes should use the verifyAttribute() method.
サービステンプレートとの属性定義のときに内省を許すEnumerationを返します。 Enumerationは属性のためにオブジェクトをServiceLocationAttributeDescriptorに返します。 このメソッドはGUIツールが主として属性情報を表示することです。 属性のプログラムに従った検証はverifyAttribute()メソッドを使用するべきです。
public abstract void
verifyAttribute(
ServiceLocationAttribute attribute)
throws ServiceLocationException
公共の抽象的な空のverifyAttribute(ServiceLocationAttribute属性)はServiceLocationExceptionを投げます。
Verify that the attribute matches the template definition. If the attribute doesn't match, ServiceLocationException is thrown with the error code as ServiceLocationException.PARSE_ERROR.
属性がテンプレート定義に合っていることを確かめてください。 属性が合っていないなら、ServiceLocationExceptionはServiceLocationException.PARSE_ERRORとしてエラーコードで投げられます。
Parameters:
パラメタ:
attribute
属性
The ServiceLocationAttribute object to be verified.
ServiceLocationAttributeは、確かめられるために反対します。
public abstract void
verifyRegistration(
Vector attributeVector)
throws ServiceLocationException
公共の抽象的な空のverifyRegistration(ベクトルattributeVector)はServiceLocationExceptionを投げます。
Kempf & Guttman Informational [Page 78] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[78ページ]のRFC2614はAPI1999年6月に位置を修理します。
Verify that the Vector of ServiceLocationAttribute objects matches the template for this service type. The vector must contain all the required attributes, and all attributes must match their template definitions. If the attributes don't match, ServiceLocationException is thrown with the error code as ServiceLocationException.PARSE_ERROR
ServiceLocationAttributeオブジェクトのVectorがこのサービスタイプのためのテンプレートに合っていることを確かめてください。 ベクトルはすべての必要な属性を含まなければなりません、そして、すべての属性が彼らのテンプレート定義に合わなければなりません。 属性が合っていないなら、ServiceLocationExceptionはServiceLocationException.PARSE_ERRORとしてエラーコードで投げられます。
Parameters:
パラメタ:
attributeVector
attributeVector
A Vector of ServiceLocationAttribute objects for the
registration.
ServiceLocationAttributeのVectorは登録のために反対します。
5.6.3. Interface ServiceLocationAttributeDescriptor
5.6.3. インタフェースServiceLocationAttributeDescriptor
5.6.3.1. Synopsis
5.6.3.1. 構文
public interface ServiceLocationAttributeDescriptor
公共のインタフェースServiceLocationAttributeDescriptor
5.6.3.2. Description
5.6.3.2. 記述
The ServiceLocationAttributeDescriptor interface provides introspection on a template attribute definition. Classes implementing the ServiceLocationAttributeDescriptor interface return information on a particular service location attribute definition from the service template. This information is primarily for GUI tools. Programmatic attribute verification should be done through the ServiceLocationAttributeVerifier.
ServiceLocationAttributeDescriptorインタフェースはテンプレート属性定義に内省を提供します。 ServiceLocationAttributeDescriptorインタフェースを実装するクラスがサービステンプレートから特定のサービス位置の属性定義の情報を返します。 この情報は主としてGUIツールのためのものです。 ServiceLocationAttributeVerifierを通してプログラムに従った属性検証をするべきです。
5.6.3.3. Instance Methods
5.6.3.3. インスタンスメソッド
public abstract String getId()
公共の抽象的なString getId()
Return a String containing the attribute's id.
属性のイドを含むStringを返してください。
public abstract String getValueType()
公共の抽象的なString getValueType()
Return a String containing the fully package-qualified Java type of the attribute. SLP types are translated into Java types as follows:
属性のパッケージで完全に適任のJavaタイプを含むStringを返してください。 SLPタイプは以下のJavaタイプに翻訳されます:
Kempf & Guttman Informational [Page 79] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[79ページ]のRFC2614はAPI1999年6月に位置を修理します。
STRING
ストリング
"java.lang.String"
"java.lang.String"
INTEGER
整数
"java.lang.Integer"
"java.lang.Integer"
BOOLEAN
論理演算子
"java.lang.Boolean"
"java.lang.Boolean"
OPAQUE
不透明なもの
"[B" (i.e. array of byte, byte[])
「[B」(すなわち、バイト、バイト[])の勢ぞろい
KEYWORD
キーワード
empty string, ""
ストリングを空にしてください、「」
public abstract String getDescription()
公共の抽象的なString getDescription()
Return a String containing the attribute's help text.
属性の助けテキストを含むStringを返してください。
public abstract Enumeration getAllowedValues()
公共の抽象的なEnumeration getAllowedValues()
Return an Enumeration of allowed values for the attribute type. For keyword attributes returns null. For no allowed values (i.e. unrestricted) returns an empty Enumeration.
属性タイプのために許容値のEnumerationを返してください。 キーワードに関しては、属性はヌルを返します。 いいえが値が(すなわち、無制限)で許容された空のEnumerationを返すので。
public abstract Enumeration getDefaultValues()
公共の抽象的なEnumeration getDefaultValues()
Return an Enumeration of default values for the attribute type. For keyword attributes returns null. For no allowed values (i.e. unrestricted) returns an empty Enumeration.
属性タイプのためにデフォルト値のEnumerationを返してください。 キーワードに関しては、属性はヌルを返します。 いいえが値が(すなわち、無制限)で許容された空のEnumerationを返すので。
public abstract boolean getRequiresExplicitMatch()
公共の抽象的な論理演算子getRequiresExplicitMatch()
Kempf & Guttman Informational [Page 80] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[80ページ]のRFC2614はAPI1999年6月に位置を修理します。
Returns true if the "X"" flag is set, indicating that the attribute should be included in an any Locator.findServices() request search filter.
「本当に、「X」」旗が設定されるなら、属性がどんなLocator.findServices()要求検索フィルタにも含まれるべきであるのを示して、戻ります。
public abstract boolean getIsMultivalued()
公共の抽象的な論理演算子getIsMultivalued()
Returns true if the "M" flag is set.
本当に、「M」旗が設定されるなら、戻ります。
public abstract boolean getIsOptional()
公共の抽象的な論理演算子getIsOptional()
Returns true if the "O"" flag is set.
「本当に、「O」」旗が設定されるなら、戻ります。
public abstract boolean getIsLiteral()
公共の抽象的な論理演算子getIsLiteral()
Returns true if the "L" flag is set.
本当に、「L」旗が設定されるなら、戻ります。
public abstract boolean getIsKeyword()
公共の抽象的な論理演算子getIsKeyword()
Returns true if the attribute is a keyword attribute.
本当に、属性がキーワード属性であるなら、戻ります。
5.7. Implementation Notes
5.7. 実装注意
5.7.1. Refreshing Registrations
5.7.1. 壮快な登録証明書
A special lifetime constant, ServiceURL.LIFETIME_PERMANENT, is used by clients to indicate that the URL should be automatically refreshed until the application exits. The API implementation should interpret this flag as indicating that the URL lifetime is ServiceURL.LIFETIME_MAXIMUM, and MUST arrange for automatic refresh to occur.
特別な生涯定数(ServiceURL.LIFETIME_PERMANENT)は、アプリケーションが出るまでURLが自動的にリフレッシュされるべきであるのを示すのにクライアントによって使用されます。 オートマチックが起こるようにリフレッシュするので、URL寿命がServiceURL.LIFETIME_MAXIMUMであり、手配しなければならないのを示すとAPI実行はこの旗を解釈するべきです。
5.7.2. Parsing Alternate Transports in ServiceURL
5.7.2. ServiceURLで代替の輸送を分析します。
The ServiceURL class is designed to handle multiple transports. The standard API performs no additional processing on transports other than IP except to separate out the host identifier and the URL path. However, implementations are free to subclass ServiceURL and support additional methods that provide more detailed parsing of alternate transport information. For IP transport, the port number, if any, is
ServiceURLのクラスは、複数の輸送を扱うように設計されています。 標準のAPIはホスト識別子とURL経路を分離する以外のIP以外の輸送にどんな追加処理も実行しません。 しかしながら、実装は、サブクラスServiceURLに自由であり、代替の輸送情報の、より詳細な構文解析を提供する追加メソッドをサポートします。 IP輸送のために、もしあればポートナンバーはそうです。
Kempf & Guttman Informational [Page 81] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[81ページ]のRFC2614はAPI1999年6月に位置を修理します。
returned from the getPort() method. For non-IP transports, the getPort() method returns NO_PORT.
getPort()メソッドから、戻りました。 非IP輸送のために、getPort()メソッドはいいえ_PORTを返します。
5.7.3. String Attribute Values
5.7.3. ストリング属性値
In general, translation between Java types for attribute values and the SLP on-the-wire string is straightforward. However, there are two corner cases. If the Java attribute value type is String and the value of the string has an on-the-wire representation that is inferred by SLP as an integer, the registered attribute value may not be what the API client intended. A similar problem could result if the Java attribute value is the string "true" or "false", in which case the on-the-wire representation is inferred to boolean. To handle these corner cases, the Java API prepends a space onto the string. So, for example, if the string attribute value is "123", the Java API transforms the value to "123 ", which will have an on-the- wire representation that is inferred by SLP to be string. Since appended and prepended spaces have no effect on query handling, this procedure should cause no problem with queries. API clients need to be aware, however, that the transformation is occurring.
一般に、属性値のためのJavaタイプとワイヤの上のSLPストリングの間の翻訳は簡単です。 しかしながら、2つの角のケースがあります。 Java属性値タイプがStringであり、ストリングの値にワイヤにおける整数としてSLPによって推論される表現があるなら、登録された属性値はAPIクライアントが意図したことでないかもしれません。 同様の問題はJava属性値が「虚偽「本当に」か」ストリングであるなら結果として生じるかもしれません、その場合、ワイヤにおける表現は論理演算子に推論されます。 これらを扱うのはケースを追い詰めて、Java API prependsはストリングへのスペースです。 そのように、例えば、Java APIがストリング属性値が「123」であるなら、値を「123」に変えて、どのウィルがそうしたか、オンである、-、-ストリングになるようにSLPによって推論される表現を配線してください。 追加されて、prependedされるので、空間は質問取り扱いのときに効き目がなくて、この手順は質問に関する問題を全く引き起こすべきではありません。 APIクライアントは、しかしながら、変換が起こっているのを意識している必要があります。
5.7.4. Client Side Syntax Checking
5.7.4. クライアントサイド構文の照合
The syntax of scope names, service type names, naming authority names, and URLs is described in [7] and [8]. The various methods and classes taking String parameters for these entities SHOULD type check the parameters for syntax errors on the client side, and throw an IllegalArgumentException if an error occurs. In addition, character escaping SHOULD be implemented before network transmission for escapable characters in attribute ids and String values. This reduces the number of error messages transmitted. The ServiceLocationAttribute class provides methods for clients to obtain escaped attribute id and value strings to facilitate query construction.
範囲名、サービス型名、命名権威名、およびURLの構文は[7]と[8]で説明されます。 SHOULDがタイプするこれらの実体のためのStringパラメタを取る様々なメソッドとクラスは、構文エラーがないかどうかクライアント側でパラメタをチェックして、誤りが発生するなら、IllegalArgumentExceptionを投げます。 追加、SHOULDから逃げるキャラクタでは、ネットワーク送信の前に属性イドとString値における脱出できるキャラクタのために実装されてください。 これは伝えられたエラーメッセージの数を減少させます。 ServiceLocationAttributeのクラスはクライアントが質問工事を容易にするために逃げられた属性イドと値のストリングを入手するメソッドを提供します。
5.7.5. Language Locale Handling
5.7.5. 言語現場取り扱い
The Locator and Advertiser interfaces are created with a Locale parameter. The language locale with which these objects are created is used in all SLP requests issued through the object. If the Locale parameter is null, the default SLP locale is used. The default SLP locale is determined by, first, checking the net.slp.locale System property. If that is unset, then the default SLP locale [7] is used, namely "en". Note that the default SLP locale may not be the same as the default Java locale.
LocatorとAdvertiserインタフェースはLocaleパラメタで作成されます。 これらのオブジェクトが作成される言語現場はオブジェクトを通して出されたすべてのSLP要求で使用されます。 Localeパラメタがヌルであるなら、デフォルトSLP現場は使用されています。 デフォルトSLP現場は、最初にnet.slp.locale Systemの特性をチェックすることによって、決定します。 それがunset、次に、使用されるデフォルトSLP現場[7]、すなわち、「アン」であるなら。 デフォルトSLP現場がデフォルトJava現場と同じでないかもしれないことに注意してください。
Kempf & Guttman Informational [Page 82] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[82ページ]のRFC2614はAPI1999年6月に位置を修理します。
5.7.6. Setting SLP System Properties
5.7.6. SLP系特性を設定します。
SLP system properties that are originally set in the configuration file can be overridden programmatically in API clients by simply invoking the System.getProperties() operation to get a copy of the system properties, modifying or adding the SLP property in question, then using System.setProperties() to set the properties to the modified Property object. Program execution continues without interruption by substituting the default for the erroneous parameter. Errors are checked when the property is used and are logged.
APIクライアントで系特性のコピーを手に入れるために単にSystem.getProperties()操作を呼び出すことによって、プログラムに基づいて元々構成ファイルに設定されるSLP系特性は無視できます、問題のSLPの特性を変更するか、または加えて、次に、変更されたPropertyオブジェクトへの特性を設定するのにSystem.setProperties()を使用して。 プログラム実行は、デフォルトを誤ったパラメタの代わりに用いることによって、間断ない続きます。 誤りは、特性が使用されているとき、チェックされて、登録されます。
The SLP configuration file cannot be read with the java.util.Properties file reader because there are some syntactic differences. The SLP configuration file syntax defines a different escape convention for non-ASCII characters than the Java syntax. However, after the file has been read, the properties are stored and retrieved from java.util.Properties objects.
いくつかの構文の違いがあるので、java.util.Propertiesファイルの読者と共にSLP構成ファイルを読むことができません。 SLP構成ファイル構文は非ASCII文字のためにJava構文と異なったエスケープコンベンションを定義します。 しかしながら、ファイルが読まれた後に、特性は、java.util.Propertiesオブジェクトから保存されて、検索されます。
Properties are global for a process, affecting all threads and all Locator and Advertiser objects obtained through the ServiceLocationManager. With the exception of the net.slp.locale, net.slp.typeHint, and net.slp.maxResults properties, clients should rarely be required to override these properties, since they reflect properties of the SLP network that are not of concern to individual agents. If changes are required, system administrators should modify the configuration file.
プロセスに、オブジェクトがServiceLocationManagerを通して入手したすべてのスレッド、すべてのLocator、およびAdvertiserに影響して、特性はグローバルです。 net.slp.locale、net.slp.typeHint、およびnet.slp.maxResultsの特性を除いて、クライアントはこれらの特性を無視するのがめったに必要であるべきではありません、SLPネットワークの個々のエージェントには、重要でない特性を反映するので。 変化が必要であるなら、システム管理者は構成ファイルを変更するべきです。
5.7.7. Multithreading
5.7.7. マルチスレッド化
Thread-safe operation is relatively easy to achieve in Java. By simply making each method in the classes implementing the Locator and Advertiser interfaces synchronized, and by synchronizing access to any shared data structures within the class, the Locator and Advertiser interfaces are made safe. Alternatively, finer grained synchronization is also possible within the classes implementing Advertiser and Locator.
スレッド・セーフ操作はJavaで比較的達成しやすいです。 クラスの中でインタフェースが連動して、連動するどんな共有データ構造にもアクセスするLocatorとAdvertiserを実装するクラスで単に各メソッドを作ることによって、LocatorとAdvertiserインタフェースを安全にします。 あるいはまた、また、よりよい粒状の同期も、AdvertiserとLocatorを実装しながら、クラスの中で可能です。
5.7.8. Modular Implementations
5.7.8. モジュールの実装
While, at first glance, the API may look rather heavyweight, the design has been carefully arranged so that modular implementations that provide only SA, only UA, or only service template access capability, or any combination of the three, are possible.
APIが一見したところではかなりヘビー級に見えているかもしれない間、デザインが慎重にアレンジされているので、SAだけ、UAだけ、サービステンプレートアクセス能力、または3つのもののどんな組み合わせだけも提供するモジュールの実装は可能です。
Because the objects returned from the ServiceLocationManager.getLocator() and ServiceLocationManager.getAdvertiser() operations are interfaces, and because the objects returned through those interfaces are in the set
オブジェクトが通じて戻ったので、オブジェクトがServiceLocationManager.getLocator()から戻って、ServiceLocationManager.getAdvertiser()操作がインタフェースであり、セットにそれらのインタフェースがあるので
Kempf & Guttman Informational [Page 83] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[83ページ]のRFC2614はAPI1999年6月に位置を修理します。
of base data structures, an implementation is free to omit either UA or SA capability by simply returning null from the instance creation operation if the classes implementing the missing function cannot be dynamically linked. API clients are encouraged to check for such a contingency, and to signal an exception if it occurs. Similarly, the TemplateRegistry concrete subclass can simply be omitted from an implementation that only supports UA and/or SA clients, and the TemplateRegistry.getRegistry() method can return null. In this way, the API implementation can be tailored for the particular memory requirements at hand.
ベースデータ構造では、ダイナミックになくなった機能を実装するクラスをリンクできないなら、実装は単に戻っているヌルでインスタンス作成操作から自由にUAかSA能力のどちらかを省略できます。 起こるなら、APIクライアントは、そのような偶然性がないかどうかチェックして、例外に合図するよう奨励されます。 同様に、UA、そして/または、SAがクライアントであるとサポートするだけである実装からTemplateRegistryの具体的なサブクラスを単に省略できます、そして、TemplateRegistry.getRegistry()メソッドはヌルを返すことができます。 このように、API実行は手元の特定のメモリ要件のために合わせることができます。
In addition, if an implementation only supports the minimal subset of SLP [7], the unsupported Locator and Advertiser interface operations can throw an exception with ServiceLocationException.NOT_IMPLEMENTED as the error code. This supports better source portability between low and high memory platforms.
さらに、実装がSLP[7]の最小量の部分集合をサポートするだけであるなら、サポートされないLocatorとAdvertiserインタフェース操作はServiceLocationException.NOT_IMPLEMENTEDと共にエラーコードとして例外を投げることができます。 これは低くて高いメモリプラットホームの間の、より良いソースの移植性をサポートします。
5.7.9. Asynchronous and Incremental Return Semantics
5.7.9. 非同期で増加のリターン意味論
The Java API contains no specific support for asynchronous operation. Incremental return is not needed for the Advertiser because service registrations can be broken up into pieces when large. Asynchronous return is also not needed because clients can always issue the Advertiser operation in a separate thread if the calling thread can't block.
Java APIは非同期動作のどんな特定のサポートも含んでいません。 増加収益は、大きいときに、ばらばらにサービス登録証明書を終えることができるので、Advertiserに必要ではありません。 また、呼ぶスレッドが立ち塞がることができないならクライアントがいつも別々のスレッドにおけるAdvertiser操作を発行できるので、非同期なリターンは必要ではありません。
The Locator can be implemented either synchronously or asynchronously. Since the return type for Locator calls is ServiceLocationEnumeration, a Java API implementation that supports asynchronous semantics can implement ServiceLocationEnumeration to dole results out as they come in, blocking when no results are available. If the client code needs to support other processing while the results are trickling in, the call into the enumeration to retrieve the results can be done in a separate thread.
Locatorを同期か非同期に実装することができます。 Locator呼び出しのためのリターンタイプがServiceLocationEnumerationであるので、非同期な意味論をサポートするJava API実行は入るとき結果を分け与えるためにServiceLocationEnumerationを実装することができます、どんな結果も利用可能でないときにブロッキング。 クライアントコードが、結果がぽつぽつ入っている間、他の処理をサポートする必要があるなら、別々のスレッドで結果を検索する列挙へ呼び出しできます。
Unlike the C case, collation semantics for return of attributes when an attribute request by service type is made require that the API collate returned values so that only one attribute having a collation of all returned values appear to the API client. In practice, this may limit the amount of asynchronous processing possible with the findAttributes() method. This requirement is imposed because memory management is much easier in Java and so implementing collation as part of the API should not be as difficult as in C, and it saves the client from having to do the collation.
Cケース、サービスタイプによる属性要求をするときの属性の復帰のための照合意味論と異なって、すべての戻り値の照合を持っている1つの属性だけがAPIクライアントにとって現れるくらいAPIが戻り値を照合するのを必要であってください。 実際には、これはfindAttributes()メソッドで可能な非同期処理の量を制限するかもしれません。 この要件は、メモリ管理がJavaではるかに簡単であるので課されるので、APIの部分がCと同じくらい難しいはずがないので、照合を実装します、そして、それは照合しなければならないので、クライアントを救います。
Kempf & Guttman Informational [Page 84] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[84ページ]のRFC2614はAPI1999年6月に位置を修理します。
5.8. Example
5.8. 例
In this example, a printer server advertises its availability to clients. Additionally, the server advertises a service template for use by client software in validating service requests:
この例では、プリンタサーバはクライアントに有用性の広告を出します。 さらに、サーバはクライアントソフトウェアでサービスのリクエストを有効にする際に使用のためのサービステンプレートの広告を出します:
//Get the Advertiser and TemplateRegistry.
//は広告主とTemplateRegistryを手に入れます。
Advertiser adv = null; TemplateRegistry tr = null
広告主advはヌルと等しいです。 TemplateRegistry trはヌルと等しいです。
try {
トライ
adv = ServiceLocationManager.getAdvertiser("en");
advはServiceLocationManager.getAdvertiser(「アン」)と等しいです。
tr = TemplateRegistry.getTemplateRegistry();
trはTemplateRegistry.getTemplateRegistry()と等しいです。
} catch( ServiceLocationException ex ) { } //Deal with error.
(ServiceLocationException元の連れ合い)を捕らえてください。 誤りとの//取引。
if( adv == null ) {
(adv=ヌル)です。
//Serious error as printer can't be registered
// if the implementation doesn't support SA
// functionality.
実装が、SA//が機能性であるとサポートしないなら、プリンタとしての//重大な誤りは登録された//であるはずがない。
}
}
//Get the printer's attributes, from a file or // otherwise. We assume that the attributes // conform to the template, otherwise, we // could register the template here and verify // them.
//はファイルか//そうでないのからプリンタの属性を得ます。 そうでなければ、属性//がテンプレートに従って、私たちが//であることは、ここにテンプレートを登録して、//について確かめるかもしれません。私たちが仮定する、それら。
Vector attributes = getPrinterAttributes();
ベクトル属性はgetPrinterAttributes()と等しいです。
//Create the service: URL for the printer.
//はサービスを作成します: プリンタのためのURL。
ServiceURL printerURL =
new ServiceURL(
"service:printer:lpr://printshop/color2",
ServiceURL.LIFETIME_MAXIMUM);
ServiceURL printerURLが新しいServiceURLと等しい、(「サービス:プリンタ:lpr://版画店/color2"、ServiceURL.LIFETIME_MAXIMUM)」、。
try {
トライ
//Register the printer.
//はプリンタを登録します。
adv.register(printerURL, attributes);
副詞レジスタ(printerURL、属性)。
Kempf & Guttman Informational [Page 85] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[85ページ]のRFC2614はAPI1999年6月に位置を修理します。
//If the template registry is available,
// register the printer's template.
//はテンプレート登録であるなら利用可能であり、//レジスタはプリンタのテンプレートです。
if( tr != null ) {
tr.registerServiceTemplate(
new ServiceType("service:printer:lpr"),
"http://shop.arv/printer/printer-lpr.slp",
new Locale("en",""),
"1.0");
「(tr!=ヌル)である、tr.registerServiceTemplate、(新しいServiceType(「サービス:プリンタ:lpr」)、" http://shop.arv/printer/printer-lpr.slp "新しい現場、(「アン」、」、」、)、「1インチ)、;、」
}
}
} catch( ServiceLocationException ex ) { } //Deal with error.
(ServiceLocationException元の連れ合い)を捕らえてください。 誤りとの//取引。
Suppose a client is looking for color printer. The following code is used to issue a request for printer advertisements:
クライアントがカラープリンタを探していると仮定してください。 以下のコードはプリンタ広告を求める要求を出すのに使用されます:
Locator loc = null; TemplateRegistry tr = null;
ロケータlocはヌルと等しいです。 TemplateRegistry trはヌルと等しいです。
try {
トライ
loc = ServiceLocationManager.getLocator("en");
locはServiceLocationManager.getLocator(「アン」)と等しいです。
} catch( ServiceLocationException ex ) { } //Deal with error.
(ServiceLocationException元の連れ合い)を捕らえてください。 誤りとの//取引。
if( loc == null ) {
(loc=ヌル)です。
//Serious error as client can't be located
// if the implementation doesn't support
// UA functionality.
実装が、//UAが機能性であるとサポートしないなら、クライアントとしての//重大な誤りは見つけられた//であるはずがない。
}
}
//We want a color printer that does CMYK // and prints at least 600 dpi.
//、私たちは、CMYK//をして、少なくとも600dpiを印刷するカラープリンタが欲しいと思います。
String query = "(&(marker-type=CMYK)(resolution=600))";
「((マーカータイプはCMYKと等しいです)(解決=600))」という質問=を結んでください。
//Get scopes.
//は範囲を手に入れます。
Vector scopes = ServiceLocationManager.findScopes();
ベクトル・スコープはServiceLocationManager.findScopes()と等しいです。
Enumeration services;
列挙サービス。
try {
トライ
Kempf & Guttman Informational [Page 86] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[86ページ]のRFC2614はAPI1999年6月に位置を修理します。
services =
loc.findServices(new ServiceType("service:printer"),scopes,query);
サービスはloc.findServices(新しいServiceType(「サービス: プリンタ」)、範囲、質問)と等しいです。
} catch { } //Deal with error.
キャッチ 誤りとの//取引。
if (services.hasMoreElements() ) {
(services.hasMoreElements() )
//Printers can now be used.
ServiceURL surl = (ServiceURL) services.next();
現在、//プリンタを使用できます。 ServiceURL surlは(ServiceURL)services.next()と等しいです。
Socket sock = new Socket(surl.getHost, surl.getPort());
ソケットソックス=の新しいSocket、(surl.getHost、surl.getPort())。
// Use the Socket...
//はソケットを使用します…
}
}
6. Internationalization Considerations
6. 国際化問題
6.1. service URL
6.1. サービスURL
The service URL itself must be encoded using the rules set forth in [2]. The character set encoding is limited to specific ranges within the UTF-8 character set [3].
[2]に詳しく説明された規則を使用することでサービスURL自体をコード化しなければなりません。 文字集合コード化はUTF-8文字集合[3]の中で特定の範囲に制限されます。
The attribute information associated with the service URL must be expressed in UTF-8. See [8] for attribute internationalization guidelines.
UTF-8でサービスURLに関連している属性情報を言い表さなければなりません。 属性国際化ガイドラインのための[8]を見てください。
6.2. Character Set Encoding
6.2. 文字コードコード化
Configuration and serialized registration files are encoded in the UTF-8 character set [3]. This is fully compatible with US-ASCII character values. C platforms that do not support UTF-8 are required to check the top bit of input bytes to determine whether the incoming character is multibyte. If it is, the character should be dealt with accordingly. This should require no additional implementation effort, since the SLP wire protocol requires that strings are encoded as UTF-8. C platforms without UTF-8 support need to supply their own support, if only in the form of multibyte string handling.
構成と連載された登録ファイルはUTF-8文字集合[3]でコード化されます。 これは米国-ASCII文字値と完全に互換性があります。 UTF-8をサポートしないCプラットホームが、入って来るキャラクタが「マルチ-バイト」であるかどうか決定するために入力バイトのトップビットをチェックするのに必要です。 それがそうなら、キャラクタはそれに従って、対処されるべきです。 SLPワイヤプロトコルが、ストリングがUTF-8としてコード化されるのを必要とするので、これはどんな追加実装取り組みも必要とするべきではありません。 UTF-8サポートのないCプラットホームは、それら自身のサポートを供給する必要があって、「マルチ-バイト」の形では、取り扱いを結びさえしてくださいという場合、よかったでしょう。
At the API level, the character encoding is specified to be Unicode for Java and UTF-8 for C. Unicode is the default in Java. For C, the standard US-ASCII 8 bits per character, null terminated C strings are a subset of the UTF-8 character set, and so work in the API. Because the C API is very simple, the API library needs to do a minimum of processing on UTF-8 strings. The strings primarily just need to be reflected into the outgoing SLP messages, and reflected out of the
APIレベルでは、文字符号化はJavaのためのユニコードになるように指定されます、そして、C.ユニコードのためのUTF-8はJavaでデフォルトです。 Cに関しては、ヌル終えられたCストリングは、UTF-8文字集合の部分集合であるのでAPIで米国-ASCII1キャラクタあたり標準の8ビット、働いています。 C APIが非常に簡単であるので、APIライブラリは、UTF-8ストリングで最小処理をする必要があります。 送信するSLPメッセージに反映されて、反映されますストリングが、主としてただ必要がある。
Kempf & Guttman Informational [Page 87] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[87ページ]のRFC2614はAPI1999年6月に位置を修理します。
API from incoming SLP messages.
入って来るSLPメッセージからのAPI。
6.3. Language Tagging
6.3. 言語タグ付け
All SLP requests and registrations are tagged to indicate in which language the strings included are encoded. This allows multiple languages to be supported. It also presents the possibility that error conditions result when a request is made in a language that is not supported. In this case, an error is only returned when there is data available, but not obtainable in the language requested.
すべてのSLP要求と登録証明書は、含まれていたストリングがどの言語でコード化されるかを示すためにタグ付けをされます。 これは、複数の言語がサポートされるのを許容します。 また、サポートされない言語で要求をするとき、それはそのエラー条件結果を可能性に提示します。 この場合、利用可能な、しかし、要求された言語で入手可能でないデータがあるときだけ、誤りは返されます。
The dialect portion of the Language Tag is used on 'best effort' basis for matching strings by SLP. Dialects that match are preferred over those which don't. Dialects that do not match will not prevent string matching or comparisons from occurring.
Language Tagの方言一部が合っているストリング'ベストエフォート型'のベースでSLPによって使用されます。 合っている方言はそうしないそれらより好まれます。 合っていない方言は、ストリングマッチングか比較が起こるのを防がないでしょう。
7. Security Considerations
7. セキュリティ問題
Security is handled within the API library and is not exposed to API clients except in the form of exceptions. The net.slp.securityEnabled, property determines whether an SA client's messages are signed, but a UA client should be prepared for an authentication exception at any time, because it may contact a DA with authenticated advertisements.
セキュリティは、API図書館の中で扱われて、例外の形以外に、APIクライアントに暴露されません。 net.slp.securityEnabled、特性は、SAクライアントのメッセージが署名されるかどうか決定しますが、UAクライアントはいつでも認証例外のために用意ができているべきです、認証された広告でDAに連絡するかもしれないので。
An adversary could delete valid service advertisements, provide false service information and deny UAs knowledge of existing services unless the mechanisms in SLP for authenticating SLP messages are used. These mechanisms allow DAAdverts, SAAdverts, Service URLs and Service Attributes to be verified using digital cryptography. For this reason, all SLP agents should be configured to use SLP SPIs. See [7] for a description of how this mechanism works.
SLPメッセージを認証するためのSLPのメカニズムが使用されていない場合、敵は、有効なサービス広告を削除して、誤ったサービスに情報を提供して、既存のサービスに関する知識をUAsに対して否定するかもしれません。 これらのメカニズムは、DAAdverts、SAAdverts、Service URL、およびService Attributesが確かめられるのをデジタル暗号を使用することで許容します。 この理由で、すべてのSLPエージェントが、SLP SPIsを使用するために構成されるべきです。 このメカニズムがどう動作するかに関する記述のための[7]を見てください。
8. Acknowledgements
8. 承認
The authors would like to thank Don Provan for his pioneering work during the initial stages of API definition.
作者はAPI定義の初期の間、彼の先導的仕事についてドンProvanに感謝したがっています。
Kempf & Guttman Informational [Page 88] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[88ページ]のRFC2614はAPI1999年6月に位置を修理します。
9. References
9. 参照
[1] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[2]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[3] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[3]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[4] Howes, T., "The String Representation of LDAP Search Filters",
RFC 2254 December 1997.
[4] ハウズ、T.、「LDAP検索フィルタのストリング表現」、RFC2254 1997年12月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[5] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[6] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[6]、RFC1766、1995年3月。
[7] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[7] Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。
[8] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
Service: Schemes", RFC 2609, June 1999.
[8] Guttman(E.、パーキンス、C.、およびJ.ケンフ)は「テンプレートを調整して、以下を修理します」。 「体系」、RFC2609、1999年6月。
Kempf & Guttman Informational [Page 89] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[89ページ]のRFC2614はAPI1999年6月に位置を修理します。
10. Authors' Addresses
10. 作者のアドレス
Questions about this memo can be directed to:
このメモに関する質問による以下のことよう指示できます。
James Kempf Sun Microsystems 901 San Antonio Rd. Palo Alto, CA, 94303 USA
ジェームスケンフサン・マイクロシステムズ901サンアントニオ通り パロアルト、カリフォルニア94303米国
Phone: +1 650 786 5890 Fax: +1 650 786 6445 EMail: james.kempf@sun.com
以下に電話をしてください。 +1 650 786、5890Fax: +1 6445年の650 786メール: james.kempf@sun.com
Erik Guttman Sun Microsystems Bahnstr. 2 74915 Waibstadt Germany
エリックGuttmanサン・マイクロシステムズBahnstr。 2 74915Waibstadtドイツ
Phone: +49 7263 911 701 EMail: erik.guttman@sun.com
以下に電話をしてください。 +49 7263 911 701はメールされます: erik.guttman@sun.com
Kempf & Guttman Informational [Page 90] RFC 2614 Service Location API June 1999
ケンフとGuttmanの情報[90ページ]のRFC2614はAPI1999年6月に位置を修理します。
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
「このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。」
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kempf & Guttman Informational [Page 91]
ケンフとGuttman情報です。[91ページ]
一覧
スポンサーリンク
