Previous
section.
CDE 1.1:
Remote Procedure Call
Copyright © 1997 The Open Group
Introduction to the RPC Specification
This document specifies both portability and interoperability
for the Remote Procedure Call (RPC) mechanism. The specification contains
material directed at two audiences:
- It provides a portability guide for application programmers.
- It provides both portability and interoperability specifications
for those who are implementing or porting RPC or who are testing an RPC
implementation.
This document may be thought of as an implementation specification,
covering both portability and interoperability, that contains within it
an application portability guide. The application portability guide consists
of Part 2, RPC Application Programmer's Interface and Part 3, Interface
Definition Language and Stubs.
Although the portability specification is part of the
broader implementation specification, it has been designed to stand alone
so that it may be used by application programmers without reference to
the other parts of the implementation specification.
- Note:
- In order to make the portability specification independent,
some material is repeated, especially between Introduction
to the RPC API and Remote
Procedure Call Model .
Portability
The portability specification describes the concrete syntax
and semantics of the Application Programmer's Interface (API) to RPC. It
consists of:
The portability specification is narrowly focussed on
providing a guide to portable usage of the RPC API. It describes behaviour
that is common to all implementations. Whenever implementation-specific
behaviour is referenced, it is clearly marked as such. Similarly, the specification
generally avoids examples or tutorial descriptions. Whenever usage guidelines
are provided, they are clearly marked as such.
All behaviour that is not specifically marked as implementation-specific
or a usage note, is considered to be required. All implementations must
conform to the specified behaviour. Programmers can rely on the specified
behaviour to be portable among conforming implementations.
Services and Protocols
The implementation specification includes a set of service
and protocol specifications. The
protocol specifications describe how implementations of the RPC client
and server run-time systems communicate. The service specifications describe
a set of abstract services that the RPC run-time system must implement.
The service and protocol specifications include:
The aim of the service and protocol specifications is
to provide a complete mapping from RPC call semantics to the byte streams
that RPC run-time clients and servers interchange using underlying services.
The RPC service primitives provide an abstract implementation of the specified
RPC call semantics and serve to map the specified semantics to the specified
protocol machines. The PDU formats give the byte streams that the protocol
machines exchange using the underlying transport services. The NDR specification,
along with the mapping of IDL to NDR data types, defines how the call data
exchanged in the RPC PDUs is encoded.
Except for the byte stream specification and the stub
specification, the service and protocol specifications are abstract. They
describe the behaviour that conforming implementations must follow, but
they do not prescribe any specific means for implementing this behaviour.
Implementations that conform to this specification interoperate
according to the following rule:
client and server applications, conforming to the same IDL source (but
not necessarily the same ACS), correctly implement the specified RPC interface
semantics for each remote procedure call operation specified in the IDL
source.
Except when specified otherwise, IDL compiler behaviour
and the stub, including the stub to run-time interface, are implementation-dependent.
Therefore, the above rule applies when stubs are generated using the local
implementation's IDL compiler. There is no requirement that stubs for a
given language are portable among implementations.
Conformance Requirements
To conform to this document, implementations must meet
the following requirements:
- Implementations must support the endpoint selection rules
in Endpoint
Selection .
- Implementations must support the manager selection rules
in Interface
and Manager Selection .
- Implementations must support the search algorithm in
Section 2.4.5.
- Implementations must support the API naming, syntax and
semantics, as defined in RPC
API Manual Pages . Implementations may extend the set of status
codes documented in RPC
API Manual Pages .
- Implementations must support the naming, syntax and semantics
for IDL, as given in Interface
Definition Language .
- Implementations must support the naming, syntax, and
semantics for stubs, as given in Stubs
.
- Implementations must support the semantics defined in
Remote
Procedure Call Model .
- Implementations must support the NSI syntax and naming,
as defined in Binding,
Addressing and Name Services .
- Implementations must support the service semantics defined
in RPC
Service Definition .
- Implementations must follow the conformance rules specified
in RPC
Protocol Definitions .
- Implementations must support the syntax of the PDU encodings
in RPC
PDU Encodings .
- Implementations must support the Authentication Verifier
encodings, as defined in Security
.
- Implementations must support the rules and encodings
for NDR, as given in Transfer
Syntax NDR .
- Implementations must support the syntax, semantics and
encoding for UUIDs, as defined in Universal
Unique Identifier .
- Implementations must support the naming and semantics
for protocol sequence strings, as defined in Protocol
Sequence Strings .
- Implementations must support the naming and semantics
for the name_syntax arguments, as defined in Name
Syntax Constants .
- Implementations must support the naming and semantics
for security parameters, as defined in Authentication,
Authorisation and Protection-level Arguments .
- Implementations must support the naming and encodings
for comm_status and fault_status, as defined Reject
Status Codes and Parameters .
- Implementations must support the mapping from IDL types
to NDR types, and from NDR types to defined ISO C types, as defined in
IDL
to C-language Mappings .
- Implementations must support the portable character set,
as defined in Portable
Character Set .
- Implementations must use the endpoint mapper ports, as
defined in Endpoint
Mapper Well-known Ports for the corresponding protocols.
- Implementations must adhere to the rules for protocol
identifier assignment, as defined in Protocol
Identifiers .
- Implementations must adhere to the mappings for Directory
Service attributes, as defined in the DCE: Directory Services specification.
- Implementations must provide defaults for the protocol
machine values specified in Architected
and Default Values for Protocol Machines .
- Implementations must obey the special protocol tower
encoding rules specified in Protocol
Tower Encoding .
- Implementations must support the syntax and semantics
of the dce_error_inq_text routine specified in The
dce_error_inq_text Manual Page .
- Implementations must adhere to the mappings for transfer
syntax UUIDs, as defined in IDL
Data Type Declarations .
- Implementations must support the endpoint mapper semantics,
as defined in Endpoint
Mapper Interface Definition .
- Implementations must support the conversation manager
semantics, as defined in Conversation
Manager Interface Definition .
- Implementations must support the remote management semantics
as defined in Remote
Management Interface .
Footnotes
- 1.
- This document specifies ISO C-language bindings for data
types and interfaces.
Please note that the html version of this specification
may contain formatting aberrations. The definitive version is available
as an electronic publication on CD-ROM from The Open Group.