RFC 1059:Network Time Protocol (Version 1) ...
RFC-Ref

State


Click on the red underlined text to get to the source

... operate in a symmetric mode, in which servers and clients are indistinguishable, yet maintain a small amount of state information, or in client/server mode, in which servers need maintain no state ...
... state information, or in client/server mode, in which servers need maintain no state other than that contained in the client request. A lightweight ...
... reachability and variable polling rate mechanisms, is included only to manage the state information and reduce resource requirements. Since only a single NTP ...


... This section consists of a formal definition of the Network Time Protocol, including its data formats, entities, state variables, events and event-processing procedures. The specification model is based on the implementation model illustrated in Figure 2.1, but it ...
... State Variables and Parameters ...
... Following is a tabular summary of the various state variables and parameters used by the protocol. They are separated into classes of ...
... Local Port peer.dstport system Peer State peer.state receive, transmit ...
... Port peer.dstport system Peer State peer.state receive, transmit Reachability ...
... port number of the local host. They are included among the state variables to support multi-homing. ...
... Following is a list of state variables used by the peer management and measurement functions. There is one set of these variables for ...
... client mode or symmetric mode. Peer State (peer.state) ...
... Peer State (peer.state) This is a bit ...
... filter and selection algorithms suggested in Section 4 are used, the following state variables are defined. There is one set of these variables for every peer operating in client mode or symmetric ...
... information and returning the message to the client. Servers then need retain no state information between client requests. Clients ...
... messages and each determines that the other is reachable, an association is formed. One or both peers must be in active state; that is, sending messages to the other regardless of reachability ...
... that is, sending messages to the other regardless of reachability status. A peer not in active state is in passive state. If a peer ...
... status. A peer not in active state is in passive state. If a peer operating in passive state ...
... state. If a peer operating in passive state discovers that the other peer is no longer reachable, it ceases sending messages and reclaims the storage and timer ...
... association. A peer operating in client mode is always in active state, while a peer operating in server mode is always in passive state ...
... active state, while a peer operating in server mode is always in passive state. ...
... bit. Then an NTP message is constructed and sent to the peer. If operating in active state or in passive state and ...
... peer. If operating in active state or in passive state and peer.reach is nonzero (reachable), the peer.timer is reinitialized ...
... NTP.MINPOLL) . If operating in active state and peer.reach is zero (unreachable), the peer variables are updated as follows: ...
... The following peer variables are initialized: peer.state <- symmetric (passive) peer.timer ...
... result in a new clock source (sys.peer). If sys.peer points to the peer data structure with the just-updated estimates, the state variables of that peer are used to update the system state ...
... state variables of that peer are used to update the system state variables as follows: ...



Google
Web
RFC-Ref