| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

Packing into and unpacking from the buffers used for transmission

The packing and unpacking of data into buffers is performed by MS RPC and is transparent to the programmer. One of the options open to a middleware developer is to add features which handle very long messages more efficiently (by splitting them automatically and reconstituting them automatically) or grouping very short messages into buffers. Another feature often provided, where the network software may not offer the feature, is to offer optional automatic compression and decompression of the buffer to speed transmission.

DCOM does not support compression or decompression of messages, nor does it split or group messages. It relies on the underlying network software to do this.

But DCOM does use a novel method of minimizing network traffic called box-carring. It is the nature of object-oriented and component-based communication that a large number of method calls are needed to set up the final request/reply between client and component. In comparison with an RPC call where the request/reply is one action, in object-oriented processing the actual sequence of calls may be—connect to object; query its functionality; create the object; and send it the method call. Each individual method call involves a round trip and as a consequence affects performance. Box-carring groups these multiple-method calls into a single invocation. The proxy object on the client side intercepts the multiple-method calls from the client and bundles them into a single RPC.

Transmitting the message—establishing sessions

Although network software may handle sessions between machines, sessions between processes have to be handled by the middleware. A number of options exist as to how those sessions are handled, each having their own advantages and disadvantages, and each having specific purposes.

A connection can be created by the middleware between two communicating processes, for example, where name-to-address resolution occurs only once at session inception. Sessions are then typically multiplexed over the underlying network transport mechanism to avoid exhausting network resources.

Alternatively, a connection may be created by the middleware in which name-to-address resolution occurs with every message sent. These sorts of sessions might be used when only a few messages are being sent during a short time period to the same process.

Within DCOM, a session is established between DCOM nodes, not between applications. The session and connection is then used for multiple request/reply communications between clients and servers on the two machines. DCOM is able to pair up request and reply, and is also able to pair up requests from threads with replies from threads.

Handling the network calls

Where middleware is not used, the developer has to create code to communicate with the network software; in other words, he or she has to code to the network transport protocols. This means he or she has to add numerous low level calls using the network-specific API into his client and server code. If the application is moved to a new network, then this aspect of the application has to be recoded. DCOM MS RPC runtime libraries include this code for the developer; no coding is needed.

Coordinating the transmission

DCOM MS RPC establishes the connection, coordinates the transmission, and synchronizes with the network. The programmer does not have to do anything.

Handling faults

One of the most tedious and time-consuming aspects for a programmer developing distributed applications is handling errors. Without middleware, the developer has to write all the code to trap the errors, interpret what went wrong, and then try to build in the code to correct or act on the fault. In some cases, the application may be in no position to actually find out what went wrong as it may be the one isolated by the fault. All these problems conspire to make error and fault handling in distributed applications a very tricky job.

Middleware handles this, and various levels of fault handling can be provided, from useful error trapping mechanisms to fully automated recovery mechanisms with automatic restart for the servers and clients, automated transfer from failed servers on failed machines, retries, plus many more automated mechanisms. DCOM offers a set of services halfway between the very basic error trapping to some support for automated procedures.

Client request failure-In DCOM, when a client makes a request and the network has failed, the server’s host has failed, or the server itself has failed, MS RPC will try to deliver the request a set number of times and then return an error message. The number of times MS RPC retries is configurable for the entire network as is the retry delay per server and queue length. But where the server has failed, DCOM will not search for alternative servers.

Server reply failure-Where the server fails before sending the reply, or the network goes down before the reply has been sent, the client will time out. The time out period is configurable.

Where the server tries to send a reply, but failure of the network (or client) causes the send to fail, MS RPC will also try to deliver the reply a set number of times and then return an error message to the server (which has to then recover itself, if need be). The number of times MS RPC retries is also configurable.

Client alive-DCOM uses a pinging protocol to detect if clients are still “alive” in a connection. Client machines send ping messages at two-minute intervals. Only if the entire client machine is idle with respect to a given server does it send ping messages. DCOM uses a per-machine keep-alive message. Thus, if the client uses many components on the server machine, a single ping message keeps all the client connections to components alive. DCOM considers a connection broken if more than three ping periods pass without the server’s receiving a ping message.

DCOM also uses an approach called delta pinging to minimize the size of the ping messages. It creates “meta-identifiers” that represent groups of clients—if the clients in the group change, the delta is changed. DCOM piggybacks ping messages onto regular messages.

Error codes-Most failure conditions within DCOM are signaled by error codes. DCOM has no automatic error correction features—servers are not restarted, nor are connections transferred, but the error code is used to indicate what error has occurred so that the programmer can take appropriate action.

Previous | Table of Contents | Next