Thanks for your answer.

On 02/16/2017 12:18 PM, Daniel Stenberg wrote:
> It seems to work for me on Linux. When we build curl debug-enabled, it
> also builds a version of the main loop that uses the event-based
> system internally and I can then try that URL like this:
>
> $ ./src/curl --test-event 127.0.0.1:1
> curl: (7) Failed to connect to 127.0.0.1 port 1: Connection refused
Oh, I will try that when I get back on windows then.
>> After those 200ms, curl checks that the socket is indeed connected
>> (CURLM_STATE_WAITCONNECT in multi_runsingle() in multi.c),
>
> The state machine will stay in that state until a connect is verified
> or failed, so yes. But for a failed connect, the socket should get a
> signal too and the regular "monitoring" of the socket should get
> triggered, libcurl should get called again and the failed connection
> attempt get noticed.
That's the problem, I don't know how this "monitoring" works during
connection. From what I understand of the multi API, curl will call my
opensocket callback, and I must return a new socket, but not connect it,
then curl will do the connect() by itself. So I don't think I can signal
curl that the connection is complete or not, and I don't know how curl
can get that event either.
>
> What I don't understand is why you need a timeout. The failed
> connection should get noticed on the socket descriptor itself. That's
> the actual reason for this problem.
>
I may have not been clear enough. We agree on that, I don't want a
timeout but a "connection refused" error as soon as possible. And on
windows, I only get a timeout depending on the CURLOPT_TIMEOUT I have set.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-02-16