Overview of ATZ Time Protocols
This page contains information on the different Time Protocols Atomic Time Zone comes equiped with.
Atomic Time Zone is the only Software in the world that supports all 4 Major Time Protocols.
Daytime Protocol (RFC-867)
Daytime Protocol was developed in 1982/3 by John Postel. The protocol is widely used by computers running MS-DOS and similar operating systems. The server listens on port 13, and responds to requests in either tcp/ip or udp/ip formats. The standard does not specify an exact format for the Daytime Protocol, but requires that the time is sent using standard ASCII characters.
Atomic Time Zone is capable of using the 2 most widely used DayTime Protocol formats. The first is a simple date/time stamp, and the second is a more complex version developed by the NIST and outlined below. The below version of the Daytime Protocol was developed by NIST and called Automated Computer Time Service (ACTS), as shown below:
JJJJJ YR-MO-DA HH:MM:SS TT L H msADV UTC(NIST) OTM
where:
JJJJJ is the Modified Julian Date (MJD). The MJD is the last five digits of the Julian Date, which is simply a count of the number of days since January 1, 4713 B.C. To get the Julian Date, add 2.4 million to the MJD.
YR-MO-DA is the date. It shows the last two digits of the year, the month, and the current day of month.
HH:MM:SS is the time in hours, minutes, and seconds. The time is always sent as Coordinated Universal Time (UTC). An offset needs to be applied to UTC to obtain local time. For example, Mountain Time in the U. S. is 7 hours behind UTC during Standard Time, and 6 hours behind UTC during Daylight Saving Time.
TT is a two digit code (00 to 99) that indicates whether the United States is on Standard Time (ST) or Daylight Saving Time (DST). It also indicates when ST or DST is approaching. This code is set to 00 when ST is in effect, or to 50 when DST is in effect. During the month in which the time change actually occurs, this number will decrement every day until the change occurs. For example, during the month of October, the U.S. changes from DST to ST. On October 1, the number will change from 50 to the actual number of days until the time change. It will decrement by 1 every day until the change occurs at 2 a.m. local time when the value is 1. Likewise, the spring change is at 2 a.m. local time when the value reaches 51.
L is a one-digit code that indicates whether a leap second will be added or subtracted at midnight on the last day of the current month. If the code is 0, no leap second will occur this month. If the code is 1, a positive leap second will be added at the end of the month. This means that the last minute of the month will contain 61 seconds instead of 60. If the code is 2, a second will be deleted on the last day of the month. Leap seconds occur at a rate of about one per year. They are used to correct for irregularity in the earth's rotation. The correction is made just before midnight UTC (not local time).
H is a health digit that indicates the health of the server. If H=0, the server is healthly. If H=1, then the server is operating properly but its time may be in error by up to 5 seconds. This state should change to fully healthy within 10 minutes. If H=2, then the server is operating properly but its time is known to be wrong by more than 5 seconds. If H=4, then a hardware or software failure has occurred and the amount of the time error is unknown.
msADV displays the number of milliseconds that NIST advances the time code to partially compensate for network delays. The advance is currently set to 50.0 milliseconds.
The label UTC(NIST) or UTC(ATZS) is contained in every time code. It indicates that you are receiving Coordinated Universal Time (UTC) from the National Institute of Standards and Technology (NIST) or via an Atomic Time Zone Server.
OTM (on-time marker) is an asterisk (*). The time values sent by the time code refer to the arrival time of the OTM. In other words, if the time code says it is 12:45:45, this means it is 12:45:45 when the OTM arrives.
Time Protocol (RFC-868)
The Time Protocol was also developed in 1982/3, but by both John Postel and K. Harrenstien. The late John Postel is considered one of the founders of the internet.
This simple protocol returns a 32-bit unsigned binary number that represents the time in UTC seconds since January 1, 1900. The server listens for Time Protocol requests on port 37, and responds in either tcp/ip or udp/ip formats.
The 32-bit binary format can represent times over a span of about 136 years with a resolution of 1 second. There is no provision for increasing the resolution or increasing the range of years.
The strength of the time protocol is its simplicity. Since many computers keep time internally as the number of seconds since January 1, 1970 (or another date), converting the received time to the necessary format is often a simple matter of binary arithmetic. However, the format does not allow any additional information to be transmitted, such as advance notification of leap seconds or daylight saving time, or information about the health of the server.
Simple Network Time Protocol (RFC-2030)
Developed by David Mills of the University of Delaware and published in 1996. The SNTP protocol is the latest major time protocol released, and expands upon David Mills earlier Network Time Protocols. The "Simple" was added to Network Time Protocol because earlier versions had caused confusion, and because SNTP was expanded to include IPv6 internet address formatting. SNTP is version 4 of the (NTP) protocol.
The most advanced, and therefore most accurate of all the time protocols, SNTP is generally in use by all major Internet Time Servers, and also available from Atomic Time Zone Server.
SNTP contains exactly 48 Bytes of receipt data, and 48 Bytes of Transmit Data. This data contains several 64 Bit Time Stamps which contain time accurate to the millisecond.
SNTP and NTP Servers operate on port 123, and only respond to valid NTP Time requests.
UnixTime and UnixTime Protocol
Unix is an operating system developed in 1969 by Ken Thompson. UnixTime counts "epochs" or seconds since the Year 1970. UnixTime recently hit it's billionth birthday.
Because Unix is widely used in many environments, UnixTime was developed into a loose simple time protocol in the late 80's and early 90's. No formal UnixTime protocol has ever been officially published as an internet protocol - until now.
UnixTime operates on the same UnixTime port - 519. Once a connection is requested on this port, exactly like in Time Protocol, the UnixTime value is sent back by either tcp/ip or udp/ip. When UDP/IP is used, a small packet of data must be received by the server in order to respond in the exact same fashion as Time Protocol. The UnixTime is then sent as an unsigned "unformatted" integer on the same port.
Note: While the America Online Service does not provide Atomically correct time, its services do use the "UnixTime" time stamp format widely in it's messaging products in particular.
Atomic Time Zone Server - Client Protocol
First developed and published in 2002 as part of the ATZ Server Distribution, the ATZ Server Client protocol is used by ATZ Server and Server Clients to provide millisecond clock accuracy. Built from the groud up to provide FAST and efficient transfer of precise time information, ATZ Server Client Protocol - or - ATZP, is lightweight yet powerful. Designed to overcome the limitations of the SNTP (Simple Network Time Protocol) - the latest and most advanced time protocol, ATZ borrows some characteristics.
For example, one limitation of todays time protocols is the overflow of data space within 38 yrs. This is due to relying on a starting point of the year 1900. ATZP, thus, starts in the year 2002, and it's payload is exactly half the size of SNTP at 24 Bytes. ATZ Protocol is starting with a fresh 64-Bit data buffer starting in the year 2002, thus offering a payload of time data with more precision and one that can last at least another 138 yrs.
The ATZ Protocol uses the following payload and operates on port 3777 in TCP and UDP:
Bytes 1-4 = Ascii Character Codes for Server or Client Abreviation - Example: ATZS
Byte 5 = Ascii Character Code for Major Version of Client or Server Protocol - IE: 5
Bytes 6-8 = 3 Ascii Character Codes for Globally Recognized Time Zone - Example: UTC
Bytes 9-16 = 64 Bit Transmission TimeStamp for ATZ Client containing millisecond accuracy.
Bytes 17-24 = 64 Bit Transmission TimeStamp for ATZ Server containing millisecond accuracy.
A typical use of the ATZ Protocol is from Client to Server. The ATZ Protocol Client makes a request to the Server with 24 Bytes, 9-16 being the exact time in which the request was transmitted to the ATZ Server. The ATZ Server then receives the payload, verifies it, and Transmits the Server Time in the 17-24 Byte payload. When the client receives the payload, Latency, Processor time, and difference in the 2 64-bit timestamps are compared, and any millisecond time adjustments are made.
|
