3.2.4.2 ORPC Invocations

  • Article

To make an ORPC call, a DCOM application supplies to the DCOM client an IPID to reference a specific interface on an object, a method number (opnum), and a list of arguments to the method. The DCOM application can also supply nondefault values for security provider, authentication level, impersonation level, SPN, and credentials settings. It is the responsibility of the specification of the higher-layer protocol to state such requirements, if any.

When an ORPC call is made, the DCOM client MUST perform the following sequence:

  1. It MUST look up the object exporter information in the client tables.

  2. It MUST perform capability negotiation.

  3. It MUST specify security settings for the ORPC.

  4. It MUST make the ORPC request.

The client MUST use the IPID specified by the client application to look up the IPID entry in the IPID table. The client MUST then look up the OXID entry to obtain the DUALSTRINGARRAY that contains the RPC binding information, the COMVERSION, and the authentication-level hint of the object exporter.

The client MUST perform capability negotiation using the COMVERSION of the server, as specified in section 1.7.

If the client specifies security on the call, it MUST specify the default values for the following security settings:

  • The client MUST specify the security provider requested by the application. If the security provider requested by the application is RPC_C_AUTHN_DEFAULT or if the application does not quest a security provider, the client MUST pick the first security provider contained in the wAuthnSvc field of the SECURITYBINDING array which is supported by the client. If the SECURITYBINDING structure is empty, the client MUST NOT specify any security on the call.

  • The client MUST specify the authentication level requested by the application, if one was supplied; otherwise, it MUST specify a value that is the higher value of the client's authentication level value, obtained in an implementation-specific manner, and the authentication-level hint of the object exporter.<86>

  • The client MUST specify the impersonation level requested by the application, if one was supplied; otherwise, it MUST specify a default impersonation level that is obtained in an implementation-specific manner.<87>

  • The client MUST specify the SPN requested by the application, if one was supplied; otherwise, it MUST specify the aPrincName field in the SECURITYBINDING packet contained in the DUALSTRINGARRAY of the object exporter bindings, if the aPrincName field is nonempty; otherwise, if the aPrincName field is empty, the client MUST NOT specify an SPN.

The client MUST initiate the ORPC as follows:

  • The client MUST specify the IID from the IPID entry in the RPC interface UUID field.

  • The client MUST specify the RPC interface version as 0.0.

  • The client MUST specify the application-supplied RPC opnum of the method on the interface.

  • The client MUST specify the application-supplied IPID in the object UUID field.

  • The client MUST specify the ORPCTHIS as the first implicit parameter in the ORPC request. In particular:

    • The client MUST set the COMVERSION to the negotiated version from activation or OXID resolution.

    • The client MUST set the cid to the CID of the current ORPC. If the client is currently executing an incoming ORPC, the client MUST set the cid of the outgoing ORPC to be the same as the cid in the ORPCTHIS of the incoming ORPC. If the client is not executing an incoming ORPC, the client MUST specify a new CID. For details, see section 1.3.5.

    • The client MAY specify the extensions field if it needs to send out-of-band data to the object.<88>

  • The client MUST marshal ORPC parameters of object reference types; see section 3.2.4.3.

    On Windows 2000 operating system, Windows XP operating system, Windows XP operating system Service Pack 1 (SP1), Windows XP operating system Service Pack 2 (SP2), Windows Server 2003 operating system, and Windows Server 2003 operating system with Service Pack 1 (SP1), DCOM clients optionally append extra data to the end of an ORPC request. This is due to a coding error and the extra data, if present, has no meaning and is ignored by Windows recipients. Whether the data is sent or not does not affect interoperability, and the protocol functions correctly.<89>

The client MUST process the ORPC response as follows:

  • The ORPCTHAT structure will be returned as the first implicit parameter of the ORPC response. In particular:

    • The client MAY process the extensions field if it needs to receive out-of-band data from the object.<90>

  • If an object reference is returned as a parameter from the ORPC, the client MUST unmarshal it; see section 3.2.4.1.2.