OSF DCE Application Development Guide--Core Components

OSF DCE Application Development Guide—Core Components
• The resources of the server and the network
• The requirements of each call
• The number of calls that can be concurrently offered at some level of service
• The performance requirements
An accurate analysis of the requirements of a given server involves detailed work
load and resource characterization and modeling techniques. Although
measurement of live configurations under load will offer the best information,
general guidelines apply. You should consider the connection, buffering,
bandwidth, and CPU resources as the most likely RPC bottlenecks to scaling. Use
these application requirements to scale resources.
Many system implementations limit the number of network connections per
process. This limit provides an upper bound on the number of clients that can be
served concurrently using the connection-oriented protocol. Some UNIX based
systems set this limit at 64. However, except for applications that use context
handles, the connection-oriented RPC runtime allows pooling of connections.
Pooling permits simultaneously supporting more clients than the maximum
number of connections, provided they do not all make calls at the same instant
and occasionally can wait briefly.
12.8 RPC Objects
DCE RPC enables clients to find servers that offer specific RPC objects. An RPC
object is an entity that an RPC server defines and identifies to its clients.
Frequently, an RPC object is a distinct computing resource such as a particular
database, directory, device, process, or processor. Identifying a resource as an
RPC object enables an application to ensure that clients can use an RPC interface
to operate on that resource. An RPC object can also be an abstraction that is
meaningful to an application such as a service or the location of a server.
RPC objects are defined by application code. The RPC runtime provides
substantial flexibility to applications about whether, when, and how they use RPC
objects. RPC applications generally use RPC objects to enable clients to find and
access a specific server. When servers are completely interchangeable, using
RPC objects may be unnecessary. However, when clients need to distinguish
between two servers that offer the same RPC interface, RPC objects are essential.
If the servers offer distinct computing resources, each server can identify itself by
treating its resources as RPC objects. Alternatively, each server can establish
itself as an RPC object that is distinct from other instances of the same server.
RPC objects also enable a single server to distinguish among alternative
implementations of an RPC interface, as long as each implementation operates on
a distinct type of object. To offer multiple implementations of an RPC interface, a
server must identify RPC objects, classify them into types, and associate each
type with a specific implementation.
The set of remote procedures that implements an RPC interface for a given type of
object is known as a manager. The tasks performed by a manager depend on the
12 − 14 Tandem Computers Incorporated 124245