 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
On Wed, 11 Nov 2009, Brian Haberman wrote:
Mohacsi Janos wrote:On Tue, 10 Nov 2009, Wes Beebee (wbeebee) wrote:I think the simplest solution to (2) is, frankly, to open connectionsat somerate (if I have N addresses and my peer has M, send a SYN-or- whateveronsuccessive pairs in the cross-product every K milliseconds until I geta SYN-ACKon one of them, and then close all other sessions).+1 I think what Fred mentioned is the only real way we're going to solve the address selection problem. If you don't try pairs and select which one works first, then you're stuck trying to outguess the network design at the operating system layer. Any approach to do this will work in some cases and fail in others. It would be very hard for the IETF to judge whether some combination of approaches works more often than it fails - because that would involve some notion of what a "typical" network topology is.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, in my opinion:1. the applications using getaddrinfo() library function has to be rewritten: most application written in principle of trying all available destination addresses, but no mechanism/logic in the codes to successively try all the source addresses. Of course this can be made hidden with some kernel implementation hacks, but this can be non-deterministic.2. With application using UDP and/or multicast your try_and_success_or_failure might not scale. Will you send n(#source_address) X m(#destination_address) to the target node/group? Will it scale with multicast? Are you willing to increase the load of the e.g. DNS servers?In what situations would m>1 if the destination is multicast?
None. Sending with multiple source address can be still problematical. But in the case of UDP might be more interesting....
Best Regards, Janos