Dispatching a Remote Procedure Call to a Server-Manager Routine

The following tables show the steps taken by the RPC run-time library to dispatch a remote procedure call to a server-manager routine.

Assume a simple case where the server registers the default manager EPV, as described in the following tables:

Interface registry table

Interface UUID Manager type UUID Entry-point vector
uuid1 Nil Default EPV

Object registry table

Object UUID Object type
Nil Nil
(Any other object UUID) Nil

Mapping the binding handle to an entry-point vector

Interface UUID (from client binding handle) Object UUID (from client binding handle) Object type (from object registry table) Manager EPV
(from interface registry table)
uuid1 Nil Nil Default EPV
Same as above uuidA Nil Default EPV

The following steps describe the actions taken by the RPC server run-time library:

  1. The server calls RpcServerRegisterIfEx or RpcServerRegisterIf to associate an interface it offers with the nil manager type UUID and with the MIDL-generated default manager EPV. This call adds an entry in the interface registry table. The interface UUID is contained in the IfSpec argument.
  2. By default, the object registry table associates all object UUIDs with the nil type UUID. In this example, the server does not call RpcObjectSetType.
  3. The server run-time library receives a remote procedure code containing the interface UUID the call belongs to and the object UUID from the call's binding handle.

    See the following function reference entries for discussions of how an object UUID is set into a binding handle:

  4. Using the interface UUID from the remote procedure call, the server's run-time library locates that interface UUID in the interface registry table.

    If the server did not register the interface using RpcServerRegisterIf*, the remote procedure call returns to the caller with an RPC_S_UNKNOWN_IF status code.

  5. Using the object UUID from the binding handle, the server's run-time library locates that object UUID in the object registry table. In this example, all object UUIDs map to the nil object type.
  6. The server's run-time library locates the nil manager type in the interface registry table.
  7. Combining the interface UUID and nil type in the interface registry table resolves to the default EPV, which contains the server-manager routines to be executed for the interface UUID found in the remote procedure call.

Assume that the server offers multiple interfaces and multiple implementations of each interface, as described in the following tables:

Interface registry table

Interface UUID Manager type UUID Entry-point vector
uuid1 Nil epv1
uuid1 uuid3 epv4
uuid2 uuid4 epv2
uuid2 uuid7 epv3

Object registry table

Object UUID Object type
uuidA uuid3
uuidB uuid7
uuidC uuid7
uuidD uuid3
uuidE uuid3
uuidF uuid8
Nil Nil
(Any other UUID) Nil

Mapping the binding handle to an entry-point vector

Interface UUID (from client binding handle) Object UUID (from client binding handle) Object type
(from object registry table)
Manager EPV (from interface registry table)
uuid1 Nil Nil epv1
uuid1 uuidA uuid3 epv4
uuid1 uuidD uuid3 epv4
uuid1 uuidE uuid3 epv4
uuid2 uuidB uuid7 epv3
uuid2 uuidC uuid7 epv3

The following steps describe the actions taken by the server's run-time library as shown in the preceding tables when called by a client with interface UUID uuid2 and object UUID uuidC:

  1. The server calls RpcServerRegisterIfEx or RpcServerRegisterIf to associate the interfaces it offers with the different manager EPVs. The entries in the interface registry table reflect four calls of RpcServerRegisterIf* to offer two interfaces, with two implementations (EPVs) for each interface.
  2. The server calls RpcObjectSetType to establish the type of each object it offers. In addition to the default association of the nil object to a nil type, all other object UUIDs not explicitly found in the object registry table also map to the nil type UUID.

    In this example, the server calls the RpcObjectSetType routine six times.

  3. The server run-time library receives a remote procedure call containing the interface UUID the call belongs to and an object UUID from the call's binding handle.
  4. Using the interface UUID from the remote procedure call, the server's run-time library locates the interface UUID in the interface registry table.
  5. Using the object UUID from the binding handle, uuidC, the server's run-time library locates the object UUID in the object registry table and finds that it maps to type uuid7.
  6. The server's run-time library locates the manager type by combining the interface UUID, uuid2, and type uuid7 in the interface registry table. This resolves to epv3, which contains the server-manager routine to be executed for the remote procedure call.

The routines in epv2 will never be executed because the server has not called the RpcObjectSetType routine to add any objects with a type UUID of uuid4 to the object registry table.

A remote procedure call with interface UUID uuid2 and object UUID uuidF returns to the caller with an RPC_S_UNKNOWN_MGR_TYPE status code because the server did not call the RpcServerRegisterIf* routine to register the interface with a manager type of uuid8.

Return Values

Value Meaning
RPC_S_OK Success
RPC_S_TYPE_ALREADY_REGISTERED Type UUID already registered

See Also

RpcBindingFromStringBinding, RpcBindingSetObject, RpcNsBindingExport, RpcNsBindingImportBegin, RpcNsBindingLookupBegin, RpcObjectSetType, RpcServerRegisterIfEx, RpcServerRegisterIf, RpcServerUnregisterIf