Re: [multipathtcp] Multipath Address Family

[Andrew Yourtchenko <[e-mail]>]

On Wed, 25 Nov 2009, Andrew Yourtchenko wrote:

> On Tue, 24 Nov 2009, Joe Touch wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> 
>> 
>> Laganier, Julien wrote:
>>> Joe Touch wrote:
>>>> Laganier, Julien wrote:
>>>>> Joe Touch wrote:
>>>>>> [...]
>>>>>> Sure, but either way you need to return at least the primary IP
>>>>>> address/port pair as results of the connect_to_name() call.
>>>>>> 
>>>>>> It's not sufficient to return an undistinguished set of such pairs,
>>>>>> nor is it sufficient to not return any such pairs.
>>>>> Unless the socket has been bind()'ed earlier, connect() doesn't
>>>>> return to the caller any information about the address/port that
>>>>> was picked as a result of the connect(). The application would need
>>>>> to call getsockname() to know what address/port pair was used.
>>>> Sure. I was speaking in a general sense.
>>>> 
>>>>> If an application is modified to use the new API, it will have to use
>>>>> getpeername() in addition to getsockname() to know what initial
>>>>> address pair has been connected.
>>>> That basically kills legacy apps. You want getsockname to return the
>>>> initial, and some other call to return the full list (or supplemental
>>>> socket pairs).
>>> 
>>> Hmm... Not sure I understand your statement about legacy apps.
>>> 
>>> We've been talking about an app using a new connect_to_name() API call, so 
>>> it's no longer entirely legacy -- If it wants to use the new 
>>> connect_to_name() API call, it has to use getpeername() to get its peer 
>>> address, that's it.
>>> 
>>> I do not see how that is related to legacy apps, nor while it would be 
>>> killing them :)
>> 
>> Agreed. But I can port a legacy app easier if these interfaces augment,
>> but don't change, the semantics.
>
> FWIW (apologies to get in the middle of the conversation) - I had looked at a 
> couple of browser apps when working on the prototype code for the "happy 
> eyeballs" draft - my code was implementing the connect_by_name() semantics, 
> with two threads racing in the background for IPv4 and IPv6 host lookup and 
> connect attempts.

And to correct/clarify myself: I was working with the 
connect_by_name(hostname,servicename) - similar to getaddrinfo()

> I saw the biggest difficulty with porting the apps to use the 
> connect_to_name() API in the work required to refactor the code that deals 
> with the blocking resolver in a non-blocking manner (along with giving the 
> user the visual clues of "Resolving host for hostname.example.com..."), 
> selects in some application-specific way the sockaddr to use and passes it to 
> the non-blocking socket code, and deals with the various recoverable error 
> conditions (like retrying with other address).
>
> But, that said, I think with the right hooks for very specific cases where 
> the application needs the fine-grained control over what exactly the "remote 
> hostname" should boil down to, connect_by_name() could save quite a lot of 
> "boilerplate coding" for the future.

thanks,
andrew