Documentation\Technical\Architecture\Discovery Process
|
This document details the procedures used by the Domain Time II time synchronization components to discover each other and to
coordinate time server information.
Other products, such as the Management Tools and Audit Server use their own methods to
discover machines. Those processes are detailed in the documentation for each individual product.
Discovery Process Overview
These are the basic steps each component uses in the discovery process:
- Masters
Masters use TCP/IP with named sources to obtain their own time, but use the domain browse list's NetBIOS names
for automatic identification of Domain Slaves. However, the control panel allows you to specify Foreign
Slaves by IP address, DNS name, or NetBIOS name. (The NetBIOS name may be a domain name rather than
a machine name, in which case the Master will treat the PDC of the named domain as a Foreign Slave.) If
your network does not support the resolution of NetBIOS names to IP addresses, you may turn off automatic
discovery of Domain Slaves and specify all Slaves as Foreign instead. Alternately, you may use a
hosts or lmhosts file, WINS, or default domain name search settings with a properly functioning DNS.
- Slaves
Slaves use the browse list and File and Print Services (called Server Service on NT) capability
bit settings to identify Master servers. The browse list only supplies NetBIOS machine names, but Domain
Time II time and control information use TCP/IP. Therefore, each Slave must be able to resolve the
Master's NetBIOS name to an IP address, either through WINS, a hosts/lmhosts file, or default domain name
search settings and DNS.
If a Slave fails to communicate with its Master using TCP/IP, it will also try
Domain Time I mailslots against the Master's NetBIOS name. This will succeed as long as the Master
shares at least one network protocol with the Slave, and the Master is set to provide the Domain Time
I protocol. If Domain Time I fails, the Slave will try NetRemoteTOD (NET TIME) against the PDCs NetBIOS
name. Note that this will allow the Slave to get the time even if the PDC is not a Domain Time II Master.
This is not a recommended configuration, since accuracy will be significantly decreased, but it does
allow the Slave to continue functioning. Note also that a Slave that retrieves the time using any protocol
other than Domain Time II will not have access to the Master's settings, and thus will not be able to
provide configuration-free failover if promoted to PDC.
- Clients
Full Clients may either have specified servers or rely on auto-discovery to find servers. Auto-discovery
uses DHCP and Domain Time II queries first. If these fail, each Client will examine the browse list
to find domain controllers. The Client will then attempt to contact each domain controller found
using all available protocols, including Domain Time I (mailslots), which usually works without IP
resolution in place. Windows Clients can also use the NetRemoteTOD protocol (NET TIME) against
the domain controller's NetBIOS name. If the Client and domain controller share any network
protocols, then the Domain Time I or NetRemoteTOD attempt will usually succeed. Other protocols
rely on the ability to resolve NetBIOS names to IP addresses.
Thin Clients and domtimed daemons first use DHCP and then Domain Time II broadcast queries to locate a server.
The Ultra Thin Client is a listen-only client and cannot auto-discover a server.
Broadcasting and Subnets
Domain Time uses UDP broadcasts for some discovery options. You can control the
broadcast behavior by setting the Broadcast Addresses for subnets.
Domain Time II Server
- Master Role (see Cascading Time Hierarchy for details)
Masters do not use discovery to find time sources. They rely on the control panel settings
to find servers and protocols.
A Master relies on the built-in browse list to discover its slaves. Any Windows
machine that claims to be a time server will be considered a slave. When propagating a Level 1
cascade trigger to its slaves, the Master will enumerate time servers from the browse list
and direct a unicast trigger to each slave. Results (including whether or not the slave
acknowledged the trigger) are recorded in the domtimes.log file.
- Independent Server Role (see Cascading Time Hierarchy for details)
Independent Servers do not use discovery. They rely on the control panel settings to find
servers and protocols.
- Slave Role on a Domain Controller (DC) (see Cascading Time Hierarchy for details)
Slaves attempt to locate the Primary Domain Controller (PDC) by examining the browse list. If a PDC
is named, the slave will attempt to resolve the name to an IP address.
- If the PDCs IP address can be determined, the slave uses the Domain Time II and NTP protocols
against the PDCs IP address.
- If the PDCs name can be determined, but not its IP address, the slave uses the
Domain Time I protocol against the PDCs NetBIOS name.
- If neither the PDCs name nor its IP address can be determined, or if the PDC fails to
provide the time using Domain Time II, NTP, or Domain Time I protocols, the slave will try
each of the PDCs servers directly (using cached information to determine the servers and
protocols).
- If the PDCs servers fail to provide the time, the slave will attempt to locate a master
by broadcast query. Any responding master (including masters from another NT domain)
will be used.
- If no master responds to the broadcast query, and the PDCs NetBIOS name is known, the
slave will try to use the NetRemoteTOD (NET TIME) protocol against the PDC.
- Slave Role on a non-DC (see Cascading Time Hierarchy for details)
Non-DC slaves first try to get the time from a DC slave.
- If a DC's IP address can be determined, the slave uses the Domain Time II protocol
against the DC's IP address.
- If the DC's name can be determined, but not its IP address, the slave uses the
Domain Time I protocol against the DC's NetBIOS name.
- If the DC fails to provide the time, the non-DC slave follows the discovery procedure
for DC slaves.
Full Client
The Full Client has two modes of operation:
- Manual Configuration
The Full Client can be configured with specified servers and protocols (manual config), or it can be
set to discover servers automatically (auto-config). If servers are specified, the Full Client will
try each server and protocol in order. If server surveying and averaging is enabled, the Full Client
will check with all listed servers; otherwise, it stops searching after the first valid response. If
all specified servers fail, and the Use any available local server checkbox is checked, then
the Full Client will perform the same search as if it were set for auto-config.
- Automatic Configuration
The Domain Time II Full Client in auto-config mode relies on being able to
discover a server via broadcast. The Full Client follows these steps when checking the time, exiting
the search as soon as a server is found:
- Known-good server (known to be good because it has provided time to this client in the past),
using whatever protocol was last used with this server
- Any server that has sent a cascade trigger recently, using the Domain Time II protocol
- If DHCP is enabled, any server(s) listed in DHCP options 002 or 042, using
- The Domain Time II protocol
- NTP/SNTP
- TIME/ITP
- Broadcast for a slave, using the Domain Time II protocol
- Broadcast for a master, using the Domain Time II protocol
- Broadcast for an independent server, using the Domain Time II protocol
- The Client's logon server (if known), using all available protocols, including Domain Time I and NetRemoteTOD
- Any available DC (if known), using all available protocols, including Domain Time I and NetRemoteTOD
- The PDC (if known), using all available protocols, including Domain Time I and NetRemoteTOD
- Any Domain Time 2.x or 1.x server, using the Domain Time I protocol (mailslots broadcast)
Thin Client
The Domain Time II Thin Client only uses the Domain Time II protocol, and relies on being able to
discover a server via broadcast. The Thin Client follows these steps when checking the time, exiting
the search as soon as a server is found:
- Known-good server (known to be good because it has provided time to this client in the past),
using whatever protocol was last used with this server
- Any server that has sent a cascade trigger recently, using the Domain Time II protocol
- If DHCP is enabled, any server(s) listed in DHCP options 002 or 042, using the Domain Time II protocol
- Broadcast for a slave
- Broadcast for a master
- Broadcast for an independent server
Ultra Thin Client
The Domain Time II Ultra Thin Client is a broadcast listener only. It does not query servers or perform any
sort of discovery. It accepts either NTP or Domain Time II broadcasts and sets the time accordingly.
domtimed daemon
The domtimed daemon can be configured with specified servers and protocols (manual config), or it can be
set to discover servers automatically (AutoConfig). If servers are specified, the daemon will
try each server and protocol in order. When in AutoConfig mode, the daemon follows
these steps when checking the time, exiting the search as soon as a server is found:
- Known-good server (known to be good because it has provided time to this client in the past),
using whatever protocol was last used with this server
- Any server that has sent a cascade trigger recently, using the Domain Time II protocol
- If DHCP is enabled, any server(s) listed in DHCP options 002 or 042, using the Domain Time II protocol
- Broadcast for a slave
- Broadcast for a master
- Broadcast for an independent server
Some examples of Domain Time II broadcast discovery
- Discovery Broadcast for Domain Time II Slaves
An automatic Domain Time client will perform a local network broadcast on UDP port 9909 to locate a Domain Time II Server.
Note that UDP broadcasts sent to the local network usually do not cross routers.
Domain Time II servers respond via the Domain Time II protocol to inform the client they are available to serve time.
The client then contacts and syncs with the server.
- Server Discovery using DHCP
An automatic Domain Time client with DHCP enabled will broadcast to locate a DHCP Server. Note that DHCP broadcasts usually do not cross routers.
If DHCP options 004 or 042 are configured, the DHCP server will respond with the IP address of the time server.
The client then uses the IP address provided by the DHCP server to contact and sync with the designated time server, even across a router.
|