[ntp:bugs] [Bug 314] Should use IP_PKTINFO

[bugzilla at ntp.org]

http://bugzilla.ntp.org/show_bug.cgi?id=314





------- Additional Comments From mayer at ntp.org  2004-06-24 13:50 -------
Subject: Re:  Should use IP_PKTINFO


>Danny, I don't want to flame. I want to improve NTP code.

I don't do flame wars.

>So far, we seem to disagree whether NTP should use single socket bound to
>0.0.0.0 or multiple sockets bound to each local ip. Lets try to come to 
>concensus.
>
>I'll try to enumerate reasons why single socket is better. Can you reply to
>each of them?
>
>1. Single socket does not need to track changes in local ips and interfaces.
>Multiple sockets need that. Just think about DHCP, PPP, OpenVPN, PPTP, etc...

Single sockets require that we have the code examine each packet address and
decide whether or not to allow it or drop it. Multiple sockets allow you to 
set up
only the addresses you want to listen on and ignore the rest. That way the O/S
is responsible for refusing requests on a port rather than the application. 
There's
no need to involve the application in that. And how would we handle it in 
the single
socket case? I don't think we can send a refused error in that case or just 
drop the
packet.

>2. "Single socket" code is simpler than "multiple sockets".

How is it simpler? How would you take advantage of multithreading in
that case? In a multithreaded application you could have a different
thread listening on each socket in a multiple sockets implementation.

>Here is why people might think that "single" is worse, and my answers:
>
>1. Something (e.g. auth) will break because we won't know over which iface
>packet came from.
>   a:With IP_PKTINFO, we get both iface# and dst addr of incoming packet.
>     We have same information as in "multiple" case. Also we can send
>     answers with proper src addr. Why it would break? I see no reason.

You can always use getsockname() to get the address. I did this in BND 9 during
debugging. That's not the issue. The code is already structured in such a 
way that
we know that address and authentication which requires the remote address can
handle the situation. We don't actually care about the iface# and I they 
only time
you might need that is if you tie the same IP address to two different 
interfaces
and then there may be other issues. Keeping the sockets separate avoids the
issue in the first place. Not to mention the work involved to change the code.

>2. It wouldn't work with IPv6.
>   a:Although I personally never worked with IPv6, others say IPv6 IP6_PKTINFO
>     works quite similar to IPv4.

We work heavily in IPv6. It's a requirement. Yes, IP6_PKINFO is basically the
same as IP_PKINFO.

>Anything I missed?

Yes. The sheer amount of work involved with no real benefit.

The real problem here is that we are not addressing the problem that needs to
be solved. What I see is that people say "Everyone else does it this way so you
should do it too" without posing the problem that needs to get solved. The 
problem
that needs to get solved is the dynamic IP address issue where addresses get
changed on the fly and ntpd is ignoring the change. It is on my list of 
things to fix
and as a side benefit we will be able to have people specify specific addresses
that they want ntpd to listen on.

The changes that I had to make to get ntp_io.c to make it stable, reliable,
buildable and changeable were enormous and took almost a year of elapsed
time (it's a volunteer project). There are still occasional build problems from
some strange platforms and O/S versions, but they are now easy to fix. You
are talking about another year or more of work to implement what you are 
suggesting
for no clear (in my view) benefit. to solve a problem that could be more 
simply solved
in another way.

Danny






------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.