This document answers some Frequently Asked Questions concerning the OSF Distributed Computing Environment.
The questions (and answers) in this FAQ have been divided into 3 tiers, for convenience, scalability, and because its just the cool thing to do.
The document is maintained by Jon
Mauney, jon@mauney.com
Suggestions,
corrections, and updates are actively sought.
Throughout: updates to contact information for Jon Mauney and The Open
Group
Q 3.02: updated available documentation, added DCE Today book
Q 1.07 : updated link to Transarc solutions page.
Q 2p-02:
remove link to Lexis-Nexis whitepaper on cell size.
Q 3.05: update
information about Linux DCE
Q 3.01: add pointer to Transarc's online
documentation
Q 3.02: add mention of Campbell's AFS book
Q 1.03 : updated info on NT, OS/390
Q 2cc-05,3.01,3.07:
updated the URLs for Transarc's web site
Q 2r-07, 2p-06, 2s-01, 2r-14,
2cc-02: Added URLs for examples at Transarc's web site.
Added
Q2p-07: Should I choose UDP or TCP for my RPC?
3.01: Add link to IBM's AIX DCE web page
2p02: Add information on IBM enhancements to security server to permit
large number of DCE principals to be created.
2cc06: Add
clarification that cross-cell delegation is possible in restricted
circumstances.
3.01: Add link to Keys Botzum's DCE & Encina
question and answer page
3.05: Add links to Linux DCE web pages by
Andrew Sandoval and by Jim Doyle.
Q 1.01: What is
DCE?
Q 1.02: What are
the advantages of DCE?
Q
1.03: What platforms support DCE?
Q 1.04: What products use
DCE?
Q 1.05: Is DCE an
official standard?
Q
1.06: The DCE threads uses draft 4 of the standard, but Posix threads
standard has moved beyond draft 4. Will DCE change to the most recent standard?
Q 1.07: Is anyone
using DCE for real-life mission-critical systems?
Q 1.08: What is the
relationship between DCE and CORBA?
Q 1.09: Is DCE IDL the same
as all the other IDL's in the world?
Q 1.10: Now that OSF is the
Open Group, should we talk about OG DCE?
RPC and IDL
Compatibility
Performance
Cell
Configuration
Security
Q 2r-01: Several of the other questions concern "interfaces". What is
meant by an interface in DCE RPC?
Q 2r-02: Can a DCE client
import multiple interfaces?
Q 2r-03: Can a DCE client
connect to multiple servers?
Q 2r-04: Can a DCE server
export multiple interfaces?
Q 2r-05: Can a process be
both a server and a client?
Q 2r-06: How do I perform
asynchronous RPC?
Q
2r-07: How can a server keep track of multiple clients?
Q 2r-08: How can a server
detect that a client as exited or crashed?
Q 2r-09: How can a server
identify the client that has called it?
Q 2r-10: Can I move
idl-compiled stubs from one platform to another and rebuild the object files
locally?
Q 2r-11: How
are UUIDs generated?
Q
2r-12: How can I pass a UUID as a parameter in an RPC? What is the format of
a uuid_t structure?
Q
2r-13: How can I pass a binding handle as an ordinary parameter in an RPC?
Q 2r-14: How do I
keep my server from advertising all the host machine's network addresses with
CDS?
Q2r-15: How do I
share type declarations between two or more IDL files?
Q 2r-16: How can I control
the timeout of a context handle?
Q 2r-17: A server has moved
or otherwise changed its binding information. How do I make the client obtain
the new binding ?
Q 2p-01: How efficient is DCE RPC?
Q 2p-02: What is the
practical limit on the size of a DCE cell?
Q 2p-03: How much memory and
disk space is required for DCE services?
Q 2p-04: How can I control
the number of concurrent client connections and the size of the request queue on
a server?
Q 2p-05: My
server gets a stack error when sending large objects. How can I avoid this?
Q 2p-06: How do I get
clients to connect to the nearest server?
Q 2p-07: Should I choose UDP
or TCP for my RPC?
Q 2c-01: Will Windows NT communicate with DCE?
Q 2c-02: Can I use DCE from
C++?
Q 2c-03: Can I
write an application that uses DCE and X11/Motif?
Q 2c-04: Is DCE RPC
compatible with ONC RPC?
Q 2c-05: Is XDR compatible
with NDR?
Q 2cc-01: Is it possible for a machine to be a member of more than one
DCE cell?
Q 2cc-02:
How do I configure cells to find each other using DNS?
Q 2cc-03: Is it possible for
a user in one cell to use secure services in another cell?
Q 2cc-04:: How do I change
the name of my cell?
Q
2cc-05:: How do I change the IP address of a host in my cell?
Q 2cc-06:: How do I do
inter-cell delegation?
Q
2cc-07:: How can I find out who is currently logged in to a DCE cell?
Q 2s-01: Where can I find an ACL manager to include in my application?
Q 2s-02: Does DCE
Security interoperate with other Kerberos systems?
Q 2s-03: Can I allow DCE
clients and servers to communicate across a firewall? Can I control the
endpoints assigned to DCE servers?
Q 2s-04: Do DCE servers
automatically update their long term secret keys?
Q 2s-05: What problems might
I cause by changing the expiration time or password lifespan in a running cell?
Q2s-06: How do I
begin to force password changes, without getting into the trouble described in
the previous question?
Q
2s_07: Do all versions of DCE support the sec_key_mgmt_manage_key()
functionality in the same way?
Q 2s_08: How can I work
around the key_mgmt problem if I have older client machines, but DCE 1.1+ based
servers?
Q 3.01: Where can I
get online information about DCE?
Q 3.02: What books are
published on DCE?
Q
3.03: Where can I get more information about DCE and DCE-related products?
Q 3.04: What are DCE
RFCs, and how can I get them?
Q 3.05: Where can I get the
Public Domain version of DCE?
Q 3.06: Is there a DCE Users
Group I can join?
Q
3.07: Are there any example programs available on-line?
The answers please:
A: 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). The Threads, RPC, CDS, Security, and DTS components are commonly referred to as the "secure core" and are the required components of any DCE installation. DFS is an optional component. DCE also includes administration tools to manage these components.
DCE is called "middleware" or "enabling technology." It is not intended to exist alone, but instead should be bundled into a vendor's operating system offering, or integrated in by a third-party vendor. DCE's security and distributed filesystem, for example, can completely replace their current, non-network, analogs. DCE is not an application in itself, but is used to build custom applications or to support purchased applications.
A:
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. The DCE Security Service provides a reliable way of determining if a user of a distributed system should be allowed to perform a certain action, for example. This is very useful for most distributed applications, yet the design and implementation effort entailed in providing such a capability would be prohibitive for an individual developer.
Third, DCE integrates components in a manner that makes them more valuable together than separately. For example, the DCE RPC uses threads in such a way that a developer can implement a multi-threaded server without ever explicitly creating or destroying a thread.
Finally, DCE supports both portability and interoperability by providing the developer with capabilities that hide differences among the various hardware, software and networking elements an application will deal with in a large network. For example, the RPC automatically converts data from the format used by one computer to that used by another.
Portability is a measure of the ease with which a piece of software that executes on one type of computer can be made to execute on a different type of computer. Interoperability is a measure of the ability of computers of different types to participate in the same distributed system.
A:
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. Client machines can use these services, they simply cannot run the server programs; another machine in the cell must run the server programs. Application programs can be built and run the application servers on these "client-only" systems.
The status of DCE implementations changes frequently; check with the specific vendors for the latest details, or see the DCE product list (see the next question). Updates to this FAQ are solicited. This table summarizes the DCE implementations currently available:
-------------------------------------------------------------
Platform Comments
-------------------------------------------------------------
Unix platforms:
Digital UNIX: Secure core, DFS, and X.500
Ultrix had a "Starter kit", but of course Ultrix is
no longer supported...
HP-UX: Secure Core, DFS , and X.500
DG/UX Secure Core and X.500
AIX: Secure core, DFS, and X.500
SunOS, Secure Core
Solaris: Secure core and DFS
Implementation by Transarc, also re-sold by Sun
Irix Secure Core, DFS, X.500
SCO Secure Core was expected by August 1994
AT&T GIS, SVR4 on Intel Secure Core
Sinix (Mips and Intel) Secure Core, DFS, and X.500
Cray Unicos Secure Core Client, and DFS server
Pyramid DC/OSx (SVR4) Secure Core
Hitachi HI-OSF/1-MJ (osf/1) Secure Core, with Japanese on-line doc
Hitachi HI-UX/WE2 Secure Core
Sony NEWS (SVR4) Secure Core
Fujitsu DS/90 (SVR4) Secure Core
System V on Intel: Secure Core, from Gradient Technologies
Unixware, Sequent Dynix, NCR MP-RAS, Unisys
Dascom AD V1.1 (OSF/1 on Intel) Secure Core Client
Non-Unix platforms:
Tandem NonStop Kernel Secure core
OpenVms (Vax, and Alpha AXP) Secure core, X.500 support
Microsoft Windows: Client-only, available from Gradient Technologies
Gradient's port is also sold by Siemens,
and IBM.
Unimetrics has announced DFS client products
for Windows
Transarc has a "DFS-Light" client for Windows
Macintosh Client only, from Gradient Technologies
Open Environment Corporation has a Macintosh
client that allows access to DCE servers by
way of an OEC server on another machine.
Windows NT: out-of-the-box, NT contains a subset of
DCE RPC. See Q 2c-01 for further discussion.
Gradient has full secure core DCE+DFS for NT
Digital has secure core
IBM has secure core
Transarc has DFS client and server and a
"DFS-Light" client for WinNT
Windows 95 Client only, from Gradient
Client only, from Digital
Transarc has a "DFS-Light" client for Win95
OS/2: Secure core
HP 3000 with MPE/iX Secure Core
VM Kapsch AG supports DCE client and the
security server on IBM's VM and VM/ESA
VM/ESA IBM has announced intent to support
"selected components" of DCE on VM/ESA.
These components boil down to secure client
without DTS
Kapsch AG supports DCE client and the
security server on IBM's VM and VM/ESA
IBM OS/390 (MVS) secure core + DFS
IBM AS/400 client only
BS2000 Client Only
Bull DPX/20 Secure Core, X.500, DFS
GCOS on Bull DPS 9xxx/7xxx threadless client only
A:
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. If you want to find
products like "PC-DCE", "Nonstop DCE", and "Kapsch-DCE/VM", search for "*DCE"
instead. If you want to find DCE-related products like Encina or Dazel, go to
the advanced search and choose the Keyword DCE.
Note to vendors, not all DCE implementations show up under a keyword search for DCE, so check your listings.
A:
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.
DCE Threads follow the Posix Threads draft standard 1003.4a draft 4. DCE Access Control Lists (ACLs) are based on POSIX.6 Draft 12. The Distributed Time Service (DTS) uses time formats defined by international standards and in POSIX.4. The Global Directory Service (GDS) complies with the X.500 international standard. (Although DCE complies with the 1988 version of X.500, not the 1992 version.)
ISO is considering an RPC standard based on the X/Open document.
DCE's status as a de facto standard is even stronger. Almost every major hardware and software vendor has committed to providing DCE on its platform. These vendors include not only Open Group stalwarts such as IBM, DEC and HP, but also other key vendors such as Novell, Inc. See Q 1.03 for a list of DCE vendors. In addition, a number of major user organizations (e.g., the European Economic Community) have already embraced DCE as their standard for distributed applications.
A:
It is hard to predict exactly what will happen. But Open Group prefers to follow standards rather then invent them. Now that Posix has settled on the standard, we can expect the DCE to migrate to it.
A:
Yes, and more every day. Tokio Marine and Fire Insurance, Co., Lehman Brothers, and Charles Schwab have all publically described their ongoing rollout of DCE based applications.
The Open Group's Web server has a section that includes some reports on 'real-world' experiences from companies using DCE in production.
Intellisoft published a 48-page "advutorial" (that means advertisement and tutorial) with the help of many DCE vendors, totally devoted to the above. There are storeis about DCE in production, technical essays, etc. The supplement is on-line and available via Intellisoft's web site (http://www.isoft.com/publications.html -- click on "DCE and The Enterprise" ).
A:
The short answer:
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.
The long answer: In order to understand the relationship between DCE and the Common Object Request Broker Architecture (CORBA) of the Object Management Group (OMG), it is necessary to consider the past, the present and the future.
Past - Historically, the object paradigm has been viewed as a break with procedural styles of the past. Objects, which encapsulate data and procedures behind an external interface, are often contrasted with other approaches where procedures and data are treated separately.
In this context, DCE is a descendant of the procedural school which emphasizes the decomposition of programs into procedures and achieves distribution by locating some of those procedures remotely. Thus there was a tendency for the object community, including the OMG, to view DCE as technology which was obsolete before it was available.
However this view ignored the fact that designers of distributed systems had for a long time recognized that the most successful approach to developing distributed systems was to created encapsulated objects that can only be accessed via well defined interfaces. Thus the cornerstone of DCE RPC is the interface definition language (IDL) which allows the external attributes of a set of server operations to be specified.
Furthermore, the name-based binding mechanisms of DCE were extended to include the ability to bind to a server based on the object instances which it supports. These object binding mechanisms also allow the transparent selection among multiple implementations of the same server operations based on the type of the specified object. In object terminology this is called polymorphism.
The DCE notion of a server supporting interfaces consisting of one or more operations is so close to the notion of an object which provides one or more methods, that it should be no surprise that CORBA defines an IDL which differs from DCE IDL in only a few significant respects.
Principal among these is that in CORBA IDL every call must specify an object, which is used in determining the server to use. DCE can do this as well, but there is more work involved and it is optional. Another difference is that CORBA IDL allows an interface to be defined as a extension of one or more other interfaces, this is called interface inheritance. DCE does not permit interface inheritance, but may in the future. Implementation inheritance is not specified by either DCE or CORBA.
The use of object oriented techniques and principles should not be confused with using an object oriented language. Object oriented designs can be expressed in procedural languages, and in fact most of the current object environments supported C before supporting C++ or Smalltalk. Therefore, the fact that the DCE API is implemented in C is no barrier to using it to create a distributed object system. In fact, CORBA specified C language bindings first.
Present - CORBA should not be viewed in isolation, but in the context of all of the OMG's standardization efforts. OMG has defined a reference architecture (OMA) and has defined or is defining standards in a broad range of areas, including: databases, events, lifecycle, transactions, persistence, security, naming and relationships. Viewed in this way, OMG's activities are much more ambitious and broader in scope than DCE.
A recent addition to CORBA, as a part of the CORBA 2.0 work was the definition of the means of interoperability between ORBs. CORBA 2.0 defines one mandatory and two optional mechanisms. The mandatory means is a new, lightweight protocol called UNO. The optional means are 1) via a gateway and 2) via an alternative protocol definition. At the present the only alternative protocol that has been defined is DCE RPC.
Many people who had hoped that DCE would be selected as the mandatory protocol were disappointed at this result. However, it should be observed that DCE is endorsed as alternative protocol and that several vendors have committed to providing ORBs that interoperate via DCE.
Another difference between DCE and the OMG standards is one of general philosophy. DCE has been defined quite rigorously in a series of documents published by X/Open. There is a set of conformance tests that are available to anyone. Any product passing these rigorous tests can be branded as DCE, without necessarily being based on the OpenGroup code. Several vendors, including Microsoft and Tandem have reverse engineered significant portions of DCE.
OMG standards vary considerably in their level of detail, but in general, aim at a much looser level of standardization. In some cases, the standard merely specifies an object interface and some general semantics. This approach is a deliberate attempt to encourage diverse solutions which may be applicable in different environments. Even where specifications are relatively tight, for example in the area of CORBA portability, there is still room for considerable interpretation, as witness the fact that there is at least one company that provides consulting services on how to make CORBA applications compliant in practice.
At the present time, CORBA-compliant products and products that work with them do not provide a scaleable infrastructure suitable for large environments. Key features such as concurrency mechanisms, security and distributed transactions are not currently available. In contrast, DCE provides proven heterogeneous interoperability and most of the capabilities required by robust, production applications. Additional capabilities can be obtained by means of third products, such as transaction monitors built upon DCE. This situation will change over the next 2-3 years from a combination of standardization work by OMG and new product development by vendors.
Future - Most authorities agree that in the long term object technology will be the basis for building large scale distributed systems. In addition to the principle of encapsulation, object- based systems allow systems to be built up, evolve and be reconfigured as needed because of their ability to dynamically bind requesters to objects that provide services.
There are many specific issues concerning the properties of distributed object systems that are the subject of research and debate. It is also clear that there are some features of existing local object environments and languages that will not scale effectively to large scale distributed systems -- dynamic inheritance is one. Never the less, the general direction of the future is clear.
Clearly, the high level of interest in OMG defined standards comes not from current products, but from their exciting future potential. There is a natural tendency to compare DCE's current capabilities with the promise of CORBA's future. However, DCE is also evolving and will likely add additional object oriented features in the future. For example, HP is offering a DCE C++ class library which is expected to eventually become a standard part of DCE.
Where DCE was built by integrating existing software, OMG has chosen by and large to start with a clean sheet of paper. The idea is to be better able to implement object oriented constructs without the baggage of features carried over from previous systems. However, OMG faces great challenges. Object theory is currently in a great state of flux. Experts disagree on very fundamental issues about what features are necessary, useful or harmful.
Developing standards under these conditions is extremely challenging. OMG's approach to date has been to compromise and allow multiple alternatives. It is unclear whether this will succeed in the long run.
Does the conclusion that future distributed systems will be object- based mean that it is a mistake to build distributed systems today using DCE? The answer is no for several reasons. First, many organizations cannot afford to do nothing for several years. End users have pressing needs for robust, scaleable systems today. For many organizations, waiting would mean attempting to catch up with competitors who will have a tremendous head start.
Second, as this brief discussion has shown, it is possible to employ object techniques when developing distributed applications using DCE. Carefully designed systems will be able to take advantage DCE features such as dynamic binding and polymorphism and converge with CORBA-compliant systems as they mature.
Third, if object environments are to be successful in supporting industrial-strength distributed systems, they will have to address the problems that DCE addresses. The skills and techniques developed in working with DCE will be directly applicable to distributed systems environments of the future. This applies not only software developers, but also to operations personnel, planners, even business managers.
Further, the likelihood that DCE will be at least one technology for CORBA interoperability, implies that the eventually migration of applications which use DCE directly to an object environment should not present any insurmountable difficulties.
Finally, your direct experience in developing and operating robust distributed systems will provide you with great insight into the important characteristics of distributed systems environments as they apply to your organization's applications. This knowledge is vital to the shaping of successful tools of the future. History has shown that vendors and standards bodies, left to their own devices, will often miss the mark.
A:
No.
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.
When asking or answering a question about IDL, one should be careful about specifying which IDL is involved.
A: No. "OSF DCE" is the registered trademark, and will apparently remain the name of the product.
A:
An 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.
A:
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.
A:
Yes. A client can connect to multiple servers providing different services, and/or multiple servers providing the same service.
To use multiple servers with the same interface, the client must obtain a binding handle for each server and use explicit handles in the RPC.
A:
Yes. A server can provide service on multiple interfaces simultaneously. A common example is a server that exports an application interface and a management interface.
To code such an application, repeat the calls to rpc_server_register_if(), rpc_ep_register(), (and rpc_ns_binding_export() if you do that sort of thing in your server) for each interface, before calling rpc_server_listen().
A:
Yes. There are two scenarios.
Note that most server programs also act as clients, since they usually access the endpoint mapper (rpcd), and the security service; these actions use RPCs, though it may not be obvious in the code.
A:
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.
A:
The DCE RPC mechanism includes a "context handle" which can be created by a server and returned to a client. The handle is used on subsequent RPCs to identify the client.
A:
The context handle provides this ability. When a context handle is created and passed to the client, the DCE runtime library keeps track of the connection between client and server; this may be done in the network code as in the case of TCP, or by DCE-specific ping messages if a connectionless protocol is used. When the client dies, the server is notified and executes a "rundown" function to clean up its data structures.
A:
The details vary, depending on exactly what you want to identify about the client, but it all comes down to handles. The server must receive a binding handle in order receive information about the client. If there is not a binding handle in the parameter list as defined in the IDL file, then use the [explicit_handle] attribute in the ACF file to add one when building the server.
If you want to identify the host machine on which the client is executing, simply convert the binding handle to a string binding using rpc_binding_to_string_binding() and then extract the address using rpc_string_binding_parse(). When the server receives the handle, it contains the client address.
If you want to identify the human user who is running the client program, you can get that from the authentication information in the handle. rpc_binding_inq_auth_client() will give you the caller's PAC, which contains, among other things, the principal's uuid and name.
If you want to identify the particular client process so your server can keep data specific to each client, then you need to look into context handles as described in Q 2r-07.
A:
No. You must run the IDL compiler separately on each platform.
The IDL compiler builds the client and server stubs to handle network communication and data marshalling, which are platform-specific activities. Therefore the stub code is not portable and must be re-created on each platform. Likewise, while the task of the stub does not change, the set of service routines called from the stub may be changed by the vendor for any given platform. Therefore stubs for the same RPC may look very different on different platforms.
A:
The DCE AES specifies the method for generating UUIDs, in case you want the gory details. In short, the UUID is a combination of the network address and current time at the moment and place it was generated. Assuming that network addresses are unique and that time never runs backwards, this guarantees that UUIDs really are unique.
Some implementations of uuidgen use the hardware address of the ethernet adapter, some use the IP address of the host.
It is possible to run uuidgen on machines without any network connection. In this case, the host must be assigned an address. The AES specifies a file that can hold the network address.
The code for generating UUIDs is part of the publically available DCE source code. See Q 3.05: for information on obtaining the code.
A:
The uuid_t structure is defined in <dce/nbase.idl> All you have to do is import this into your .idl file and pass parameters of that type all day long.
Note that uuid's passed as parameters are just ordinary data. If you want the uuid to affect the interface or object in the rpc, they must be attached to the binding handle.
A:
The binding handle is an opaque type and cannot be marshalled as data. A parameter of type handle_t must be the first parameter and will serve to specify the binding of the RPC; an attempt to use a handle_t as other than the first parameter will be flagged as an error by the IDL compiler.
To send a handle from one process to another, convert it to a string binding and pass the string as a parameter.
A: If a server machine has two (or more) network interfaces, it will have at least that many network addresses. A typical server program will export binding handles to CDS for every protocol sequence on every network interface. If some of these interfaces are unreachable from some clients, binding may be delayed while the client cycles through the useless handles.
To limit a particular server, set the environment variables RPC_UNSUPPORTED_NETIFS and/or RPC_UNSUPPORTED_NETADDRS to exclude the interface or specific addresses that you don't want your server to use. On HP, set RPC_SUPPORTED_NETADDRS instead, to give a list of addresses you do want to use. Look in your vendor's documentation for syntax and to verify that they support this feature; it is not standardized by Open Group. You must set the environment before starting the server, of course, and you may have to manually remove CDS entries that are already present.
A: Imagine a program that uses two interfaces, in two idl files, and these two interfaces share many of the same structures which must be typedef'ed in the idl file. A C-programmer's first instinct would be to #include a header file in both idl files, and this would appear to work, because the IDL compile generally runs the C preprocessor. But when the application code is compiled and #includes both of the generated *.h files, the C compiler will complain about duplicated declarations of these structures.
You should instead put the shared declarations in a separate .idl file, compile it separately with the idl compiler, and "import" the .idl file into all the other idl files that need it.
This way, each definition will appear in exactly 1 generated .h file, where it will be protected by the usual #ifdef to prevent multiple declarations.
Some shops have an explicit style guideline that says an idl file should contain either type definitions or function declarations, but not both. You might want to try it.
A: The DCE runtime calls the context rundown routine as soon as it notices that the connection with the client has been lost. Exactly when the runtime will notice depends on the communications protocol.
If the conversation is using a connection-oriented protocol like TCP, then the runtime depends on the protocol to notify it of a lost connection; if the client crashes or exits, the speed with which the server is notified depends on the TCP implementation and may be quick or very slow. If the socket is shut down gracefully, the rundown may be called immediately; otherwise it all depends on the timeout parameters in TCP. You may be able to adjust the timing by changing parameters in your network stack, but it will affect the whole system, not just DCE.
With a connectionless protocol like UDP, the runtime generates its own keepalive messages to test the "connection". (Actually, they are "I'm Not Dead Yet" messages from the client.) If the client exits, the server will assume the connection is down after a number of missed messages.
Thus the speed with which your server is notified after a client crashes may vary from platform to platform due to differences in TCP implementation, and from minute to minute on the same platform depending on whether the client happens to use a TCP or UDP binding handle.
Moral: context rundown allows the server to clean up, but is not a real-time monitoring tool.
First, remember that a client must always be prepared to deal with stale binding handles. Before starting to make RPCs, call rpc_mgmt_is_server_listening() to verify the handle, and continue importing bindings until you get one that works.
If the server information has changed recently, the information in the client's cache may need updating. Call rpc_ns_mgmt_set_exp_age() with an expiration_age value of 0 to force an update.
A:
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. Using the packet integrity and packet privacy features of the security service can increase processing times as a linear function of message sizes.
There are three papers providing preliminary performance data published in:
DCE--The OSF Distributed Computing Environment,
Lecture Notes in Computer Science #731, Springer-Verlag,
(see Q 3.02 for ISBN)
IBM has done quite a bit of performance testing of DCE. Many of the reports are available on line; go to IBM's corporate Web page, http://www.ibm.com/ and choose the search feature to search for something like "dce performance". To summarize a few of the results in these reports:
A:
Good question. There are no hard and fast answers, but there are some large-ish cells in operation.
Certainly it is reasonable to plan on cells with thousands of nodes and perhaps tens of thousands of users.
The University of Michigan Center for Information Technology Integration has done a study in which they added 50,000 entries to the Cell Directory and to the security registry. Their results are reported in technical reports 93-12 and 94-1. See Q 3.01 for the ftp site for CITI tech reports.
Lexis-Nexis has a more recent study in which they added 400,000 accounts to the DCE registry. The write-up was available at their web site http://www.lexis-nexis.com/ but if it is still there, you apparently must be a subscriber to see it.
Several years ago IBM's DCE performance testing (see Q 2p-01 above for citation) includes load testing to simulate the environment of a large cell. A short, oversimplified, summary is that server machines based on 486/66 and P90 (running OS/2) could support the projected needs of a cell with 10,000 users. An informal post on Usenet claimed that a test on an AIX platform had reached over 700,000 users created in the security server.
IBM's OS/390 DCE server includes modifications to the security server to use a better backing store so that the entire set of principals need not be keep in-core.
A:
This depends on the size of the cell, the number of users, number of services, etc.
According to a paper present by Dan Hamel of Transarc, at the Decorum conference in February 1994, the following can be used as rough guidelines:
The security server as shipped by the Open Group keeps all security registry information resident in main memory, which means that the security host machine needs memory as well as disk.
A:
The rpc_server_listen() call creates a pool of threads to handle incoming RPCs. The server can be actively working on at most this many RPCs simultaneously. The size of the pool is controlled by a parameter to rpc_server_listen. This is the primary place where you are expected to control the number of simultaneous connections.
If you want to go deeper, into the question of what happens when all the server-listen threads are busy, things become tricky, because there are so many factors affecting the answer.
If all the server threads are currently busy, incoming requests will be queued by the RPC runtime. There is not an explicit API for controlling the size of this queue. The rpc_use_protseq*() calls have a "max calls" parameter, but its effect is murky and it may be ignored completely by the implementation.
If the RPC queue is full, the runtime will not accept any more network messages. Incoming requests will therefore be held at the network protocol layer, which maintains a queue of its own. If the network layer's queue is full then the incoming message will be rejected and the client will be told that it is unable to connect to the server.
A:
Each thread in a process is assigned a fixed area for its procedure-call stack. The stubs normally marshall and unmarshall parameters in space allocated on the thread's stack. If the parameters are large, the stack size may be exceeded. In most thread implementations, the stack size cannot be increased after the thread is created. For threads created explicitly by your application, you can adjust the size of the thread stack by setting an attribute before calling pthread_create(). However, server threads are created automatically, so that method won't work; instead, call rpc_mgmt_set_server_stack_size() before starting the threads with rpc_server_listen().
Another possibility is to use the [heap] attribute to have some parameter types marshalled on the heap instead of the stack.
You should know that current implementations of the IDL compiler generate recursive code to marshall linked lists. Therefore, passing a long linked list may cause stack overflow due to all the recursive calls.
A:
It's not easy. Currently, vanilla DCE gives essentially no help.
For clients for which you have source code, you can use the rpc_ns_binding_lookup*() routines to search through the binding handles and apply some custom logic to finding a nearby server.
For standard DCE services, such as CDS and security queries, you get a random server, which could be anywhere in the cell. For the security service, you might be tempted to set the BIND_PE_SITE environment variable and the file /opt/dcelocal/etc/security/pe_site to hardwire each client host to its nearest security replica, but this is a hack with serious administrative downside: if the replica goes down or is moved, all the associated clients must be manually updated.
Individual products may provide additional help. For example Transarc's DCE now includes a feature that lets clients connect to the closest CDS server.
A:
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.
For heavily-loaded servers, UDP is often recommended over TCP. In low-bandwidth networks, or when running servers under a debugger, TCP may be preferred.
A:
No. A machine can only be in a single cell. However, it is possible for cells to cooperate. See the next question.
DCE v1.1 will allow for "hierarchical cells", which may solve the problem, depending on why you want to have a machine in two cells.
A:
In order for a client program in cell A to find a server in cell B, it must be able to find the CDS server in cell B; once communication with CDS is established, everything else in the cell can be found. One of the ways to make the location of of the cell known is to create the proper entries in the Internet Domain Name Service (DNS).
Suppose we want to make a cell available, and that the name of the cell is "/.../cell.mauney.com". We must create two DNS entries. One entry will provide the IP address of the machine that runs the CDS server within the cell. The other entry gives other details about the cell.
The first entry, which advertises the location of the CDS server, can be either an MX or an AFSDB record type. The DCE code will be happy to use either one, but you as a system administrator have to make a choice; both possibilities have drawbacks. The MX record type is intended for mail exchange, so using it for DCE is a bit of a kludge; and if you already have a machine in your name with the same hostname as your cell name and it ever participates in e-mail, then you'll have a conflict. On the other hand, the AFSDB record is new and not supported by all nameservers; you'll need Bind version 4.9.2 or later.
The MX or AFSDB record relates the cell name to a host name. DCE ignores the "preference" value of an MX record. With AFSDB, you should use sub-type 2. E.g.,
cell.mauney.com. IN MX 200 tophat
or
cell.mauney.com. IN AFSDB 2 tophat
where "tophat" is the hostname of the machine that runs the CDS master server.
The second piece of information in DNS is a TXT record giving UUIDs for the CDS master replica and clearinghouse. You obtain the information with the command "cdscp show cell as dns", and copy the information verbatim into DNS. E.g.
cell.mauney.com. IN TXT "1
44007e75-08b4-11ce-9055-08002b32b23b Master /.../cell.mauney.com/tophat_ch 43373550-08b4-11ce-9055-08002b32b23b tophat.mauney.com"
See Q 2cc-03: Is it possible for a user in one cell to use secure services in another cell?
A:
Yes. The Access Control List (ACL) permits three entry types -- foreign_user, foreign_group and foreign_other -- which specify the permissions available to users on other cells. All that is required for intercell access, other than physical connectivity, is for the two cell's security services to be configured to know about each other.
There is a command, the rgy_edit "cell" command, that must be run, once, by the cell admin of the two cells that wish to communicate. After that, it's all transparent.
A: You don't.
The cell name in embedded into too many hidden places. Live with the old cell name, or create a new cell and configure it to look like the old cell.
If you haven't created your cell yet, learn this lesson and choose a cell name you can live with.
A: Very Carefully. You need start this before changing the address of the machine.
A: Our initial answer to that question was: Inter-cell delegation is a poor idea from a security standpoint. Therefore, DCE does not implement it. That answer may have been too absolute. It may be better to say that DCE severely restricts delegation because of the security problems.
Keys Botzum's Q&A says the following: The delegation chain of RPCs may cross only one cell boundary. This means that with two cells you can not cross back into the originating cell, and any delegation involving 3 cells will not work at all.
A: You can't.
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.
Answering the question of "who is logged in" is difficult, in part because in the DCE architecture it is hard to decide exactly what the question means. For example, if a person is logged in to a DCE client machine, but his DCE tickets have expired, does that person count as logged in or not?
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. Another approach would be a daemon that runs on each host and periodically notices ticket files; there are security concerns with this approach. Or you could just run "rwho" :-)
A:
DCE version 1.1 includes a basic ACL manager library.
HP's OODCE (DCE C++ class library) provides you with a default, built-in ACL Manager with the server class.
Transarc's Encina (transaction monitor) product includes an ACL manager.
Lockhart's book contains a sample ACL manager. (see Q 3.02)
Hu's book on DCE Security Programming contains a sample ACL manager. (see Q.3.02)
The code from both the Lockhart and Hu books is available on-line. See Q 3.07 for URLs.
A:
Basically, no, or maybe yes, depending on what you want to do.
To use authenticated DCE services, you must have credentials from the DCE security service; vanilla Kerberos v5 tickets aren't sufficient. But then, to use DCE services you must be using DCE RPC, so this is not really a problem.
Going the other way, it is expected that a DCE security server can issue tickets that can be used by vanilla Kerberos applications. The Open Group was wary of promising this until the Kerberos v5 specs were published, but now that the Kerberos RFC has been published, Open Group anticipates guaranteeing interoperability sometime "soon".
In a little more detail, the way to think about this is as follows:
Kerberos offers 2 services (Authentication Service, Ticket Granting Service) over 1 communication mechanism (UDP port 88).
DCE security offers 3 services (AS, TGS, Privilege Service) over 2 communication mechanisms (UDP port 88, RPC).
Where Kerberos and DCE security intersect (AS, TGS over UDP port 88), the services are identical.
DCE V1.1 supports the GSSAPI, so non-DCE services that use GSSAPI can be integrated with DCE security server.
A:
Yes.
You can, of course, assign well-known endpoints to all your servers, but that is a truly bad idea, and won't work for services that you don't have source code for (such as CDS and the security registry).
The endpoint mapper will examine the environment variable RPC_RESTRICTED_PORTS and choose endpoints only in that range. You can make the range as small as necessary, and configure your firewall to pass traffic only to those ports.
The format of RPC_RESTRICTED_PORTS is a list of settings, separated by colons. Each setting is of the form protocol[lo-hi]. E.g.
export RPC_RESTRICTED_PORTS=ncacn_ip_tcp[5000-6000]:ncadg_ip_udp[5000-6000]
A: No.
Except for exceptional circumstances, all DCE servers should periodically change their long-term key. However, neither the servers provided by DCE nor those written by you or third parties will do this out-of-the-box.
The way to have a server update its key is by spawning a thread that calls sec_key_mgmt_manage_key() (which never returns under normal circumstances). As distributed by Open Group, DCE has no password expirations set, so sec_key_mgmt_manage_key() won't actually do anything. You may set the password expiration time or lifespan using an admin tool such as rgy_edit or dcecp.
In 1.0.x releases, DCE only enforced passwd expiration in the clients (such as printing a warning in dce_login). As of DCE 1.1, however, the security server will no longer grant a TGT for an account who's password/key has expired, so servers that aren't correctly running the manage key code before their password expires will require administrative intervention to become operational again.
The following table shows what the Open Group-provided servers do:
cdsd -- yes; uses FILE:/krb5/v5srvtab dced -- yes (uses FILE:/krb5/v5srvtab and manages hosts/<machine>/self) dtsd -- not applicable; runs as the machine principal pwd_strengthd -- yes; uses FILE:/krb5/pwd_strength_tab secd (maintains three keys) -- not applicable
A: DCE v1.1 will not let you authenticate (acquire a TGT) with an expired password. As such, if you change the "password lifespan" policy from "never" or a period longer than 30 days, to days, then every host principal, user and server account that has not (by coincidence) updated their password/key within the last 30 days, will be locked out. Users would not be able to log in, server applications would no longer be able to obtain credentials and the dceds would no longer be able to obtain/refresh their machine credentials.
A: Set an explicit "expiration date" policy, some time in the near future. (Make sure it's at least 30 minutes from the current time, to give the key management threads time to catch the change and a couple of chances to make the change.) At that specified date/time, all users, server apps and machines should have updated their passwords/keys. Recover from any problems that occurred (machines down during that time, users forgetting...), then set the "password lifespan" policy field to the desired limit.
A: Unfortunately not. DCE 1.0.x releases had a limitation in this key mgmt call, in that it would not wake up until shortly before the key was due to expire (based on the expiration data that it obtained when the call was started or the last time through the loop after a change). DCE 1.1 should no longer have this problem, as the call wakes up every 10 minutes to see whether the expiration time has changed.
A: Preferably, upgrade them all to an DCE 1.1 or later. If this is not possible, manually change the keys for each older client:
rgy_edit-> kta -p hosts/<hostname>/self -a -r
(on each DCE 1.0.x-based client machine). Do this for any accounts in the default keytable, and any servers running on older versions that also use the sec_key_mgmt_manage_key() call.
A:
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. This kind of change can be covered up by a set of preprocessor macros, but it is a change to be dealt with.
A more serious consideration is that Microsoft's RPC does not use the standard DCE services, such as directory service and security. Thus applications that cross between Microsoft RPC and DCE will have to make unauthenticated calls and use string bindings. Digital bundles a Name Service Interface Daemon (nsid) into its DCE products. The nsid fills in the gap and allows an NT client to get bindings from CDS.
See the book "Distributing Applications Across DCE and Windows NT" for more details (see Q 3.02).
The good news is that DEC and Gradient both have DCE products for NT. Digital has a DCE client product available for both Intel and Alpha architectures. Gradient has a full secure core product.
Information on Digital's DCE on NT product is available at http://www.digital.com/info/Customer-Update/940412019.txt.html Information from Gradient can be obtained by sending email to info@gradient.com or at their Web site: http://www.gradient.com/products/products.htm
A:
Yes. First of all, since you can call C functions from C++ you can access all the DCE services from a C++ program. But that will not give you the benefits of C++.
There are several packages that provide a C++ interface to DCE. They different quite a bit in style and approach, so you'll need to consider them carefully in light of your own needs and preferences.
Objtran was produced by Citibank, and is available by anonymous ftp at ftp://wilma.cs.brown.edu/pub/Objtran.tar.Z
Hal Computer Systems developed a set of classes called DCE++. That part of the company was spun off into Chisholm Technologies. For information on DCE++, see their web page: http://www.chistech.com/products/dce++.html
Hewlett-Packard has a product called OODCE. It is for sale, and currently supported only on HP-UX. For technical information retrieve the OSF RFC #49 (see Q 3.05); for sales information contact your HP sales office.
DCE version 1.2.1 will include IDL support for C++. The OSF (oops, the Open Group) recently announced that OODCE will be adopted as part of DCE in a future version.
Transarc's Encina v2.0 includes Encina++, C++ support for Encina and DCE.
A:
Yes but there are several serious pitfalls.
The X11/Xt/Motif libraries may not be thread-safe. For example, suppose one thread calls a function in Xt, which calls a nonthreadsafe malloc(), which then gets preempted. The next thread may call a threadsafe malloc() that comes with DCE. When control returns to the first malloc(), any assumptions about the state of the heap are invalid.
Also, Motif/Xt/Xlib are not currently reentrant wrt/themselves. You can't have multiple threads concurrently manipulating any Motif/Xt/Xlib global state. Fortunately this issue is under you control when designing the application. X11R6 includes a thread-safe version of Xlib, but it will be a while yet before the vendors are all delivering thread-safe Motif.
A related issue is that XtAppMainLoop() waits in a select() for activity, coupled with the fact that DCE also waits in a select() for activity. Unless the two are select()s are cooperating, one or the other will be starved. This is a platform-specific issue, you should check with your DCE vendor for full details. If it is a problem in your environment, the standard solution is to encapsulate the GUI in one process, the DCE client code in another process, and connect them with a simple IPC such as a Unix pipe.
A:
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.
A: No
(For those of you not fluent in three-letter abbreviations, XDR is eXternal Data Representation, the data format used on the wire by ONC, and NDR is Network Data Representation, used on the wire by DCE.) XDR and NDR use different methods for tagging data items.
A:
First of all, the official documentation for DCE is not available for anonymous ftp. But there are several sites providing lots of other information. Here are some of the most useful:
The Open Software Foundation maintains a WWW server with information about all the Open Group products, including DCE. http://www.opengroup.org/dce/ takes you directly to the DCE index. Highlights of the Open Group's web server include a complete list of DCE products, the DCE Request for Comments documents (RFCs), the DCE product catalog (see Q 1.04) and a hypertext version of the Frequently Asked Questions list.
Project Pilgrim at the University of Massachussetts has a DCE homepage at http://info.pilgrim.umass.edu/pub/osf_dce/osf.html Their server provides a complete set of RFCS, searchable by http and also by gopher, at gopher://info.pilgrim.umass.edu/77/lib/.wais-sources/osf-dce-rfc.txt and a directory of contributed software, currently consisting of performance measurement utilities from Pilgrim, and book examples from O'Reilly&Associates.
The Center for Information Technology Integration at the University of Michigan has several pieces of DCE information on their servers. The big attraction here is the set of CITI Technical Reports related to DCE. You can get to the tech-reports from the CITI web server, http://www.citi.umich.edu/techreports
The PC Webopaedia http://www.sandybay.com/pc-web contains pointers to number of DCE-related web pages (including this FAQ), including magazine articles. Use the search feature to find DCE links.
IBM has a support web page for DCE on AIX at http://service.boulder.ibm.com/dssdce
A:
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.org
The DCE documentation is also published by Prentice-Hall. These books contain about the same material as the Open Group manuals, but are edited to improve the presentation.
Introduction to DCE ISBN 0-13-490624-1
DCE Administration Reference ISBN 0-13-643818-0
DCE User's Guide and Reference ISBN 0-13-643842-3
DCE Application Development Guide ISBN 0-13-643826-1
DCE Application Development Reference ISBN 0-13-643834-2
DCE Administration Guide
Vol. 1, Introduction ISBN 0-13-176546-9
Vol. 2, Core Components ISBN 0-13-176553-1
Vol. 3, Extended Services ISBN 0-13-176561-2
Application Environment Specification/Distributed Computing
RPC Volume ISBN 0-13-043688-7
Other books on DCE:
DCE Today
ISBN 1-85912-157-8
Practical DCE Programming
by Charles Knouse (Hewlett Packard)
Prentice Hall ISBN 0-13-324419-9
Understanding OSF DCE 1.1 for AIX and OS/2
by Rolf Lendenmann
Prentice Hall, ISBN: 0-13-493750-3 (paper)
Understanding DCE, by Rosenberry, Kenney, and Fisher
O'Reilly, ISBN 1-56592-005-8
Guide to writing DCE Appplications,2nd edition
by Shirley, Hu, and Magid
O'Reilly, ISBN 1-56592-045-7
Distributing Applications Across DCE and Windows NT,
by Rosenberry and Teague
O'Reilly, ISBN 1-56592-047-3
DCE Security
by Wei Hu
O'Reilly, ISBN 1-56592-134-8
DCE: A Guide to Developing Portable Applications
Michael T. Peterson
McGraw/Hill (Ranade Workstation Series)
ISBN 0079118003 (hard)
ISBN 0079118011 (paper)
OSF DCE: Guide to Developing Distributed Applications,
by H. W. Lockhart, Jr,
McGraw-Hill,(Ranade Workstation Series)
ISBN 0-07-911481-4
DCE--The OSF Distributed Computing Environment, Client/Server Model
and Beyond; Proceedings of the International Workshop on DCE, 1993
Lecture Notes in Computer Science #731, Springer-Verlag,
ISBN 3-540-57306-2
And for you German-speaking DCE-ers:
DCE--Das OSF Distributed
Computing Environment, Einfuerhrung und
Grundlagen,
by Alexander Schill,
Springer-Verlag, ISBN 3-540-55335-5
There are currently no books on DFS, but there is a recently published book
on AFS, the predecessor to DFS. AFS has very much the same architecture and
goals of DFS, though DFS uses DCE services throughout and most of the actual
command names have been changed. However, the concepts of cells, filesets, and
the DFS database replication mechanisms are practically equivalent. The book
is
Managing AFS: The Andrew File System,
by
Richard Campbell, Prentice-Hall, ISBN 0-13-802729-3.
A:
The Open Group's DCE web isite is at:: http://www.opengroup.org/dce/
For Users of DCE on MVS, there is a mailing list:
mvsdce-l@psuvm.psu.edu
and a Web
page (under construction): http://dcewww.citi.umich.edu:8080/mvsdce
A:
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
gopher://info.pilgrim.umass.edu/77/lib/.wais-sources/osf-dce-rfc.txt
A:
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.
The code is available on the Internet from several servers:
ftp://ftp.digital.com/pub/DEC/DCE/PD-DCE-RPC.tar.Z
http://www.pilgrim.umass.edu/pub/osf_dce/contrib/PD-DCE-RPC.tar.Z
http://www.opengroup.org/dce/
Be sure also to read the licensing information found in the same
directories.
Be warned that building anything from this release is not a simple matter. DCE uses an older draft of the Posix threads standard, the IDL compiler does some odd things with YACC, and there is no simple configuration mechanism.
Jim Doyle has a DCE client package for RedHat Linux, and is working on porting all of DCE to Linux/FreeBSD. See: http://www.bu.edu/~jrd/FreeDCE/
Andrew Sandoval has made a Linux port available. See: http://www.netwaysglobal.com/DCE/
Michael Peterson's work on DCE and Pthreads for Linux is available at: http://www.aa.net/~mtp
A:
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.
A: Yes.
The examples from the O'Reilly books (Shirley-Hu-Magid, Rosenberry-Teague, Hu) are available at ftp://ftp.ora.com/pub/examples/dce
Gradient Technologies has sample PC-DCE code available at their ftp site.
ACK: Thanks to the following, who provided netnews and email messages from which this information is gleaned. All errors should be blamed on Jon Mauney. (Corrections are actively solicited.)
Hal Lichtin, Open Software Foundation
Rich Salz, Open Software Foundation
Courtney Mark Grey, Open Software Foundation
Walt Tuvell Open Software Foundation
David Weisman Open Software Foundation
Matt Thomas, Digital Equipment Corporation
Jonathon Chinitz Intellisoft
Nat Mishkin Atria Software
Mark Hickey OpenVision
Keys Botzum Transarc
numerous others who have been accidentally omitted but
whose contributions are highly valued.
And special thanks to:
Harold Lockhart, Jr. Locus Computing Corporation
who wrote several of the answers in this FAQ.