Le Dimanche 14 Mai 2006 17:44, vous avez écrit : > El 13/05/2006, a las 12:14, Rémi Denis-Courmont escribió: > > There are possibly more troublesome issues: > > 1/ how to handle UDP, which is also supported by getaddrinfo(), and > > has more varied usages (not just socket() then connect())?
> but this seems to be the natural behaviour... > In the case of UDP, it is a non connection oriented service, so it is > not possible for UDP to determine if the address pair is working, > hence it is up to the application that has selected the usage of UDP > to handel failures by themselves, i.e. to determine if the current > address pair is working and if not it is up to the app to try > alternative ones. That's true on the paper. But in practice, it is completely unmanageable for many UDP applications to keep a list of candidates (protocol family, destinations), and to handle failures asynchronously, particularly if there are several peers. ntpdate is a good example. You really don't want to pass several sockets, a whole addrinfo chained-list, and keep track of who's next in the list in case of ICMP failure. Actually, this would not only be way too complex, this would be worst because they would be so many ways it could be coded wrong. Dual-stack UDP applications do need to know immediatly via which protocol version any peer should be reached. That's as simple as that. And flooding all alternatives destination addresses sounds highly suboptimal, as contrary to TCP, each of these packets will actually contain a payload, and likely be processed by the destination. > so, as i see it, this result is completelly coherent with the type of > service provided by each of the transport layers... I'm not saying UDP should be considered reliable. I'm saying some applications should have a non-blocking way to know which destination (and source) address to use to try to reach a single peer via UDP. That doesn't mean failure should not be handled. -- Rémi Denis-Courmont http://www.simphalempin.com/home/
pgpMteFiNWEUK.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
