Re: TCP v6 and LuaSocket

[Andrew Yourtchenko <ayourtch@...>]

Hi Diego,

On Tue, Mar 29, 2011 at 5:44 PM, Diego Nehab <diego@tecgraf.puc-rio.br> wrote:
> 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.

I was thinking the most important part would be to give a primitive to
"do the right thing" which by default would just shortcut to
OS-provided connect, but the library would provide a hook to implement
a different behavior later, without refactoring the apps. (name lookup
code and connect code  tend to drift away from each other within an
app, unless the programmers are careful).

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

yes, I'd be delighted to discuss this.

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

yes, getaddrinfo's semantics is in the right direction.

Let's sync offline.

cheers,
andrew

>
> Kind regards,
> Diego
>