No. DCE and ONC both use the concept of the Remote Procedure Call, but the wire protocols that they use are not compatible. You will need to use either DCE for both client and server, or ONC for both client and server; both products are available for most platforms. It is possible for a single program to use both DCE and ONC. Thus a server could be built to server both DCE and ONC clients, or a gateway could be built to accept one kind of RPC and forward to a server of another kind.

Performance testing at several user organizations has shown that DCE RPC performance is similiar to other RPC implementations when doing the same things. The throughput and response times for a series of remote procedure calls is similiar. The use of features in DCE not present in other implementations may consume additional time and resources. For example, name-based binding may required additional time, depending on the number of directories traversed.

DCE is the Distributed Computing Environment, from the Open Software Foundation. (It is called "the DCE" by sticklers for grammatical consistency.) (The Open Software Foundation is now called the Open Group.) DCE consists of multiple components which have been integrated to work closely together. They are the Remote Procedure Call (RPC), the Cell and Global Directory Services (CDS and GDS), the Security Service, DCE Threads, Distributed Time Service (DTS),and Distributed File Service (DFS).

First, DCE provides services that can be found in other computer networking environments, but packages them so as to make them much easier to use. For example, the DCE Remote Procedure Call (RPC) facility provides a way of communicating between software modules running on different systems that is much simpler to code than older methods, such as using socket calls. Second, DCE provides new capabilities that go beyond what was available previously.

DCE RFCs are requests for comments for ongoing DCE development. They are similar in concept to the Internet RFCs. Nothing in there is promised from by Open Group. They are a formal way to pass ideas among DCE development partners. You can access them by WWW (or gopher) by: http://www.pilgrim.umass.edu/pub/osf_dce/RFC/rfc-index.html

DCE is fully supported on most major platforms, including all major Unix platforms and many non-Unix platforms. Most vendors support at least the "secure core" which means all of the DCE services except the Distributed File Service and X.500 interface to the Global Directory Service. Some products are client-only, which means that the actual servers for the DCE services are not provided: Directory Service, Security Service, Time Service.

The Open Group maintains an Open Software Registry, which contains information about DCE products, among others. Access is free, but you must register. The registry is available on-line at http://www.opensoftware.com/ Once you get in, you can search for DCE, and your favorite platform or other criteria. Hint: A search using "DCE" as the product name will find only those products whose listed name starts with DCE.

The OSF calls the specification an Application Environment Specification, or AES. The AES documents both the software programming interfaces and also the communications protocols employed by DCE. Thus it would be possible, in theory, for someone to build a compatible implementation without using the code from the Open Group. The AES for RPC, Time, and Directory services have been accepted as standards by X/Open. The AES for Security is currently undergoing review.

There is not a lot of direct relationship. DCE and CORBA are tools to help you build distributed systems. Each has its advantages and disadvantages. Use of one will not hinder future use of the other. DCE provides a lower-level programming model than does CORBA. DCE is not fully "Object-Oriented". DCE has far better inter-operability than (current) CORBA products. DCE is an optional interoperability mechanism in the CORBA 2.0 specification.

IDL stands for "Interface Definition Language," and the idea of using a special language to define the interface between entities is not unique to DCE. In particular, OMG's IDL for CORBA is used for the same purpose as DCE's, but the two languages are not identical; see Q 1.08 for more information. There are other Interface Definition Languages as well. IDL also stands for "Interactive Data Language", which is a completely unrelated product.

DCE does not track this information, does not supply any tools to help collect this information, does not provide any hooks in the security server to allow you to collect this information. If you must track who is logged in, you'll need to build your own service to maintain the information. An obvious approach is to capture login and logout events and report them to some central location; this requires that you be able to instrument all login/logout commands on hosts within your cell.

Windows NT comes with an RPC which interoperates with DCE RPC. Windows 95 apparently provides this interface as well. However, it is not quite the same as DCE. The wire-level protocol is the same as DCE RPC, so applications running on NT can communicate with DCE applications on other platforms. However, the application source code is not instantly portable. Microsoft changed the format of procedure names and moved the status result from a parameter to the function value.

Documentation on DCE should be supplied with vendor products. The Open Group sells complete sets of documentation. The DCE set consists of 14 volumes. The three volumes of specifications (AES) can be purchased separately. Information on DCE documentation available from The Open Group can be found at: http://www.opengroup.org/publications/catalog/dz.htm. Order documentation by contacting The Open Group via E-mail at: sales-team@opengroup.

In October 1994, Digital Equipment Corporation and Hewlett-Packard released into the public domain the RPC implementation used by DCE. This code includes the IDL compiler and the RPC runtime. It does not include any of the other services: DTS, CDS, Security, DFS. In fact, it is not a sufficient base for a client machine, as it does not include the CDS, DTS, and security clerk processes that are normally required. Be warned that building anything from this release is not a simple matter.

Yes. Besides the Open Group itself, there are local DCE users groups in several areas. Changes in the set of users groups have proven difficult to track in this FAQ, so contact the Open Group to find the user group nearest you.

DCE-RPC is synchronous. The way to make an asynchronous call is to create a thread for each RPC call. You should be able to have dozens, if not hundreds, of threads with no problem. Q 2r-07: How can a server keep track of multiple clients? For example, to know what information has already been provided to a client, and thus vary subsequent responses. The DCE RPC mechanism includes a "context handle" which can be created by a server and returned to a client.

First have you considered the advantages of using all protocol sequences? RPCs work the same either way. DCE's implementation provides the same security and reliability over all communication protocols. In most cases the performance is about the same as well. For some applications and some platforms, there may be reasons to prefer one protocol over another. For instance, if your platform has a poor implementation of UDP, that could be a reason to prefer TCP, or vice-versa.

interface is a set of remote procedure call operations and associated data. Every interface contains one or more operations. An operation is an actual remote procedure. Each operation may have input and output parameters associated with it, just like any procedure call.

Yes. A client can use as many different services as it needs. To code such a client, simply include the header files for all the RPC interfaces used, and code each call the same way you would if using that interface in isolation.