Top of Page

 Documentation\Technical\Architecture\Discovery Process

One True Time

    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:

      1. 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
      2. Any server that has sent a cascade trigger recently, using the Domain Time II protocol
      3. If DHCP is enabled, any server(s) listed in DHCP options 002 or 042, using
        1. The Domain Time II protocol
        2. NTP/SNTP
        3. TIME/ITP
      4. Broadcast for a slave, using the Domain Time II protocol
      5. Broadcast for a master, using the Domain Time II protocol
      6. Broadcast for an independent server, using the Domain Time II protocol
      7. The Client's logon server (if known), using all available protocols, including Domain Time I and NetRemoteTOD
      8. Any available DC (if known), using all available protocols, including Domain Time I and NetRemoteTOD
      9. The PDC (if known), using all available protocols, including Domain Time I and NetRemoteTOD
      10. 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:

    1. 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
    2. Any server that has sent a cascade trigger recently, using the Domain Time II protocol
    3. If DHCP is enabled, any server(s) listed in DHCP options 002 or 042, using the Domain Time II protocol
    4. Broadcast for a slave
    5. Broadcast for a master
    6. 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:

    1. 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
    2. Any server that has sent a cascade trigger recently, using the Domain Time II protocol
    3. If DHCP is enabled, any server(s) listed in DHCP options 002 or 042, using the Domain Time II protocol
    4. Broadcast for a slave
    5. Broadcast for a master
    6. 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.

      Client sends UDP broadcast to discover servers

      Domain Time II servers respond via the Domain Time II protocol to inform the client they are available to serve time.

      Domain Time II Servers respond via Domain Time II protocol

      The client then contacts and syncs with the server.

      The client synchronizes with the server it found

       

    • 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.

      DHCP Broadcast - Discover DHCP Server and Request Timeserver Address

      If DHCP options 004 or 042 are configured, the DHCP server will respond with the IP address of the time server.

      DHCP Server responds with 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.

      The client uses the IP address to sync with the time server

Domain Time II Software distributed by Microsemi, Inc.
Documentation copyright © 1995-2024 Greyware Automation Products, Inc.
All Rights Reserved
All Trademarks mentioned are the properties of their respective owners.