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
--------------------------------------------------------------------

Reply via email to