Regarding this way of try-and-error approach,
I think It should be implemented the following way:
for each source address in some order {
create socket
bind (current source address)
for each destination address in some order {
connect (current destination address)
do {
"select" for K ms or a result, whichever comes first
} while (result was a connection attempt failing)
if result was a connection succeeding goto "connected"
}
destroy socket }
connected:
....
Even when a host can find a successful working address pair,
it is not always a desirable address.
From user's perspective, the pair found by chance might have
poorest bandwidth or latency.
From site administrator's perspective, the pair might not be
the best with regard to user experience, or provisioning cost.
For example, he may want to unload the traffic through CGN,
tunnel, translator middleboxes.
I'm not arguing that this approach is good or bad, but that
this approach fulfills all that we needed.
--
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
--------------------------------------------------------------------
