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

Alexandre Janniaux ajanni at videolabs.io
Wed Mar 10 12:55:22 UTC 2021


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


More information about the vlc-devel mailing list