Documentation\Technical\Network\Time Protocols
|
A protocol is an agreed-upon way to exchange data. Domain Time II (the program)
uses many different protocols -- including Domain Time II (the protocol) -- to discover the
time of day when talking to other machines. Most of these protocols rely on
TCP/IP for their underlying transport connectivity.
Note that regardless of the accuracy of the underlying protocol, the operating system may
not be able to utilize the full precision when setting the time. For example,
Win95/Win98 machines can only set the time to the next-higher 55-millisecond interval
(an 1/18 of a second).
DT2 (UDP & TCP)
|
| Resolution: |
1 hectonanosecond |
| Accuracy: |
Less than 1 millisecond best-case, 1-10 milliseconds via Internet |
|
Port:
|
9909 UDP / 9909 TCP (registered with IANA as "domaintime")
|
| Dates: |
01 Jan 1900 through 31 Dec 21244 |
| Server: |
Supported |
| Client: |
Supported |
| Desc: |
DT2 is an open protocol used by version 2.x or above of
Domain Time II (both client and server). Its theoretical limit of accuracy is
one ten-tenth of a microsecond (0.0000001 seconds, also known as 1 hectonanosecond), but in practice
DT2 is limited to a best-case accuracy of 0.5 to 1 millisecond, like any
other network time protocol, due to asymmetries of network traffic.
Domain Time II typically achieves accuracies under 10 milliseconds regardless
of the distance between machines or type of connection.
In addition to supporting the communication of time among machines,
DT2 is a full-featured, extensible, multi-tiered specification
allowing control messages, statistics exchange, and multiple data formats.
Unlike NTP/SNTP, whose data format requires complex floating-point calculations with their attendant
rounding errors, the DT2 protocol allows implementations to
convert among useful time representations using only integer math.
|
DT2 over HTTP
|
| Resolution: |
1 hectonanosecond |
| Accuracy: |
1-100 milliseconds typical |
| Port: |
80 TCP (can use any port) |
| Dates: |
01 Jan 1900 through 31 Dec 21244 |
| Server: |
Supported |
| Client: |
Supported |
| Desc: |
A Domain Time II Server can be configured to answer on port 80, just like a web
server. If visited by a browser, the server will display a normal HTML page,
including the version of Domain Time II and the local time on the server. For an
example, you may visit tick.greyware.com.
The Domain Time II Server examines the request headers to determine if the request
is coming from a browser or a client machine trying to set its clock. If the request is
from a client, Domain Time II Server responds with a specially encoded set of headers and
abbreviated body that the client can use to calculate UTC. The server also provides packet
serialization and sequence numbers so the client can distinguish between timely responses and
cached information. If the server's own clock is not set, it will return an HTTP
"503 Not Synchronized" message to the client; otherwise it returns the standard "200 OK" message.
If the client does not have direct access to the server's port 80, the client may
be configured to use a regular web proxy server. Domain Time II Server uses expiry
headers and no-cache directives to keep the proxy server from caching the response;
however, Domain Time II has no control over proxy servers that are non-compliant. The
client examines the serialization information to ensure that the response came
directly from the Domain Time II server rather than the proxy's cache.
Domain Time II supports proxy authentication. If your
proxy server requires authentication, you may specify a username and password on the
proxy line: user:pass@proxyname
For example, if the proxy server is proxy1.mycompany.com, a valid
username is bubba with password gump, you would use bubba:gump@proxy1.mycompany.com
as the proxy server string.
You may also specify the proxy port number on the proxy string. If the parameter is
omitted, the default port used is 80.
Domain Time II supports SOCKS4 as well as regular web
proxies. If your connection to the Internet is through a SOCKS4 gateway/firewall,
then append /socks4 after
the proxy server name. Example: soxprox.mycompany.com/socks4.
The HTTP protocol has a high overhead, and the calculation's accuracy therefore suffers,
but DT2 over HTTP is about as accurate as NTP/SNTP across a WAN, and useful in
situations where access to ports other than 80 have been blocked by a firewall.
|
NTP/SNTP
|
| RFC: |
RFC 1769 RFC 2030 |
| Resolution: |
1 microsecond in practice, 200 picoseconds in theory |
| Accuracy: |
1-50 milliseconds on a LAN, 50-250 milliseconds via Internet
|
| Port: |
123 UDP |
| Dates: |
01 Jan 1970 through 31 Dec 2035 or beyond (implementation-dependent) |
| Server: |
Supported |
| Client: |
Supported |
| Desc: |
The (Simple) Network Time Protocol's theoretical accuracy is on the order
of a picoseconds, but this level of accuracy is far below the granularity of
all PC clocks and much laboratory test equipment. In practice is NTP is limited
a few milliseconds (thousandths of a second) in a symmetric multi-peer implementation.
SNTP, a simplified version of the full NTP specification suitable for
PC clocks set over the network, typically achieves accuracies of 1-250 milliseconds.
Domain Time is a fully-compliant SNTP server and client.
When acting as an SNTP server, Domain Time II represents itself as stratum 2 if
it is a master, stratum 3 if it is a slave, or stratum 4 if it is an independent
time server. Domain Time II sets the outbound ReferenceID field to GREY if
the time source was not another NTP server.
|
Domain Time I
|
| Resolution: |
1 millisecond |
Accuracy: |
1 millisecond best case, 10-50 milliseconds typical (only LANs supported)
|
| Port: |
N/A (uses mailslots; works with
TCP/IP, IPX/SPX, or NetBEUI, as long as the server and client are running at least one of the
same protocols)
|
| Dates: |
01 Jan 1900 through 31 Dec 21244 |
| Server: |
Supported |
| Client: |
Supported |
| Desc: |
Domain Time I is a proprietary protocol used by version 1.x of the Domain Time
Client to obtain the time from a Domain Time Server. Domain Time I uses
mailslots to deliver a host-byte-ordered representation of a Microsoft SYSTEMTIME
structure. The theoretical accuracy of this protocol is one millisecond.
A version 1.x Domain Time Client will attempt to discover the nearest BDC
and direct a mailslot query to that machine. If the BDC's name cannot be
determined, or if the targeted machine fails to respond (perhaps because it
is not running the Domain Time server program), the Domain Time Client resorts
to a broadcast query, and accepts the time from the first responding server.
Mailslot broadcasts do not cross IP subnets. The Domain Time I protocol
is supported by Domain Time 1x and Domain Time II Server version 2.x or above, but
is depreciated in favor of the Domain Time II protocol.
Domain Time I also supports the Domain Time Client for Windows for Workgroups.
In a special mode specifically for this client, the Domain Time I protocol provides the server's
local time instead of UTC/GMT. This is because Windows for Workgroups does
not support timezones and daylight savings time adjustments. Since the Domain Time
Client for Windows for Workgroups only works on the local segment, it is reasonable
to assume that the client machine's time zone and daylight savings settings should
match the local server's settings. Note that this particular combination -- Domain
Time Client for Windows for Workgroups using Domain Time I against a Domain Time II
server -- is the only time the server's time zone settings matter to a client. All
other protocol-client combinations use UTC/GMT.
|
LAN Manager
|
| Resolution: |
10-15 milliseconds |
| RFC: |
NetRemoteTOD |
| Accuracy: |
10 milliseconds best case, 100-500 milliseconds typical
|
| Port: |
N/A |
| Dates: |
01 Jan 1900 through 31 Dec 21244 |
| Server: |
Supported |
| Client: |
Supported on NT and Windows 2000 |
| Desc: |
NetRemoteTOD is a protocol built into Windows NT. The theoretical accuracy
is one hundredth of a second, but this protocol does not provide for measuring network
latency, so can be wildly off when used over a WAN or unreliable network.
The chief advantage of NetRemoteTOD is that is does not require TCP/IP; it will
operate over whatever transport is available, including NetBEUI, IPX/SPX,
and TCP/IP. If used with TCP/IP, NetBIOS over TCP/IP (NetBt) is required.
Version 1.x of Domain Time used NetRemoteTOD in conjunction with its own latency
measurements to coordinate the time among NT machines. The protocol is still
supported for backward compatibility and for those situations where no TCP/IP
connectivity is available between server and client. It is not otherwise used
by Domain Time II version 2.x or above.
|
TIME/ITP (UDP & TCP)
|
| RFC: |
RFC 868 |
| Resolution: |
1 second |
| Accuracy: |
0.5 seconds best case, 1.0-1.5 seconds typical |
| Port: |
37 TCP, 37 UDP |
| Dates: |
01 Jan 1970 through 31 Dec 2035 |
| Server: |
Supported |
| Client: |
Supported |
| Desc: |
Called either "Time Protocol" or "Internet Time Protocol" (and sometimes
also "RDATE" because of the rdate program that uses this protocol), TIME's
granularity is one second, so is useful primarily only when other protocols
are not available. Domain Time II supports both client and server sides for
TIME/ITP over both TCP and UDP.
|
Daytime
|
| RFC: |
RFC 867 |
| Resolution: |
unmeasurable |
| Accuracy: |
unmeasurable |
| Port: |
13 |
| Server: |
Not supported |
| Client: |
Not supported |
| Desc: |
Not used by Domain Time II server or client. This protocol relies on expressing
the time of day as a text string, without a format specification. This makes
Daytime useful for humans, but not for computers.
Note: Domain Time II Server
will serve time via the Daytime protocol, but no Domain Time II component
uses Daytime for time synchronization purposes. Domain Time II Server's Daytime string
format defaults to the NIST standard (see below), but may be customized to any format.
|
NIST Daytime Protocol
|
| Resolution: |
1 second; using estimation of lag time, 100-250 milliseconds are theoretically possible |
| Accuracy: |
100-250 milliseconds best case; 1-2 seconds typical |
| Port: |
13 |
| Server: |
Not supported |
| Client: |
Not supported |
| Desc: |
The NIST Daytime Protocol is not used by Domain Time II server or client. NIST Daytime
uses a variation of the Daytime protocol (see above) with a defined text string response
from the server. Although this overcomes the parsing problems of the standard Daytime
protocol, the NIST Daytime protocol is limited in accuracy to one second. Repeated testing
to estimate round-trip time, plus text parsing, can yield (undependably) sub-second accuracy.
Note: Most servers operated by NIST also provide the
time via NTP and TIME as well as NIST's version of Daytime. You may still use NIST as your
time source with the other, higher-accuracy, protocols.
|
|
