Re: TCP v6 and LuaSocket

[Andrew Yourtchenko <ayourtch@...>]

Hi Diego,

(sorry for the late reaction. And first of all - thanks a lot for
working on this! :-)

On Tue, Mar 22, 2011 at 5:49 PM, Diego Nehab <diego@tecgraf.puc-rio.br> wrote:
> Hi,
>
> How about I make the automatic name resolution in LuaSocket to follow the
> principled approach of trying addresses in the order returned by getaddrinfo?
> Users could invoke the name resolution function themselves, and filter
> out the resolved addresses based on their own family requirements?

The getaddrinfo() returns the results sorted as per RFC3484, yes.
However, more comments on this in the end of the mail.

>
> In other words, socket.connect("www.example.com", 80) would try whatever
> the resolve returns: perhaps IPv6 first then if that fails IPv4, or perhaps the
> only address returned is IPv4 so that's what connect tries. On the other hand,
> socket.connect("192.168.1.4", 80) would obviously try to connect only through
> IPv4 and fail through to the user if that doesn't work, whereas
> socket.connect("2001:db8::1", 80) would try only IPv6. Since the user can
> perform his/her own name resolution, this would be the method to control
> specific behavior without weighting the API down with options.
>
> Wouldn't that be both simple and general enough to satisfy everyone?

Do you think there is a chance to place a hook somewhere that would
allow experimentation with approaches like
http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs without
rewriting the entire app ? I suspect just monkey-patching a shim into
socket.connect could work, but thought to bring this up anyway, maybe
you have better ideas.

(By the way: to all the folks on the thread who saw the problems when
the machine had IPv6 enabled, please ping me unicast, I'd be very
curious to look at the failure scenarios but this is clearly an OT for
lua-l).

>
> Maybe the connect() call could accept a table of IP addresses to try
> in sequence, so that socket.connect("www.example.com", 80) is equivalent to
> socket.connect(socket.toip("www.example.com"), 80), assuming socket.toip()
> simply returns the list of resolved addresses in the order provided by
> getaddrinfo...

I think steering towards a 'connect("domain-name", "service")' (and
helping with the hooks that would allow to refactor its behavior)
might be more useful in terms of portability later on. (NB: 'service'
potentially being a string - that would allow to do interesting things
like SRV records lookups, without the need to drastically change the
architecture of the calling code.

The reason I am suggesting this approach is I think it is easier to
modify later on. If the name resolution and the socket operations are
explicitly exposed to the user as a default, they may frequently end
up in different parts of the code, so any subsequent modifications to
transport layer (e.g. also using alternative transport protocols)
requires changes in two places, which makes it more difficult.

cheers,
andrew

>
> Regards,
> Diego
>
>