El 15/05/2006, a las 17:54, Rémi Denis-Courmont escribió:
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.
i agree with your points there, but first of all, it should be noted
that currently, as per RFC3484 application are the one responsible for
retrying when there are multiple destiantion addresses available
However, there may be some strategies that would allow to the IP layer
to keep track of the address that has been tried, (especially source
address for a given destiantion address) and the app only needs to ask
for a retrial
I mean, the problem with UDP is that only the app knows if the packet
was succesfully transitted so only the app knows when there is the need
for a retrial
so it may possible to think some approaches where the app only signals
that the packet that it sent need to be retired and the lower layer
take care of manaiging which addresses to use. For instance, there
could be a cache about what addresses have been tried lately and for
which ones the app have send a signal requiring a retrial (which is a
strong indication that the last address pair tried is not working)
so perhpas it would be interesting to explore this type of hybrid
alternatives, where the app detects non working address pairs (since it
is the only one able to do that in the case of UDP) but the lower
layers are the ones managing the address pairs and caching the
knowledge about which address pairs are working and which ones are not
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.
yes, flooding is not nice, i would try other alternatives first indeed
regards, marcelo
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/
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
