"Interesting" changes - please test and keep an eye out for quirks
Eric S. Raymond
esr at thyrsus.com
Tue Mar 20 09:31:51 UTC 2018
Hal Murray via devel <devel at ntpsec.org>:
>
> I cleaned up the processing of received packets. This has been on my list
> for a while. I finally looked at it right and it was simple.
>
> There used to be a big table indexed by packet mode and peer mode. That
> handled multicast, responses to pool probes, and "peer" requests/responses.
> We don't support multicast or peer mode, and the DNS lookup for the pool
> creates the peer block before it sends the first packet so the pool response
> now looks like a normal response from a server.
>
> I also moved the parsed_pkt copy of a packet into the recvbuff to avoid a
> calloc/free with each packet.
>
> It all works in my setup, but I won't be surprised if there is some obscure
> case that I don't test.
Good work.
You might soon get to do that cleanup of the network I/O you wanted to a while
back. Last time it was blocked because removing that grotty socket-per-interface
loop wasn't compatible with keeping the ability to filter by interface name.
However...I was revisiting that problem recently recently and found
some indications that it *is* possible to get the transit interface of
a recieved packet under Linux using CMSG.
If I can nail this down, and establish that there are equivalent capabilities
on all our primary target platforms, I may be able to write a packet_iface.c
parallel to packet_stamp.c.
And if that's true, most of ntp_io.c can turn into a single select on
a socket list.
Practical motivation: Daniel wants this for NTS support.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
More information about the devel
mailing list