[vlc-devel] [PATCH 4/6] smb2: use new happy eyeballs API

[Rémi Denis-Courmont]

Hi,

There's no differences between the two versions in this respect. Happy Eyeballs was originally meant for HTTP in fact.

It wouldn't make much sense for NB to resolve IPv6 with SMB over IPv4 when it's basically two parts of the same thing. Windows wouldn't be able to connect, would it?

Le 10 mars 2021 14:55:22 GMT+02:00, Alexandre Janniaux <ajanni at videolabs.io> a écrit :
>Hi,
>
>On Tue, Mar 09, 2021 at 05:32:56PM +0200, Rémi Denis-Courmont wrote:
>> Le mardi 9 mars 2021, 13:06:41 EET Thomas Guillem a écrit :
>> > On Wed, Mar 3, 2021, at 18:38, Rémi Denis-Courmont wrote:
>> > > Le tiistaina 2. maaliskuuta 2021, 16.52.23 EET Thomas Guillem a
>écrit :
>> > > > Connect to all resolved addresses in parallel, waiting 100ms
>between
>> > > > each new connection.
>> > >
>> > > AFAIK, Happy Eyeballs is meant for the Internet, not private
>networks. But
>> > > then, CIFS/SMB is pretty only for private netwoks, not the
>Internet...
>> >
>> > A lot of NAS support both IPv4 and IPv6 but have smb2 server
>listening on
>> > only one IP type. The happy eyeballs algorithm seems a very good
>way to
>> > solve this issue, as advised by Martin.
>>
>> I fail to see how it "seems" so.
>>
>> If the UNC locator has an IP literal, then Happy Eyeballs cannot be
>used in
>> the first place. And if the UNC locator has a NetBIOS server name,
>then it will
>> resolve to resolve the correct address family.
>>
>> Happy Eyeballs is meant for the Internet, as in it's meant for use
>with the
>> public DNS system.
>
>I agree that RFC8305 aka. Happy Eyeballs Version 2 mostly
>try to solve internet problems, but original version RFC6555
>aka. Happy Eyeballs: Success with Dual-Stack Hosts previously
>tried to solve general dual-stack problems, as highlighted by
>the abstract:
>
>Abstract
>
>   When a server's IPv4 path and protocol are working, but the server's
>   IPv6 path and protocol are not working, a dual-stack client
>   application experiences significant connection delay compared to an
>   IPv4-only client.  This is undesirable because it causes the dual-
>   stack client to have a worse user experience.  This document
>   specifies requirements for algorithms that reduce this user-visible
>   delay and provides an algorithm.
>
>It seems that the situation exposed by Thomas is exactly a
>situation with a dual stack network were transport between
>two endpoints doesn't exist on the IPv6 stack.
>
>I didn't really read thoroughly the whole RFCs though, so I
>might be missing something but maybe you can shed some light
>on this point:
>
>> And if the UNC locator has a NetBIOS server name, then it will
>> resolve to resolve the correct address family.
>
>If it is resolved into the correct address family, then I
>agree that there should be no issues there. But Thomas seems
>to have exactly the issue where it's not resolved into the
>correct address family.
>
>How do you define the «correct address family» and why netbios
>would always resolve to it?
>
>Regards,
>--
>Alexandre Janniaux
>Videolabs
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20210310/ad1aaa5f/attachment.html>