Re: [multipathtcp] Multipath Address Family

[Joe Touch <[e-mail]>]

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

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksMb74ACgkQE5f5cImnZrtaTQCgtYi1XsM/MqwjuZ3pvLADCDGo
3CkAoNvREr371TwMJ3FEceoiW8cKYJCA
=Tnab
-----END PGP SIGNATURE-----