"There is a similar API in Winsock2 that tries multiple destination addresses, but not every pair of destination and source address."
In windows 7 you get every pair possible with some restrictions and the ordering is based on improving the chances of success of successful connection completion - but it still attempts to adhere to 3484 to some extent. Simha -----Original Message----- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Arifumi Matsumoto Sent: Wednesday, November 18, 2009 1:23 AM To: Fred Baker Cc: draft-ietf-6man-addr-select-...@tools.ietf.org; draft-ietf-6man-addr-select-considerati...@tools.ietf.org; IETF IPv6 Mailing List; Mohacsi Janos; draft-arifumi-6man-addr-select-confl...@tools.ietf.org Subject: Re: Thoughts on address selection Fred, On 2009/11/11, at 7:52, Fred Baker wrote: > > On Nov 11, 2009, at 2:00 AM, Mohacsi Janos wrote: > >> I think this try_and_success_or_failure method can work in most >> cases, however it has some burden for implementation and >> operational point of view, > > It does indeed, at least operationally. That is trivially solved for > sites one frequently visits, using a cache - if one finds that > address pair {source, destination} works one time, one might try it > first next time. > > As to the implementation, I have written the code for the naive > version on Linux (and then threw it away for some reason), and it's > not too hard. It comes down to > > get all of my addresses > get all his addresses > for each address pair in some order > "connect" on the socket > do { > "select" for K ms or a result, whichever comes first > } while (result was a connection attempt failing) > if result was a connection succeeding, break > } > > // at this point we have an open connection or some outstanding > while (we have no open connection and some connection attempts in > progress) { > "select" seeking a result > } > if (we have a connection open) { > for each connection attempt except that one { > close it > } > } > return the connected socket There is a similar API in Winsock2 that tries multiple destination addresses, but not every pair of destination and source address. I guess that is because if you force to try all the pairs, it perfectly ignores the address selection manner defined in RFC 3484, and thus, it gives us not little impact. Usually the source address that is attached to the outgoing interface is selected as defined in RFC3484. However, the above mentioned implementation does not follow this manner. > Ideally, if one wishes to have a properly designed socket interface, > one puts that in a subroutine that one calls with a name and gets > either a connected socket or a failure in response, so that the > application knows nothing about IP addresses (see UNSAF). But now I > am engaging in wishful thinking - that the socket interface would be > reasonably designed. > > Caching implies some form of storage, which probably involves a > kernel API, which I have not tried to prototype. Caching sometimes work nicely, and sometimes do harm. I'm not sure we can create perfect-in-every-environment caching algorithm. -- Arifumi Matsumoto Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arif...@nttv6.net -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
