1.7 Versioning and Capability Negotiation

  • Article

This document covers versioning issues in the following areas:

  • Supported transports: The DCOM Remote Protocol needs to be implemented on top of at least one of the RPC transports described in section 2.1.

  • Protocol versions: The DCOM Remote Protocol needs to use an RPC version of 0.0 for all RPC and ORPC interfaces. At the DCOM Remote Protocol level, a major and minor version numbering scheme is maintained (see section 2.2.11). The major version needs to be 5. The minor version needs to be one of the following: 1, 2, 4, 6, or 7. A minor version of 3 or 5 is unused and is required not to appear in any capability negotiation. The minor versions signify the addition of various capabilities to the protocol. For example, minor version 2 signifies the addition of the ResolveOXID2 method to the IObjectExporter interface (see section 3.1.2.5.1.5).

  • Security and authentication methods: It is recommended that the DCOM Remote Protocol use the underlying security and authentication services provided by RPC.

  • Capability negotiation: The protocol needs to perform explicit capability negotiation, as specified in this section.

The DCOM Remote Protocol implements version negotiation through the following two mechanisms:

  1. By the availability of an RPC method or interface on the server; the unavailability of that method or interface implies a certain version to the client, which then undertakes a fallback action as appropriate.

  2. By use of the COMVERSION structure, which is passed between client and server, clients and servers associate specific version numbers with specific capabilities and behaviors.

The first mechanism is used at the initiation of the protocol, when the client has no knowledge of the capabilities of the server. The second mechanism is used within the operation of the protocol when the COMVERSION can be sent or received.

A client detects the version of a server using one of the following mechanisms:

  1. By calling either the IObjectExporter::ServerAlive2 (Opnum 5) method or the IObjectExporter::ResolveOxid2 method on the object resolver. If the server does not support either of these methods, the client assumes that the server supports COM version 5.1. Otherwise, the server returns its version explicitly as a return argument during the method call.

  2. During an activation, a server returns its version to the client either as a return argument from the IActivation:: RemoteActivation (Opnum 0) method, or as a field of the custom REMOTE_REPLY_SCM_INFO structure contained in the ScmReplyInfoData property returned by either IRemoteSCMActivator:: RemoteGetClassObject (Opnum 3) or IRemoteSCMActivator::RemoteCreateInstance (Opnum 4).

Clients are required not to call servers with nonmatching major versions. Clients need to compute the lower of the client and the server minor versions and need to pass this computed version as the client minor version when making activation or ORPC calls. For example, if the client minor version is 7 and the server minor version is 4, the client needs to specify 4 as its minor version when making activation  or ORPC calls.

Servers need to reject activation requests or ORPC calls from clients with nonmatching major versions or higher minor versions.

For more information on the capabilities introduced in each DCOM version, see section 2.2.11.