Brian Utterback wrote: > Danny Mayer wrote: >> Brian Utterback wrote: >> >>> Perhaps proper, but ill-advised. Look at the trouble we have >>> had trying to satisfy that requirement. I am sitting at a >>> system that currently has over 300 UDP ports in use. Exactly >>> one of those UDP ports is bound on each interface, namely 123. >>> Interestingly, it is also bound twice on the wildcard address >>> as well. >>> >>> Until recently, it wasn't possible in a portable manner, for >>> a process to listen on a UDP port, receive a request and >>> then issue a reply with the reply's source address guaranteed >>> to be the same as the request's destination address. And >>> virtually all UDP protocols had a way to deal with it, except >>> NTP. >>> >>> >> >> Not true. NTP had a number of bugs in it that needed to get fixed. >> Getting through all of the use cases took a long time to get right. >> That's a bug not an architectural flaw. >> > What's not true? Are you saying that NTP doesn't need to bind all the > interfaces anymore?
No, it does to thast. > If that is the case, then great, but the argument still stands. If that > is not the case, > then nothing has changed and the argument still stands. > If you want to send a reply back to a client how would you specify the outgoing local interface address? Even using sendmsg() you cannot do that if you want to use, for example, the wildcard socket. Don't forget this is UDP so it's connectionless and is a separate datagram each time. There are very few choices here. With TCP there is an established connection and you can reply on that connection. This is not the case here. Danny _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
