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

listen on *

listen on *
listens, well, everywhere.

flight. should we draw concludions from that? I'd like to blame the
Air Canada seats...

struct ntp_addr, which just wraps a sockaddr_storage and a next pointer,
so that host_dns can return more than one entry.
let host_dns do exactly that, return a list of all IPs for that hostname
adjust all callers in the grammar to cope with that

a lot of credit for not having supplied us with enough data within an
adjtime run interval, and get a little credit each time we get a good
reply packet. if a peer is below 20%, only send a packet occasionally to
see wether it is back. send out queries much more often between 20 and 80%
to (re-)sync quickly, and above 80% usethe regular interval.
do not use peers < 60% for calculating teh local clock offset.
designed with theo at the pho, alexander ok

form the last 8 replied received from a peer, find the one with the lowest
delay. Use that as the peer's update taken into account for calculating
the local clock's offset.
Invalidate that reply and all ones received earlier than it so that they do
not get used again.

function until henning showed me the light... log_sockaddr... nifty);
this diff is from henning and should be henning ok =)

for now, average over those to adjust the local clock.

adjtime() when necessary to keep the local clock in sync
yes, that means ntpd syncs the local clock now.

ok henning@

reported by Peter Hessler.  ok henning@

limit on OPEN_MAX, modeled after bgpd

hook the descriptors into the main poll and such.
we're not doing anything with the reply we recive yet, tho.
mostly hacked on the Frankfurt->Montreal flight, as batteries and those
horrible air canada seats permitted...

ok henning@

for now, one can set the addresses to listen on

default to one IPv4 wildcard and one IPv6 wildcard one.