Comment #12 on issue 23364 by [email protected]: Chrome does not fall back  
to IPv4 when using IPv6 fails with Webpage Not Available
http://code.google.com/p/chromium/issues/detail?id=23364

I don't think this has anything to do with my previous bug either.

If connect() timed out and there were no more addresses to try, we'd be  
seeing
ERR_CONNECTION_TIMED_OUT, not ERR_TIMED_OUT.  See
net/socket/tcp_client_socket_libevent.cc net::(anonymous
namespace)::MapConnectError().

If connection fails with ERR_TIMED_OUT, it would seem to mean that a  
higher-level
timeout was triggered.  That would seem to be
net/socket/client_socket_pool_base.cc net::ConnectJob::OnTimeout(), which  
is called
when timer_ fires.  timer_ is set by Connect() to fire after  
timeout_duration_.

The problem would seem to be that in order to fall back from the black-holed
address to the next one in the list, we'd need for connect() (lowercase c,  
the system
call) to time out sooner than Connect() (uppercase C, our higher-level  
method).

Unfortunately, the connect() timeout is unspecified.  Mac OS X 10.5 and  
10.6 both
seem to use 75 seconds for blocking connect().  Linux 2.6.28 (Ubuntu 9.04)  
seems to
use 189 seconds.  (Remember, I did not use O_NONBLOCK for these tests like  
we use
in Chrome.)

I wonder why we've established our own higher-level timeout around this.   
The
timeout in question appears to be net/socket/tcp_client_socket_pool.cc
net::kTCPConnectJobTimeoutInSeconds, which is 60.  60 seems very low.

Maybe we could also cancel individual connect() attempts sooner than the OS  
default
timeout.  I don't really love this approach, but it might make sense to  
protect against
systems with ridiculous 189-second timeouts.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

--~--~---------~--~----~------------~-------~--~----~
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
-~----------~----~----~----~------~----~------~--~---

Reply via email to