On Wed, 9 Oct 2013, David Strauss wrote:

> In Curl_connecthost(), there's a loop to call singleipconnect() for each
> address. This loop breaks when it gets a non-bad file descriptor. But, 99%
> of libcurl invocations use non-blocking sockets, especially in the current
> era of even the "easy" interface using the "multi" back-end.

Only 99% ? I would've expected it to be 100%. libcurl always uses non-blocking
sockets internally and has always done so.

> This effectively causes singleipconnect() to "succeed" in all but the most
> catastrophic scenarios. libcurl then runs off with this file descriptor as
> the connection, even if the connection fails asynchronously.

What kind of cases are you refering to?

> Could we support iterating through IPs in a more useful way even with
> non-blocking sockets?

The function is supposed to be non-blocking so it would still have to return,
but of course it should then still detect failures and continue on to the
subsequent address if possible. Failing to do so is a bug!

> If not, could there be a flag to force blocking behavior to allow fail-over
> to occur?

That sounds like a really bad option really. We want more non-blocking
behaviors internally, not less!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html