On 21/08/2018 09:29, Martin Storsjö wrote: > For cases with dual stack (IPv4 + IPv6) connectivity, but where one > stack potentially is less reliable, strive to trying to connect over > both protocols in parallel, using whichever address connected first. > > In cases with a hostname resolving to multiple IPv4 and IPv6 > addresses, the current connection mechanism would try all addresses > in the order returned by getaddrinfo (with all IPv6 addresses ordered > before the IPv4 addresses normally). If connection attempts to the > IPv6 addresses return quickly with an error, this was no problem, but > if they were unsuccessful leading up to timeouts, the connection process > would have to wait for timeouts on all IPv6 target addresses before > attempting any IPv4 address. > > Similar to what RFC 8305 suggests, reorder the list of addresses to > try connecting to, interleaving address families. After starting one > connection attempt, start another one in parallel after a small delay > (200 ms as suggested by the RFC). > > For cases with unreliable IPv6 but reliable IPv4, this should make > connection attempts work as reliably as with plain IPv4, with only an > extra 200 ms of connection delay.
The set looks fine to me. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
