⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1769.txt

📁 一个开源的NTP客户端程序
💻 TXT
📖 第 1 页 / 共 3 页
字号:
   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 significantMills                                                           [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

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -