Partager via

3.1.1 Abstract Data Model

  • Article

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The organization is provided to explain how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.

Because the DFS clients effectively block an application from accessing a specific file share until the DFS: Referral Protocol can map the DFS root name to an actual file server path, it is advantageous to cache DFS referral responses. Because of this, clients SHOULD maintain local caches of information received through referral requests to avoid future referral requests and to improve the performance of DFS resource access.

  • BootstrapDC: Applicable only for a computer joined to a domain. This contains the name of a DC from which the DFS client will obtain a list of domain referral entries, in addition to a list of DC host names for a domain.

  • DomainCache: Applicable only for a computer joined to a domain. This cache contains a list of trusted domains in both NetBIOS and fully qualified domain name forms, in addition to a list of DC host names for each domain. Conceptually, this is an array of tuples of the form <DomainName, DCHint, DCList>. Cache lookup involves finding a DomainCache entry with a matching DomainName. This can be used to check for a valid domain name or to find a DC host name for a given domain name. DCHint identifies a DC host name from DCList that is the DC that was last successfully used by the DFS client.

  • ReferralCache: This cache contains root, link, and sysvol referral responses. A hit on a ReferralCache entry indicates that the path in a name resolution operation is a DFS Root, DFS link, or a SYSVOL/NETLOGON share.

    A ReferralCache entry conceptually contains entries indexed by a DFS path prefix, DFSPathPrefix. An entry is a tuple of the form <DFSPathPrefix, RootOrLink, Interlink, TTL, TargetFailback, TargetHint, TargetList>.

    DFSPathPrefix is the DFS path that corresponds to a DFS root or a DFS link, and is the same as the string pointed to by the DFSPathOffset of a DFS_REFERRAL_V2, DFS_REFERRAL_V3 or DFS_REFERRAL_V4 referral entry.

    RootOrLink identifies whether the entry contains DFS root targets or DFS link targets. It reflects the value from the ServerType field of a referral entry (as specified in sections 2.2.5.1, 2.2.5.2, 2.2.5.3, and 2.2.5.4).

    Interlink identifies whether the entry contains a target in another DFS namespace, as determined by the test in section 3.1.5.4.5.

    TargetFailback is used only for DFS_REFERRAL_V4 and contains the value from the TargetFailback bit of the referral header (as specified in section 2.2.4).

    TTL contains a value derived from the TimeToLive field of a referral entry (as specified in sections 2.2.5.1, 2.2.5.2, 2.2.5.3, and 2.2.5.4). This is the time stamp at which a ReferralCache entry is considered to be expired. An implementation is free to come up with soft and hard time-outs based on the TimeToLive field of the referral entry, for example. The soft time-out can be used to initiate a ReferralCache entry refresh operation while permitting the use of the ReferralCache entry; the hard time-out limit can be used to fail any operation using the ReferralCache entry if all attempts to refresh it fail.<4>

    TargetHint identifies a target in TargetList that was last successfully used by the DFS client. TargetList consists of tuples of the form <TargetPath, TargetSetBoundary>, where TargetPath is the string pointed to by the NetworkAddressOffset field (as specified in sections 2.2.5.2, 2.2.5.3, and 2.2.5.4). TargetSetBoundary is only present in V4 referrals and reflects the value from the TargetSetBoundary of the referral entry (as specified in section 2.2.5.4).