David Schwartz wrote: > "Brian Utterback" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > David Schwartz wrote: > > >> "Brian Utterback" <[EMAIL PROTECTED]> wrote in message > >> news:[EMAIL PROTECTED] > >> > >>> 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. >
[snip] > 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 all 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 do not do it at all. That is to say, UDP was designed (I would guess deliberately, but I do not know for sure) not to need this information and the protocols 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 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. [snip] > 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 this info, 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 requirement, is 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? [snip] > 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. I am reminded of an instance a year or so ago when someone (Harlan?) suggested 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 adjustment greater than the max is slilently capped at the max. To anybody experienced with software design, this just screamed out for an error return. Except Dr. Mills screamed out first. He said that the behavior was/is by design and changing it as proposed 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 works. blu _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
