[ntp:questions] Re: server's address in ntp payload?
brian.utterback at sun.com
brian.utterback at sun.com
Thu Nov 24 00:07:35 UTC 2005
David Schwartz wrote:
> "Brian Utterback" <brian.utterback at sun.removeme.com> wrote in message
> news:4384D261.4080107 at sun.removeme.com...
> > David Schwartz wrote:
> >> "Brian Utterback" <brian.utterback at sun.removeme.com> wrote in message
> >> news:4384C69A.7090003 at sun.removeme.com...
> >>> David Schwartz wrote:
> >> I am saying the default presumption is that it must be that way but
> >> that particular protocols can override it. That's effectively what SHOULD
> >> means in a general description -- done that way unless the specifics of
> >> some particular case justify doing otherwise.
> > Oh? Do you know of any OS that does this?
> Sure, I do. All of Linux's kernel request/response UDP protocols work
> this way, including NFS-over-UDP.
> If the OS implements a UDP request/response protocol, it should ensure
> the source address of the reply is the destination address of the request
> unless the protocol specifies otherwise. Most OS implementations of UDP
> request/reply protocols *DO* do this.
> You are asking about both OSes and applications in a confusing way that
> seems to be based on the misunderstanding that I'm saying the kernel should
> somehow make an application do the right thing. I'm saying whatever
> implements the request/response protocol over UDP should do the right thing,
> which in most cases is the application, not the kernel.
Right. That is my point. The kernel can easily do this because it has
of the necessary information. Protocols implemented in the user space
would have a much more difficult time because there is no standard way
to get this information. I say "would have", because historically they
not do it at all. That is to say, UDP was designed (I would guess
but I do not know for sure) not to need this information and the
implemented using all use another method to match up requests and
responses than by using the IP address.
This is why I say that no OS implements the "SHOULD" as you defined it
the host requirements RFC. No OS to my knowledge enforces or provides
this service for the applications automatically. The applications must
for themselves. Thus as a "host requirement", these OS's fail to
the requirement, at least for UDP.
> Which it can, unless the OS is broken. Do we agree that an OS that makes
> it difficult or impossible for an application to determine the destination
> address of a received UDP datagram is broken?
No, provisonally. As I noted, some applications do indeed need to have
so if it is impossible then those applications cannot run. But my point
is that UDP/IP
was not expected to need this information. I would therefore contend
that a protocol
that has this requirement gratuitiously is flawed. Which brings me back
to my question,
since IP does not have this requirement, and UDP does not have this
it the case that NTP explicitly has this requirement. I mean the base
protocol, not the
reference implementation, and even if it does, does it really need it?
> I'm not sure I understand what you think the point of this is. Is it
> that bad design in the past somehow justifies bad design now? The source and
> destination IP addresses are not internal protocol details -- they're always
> already visible at the application level.
My point is that the destination is not always readily visible from the
level. And I do not think that this is a bad design, just not
I am reminded of an instance a year or so ago when someone (Harlan?)
that an error return be added to the ntp_adjtime call if the call
requested a frequency
adjustment greater than the maximum. As it was, requesting a frequency
greater than the max is slilently capped at the max. To anybody
software design, this just screamed out for an error return. Except Dr.
out first. He said that the behavior was/is by design and changing it
would invalidate all of the correctness proofs.
It is the same here. It was clearly a design goal of UDP protocols not
to have the requirement. Since there was no such requirement, there was
no need for an API to get the destination address. People at various
times needed the desitnation address for other reasons, or because they
didn't understand this aspect of UDP, so the API was added, which just
means that new UDP protocols forego this aspect entirely and the people
designing them may not even realize that they are changing the way UDP
More information about the questions