imacat/vsntp
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Initial commit.

Browse Source
This commit is contained in:
依瑪貓
2021-02-06 08:59:23 +08:00
commit 3d641859e1
32 changed files with 4544 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
doc/Makefile.am Normal file
View File

@ -0,0 +1,25 @@
## Makefile.in template file for vsntp documentation
## Process this file with automake to produce Makefile.in
##
## Copyright (c) 2007 imacat
##
## This program is free software: you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation, either version 3 of the License, or
## (at your option) any later version.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with this program. If not, see <http://www.gnu.org/licenses/>.
AUTOMAKE_OPTIONS = gnits
info_TEXINFOS = vsntp.texi
man8_MANS = vsntp.8
dist_man8_MANS = $(man8_MANS)
EXTRA_DIST = rfc1769.txt

787
doc/rfc1769.txt Normal file
View File

@ -0,0 +1,787 @@
Network Working Group D. Mills
Request for Comments: 1769 University of Delaware
Obsoletes: 1361 March 1995
Category: Informational
Simple Network Time Protocol (SNTP)
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This memorandum describes the Simple Network Time Protocol (SNTP),
which is an adaptation of the Network Time Protocol (NTP) used to
synchronize computer clocks in the Internet. SNTP can be used when
the ultimate performance of the full NTP implementation described in
RFC-1305 is not needed or justified. It can operate in both unicast
modes (point to point) and broadcast modes (point to multipoint). It
can also operate in IP multicast mode where this service is
available. SNTP involves no change to the current or previous NTP
specification versions or known implementations, but rather a
clarification of certain design features of NTP which allow operation
in a simple, stateless remote-procedure call (RPC) mode with accuracy
and reliability expectations similar to the UDP/TIME protocol
described in RFC-868.
This memorandum obsoletes RFC-1361 of the same title. Its purpose is
to explain the protocol model for operation in broadcast mode, to
provide additional clarification in some places and to correct a few
typographical errors. A working knowledge of the NTP Version 3
specification RFC-1305 is not required for an implementation of SNTP.
Distribution of this memorandum is unlimited.
1. Introduction
The Network Time Protocol (NTP) specified in RFC-1305 [MIL92] is used
to synchronize computer clocks in the global Internet. It provides
comprehensive mechanisms to access national time and frequency
dissemination services, organize the time-synchronization subnet and
adjust the local clock in each participating subnet peer. In most
places of the Internet of today, NTP provides accuracies of 1-50 ms,
depending on the characteristics of the synchronization source and
network paths.
Mills [Page 1]
RFC 1769 SNTP March 1995
RFC-1305 specifies the NTP protocol machine in terms of events,
states, transition functions and actions and, in addition, optional
algorithms to improve the timekeeping quality and mitigate among
several, possibly faulty, synchronization sources. To achieve
accuracies in the low milliseconds over paths spanning major portions
of the Internet of today, these intricate algorithms, or their
functional equivalents, are necessary. However, in many cases
accuracies of this order are not required and something less, perhaps
in the order of large fractions of the second, is sufficient. In such
cases simpler protocols such as the Time Protocol [POS83], have been
used for this purpose. These protocols usually involve an RPC
exchange where the client requests the time of day and the server
returns it in seconds past some known reference epoch.
NTP is designed for use by clients and servers with a wide range of
capabilities and over a wide range of network delays and jitter
characteristics. Most users of the Internet NTP synchronization
subnet of today use a software package including the full suite of
NTP options and algorithms, which are relatively complex, real-time
applications. While the software has been ported to a wide variety of
hardware platforms ranging from supercomputers to personal computers,
its sheer size and complexity is not appropriate for many
applications. Accordingly, it is useful to explore alternative access
strategies using far simpler software appropriate for less stringent
accuracy expectations.
This memorandum describes the Simple Network Time Protocol (SNTP),
which is a simplified access strategy for servers and clients using
NTP as now specified and deployed in the Internet. There are no
changes to the protocol or implementations now running or likely to
be implemented in the near future. The access paradigm is identical
to the UDP/TIME Protocol and, in fact, it should be easily possible
to adapt a UDP/TIME client implementation, say for a personal
computer, to operate using SNTP. Moreover, SNTP is also designed to
operate in a dedicated server configuration including an integrated
radio clock. With careful design and control of the various latencies
in the system, which is practical in a dedicated design, it is
possible to deliver time accurate to the order of microseconds.
It is strongly recommended that SNTP be used only at the extremities
of the synchronization subnet. SNTP clients should operate only at
the leaves (highest stratum) of the subnet and in configurations
where no NTP or SNTP client is dependent on another SNTP client for
synchronization. SNTP servers should operate only at the root
(stratum 1) of the subnet and then only in configurations where no
other source of synchronization other than a reliable radio clock is
available. The full degree of reliability ordinarily expected of
primary servers is possible only using the redundant sources, diverse
Mills [Page 2]
RFC 1769 SNTP March 1995
subnet paths and crafted algorithms of a full NTP implementation.
This extends to the primary source of synchronization itself in the
form of multiple radio clocks and backup paths to other primary
servers should the radio clock fail or deliver incorrect time.
Therefore, the use of SNTP rather than NTP in primary servers should
be carefully considered.
2. Operating Modes and Addressing
Like NTP, SNTP can operate in either unicast (point to point) or
broadcast (point to multipoint) modes. A unicast client sends a
request to a server and expects a reply from which it can determine
the time and, optionally, the roundtrip delay and local clock offset
relative to the server. A broadcast server periodically sends a
message to a designated IP broadcast address or IP multicast group
address and ordinarily expects no requests from clients, while a
broadcast client listens on this address and ordinarily sends no
requests to servers. Some broadcast servers may elect to respond to
client requests as well as send unsolicited broadcast messages, while
some broadcast clients may elect to send requests only in order to
determine the network propagation delay between the server and
client.
In unicast mode the client and server IP addresses are assigned
following the usual conventions. In broadcast mode the server uses a
designated IP broadcast address or IP multicast group address,
together with a designated media-access broadcast address, and the
client listens on these addresses. For this purpose, an IP broadcast
address has scope limited to a single IP subnet, since routers do not
propagate IP broadcast datagrams. In the case of Ethernets, for
example, the Ethernet media-access broadcast address (all ones) is
used with an IP address consisting of the IP subnet number in the net
field and all ones in the host field.
On the other hand, an IP multicast group address has scope extending
to potentially the entire Internet. The actual scope, group
membership and routing are determined by the Internet Group
Management Protocol (IGMP) [DEE89] and various routing protocols,
which are beyond the scope of this document. In the case of
Ethernets, for example, the Ethernet media-access broadcast address
(all ones) is used with the assigned IP multicast group address of
224.0.1.1. Other than the IP addressing conventions and IGMP, there
is no difference in server operations with either the IP broadcast
address or IP multicast group address.
Broadcast clients listen on the designated media-access broadcast
address, such as all ones in the case of Ethernets. In the case of IP
broadcast addresses, no further provisions are necessary. In the case
Mills [Page 3]
RFC 1769 SNTP March 1995
of IP multicast group addresses, the host may need to implement IGMP
in order that the local router intercepts messages to the 224.0.1.1
multicast group. These considerations are beyond the scope of this
document.
In the case of SNTP as specified herein, there is a very real
vulnerability that SNTP multicast clients can be disrupted by
misbehaving or hostile SNTP or NTP multicast servers elsewhere in the
Internet, since at present all such servers use the same IP multicast
group address 224.0.1.1. Where necessary, access control based on the
server source address can be used to select only those servers known
to and trusted by the client. Alternatively, by convention and
informal agreement, all NTP multicast servers now include an MD5-
encrypted message digest in every message, so that clients can
determine if the message is authentic and not modified in transit. It
is in principle possible that SNTP clients could implement the
necessary encryption and key-distribution schemes, but this is
considered not likely in the simple systems for which SNTP is
intended.
While not integral to the SNTP specification, it is intended that IP
broadcast addresses will be used primarily in IP subnets and LAN
segments including a fully functional NTP server with a number of
SNTP clients in the same subnet, while IP multicast group addresses
will be used only in special cases engineered for the purpose. In
particular, IP multicast group addresses should be used in SNTP
servers only if the server implements the NTP authentication scheme
described in RFC-1305, including support for the MD5 message-digest
algorithm.
3. NTP Timestamp Format
SNTP uses the standard NTP timestamp format described in RFC-1305 and
previous versions of that document. In conformance with standard
Internet practice, NTP data are specified as integer or fixed-point
quantities, with bits numbered in big-endian fashion from 0 starting
at the left, or high-order, position. Unless specified otherwise, all
quantities are unsigned and may occupy the full field width with an
implied 0 preceding bit 0.
Since NTP timestamps are cherished data and, in fact, represent the
main product of the protocol, a special timestamp format has been
established. NTP timestamps are represented as a 64-bit unsigned
fixed-point number, in seconds relative to 0h on 1 January 1900. The
integer part is in the first 32 bits and the fraction part in the
last 32 bits. In the fraction part, the non-significant low-order
bits should be set to 0. This format allows convenient multiple-
precision arithmetic and conversion to UDP/TIME representation
Mills [Page 4]
RFC 1769 SNTP March 1995
(seconds), but does complicate the conversion to ICMP Timestamp
message representation (milliseconds). The precision of this
representation is about 200 picoseconds, which should be adequate for
even the most exotic requirements.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Fraction (0-padded) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that, since some time in 1968 the most significant bit (bit 0 of
the integer part) has been set and that the 64-bit field will
overflow some time in 2036. Should NTP or SNTP be in use in 2036,
some external means will be necessary to qualify time relative to
1900 and time relative to 2036 (and other multiples of 136 years).
Timestamped data requiring such qualification will be so precious
that appropriate means should be readily available. There will exist
a 200-picosecond interval, henceforth ignored, every 136 years when
the 64-bit field will be 0, which by convention is interpreted as an
invalid or unavailable timestamp.
4. NTP Message Format
Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
[POS80], which itself is a client of the Internet Protocol (IP)
[DAR81]. The structure of the IP and UDP headers is described in the
cited specification documents and will not be described further here.
The UDP port number assigned to NTP is 123, which should be used in
both the Source Port and Destination Port fields in the UDP header.
The remaining UDP header fields should be set as described in the
specification.
Mills [Page 5]
RFC 1769 SNTP March 1995
Following is a description of the SNTP message format, which follows
the IP and UDP headers. The SNTP message format is identical to the
NTP format described in RFC-1305, with the exception that some of the
data fields are "canned," that is, initialized to pre-specified
values. The format of the NTP message is shown below.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reference Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Originate Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receive Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transmit Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Authenticator (optional) (96) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As described in the next section, in SNTP most of these fields are
initialized with pre-specified data. For completeness, the function
of each field is briefly summarized below.
Mills [Page 6]
RFC 1769 SNTP March 1995
Leap Indicator (LI): This is a two-bit code warning of an impending
leap second to be inserted/deleted in the last minute of the current
day, with bit 0 and bit 1, respectively, coded as follows:
LI Value Meaning
-------------------------------------------------------
00 0 no warning
01 1 last minute has 61 seconds
10 2 last minute has 59 seconds)
11 3 alarm condition (clock not synchronized)
Version Number (VN): This is a three-bit integer indicating the NTP
version number, currently 3.
Mode: This is a three-bit integer indicating the mode, with values
defined as follows:
Mode Meaning
------------------------------------
0 reserved
1 symmetric active
2 symmetric passive
3 client
4 server
5 broadcast
6 reserved for NTP control message
7 reserved for private use
In unicast mode the client sets this field to 3 (client) in the
request and the server sets it to 4 (server) in the reply. In
broadcast mode the server sets this field to 5 (broadcast).
Stratum: This is a eight-bit unsigned integer indicating the stratum
level of the local clock, with values defined as follows:
Stratum Meaning
----------------------------------------------
0 unspecified or unavailable
1 primary reference (e.g., radio clock)
2-15 secondary reference (via NTP or SNTP)
16-255 reserved
Poll Interval: This is an eight-bit signed integer indicating the
maximum interval between successive messages, in seconds to the
nearest power of two. The values that can appear in this field
presently range from 4 (16 s) to 14 (16284 s); however, most
applications use only the sub-range 6 (64 s) to 10 (1024 s).
Mills [Page 7]
RFC 1769 SNTP March 1995
Precision: This is an eight-bit signed integer indicating the
precision of the local clock, in seconds to the nearest power of two.
The values that normally appear in this field range from -6 for
mains-frequency clocks to -20 for microsecond clocks found in some
workstations.
Root Delay: This is a 32-bit signed fixed-point number indicating the
total roundtrip delay to the primary reference source, in seconds
with fraction point between bits 15 and 16. Note that this variable
can take on both positive and negative values, depending on the
relative time and frequency offsets. The values that normally appear
in this field range from negative values of a few milliseconds to
positive values of several hundred milliseconds.
Root Dispersion: This is a 32-bit unsigned fixed-point number
indicating the nominal error relative to the primary reference
source, in seconds with fraction point between bits 15 and 16. The
values that normally appear in this field range from 0 to several
hundred milliseconds.
Reference Clock Identifier: This is a 32-bit code identifying the
particular reference source. In the case of stratum 0 (unspecified)
or stratum 1 (primary reference), this is a four-octet, left-
justified, 0-padded ASCII string. While not enumerated as part of the
NTP specification, the following are representative ASCII
identifiers:
Stratum Code Meaning
----------------------------------------------------------------
1 pps precision calibrated source, such as ATOM (atomic
clock), PPS (precision pulse-per-second source),
etc.
1 service generic time service other than NTP, such as ACTS
(Automated Computer Time Service), TIME (UDP/Time
Protocol), TSP (Unix Time Service Protocol), DTSS
(Digital Time Synchronization Service), etc.
1 radio Generic radio service, with callsigns such as CHU,
DCF77, MSF, TDF, WWV, WWVB, WWVH, etc.
1 nav radionavigation system, such as OMEG (OMEGA), LORC
(LORAN-C), etc.
1 satellite generic satellite service, such as GOES
(Geostationary Orbit Environment Satellite, GPS
(Global Positioning Service), etc.
2 address secondary reference (four-octet Internet address of
the NTP server)
Mills [Page 8]
RFC 1769 SNTP March 1995
Reference Timestamp: This is the time at which the local clock was
last set or corrected, in 64-bit timestamp format.
Originate Timestamp: This is the time at which the request departed
the client for the server, in 64-bit timestamp format.
Receive Timestamp: This is the time at which the request arrived at
the server, in 64-bit timestamp format.
Transmit Timestamp: This is the time at which the reply departed the
server for the client, in 64-bit timestamp format.
Authenticator (optional): When the NTP authentication mechanism is
implemented, this contains the authenticator information defined in
Appendix C of RFC-1305. In SNTP this field is ignored for incoming
messages and is not generated for outgoing messages.
5. SNTP Client Operations
The model for n SNTP client operating with either a NTP or SNTP
server is a RPC client with no persistent state. In unicast mode, the
client sends a client request (mode 3) to the server and expects a
server reply (mode 4). In broadcast mode, the client sends no request
and waits for a broadcast message (mode 5) from one or more servers,
depending on configuration. Unicast client and broadcast server
messages are normally sent at periods from 64 s to 1024 s, depending
on the client and server configurations.
A unicast client initializes the SNTP message header, sends the
message to the server and strips the time of day from the reply. For
this purpose all of the message-header fields shown above are set to
0, except the first octet. In this octet the LI field is set to 0 (no
warning) and the Mode field is set to 3 (client). The VN field must
agree with the software version of the NTP or SNTP server; however,
NTP Version 3 (RFC-1305) servers will also accept Version 2 (RFC-
1119) and Version 1 (RFC-1059) messages, while NTP Version 2 servers
will also accept NTP Version 1 messages. Version 0 (RFC-959) messages
are no longer supported. Since there are NTP servers of all three
versions interoperating in the Internet of today, it is recommended
that the VN field be set to 1.
In both unicast and broadcast modes, the unicast server reply or
broadcast message includes all the fields described above; however,
in SNTP only the Transmit Timestamp has explicit meaning and then
only if nonzero. The integer part of this field contains the server
time of day in the same format as the UDP/TIME Protocol [POS83].
While the fraction part of this field will usually be valid, the
accuracy achieved with SNTP may justify its use only to a significant
Mills [Page 9]
RFC 1769 SNTP March 1995
fraction of a second. If the Transmit Timestamp field is 0, the
message should be disregarded.
In broadcast mode, a client has no additional information to
calculate the propagation delay between the server and client, as the
Transmit Timestamp and Receive Timestamp fields have no meaning in
this mode. Even in unicast mode, most clients will probably elect to
ignore the Originate Timestamp and Receive Timestamp fields anyway.
However, in unicast mode a simple calculation can be used to provide
the roundtrip delay d and local clock offset t relative to the
server, generally to within a few tens of milliseconds. To do this,
the client sets the Originate Timestamp in the request to the time of
day according to its local clock converted to NTP timestamp format.
When the reply is received, the client determines a Destination
Timestamp as the time of arrival according to its local clock
converted to NTP timestamp format. The following table summarizes the
four timestamps.
Timestamp Name ID When Generated
------------------------------------------------------------
Originate Timestamp T1 time request sent by client
Receive Timestamp T2 time request received at server
Transmit Timestamp T3 time reply sent by server
Destination Timestamp T4 time reply received at client
The roundtrip delay d and local clock offset t are defined as
d = (T4 - T1) - (T2 - T3)
t = ((T2 - T1) + (T3 - T4)) / 2.
The following table is a summary of the SNTP client operations. There
are two recommended error checks shown in the table. In all NTP
versions, if the LI field is 3, or the Stratum field is not in the
range 1-15, or the Transmit Timestamp is 0, the server has never
synchronized or not synchronized to a valid timing source within the
last 24 hours. At the client discretion, the values of the remaining
fields can be checked as well. Whether to believe the transmit
timestamp or not in case one or more of these fields appears invalid
is at the discretion of the implementation.
Mills [Page 10]
RFC 1769 SNTP March 1995
Field Name Request Reply
-------------------------------------------------------------
LI 0 leap indicator; if 3
(unsynchronized), disregard
message
VN 1 (see text) ignore
Mode 3 (client) ignore
Stratum 0 ignore
Poll 0 ignore
Precision 0 ignore
Root Delay 0 ignore
Root Dispersion 0 ignore
Reference Identifier 0 ignore
Reference Timestamp 0 ignore
Originate Timestamp 0 (see text) ignore (see text)
Receive Timestamp 0 ignore (see text)
Transmit Timestamp 0 time of day; if 0
(unsynchronized), disregard
message
Authenticator (not used) ignore
6. SNTP Server Operations
The model for a SNTP server operating with either a NTP or SNTP
client is an RPC server with no persistent state. Since a SNTP server
ordinarily does not implement the full set of NTP algorithms intended
to support redundant peers and diverse network paths, it is
recommended that a SNTP server be operated only in conjunction with a
source of external synchronization, such as a reliable radio clock.
In this case the server always operates at stratum 1.
A server can operate in unicast mode, broadcast mode or both at the
same time. In unicast mode the server receives a request message,
modifies certain fields in the NTP or SNTP header, and returns the
message to the sender, possibly using the same message buffer as the
request. The server may or may not respond if not synchronized to a
correctly operating radio clock, but the preferred option is to
respond, since this allows reachability to be determined regardless
of synchronization state. In unicast mode, the VN and Poll fields of
the request are copied intact to the reply. If the Mode field of the
request is 3 (client), it is set to 4 (server) in the reply;
otherwise, this field is set to 2 (symmetric passive) in order to
conform to the NTP specification.
In broadcast mode, the server sends messages only if synchronized to
a correctly operating reference clock. In this mode, the VN field is
set to 3 (for the current SNTP version), and the Mode field to 5
(broadcast). The Poll field is set to the server poll interval, in
Mills [Page 11]
RFC 1769 SNTP March 1995
seconds to the nearest power of two. It is highly desirable that, if
a server supports broadcast mode, it also supports unicast mode. This
is necessary so a potential broadcast client can calculate the
propagation delay using client/server messages prior to regular
operation using only broadcast messages.
The remaining fields are set in the same way in both unicast and
broadcast modes. Assuming the server is synchronized to a radio clock
or other primary reference source and operating correctly, the
Stratum field is set to 1 (primary server) and the LI field is set to
0; if not, the Stratum field is set to 0 and the LI field is set to
3. The Precision field is set to reflect the maximum reading error of
the local clock. For all practical cases it is computed as the
negative of the number of significant bits to the right of the
decimal point in the NTP timestamp format. The Root Delay and Root
Dispersion fields are set to 0 for a primary server; optionally, the
Root Dispersion field can be set to a value corresponding to the
maximum expected error of the radio clock itself. The Reference
Identifier is set to designate the primary reference source, as
indicated in the table above.
The timestamp fields are set as follows. If the server is
unsynchronized or first coming up, all timestamp fields are set to
zero. If synchronized, the Reference Timestamp is set to the time the
last update was received from the radio clock or, if unavailable, to
the time of day when the message is sent. The Receive Timestamp and
Transmit Timestamp fields are set to the time of day when the message
is sent. In unicast mode, the Originate Timestamp field is copied
unchanged from the Transmit Timestamp field of the request. It is
important that this field be copied intact, as a NTP client uses it
to check for replays. In broadcast mode, this field is set to the
time of day when the message is sent. The following table summarizes
these actions.
Mills [Page 12]
RFC 1769 SNTP March 1995
Field Name Request Reply
----------------------------------------------------------
LI ignore 0 (normal), 3
(unsynchronized)
VN 1, 2 or 3 3 or copied from request
Mode 3 (see text) 2, 4 or 5 (see text)
Stratum ignore 1 server stratum
Poll ignore copied from request
Precision ignore server precision
Root Delay ignore 0
Root Dispersion ignore 0 (see text)
Reference Identifier ignore source identifier
Reference Timestamp ignore 0 or time of day
Originate Timestamp ignore 0 or time of day or copied
from Transmit Timestamp of
request
Receive Timestamp ignore 0 or time of day
Transmit Timestamp (see text) 0 or time of day
Authenticator ignore (not used)
There is some latitude on the part of most clients to forgive invalid
timestamps, such as might occur when first coming up or during
periods when the primary reference source is inoperative. The most
important indicator of an unhealthy server is the LI field, in which
a value of 3 indicates an unsynchronized condition. When this value
is displayed, clients should discard the server message, regardless
of the contents of other fields.
7. References
[DAR81] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, DARPA, September 1981.
[DEE89] Deering, S., "Host Extensions for IP Multicasting. STD 5,
RFC 1112, Stanford University, August 1989.
[MIL92] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis. RFC 1305, University of Delaware,
March 1992.
[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[POS83] Postel, J., and K. Harrenstien, "Time Protocol", STD 26,
RFC 868, USC/Information Sciences Institute, SRI, May 1983.
Mills [Page 13]
RFC 1769 SNTP March 1995
Security Considerations
Security issues are not discussed in this memo.
Author's Address
David L. Mills
Electrical Engineering Department
University of Delaware
Newark, DE 19716
Phone: (302) 831-8247
EMail: mills@udel.edu
Mills [Page 14]

219
doc/vsntp.8 Normal file
View File

@ -0,0 +1,219 @@
.\" Process this file with
.\" groff -man -Tascii vsntp.8
.\"
.TH VSNTP 8 "MARCH 2007" VSNTP "System Administration Tools"
.SH NAME
vsntp \- SNTP client for Virtual PC
.SH SYNOPSIS
.BI "vsntp [-i " n "] [-p " file "] [-a|-s] " server
.SH DESCRIPTION
.B vsntp
is an
.SM SNTP
client daemon for machines without a sane system time. The word
.B vsntp
stands for
.BR "SNTP for Virtual PC" .
It was originally designed for my
.I GNU/Linux
server running on Connectix Virtual PC. It runs according to
.SM RFC
1769
.SM SNTP
, connecting the
.SM NTP
server on
.SM UDP
port 123. It has only been compiled and run on
.I GNU/Linux
before.
Without "Virtual
.SM PC
Additions", the system time on Virtual
.SM PC
is completely insane. It's
.SM RTC
(Real Time Clock, or
.SM CMOS
time, or hardware clock) is software emulated, which does not seems
to be running. The
.I GNU/Linux
kernel hardly maintains a system time itself. With smooth run it
goes 4 seconds ahead per minute, which is nearly 1.5 hours per day.
That is insane. You can even tell it with your eyes.
David L. Mills'
.B ntp
does not work here. It uses a method that learns the clock frequency
drift first, and adjust the kerenl clock with
.B adjtimex()
so that time adjustment goes smoothly, from the point of view of
system and applications. This assumes an existing fix-speed system
clock. But this is not the case here. The system clock on Virtual
.SM PC
is software emulated. It goes faster or slower now and then,
depending on the load of the hosting machine. There is no fixed
clock speed. The frequency drift does not exist, then. It dooms to
fail to measure it.
There is an
.B sntp
client that comes with David L. Mills'
.B ntp
package.
It is suggested to be run from crontab. But crontab runs by minutes,
and Virtual
.SM PC
goes 4 seconds ahead per minute. Rolling back 4 seconds every minute
is insane for most applications. It also increases system load
heavily to run one instance per minute.
.B vsntp
is a workaround on this. It runs as a daemon to to eliminates the
additional system load on every synchronization. It uses
.B settimeofday()
to synchronize the time. It synchronizes the
time with an arbitrary interval, so that time can be accurate within
a second.
There are some defects. Synchronizing the time too often introduces
heavy network load. It introduces heavy load on the target
.SM NTP
server, too. You should have a working
.SM NTP
server nearby that is owned by you. Also, since
.B settimeofday()
is called so often, highly-accurate time operations like timer, etc.,
may not run correctly.
.B vsntp
uses
.BI sleep()
as the synchronization scheduler. Reports show that on some systems
.BI sleep()
may not function normally. If you find
.BI vsntp
stops synchronization after running for some time, that the
.BI sleep()
is not functioning normally on your system, you may want to switch
to the
.BI alarm()
scheduler with the
.B -a
switch.
.B vsntp
was originally written for
.I GNU/Linux .
It uses
.SM POSIX
compatible system calls. It should work on any
.SM POSIX
compatible system. But I have yet only tested it on Cygwin. Cygwin
is known to work. I don't have others to test and run on. Please let
me know (and submit the patch if needed) if you can port it to other
systems. I know it does not work on MSWin32, for the way it handles
the
.SM PID
file path.
Please tell me if you have successfully running vsntp on other virtual
machines, like
.BR "VMWare" .
Generally, please tell me if you are using
.B "vsntp" .
I would like to know that I am really doing some good for the world,
*^_^* but not having fun myself. :p
This is my first daemon, my first socket program and my first
public-released C program. Any comment or suggestion is welcome. ^_*'
.SH OPTIONS
.IP "-i,--interval n"
Set the synchronization interval to
.I n
seconds. Default is 900 seconds (15 minutes).
.IP "-p,--pidfile file"
The
.SM PID
file location. Default to
.IR /var/run/vsntp.pid .
.IP -s,--sleep
Use
.BI sleep()
as the scheduler. This is currently the default.
.IP -a,--alarm
Use
.BI alarm()
as the scheduler.
.IP -h,--help
Display the help message.
.IP -v,--version
Display version information.
.SH FILES
.I /var/run/vsntp.pid
.RS
The
.SM PID
of the running daemon.
.SH DIAGNOSTICS
If you ever encounter any problem, you may check your syslog.
.B vsntp
logs detailed debugging information to syslog in log level
.B LOG_DEBUG
with facility
.B LOG_DAEMON .
You may turn it on in your
.I /etc/syslog.conf
with the following line:
daemon.debug /var/log/debug
and check the
.I /var/log/debug
file for the debugging message. Remember to remove this afterwards,
for the amount of the debugging messages may be huge and may use up
your harddisk in a very short time. To the least it may slow down
your system for frequent harddisk
.SM "I/O" .
.SH BUGS
.B vsntp
is hosted on SourceForge and Tavern IMACAT's. For the latest
infomation, see:
http://vsntp.sourceforge.net/
https://sourceforge.net/projects/vsntp/
http://www.imacat.idv.tw/tech/vsntp.html
.B vsntp has a mailing list hosted at SourceForge:
vsntp-users@lists.sourceforge.net . Please submit your questions,
suggestions or bug reports there. It is a Mailman mailing list.
For more information, see:
https://lists.sourceforge.net/lists/listinfo/vsntp-users
Alternatively, you can send a mail to:
vsntp-users-request@lists.sourceforge.net with the subject
.B help
for a list of available e-mail commands.
.SH AUTHOR
imacat <imacat@mail.imacat.idv.tw>.
.SH "SEE ALSO"
.BR settimeofday (2),
.BR adjtimex (2),
.BR sleep (3),
.BR alarm (2).
.BR ntp :
http://www.ntp.org/ .
.SM RFC
1769
.SM SNTP
: http://www.faqs.org/rfcs/rfc1769.html .
.SM RFC
1305
.SM NTP
: http://www.faqs.org/rfcs/rfc1305.html .

410
doc/vsntp.texi Normal file
View File

@ -0,0 +1,410 @@
\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename vsntp.info
@include version.texi
@settitle vsntp v@value{VERSION}
@syncodeindex vr cp
@syncodeindex pg cp
@c %**end of header
@copying
This manual is for vsntp
(version @value{VERSION}, @value{UPDATED}),
a SNTP daemon for Virtual @acronym{PC}@.
Copyright @copyright{} 2003-2007 imacat@.
@quotation
Permission is granted to copy, distribute and/or modify this document
under the terms of the @acronym{GNU} Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts@.
A copy of the license is included in the section entitled ``@acronym{GNU}
Free Documentation License''@.
@end quotation
@end copying
@titlepage
@title vsntp v@value{VERSION}
@c The following two commands start the copyright page.
@page
@vskip 0pt plus 1filll
@insertcopying
Published by imacat@*
@email{imacat@@mail.imacat.idv.tw}@*
@uref{http://www.imacat.idv.tw/}@*
@end titlepage
@c Output the table of contents at the beginning.
@contents
@ifnottex
@node Top
@top Short Sample
@insertcopying
@end ifnottex
@menu
* Introduction::
* Download the Newest Version: Download.
* Compilation and Installation: Install.
* Running and Stopping: Run.
* Command Line Options: Options.
* Supports and Bugs Report: Support.
* References::
* Copyright::
* Index::
@end menu
@node Introduction
@chapter Introduction
@pindex Virtual PC
@pindex Connectix Virtual PC
@cindex RFC 1769 SNTP
@cindex UDP
@dfn{vsntp} is an @acronym{SNTP} client daemon for machines without a
sane system time@. The word ``@dfn{vsntp}'' stands for
``@dfn{@acronym{SNTP} for Virtual PC}''@. It was originally designed
for my @acronym{GNU}/Linux server running on Connectix Virtual @acronym{PC}@.
It runs according to @acronym{RFC} 1769 @acronym{SNTP}, connecting
the @acronym{NTP} server on @acronym{UDP} port 123@. It was originally
written for @acronym{GNU}/Linux@.
Without Virtual @acronym{PC} Additions, the system time on Virtual @acronym{PC} is
completely insane@. It's @acronym{RTC} (Real Time Clock, or
@acronym{CMOS} time, or hardware clock) is software emulated, which
does not seems to be running@. The @acronym{GNU}/Linux kernel hardly
maintains a system time itself@. With smooth run it goes 4 seconds
ahead per minute, which is nearly 1.5 hours per day@. That is
insane@. You can even tell it with your eyes@.
@pindex David L. Mills
@pindex ntp
@findex adjtimex()
@uref{http://www.ntp.org/,David L. Mills' @command{ntp}} does not
work here@. It uses a method that learns the clock frequency drift
first, and adjust the kerenl clock with @code{adjtimex()} so that
time adjustment goes smoothly, from the point of view of system and
applications@. This assumes an existing fix-speed system clock@.
But this is not the case of Virtual @acronym{PC}@. The system clock
on Virtual @acronym{PC} is software emulated@. It can be faster or
slower now and then, depending on the load of the hosting machine@.
There is no fixed clock speed@. The frequency drift does not exist,
then@. It dooms to fail to measure it@.
@pindex sntp
There is an @command{sntp} client that comes with David L. Mills'
@command{ntp} package@. It is suggested to be run from
@command{crontab}@. But @command{crontab} runs by minutes, and
Virtual @acronym{PC} goes 4 seconds ahead per minute@. Rolling back
4 seconds every minute is insane for most applications@. It also
increases system load heavily to run one instance per minute@.
@findex settimeofday()
@command{vsntp} is a workaround on this@. It runs as a daemon to
eliminates the additional system load on every synchronization@. It
uses @code{settimeofday()} to synchronize the time@. It synchronizes
the time with an arbitrary interval, so that time can be accurate
within a second@.
There are some defects@. Synchronizing the time too often introduces
heavy network load@. It introduces heavy load on the target
@acronym{NTP} server, too@. You should have a working
@acronym{NTP} server nearby that is owned by you@. Also, since
@code{settimeofday()} is called so often, high-accurate time
operations like timer, @acronym{etc.}, may not run correctly@.
@findex sleep()
@findex alarm()
@command{vsntp} uses @code{sleep()} as the synchronization scheduler.
Reports show that on some systems @code{sleep()} may not function
normally@. If you find @command{vsntp} stops synchronization after
running for some time, that the @code{sleep()} is not functioning
normally on your system, you may want to switch to the @code{alarm()}
scheduler with the @option{-a} switch@.
If you ever encounter any problem, you may check your syslog@.
@command{vsntp} logs detailed debugging information to syslog in log
level @code{LOG_DEBUG} with facility @code{LOG_DAEMON}@. You may turn
it on in your @file{/etc/syslog.conf} with the following line:
@example
daemon.debug /var/log/debug
@end example
and check the @file{/var/log/debug} file for the debugging message@.
Remember to remove this afterwards, for the amount of the debugging
messages may be huge and may use up your harddisk in a very short
time@. To the least it may slow down your system for frequent
harddisk @acronym{I/O}@.
@command{vsntp} was originally written for @acronym{GNU}/Linux@. It
uses @acronym{POSIX} compatible system calls@. It should work on
any @acronym{POSIX} compatible system@. But I have yet only tested
it on @uref{http://www.cygwin.com/, Cygwin}@. Cygwin is known to
work. I don't have others to test and run on. Please
let me know (and submit the patch if needed) if you can port it to
other systems@. I know it does not work on MSWin32, for the way it
handles the @acronym{PID} file path@.
Please tell me if you have successfully running @command{vsntp} on
other virtual machines, like @uref{http://www.vmware.com/, VMWare}@.
Generally, please tell me if you are using @command{vsntp}@. I
would like to know that I am really doing some good for the world,
*^_^* but not having fun myself@. :p
@node Download
@chapter Download the Newest Version
@cindex website
@cindex official website
@cindex download
@cindex SourceForge
@cindex Tavern IMACAT's
@command{vsntp}'s official website is at@dots{}
@itemize
@item
@uref{https://sourceforge.net/,SourceForge}'s home site:
@uref{http://vsntp.sourceforge.net/}
@item
@uref{https://sourceforge.net/,SourceForge}'s project page:
@uref{https://sourceforge.net/projects/vsntp/}
@item
@uref{http://www.imacat.idv.tw/,Tavern IMACAT's} page:
@uref{http://www.imacat.idv.tw/tech/vsntp.html}
@end itemize
You can always download the newest version of @command{vsntp}
from@dots{}
@itemize
@item
SourceForge:
@uref{https://sourceforge.net/project/showfiles.php?group_id=99098}
@item
Tavern IMACAT's @acronym{FTP}:
@uref{ftp://ftp.imacat.idv.tw/pub/vsntp/}
@end itemize
imacat's @acronym{PGP} public key is at@dots{}
@itemize
@item
SourceForge:
@uref{http://vsntp.sourceforge.net/pgpkey.asc}
@item
Tavern IMACAT's:
@uref{http://www.imacat.idv.tw/me/pgpkey.asc}
@end itemize
@node Install
@chapter Compilation and Installation
@command{vsntp} uses standard @acronym{GNU} @command{autoconf} to
compile and install:
@enumerate
@item
Download, unzip and untar the @command{vsntp} package:
@example
% tar xzf vsntp-@value{VERSION}.tar.gz
@end example
@item
Go into its directory:
@example
% cd vsntp-@value{VERSION}
@end example
@pindex configure
@item
Configure with @command{./configure}:
@example
% ./configure
@end example
@item
Compile with @command{make}:
@example
% make
@end example
The resulted executable will be named @file{vsntp}@.
@item
You need to be @code{root} in order to install @command{vsntp}:
@example
% su
Password:
#
@end example
@item
You can simply copy @command{vsntp} to the appropriate directory:
@example
# cp vsntp /usr/local/sbin
@end example
Or, you can run automatic install:
@example
# make install
@end example
You can reduce the size of the installed executable by stripping off
debug symbols inside:
@example
# make install-strip
@end example
By default @command{vsntp} will be installed in
@file{/usr/local/sbin}@.
@end enumerate
@node Run
@chapter Running and Stopping
You need to be @code{root} to run @command{vsntp}@. @command{vsntp}
uses @code{settimeofday()} to set the system time@.
@code{settimeofday()} requires @code{root} privilege@.
To start @command{vsntp}, just specify your @acronym{NTP} server:
@example
# vsntp my.ntp.server.com
@end example
@command{vsntp} writes its @acronym{PID} in
@file{/var/run/vsntp.pid}@. To stop @command{vsntp}, @command{kill}
it by its @acronym{PID}:
@example
# kill `cat /var/run/vsntp.pid`
@end example
The @acronym{PID} file location can be changed with the @option{-p}
switch.
@node Options
@chapter Command Line Options
@defopt{-i,--interval} @var{n}
Set the synchronization interval to @var{n} seconds@. Default is
900@dmn{sec} (15@dmn{min})@.
@end defopt
@defopt{-p,--pidfile} @var{file}
The @acronym{PID} file location@. Default to @file{/var/run/vsntp.pid}@.
@end defopt
@defopt{-s,--sleep}
Use @code{sleep()} to schedule synchronization@. (default)
@end defopt
@defopt{-a,--alarm}
Use @code{alarm()} to schedule synchronization@.
@end defopt
@defopt{-h,--help}
Display the help message@.
@end defopt
@defopt{-v,--version}
Display version information@.
@end defopt
@node Support
@chapter Supports and Bugs Report
@cindex SourceForge
@cindex Tavern IMACAT's
@command{vsntp} is hosted on
@uref{https://sourceforge.net/,SourceForge} and
@uref{http://www.imacat.idv.tw/,Tavern IMACAT's}@. For the latest
infomation, see:
@itemize
@item
@uref{http://vsntp.sourceforge.net/}
@item
@uref{https://sourceforge.net/projects/vsntp/}
@item
@uref{http://www.imacat.idv.tw/tech/vsntp.html}
@end itemize
@cindex mailing list
@cindex Mailman
@command{vsntp} has a mailing list hosted at
@uref{https://sourceforge.net/,SourceForge}:
@email{vsntp-users@@lists.sourceforge.net}@. Please submit your
questions, suggestions or bug reports there@. It is a
@uref{http://www.list.org/,Mailman} mailing list@. For more
information, see:
@uref{https://lists.sourceforge.net/lists/listinfo/vsntp-users}@.
Alternatively, you can send a mail to:
@email{vsntp-users-request@@lists.sourceforge.net}
with the subject @code{help} for a list of available e-mail
commands@.
@node References
@unnumbered References
@findex settimeofday()
@findex adjtimex()
@pindex ntp
@cindex RFC 1769 SNTP
@cindex RFC 1305 NTP
@itemize
@item
@inforef{High-Resolution Calendar, ,libc}, for settimeofday() and adjtimex().
@inforef{Setting an Alarm, ,libc}, for alarm().
@inforef{Sleeping, ,libc}, for sleep().
@item
@uref{http://www.ntp.org/,ntp}
@item
@uref{http://www.faqs.org/rfcs/rfc1769.html,@acronym{RFC} 1769 @acronym{SNTP}}.
@item
@uref{http://www.faqs.org/rfcs/rfc1305.html,@acronym{RFC} 1305 @acronym{NTP}}.
@end itemize
@node Copyright
@unnumbered Copyright
@quotation
Copyright @copyright{} 2003-2007 imacat@.
This program is free software: you can redistribute it and/or modify
it under the terms of the @cite{@acronym{GNU} General Public License}
as published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version@.
This program is distributed in the hope that it will be useful,
but @emph{WITHOUT ANY WARRANTY}; without even the implied warranty of
@emph{MERCHANTABILITY} or @emph{FITNESS FOR A PARTICULAR PURPOSE}@.
See the @cite{@acronym{GNU} General Public License} for more details@.
You should have received a copy of the @cite{@acronym{GNU} General
Public License} along with this program@. If not, see
<@uref{http://www.gnu.org/licenses/}>@.
@end quotation
@node Index
@unnumbered Index
@printindex cp
@bye
@bye