What is DCOM? (Part 2)

After discussing COM and DCOM in the previous posts, I would like to dig into the way DCOM is transmitted over the wire. As I already mentioned, DCOM needs to execute procedures and receive their output via the network. To achieve that it has to use a standard protocol that is implemented on multiple platforms, be security aware and provide a suitable interface that will not harm the advantage of DCOM.

DCE/RPC protocol was chosen for those reasons and it is used as the wire-protocol for DCOM. DCE/RPC stands for Distributed Computing Environment / Remote Procedure Calls and it defines a standard for converting objects and structures into a format that can be split into packets and sent over the network in a platform independent way. Let's dig a little more into details.

The Challenge

It can be said that the goal is set up a "conversation" between a user and the service provider in a way that that the interface that is defined by the service provider could be called by the user from far away, the service provider will process the request and return an answer. When this happens within a local machine, both client and server will usually share the same memory address space so the interface calls, the arguments passed and the return values can be passed and accessed on the process's stack.

When the whole things goes remote and the client and server are not on the same machine/system, the interface calls including the arguments and return values must have a Network Data Representation (NDR) to be sent over the network. The cool thing that RPC mechanism managed to achieve is that it makes the process look to the programmer almost as the interface he uses is just a regular local procedure call. That is why using DCE/RPC was chosen from DCOM.

The IDL

The Interface Definition Language and its compiler. DCE/RPC uses a language to define the procedures, the parameters to these procedures and the data types and objects that the interface will use. An IDL interface will have the following structure:

<interface> ::= <interface_header> { <interface_body> }

For a detailed explanation regarding the definition for the interface header and body, please refer to the DCE/RPC opengroup.org document here.

RPC runtime library

The RPC runtime library is used by both client and server side to implement the communication between them. The runtime library is responsible for finding the server over the network, manage the connection, sending messages, receiving answers, manage and handle errors and more. To keep it simple let's just look at the diagram below.

RPC flow (Source: MSDN)

The client application calls a client stub that is responsible on calling the runtime library interface with the parameter the client application has passed to it. The client RPC runtime library converts the request into a standard NDR and sends the message to the server. The server receives the requests, the runtime library translates it back from NDR into objects and structures that the server understands, queries the server application for and answers and transmits it back to the client.

Every DCE enables machine runs a daemon application called DCE Host Daemon (DCED) and a DCE control program (DCECP) to administrate it. The DCED is listening to the DCE requests and manage them.

DCE/RPC development process

When it comes to the development of a DCE/RPC client/server application the process is pretty straightforward. It comprises of defining the interfaces using DCE IDL, running the IDL compiler to create the client and the server stubs and implement them on the client and server machines.

The IDL interface, like every other interface in computer science, is a set of procedures that the server can execute. On the client side, the client application is linked with the client-stub created by the IDL compiler. The client-stub hides all the network communication with the server. On the server side, the server-stub is linked with the server application, converts the client's calls from NDR and calls the server application that the client requested.

Conclusion

After this discussion I feel that now you should have a pretty good idea what is DCOM, why do we need it and how it works. I didn't go into many details as I think that this blog should be a more-or-less easy read for those of you who want to have a general idea of the subjects that I'm dealing with. Please comment and write me your remarks or requests.

It's a rainy day today so let me finish with a song on that subject. Enjoy!