[ntp:questions] Re: server's address in ntp payload?

David Schwartz davids at webmaster.com
Thu Nov 24 01:09:18 UTC 2005

<brian.utterback at sun.com> wrote in message 
news:1132790855.492030.289600 at g49g2000cwa.googlegroups.com...

> This is why I say that no OS implements the "SHOULD" as you defined it
> from
> the host requirements RFC. No OS to my knowledge enforces or provides
> this service for the applications automatically. The applications must
> provide it
> for themselves. Thus as a "host requirement", these OS's fail to
> implement the
> the requirement, at least for UDP.

    This is a nonsensical argument. Kernls *do* in fact do this when they 
provide the UDP based services. They *can't* enforce it for applications 
that provide a service because that is functionality that would have to be 
in the kernel.

>>     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.

    In other words, because kernels have historically been defective in this 
regard and we've been able to make things mostly work, they must not be 

> As I noted, some applications do indeed need to have
> this info,
> so if it is impossible then those applications cannot run.

    And that's not a kernel defect because ... ?

> But my point
> is that UDP/IP
> was not expected to need this information.

    Because it's always visible to the application. When I send you a UDP 
datagram, I know what address I'm sending it too, and if you need that for 
some reason (say, to reply from the same address), then I can put it in the 
payload. Which gets us back to the subject ... If you're right that it's 
okay for kernels not to provide this information, it's only because the 
sender has the information and can put it in the payload if it's needed.

> I would therefore contend
> that a protocol
> that has this requirement gratuitiously is flawed.

    Right, so NTP is flawed because it does not put the IP address in the 
payload, thus requiring you to get it from the kernel if you need it. (I 
don't agree with your premises, but they lead inexorably to this 

>>     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
> application
> level.  And I do not think that this is a bad design, just not
> necessarily intuitively
> obvious.

    What? How can you send a UDP datagram without knowing what address 
you're sending it to? And when you receive it, you are always told the 
sender's address. So both the source and destination address of a UDP 
datagram are visible from application level. There are *no* layering 
violations here.

> It is the same here. It was clearly a design goal of UDP protocols not
> to have the requirement.

    Huh? It may be a design goal of UDP, but every request/response protocol 
layered over UDP has its own design requirements. UDP always makes both 
addresses visible at application level.

> 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
> works.

    They are not changing the way UDP works. That's absurd.


More information about the questions mailing list