2 — Client Configurations

[Previous] [Next] [Contents] [Index]

This chapter provides a deeper level of technical detail on the NetCrusader DCE/PC-DCE client runtime implementation. The primary reason for this information is to provide developers and administrators with a sufficient understanding of the full and lightweight client options offered by NetCrusader DCE/PC-DCE.

This chapter contains the following sections:

2.1 Client Component Overview
2.2 Understanding Lightweight Clients

2.1 Client Component Overview

Figure 2-1 and the sections that follow describe the main components of a client configuration. For the purpose of discussion, the full client configuration is shown; the lightweight client configuration does not include dced and cdsadv.

Figure 2-1: PC-DCE Client Configuration

2.1.1 cdsadv.exe

The CDS Advertiser (cdsadv.exe) assists the CDS clerk in maintaining the local CDS cache files, which DCE clients use when trying to locate network resources. The CDS Advertiser monitors the LAN for broadcasts from CDS servers, which contain information such as server status and clearinghouse name. The CDS Advertiser populates the CDS cache with this information, entering new servers and updating server status.

2.1.2 dced.exe

The dced daemon, dced.exe, supports the following services:

• On all supported Windows operating systems except Windows 98, the Microsoft endpoint mapper is used rather than the dced endpoint mapper.

  Local endpoint mapping services (Windows 98 only).

• Third-party pre-authenticated logins, which may or may not be required depending on the security requirements at your site.

• Certification of credentials, which proves that the credentials were not obtained from a rogue security server. Again, these may or may not be required depending on the security requirements at your site.

• Machine credential creation and maintenance.

dce32.dll includes the DCE runtime.

If a DCE application needs to call the security server, it uses the security APIs in the runtime. If a DCE application needs to contact the CDS namespace, it calls the RPC routines in the runtime; the runtime then calls the routines in the CDS clerk to get the namespace information.

2.1.4 CDS Clerk

In UNIX-based DCE, the CDS clerk is implemented as a process. In PC-DCE, the CDS clerk is implemented as a Windows DLL (cdsclerk.dll). The CDS clerk includes the CDS runtime.

Any application that needs access to CDS must go through the CDS clerk. Applications that request access to the CDS namespace call RPC routines in the DCE runtime; the DCE runtime then calls routines in the CDS clerk to obtain the requested information from CDS.

The CDS clerk, along with certain application clients and the CDS Advertiser, maintain the CDS cache. The CDS clerk queries CDS servers for namespace information on behalf of the client. The clerk also helps maintain cache records of which servers are currently responding and which are not.

2.1.5 CDS Cache

The CDS cache is a collection of information about servers, clearinghouses, and other CDS resources that a CDS clerk establishes on the local system for its reference.

The CDS cache is maintained in two areas:

• Common (global) cache, which contains information available to everyone (directory entries, clearinghouses, and so on).

• Per-user cache, which contains user-specific information (softlinks, groups, directory entries).

Information remains stored in the cache until either of the following occurs:

• The lifetime (roughly 8-10 hours) of the cached entry expires. (The exception to this lifetime is CDS server entries, which are updated hourly by dce_update.) Expired entries are updated when the clerk attempts to use the information and finds it to be inaccurate.

• The user establishes new credentials (probably through a new dce_login). This updates both the common and per-user cache files.

The PC-DCE configuration process creates the initial CDS cache by reading the root directory of the client's primary CDS server, whose name is supplied by the person performing the configuration. The root directory contains references to all of the CDS clearinghouses and their associated CDS servers.

The CDS cache is maintained primarily by the CDS clerk, with help from the CDS Advertiser and certain application clients.

• CDS Clerk maintenance — When the CDS clerk receives a CDS servers's response to a query, it stores the response in its cache. The next time the clerk needs this information, the clerk retrieves it from the cache rather than issuing a network request to a CDS server.

• CDS Advertiser maintenance — The CDS Advertiser monitors the LAN for CDS server broadcasts. These broadcasts inform the CDS Advertiser about new CDS servers, which it enters into the cache. CDS Advertiser also uses the broadcasts to update cache records of which servers are currently responding.

dce_update.exe is a lightweight PC-DCE process that keeps the CDS cache and pe_site file up-to-date.

Each clearinghouse entry in the CDS cache is designated as OK or Not OK. Every hour (this period is tunable), the dce_update process solicits clearinghouses that are marked Not OK, and changes the setting to OK if it is now responding.

