Previous Table of Contents Next


16.3.1 Pipe-based Interface


   The dce_ciop_pipe interface is defined by the DCE IDL specification shown below:

   [/* DCE IDL */uuid(d7d99f66-97ee-11cf-b1a0-0800090b5d3e),/* 2nd revision */version(1.0)]interface dce_ciop_pipe{typedef pipe byte message_type;

void invoke ( [in] handle_t binding_handle,
[in] message_type *request_message,
[out] message_type *response_message);
void locate ( [in] handle_t binding_handle,
[in] message_type *request_message,
[out] message_type *response_message);
}

   ORBs can implement the dce_ciop_pipe interface by using DCE stubs generated from this IDL specification, or by using lower-level APIs provided by a particular DCE-RPC implementation.

   The dce_ciop_pipeinterface is identified by the UUID and version number shown. To provide maximal performance, all server ORBs and location agents implementing DCE-CIOP should listen for and handle requests made to this interface. To maximize the chances of interoperating with any DCE-CIOP client, servers should listen for requests arriving via all available DCE protocol sequences.

   Client ORBs can invoke OMG IDL operations over DCE-CIOP by performing DCE RPCs on the dce_ciop_pipe interface. The dce_ciop_pipeinterface is made up of two DCE-RPC operations, invoke and locate. The first parameter of each of these RPCs is a DCE binding handle, which identifies the server process on which to

    perform the RPC. See “DCE-CIOP String Binding Component? on page 16-17, “DCE CIOP Binding Name Component? on page 16-18, and “DCE-CIOP Object Location? on page 16-21 for discussion of how these binding handles are obtained. The remaining parameters of the dce_ciop_pipe RPCs are pipes of uninterpreted bytes. These pipes are used to convey messages encoded using CDR. The request_message input parameters send a request message from the client to the server, while the response_message output parameters return a response message from the server to the client.

    Figure 16-1 illustrates the layering of DCE-CIOP messages on the DCE-RPC protocol as NDR pipes:


   Figure 16-1 Pipe-based Interface Protocol Layering

   The DCE-RPC protocol data unit (PDU) bodies, after any appropriate authentication is performed, are concatenated by the DCE-RPC run-time to form an NDR stream. This stream is then interpreted as the NDR representation of a DCE IDL pipe.

   A pipe is made up of chunks, where each chunk consists of a chunk length and chunk data. The chunk length is an unsigned long indicating the number of pipe elements that make up the chunk data. The pipe elements are DCE IDL bytes, which are uninterpreted by NDR. A pipe is terminated by a chunk length of zero. The pipe chunks are concatenated to form a DCE-CIOP message.

   16.3.1.1 Invoke

   The invoke RPC is used by a DCE-CIOP client process to attempt to invoke a CORBA operation in the server process identified by the binding_handle parameter. The request_message pipe transmits a DCE-CIOP invoke request message, encoded using CDR, from the client to the server. See Section 16.4.1, “DCE_CIOP Invoke Request Message,? on page 16-11 for a description of its format. The response_message pipe transmits a DCE-CIOP invoke response message, also encoded using CDR, from the server to the client. See Section 16.4.2, “DCE-CIOP Invoke Response Message,? on page 16-12 for a description of the response format.

   16.3.1.2 Locate

   The locate RPC is used by a DCE-CIOP client process to query the server process identified by the binding_handle parameter for the location of the server process where requests should be sent. The request_message and response_message parameters are used similarly to the parameters of the invoke RPC. See Section 16.4.3, “DCE-CIOP Locate Request Message,? on page 16-14 and Section 16.4.4, “DCE-CIOP Locate Response Message,? on page 16-15 for descriptions of their formats. Use of the locate RPC is described in detail in Section 16.6, “DCE-CIOP Object Location,? on page 16-21.