Hi,
>> These are happening at startup only and are a direct consequence of
>> using getaddrinfo().
>
> Ah indeed I didn't notice the destination port is zero, so they're just
> used to check whether the protocols are supported or not! Thanks for
> enlighting me on this! So this is not a problem in practice, as we don't
> care about the number of calls during the startup.
Argh, apologies for the confusion. In fact, after startup everything works
fine:
accept4(4, {sa_family=AF_INET, sin_port=htons(63699),
sin_addr=inet_addr("10.0.0.3")}, [16], SOCK_NONBLOCK) = 5
setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0
accept4(4, 0xbf9527bc, [128], SOCK_NONBLOCK) = -1 EAGAIN (Resource temporarily
unavailable)
recv(5, "GET / HTTP/1.1\r\nUser-Agent: curl"..., 8192, 0) = 73
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
fcntl64(6, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
connect(6, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("31.13.86.65")}, 16) = -1 EINPROGRESS (Operation now in
progress)
Also, if the hostnames are prefixed with ipv4@, strace show zero AF_INET6
activity. So forcing ipv4 will fix all ipv6 connectivity related problems.
> Well, it's still possible to do something. gai() was not supported in 1.4.
> So people who will notice a difference are those who would upgrade from
> 1.4 to 1.5 or simply from 1.5-devX to 1.5. In both cases these are not
> migrations that can be done without double-checking. And if someone is
> fool enough to upgrade from a major version to another one without at
> least ensuring that all servers are up, he's definitely trying to get
> harmed. So we could decide to use gai() by default.
I agree.
> But there are all the other cases. People who run code on servers they
> don't manage, where gai() does not work properly or is not configured
> in a way to return the same thing as ghbn(). These ones need an option
> to disable use of gai(), or to force ghbn() first as we do today.
>
> So we could have a global option to disable use of gai() even when it's
> supported so that they get the original behaviour again. The common
> example is ghbn() using /etc/hosts while gai() uses the DNS. For a
> number of users, this might not be an acceptable change.
>
> The reason for having this option to disable it instead of the opposite
> is that it will progressively fade away and we won't have to support
> such an interim option forever.
>
> What do you think about this ?
Let me see if we are on the same page:
- remove the USE flag USE_GETADDRINFO and use gai() by default
- implement a global config option to disable gai()
- gai(), if not disabled, would take precedence over ghbn() (Nenad's patch)
This way:
- a user can always force IPv4 by prefixing the server with ipv4@
- a user can disable gai() with the global config option
- the behavior doesn't depend on USE flags (which the user may not be able
change)
This way we are moving forward (ghbn() -> gai()), while we can still restore
the old behavior via configuration and we don't depend on USE flags to do so.
I like this and I fully agree with this approach.
Regards,
Lukas
