MessageStreams

MessageStreams is the simplest example of CommonPoint(TM) communications. This sample shows how to create a service definition, implement a message-streams-based server, access a message-streams-based server, and make queries to the server.

Running the sample

Execute AdditionApp. The server is launched automatically. The client makes requests of the server, and prints the results to the shell.

Files and classes

MessageStreamsServerMain.C

This file shows how to create a message-streams-based server.

The TQualityOfService object determines whether this service is accessible to local or network clients. This service is accessible only to clients on the same machine as the server, so kSameHost is passed-in.

Users of TServiceDefinition must take care to properly increment the reference count after creating it. TServiceDefinition deletes itself when the reference count goes to zero, so do not delete it yourself.

The receiverStream.Receive call blocks the thread and waits for a client request.

MessageStreamsCallerMain.C

This file shows how to create a reference to a server and make a query.

Developers do not usually create service references. Typically developers get a service passed to them from a network browser or something similar.

The call request.Send blocks the current thread waiting for a reply. If the server crashes or some other catastrophe happens, this thread stays blocked. It is usually good practice to create a thread and have that thread do the calling for you. When that thread receives a reply from the server, it can notify you with the result.

Notes:

Message streams are used instead of RPC for these reasons: message streams are easier to learn and implement; message streams can be better for transferring large blocks of data because they have less overhead; and message streams will allow for communicating with legacy servers in future versions of the CommonPoint system.

RPC is used instead of message streams for these reasons: RPC takes care of marshalling and unmarshalling parameters; RPC propagates exceptions from the dispatcher to the caller; and RPC is more invisible--if it is done properly it can look like regular function calls rather than obvious remote communication (like message streams).


Click the icon to mail questions or corrections about this material to Taligent personnel.
Copyright©1995 Taligent,Inc. All rights reserved.