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

[Thomas Guillem]

On Wed, Mar 10, 2021, at 13:55, Alexandre Janniaux wrote:
> 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?

Our mdns service discovery (mdns, avahi) resolve ip4 or ip6 addresses, so the happy eyeballs algo is not used in that case (since there is only one ip/port to connect to).

For netbios names, in the smb2 module, if the name can be resolved via getaddrinfo, then It skips the netbios resolve (that can be quite long). I could do a netbios resolve before everything to be sure that the resolved ip is always correct, but I don't think we should favor netbios resolve that start to be less common.

By the way, I checked the samba source code to see if they did the same thing. No mention of happy eyeballs, but they do have the same kind of mechanism, cf. https://github.com/samba-team/samba/commit/5d18e57bec9db9444ae738c24ef63b21e3197a77 from 2011 (before happy eyeballs).

> 
> Regards,
> --
> Alexandre Janniaux
> Videolabs
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel