I'm getting ready to work on this. It might help if some other eyes took a look at the code.
Here is what I think is supposed to happen. ntpd keeps a list of hosts that have sent it traffic. It's a doubly linked list, sorted by time of last packet arrived from that IP Address. There is also a hash table so it can find a slot without a linear search. During the early parts of the receive packet processing, the hash table is used to find the slot. If the slot doesn't exist, a new one is allocated or an old one is recycled. If the slot is found, it is removed from it's current position and inserted at the front of the list. The counter is bumped and the time, mode, version, and remote port number are saved. You can see the list with ntpq -c mru You can see the allocation statistics with ntpq -c monstats (They aren't very interesting unless you look at a busy server.) Collecting the list is a bit tricky since the answer may not fit in a single packet. The answers are sent oldest first. If multiple packets are needed, a continuing request contains an array of where to start IP Address and time-stamp from the last successful reply. One glitch is that slots that have already been sent may get updated while ntpq is collecting and moved to the head of the list where ntpq will see it again. ntpq sorts the list and drops duplicates. When processing a continuation request, ntpd uses the hash table to find the slot, then checks the time stamp. If the time stamp matches, ntpq continues with the next slot on the list. If it doesn't match, ntpd tries the next pair from the continuation request. On a busy server, slots can get updated faster than ntpq can read them. If that happens, ntpq will not be able to finish collecting samples. ntpq has a "direct" mode that doesn't sort the answers, just writes things out. That avoids the memory requirements to hold the whole answer (and duplicates). There is an option to only send slots with more than N packets so you can look for the piggy users without collecting the whole thing. There may be bugs in the above description as well as in the code. There is another quirk in this area. If a probe (and retries) times out, it bails with an error message without printing what it has collected. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
