Re: TCP v6 and LuaSocket

[Diego Nehab <diego@...>]

Hey Andrew,

On Tue, Mar 29, 2011 at 6:33 AM, Andrew Yourtchenko <ayourtch@gmail.com> wrote:
>> 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.

I was talking to Matthew the other day and the suggestion came up.
Well, at least the part of trying to connect on both IPv4 and IPv6
simultaneously. The part of caching which one worked did not come up.

I like both solutions, but I believe this does not belong inside the
C implementation of connect. It is too much implicit behavior. I believe
a better place for this is at a higher level. Perhaps a tiny library
that we could distribute along with LuaSocket? That way we could
implement all recommendations and give it away so people can
adapt the code to their own asynchronous dispatch loops.

Can I  cross-check the API with you (out of band) to make sure all
relevant provisions *can* be implemented effectively?

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

Yes, definitely will have "service" as general strings. *Not* doing
that actually requires work when we use getaddrinfo. :)

Kind regards,
Diego