次の方法で共有


2.1 Transport

DCOM is based on RPC, and implementations SHOULD support the use of any RPC protocol sequence available in the underlying RPC implementation. The client SHOULD discover an initial working RPC protocol by calling the object resolver on multiple protocols. IObjectExporter::ServerAlive2 (Opnum 5) SHOULD be used for this purpose, and then any RPC protocol to which the object resolver responds SHOULD be used.

The object resolver and any given object exporter MUST indicate their supported RPC protocols through an array of STRINGBINDING structures contained in the DUALSTRINGARRAY structure. The DUALSTRINGARRAY structure is returned from the server to the client through various methods in the protocol.

The object resolver service MUST be reachable at either well-known endpoints or through the RPC endpoint mapper, as specified in section 1.9.

Object resolvers and object exporters MUST always support the OXID resolution mechanism specified in section 3.2.4.1.2.2, even if the object exporters use well-known endpoints. Object resolvers and object exporters MUST NOT rely on clients to know the endpoint other than obtaining it through the protocol.

The interface version of all object (ORPC) interfaces MUST be 0.0. DCOM does not support versioning of ORPC interfaces through the RPC interface versioning mechanism. Instead, all DCOM interfaces MUST be immutable once defined.

The interface version of all native (nonobject) RPC interfaces used in the protocol MUST be 0.0.

ORPC calls are equivalent to, and possess a one-to-one correspondence with, RPC calls. ORPC calls are distinguished from RPC calls by the contents of the Object UUID field of the RPC header, as specified in [C706] section 12.5.2.6. In DCOM, the Object UUID field carries an IPID specifying the interface targeted by a given ORPC call on an object.

ORPC calls are further distinguished from RPC calls in that the former will always have implicit additional parameters present within the request and response buffers for each call. These additional parameters are referred to as ORPCTHIS and ORPCTHAT respectively; see section 2.2.12. The ORPCTHIS and ORPCTHAT values are conceptually and syntactically placed ahead of all other values in the RPC PDU body (as specified in [C706] section 12.1).

RPC PDU types other than Request and Response PDUs (as specified in [C706] section 12) are used by DCOM without extension or modification and are therefore not discussed further in this specification.

DCOM uses security, as described in [MS-RPCE] section 1.7.

The server SHOULD register one or more security providers specified in [MS-RPCE] section 2.2.1.1.7; the choice of security provider is implementation-dependent.<3>