Re: [multipathtcp] Multipath Address Family

[Andrew Yourtchenko <[e-mail]>]

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.

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