This is especially important if a preferred server outside the LAN goes down. Since the server is outside the LAN, no broadcast occurs to indicate when it is available again. dce_update monitors the server's status, ensuring that the client returns to it after the preferred server comes back on line.

The pe_site file contains a list of security servers and associated bindings that the DCE runtime uses to select a security server. Every hour (this period is tunable), the dce_update process pings all known security servers and moves servers that do not respond to the bottom of the pe_site list, keeping the list sorted so that available servers are listed first.

The dce_update process checks for any registry keys or variables that you have modified, such as SEC_DEFAULT_ENTRY, which you can use to specify a preferred security server. These modifications are taken into account when dce_update creates the pe_site file.

2.2 Understanding Lightweight Clients

By default, the PC-DCE Configuration program configures your system as a lightweight DCE client, which does not include configuration of the dced, dtsd or cdsadv client daemons. Lightweight clients participate as a functioning member of a cell while offering performance and overhead advantages that make them preferable to full clients.

The information in this section will help you decide if a lightweight client configuration will be effective in your environment.

2.2.1 Lightweight Versus Full Clients

Configure lightweight clients to minimize the amount of memory PC-DCE uses, or when you want someone who is not the cell administrator to be able to manage his or her own PC-DCE configuration.

Lightweight clients are different from full clients in the following ways:

• Lightweight clients do not run dced. In a full client configuration, at startup, dced must register its bindings with the master CDS server. This involves approximately 180 Kbytes of network traffic. This is a disadvantage in a large cell or when the traffic must span a WAN link. dced consumes local CPU resources, and its startup requirements slow down system reboots.

  By running without dced, lightweight clients save space in CDS clearinghouses because no entries are required in the hosts directory. Space is also saved in the security registry because no machine principal accounts are required.

  The lightweight client compensates for the absence of dced by offering an optional endpoint mapper service that lets you run local applications (see Section 1.2.3 on page 10).

• Lightweight clients do not run cdsadv. In a full client configuration, at startup, cdsadv must register its bindings with the master CDS server. This involves approximately 70 Kbytes of network traffic, which is a disadvantage in a large cell or when the traffic must span a WAN link.

  cdsadv consumes local CPU resources, and its startup requirements slow down system reboots.

  The lightweight client compensates for the absence of cdsadv by using the dce_update process, which periodically tests each server marked as not responsive in the CDS cache, and updates the cache if the server is now responding.

The benefits of the lightweight configuration are:

• The person who configures the lightweight configuration does not require the cell administrator's account name and password.

• A lightweight client does not require entries in the CDS hosts directory, conserving CDS resources as well as expediting lookups and the replication process. This advantage becomes very significant in larger cells.

• A lightweight client does not require a registry entry for the machine/self principal, conserving space in the registry.

• The lightweight client configuration process does not make changes to the CDS namespace or the security registry, so it completes quickly.

• Because a lightweight client does not run daemon processes, it uses less local computing resources.

• Because a lightweight client avoids daemon startup overhead, the local machine comes up faster.

• Because daemons must register their bindings at startup, a lightweight client uses less local network resources.

Depending upon the requirements at your site, you may need to run a full client instead of a lightweight client:

• Lightweight client configurations do not generate machine and host self credential files, which are required by certain software programs (such as older versions of DFS). Check with your software vendor to determine if the software can run on a system configured as a lightweight client.

• A lightweight client configuration does not support third-party pre-authenticated logins, which may or may not be required depending on the security requirements at your site.

• A lightweight client configuration does not support certification of credentials. These may or may not be required depending on the security requirements at your site.

  NOTE: In all supported Windows operating systems except Windows 98, if endpoint mapping services are required in a lightweight client configuration (if you want to run local server applications), you can configure PC-DCE to use rpcss.exe. Section 1.2.3 on page 10 If you are running Windows 98, you cannot have a lightweight client configuration and endpoint mapping services

[Previous] [Next] [Contents] [Index]

To make comments or ask for help, contact support@entegrity.com.

Portions of this document were derived from materials provided by Compaq Computer Corporation. Copyright © 1998-2003 Compaq Computer Corporation.

Copyright © 2003 Entegrity Solutions Corporation & its subsidiaries.

All rights reserved.