a close-to-reality stratum, a real reference time, and a leap indicator
that will indicate if the local clock isn't synchronized.
This also means that until the server feels it's synchronized, it will
tell the clients it isn't.  This is normal, and correct.
ok henning@

offsets, in preparation for having correct server statistics in
responses to client queries.  ok henning@

of each packet, not only after each 8th (where we have enough for sure)

not as efficient as I want it to be yet, but more is coming

mostly from Andreas Kahari (PR #3846);

noticed & fix tested by fries@

- mention '#' comments
- fix macros for directives
- typos
- change list display
- ntp -> NTP
- slight rewording
help and ok jmc
ok henning otto

SIGHUP, noticed by otto

we know have both a "server" and "servers" keyword. they differ when the
hostname resolves to more than one IP, server picks one and servers expands
to all.
that means no longer stuffing a sockaddr_storage into ntp_peer but a pointer
to a linked list of ntp_addr structs.
in the "servers" case the list of n addresses returned by host() is expanded
into n ntp_peer structs and thus n individual peers.
in the "server" case the whole list is attached to ntp_peer, and whenever we
do not receive a reply in time we traverse the list one further, so that
hosts with both AAAA and A records are first tried with the AAAA one but
we gracefully fall back to the A one.
semantics with theo; hacked up on the Montreal->Frankfurt flight.
again Air Canada surprised me, that older 767 hat pretty decent seats.

the outstanding queries into account
just-before-meal from the Montreal->Frankfurt flight

deraadt@ OK

fixes the dns resolves to v4 and v6 addresses bug found by phessler
hacked on the Calgary->Montreal flight that proved that Air Canada _does_
have some modern aircrafts with good seats

foreground/debug mode

before, it would log with LOG_DEBUG to syslog when !debug

for NTP queries/replies.  RFC 1305 and some of Mills' other papers have
the correct formula.
ok henning@

* Respond to the query with a reasonable received time (which
will help clients get better accuracy).
* Consolidate the server response code in preparation for a
completely 'proper' response to the client.
tips and ok from henning@

the logging was useful for development but is a bad idea in production
use as a remote attacker could flood your logs

pool.ntp.org. Give some commented out examples tho.

listen on *

listen on *
listens, well, everywhere.