Hello,

I would like to fail transfers that don't have a connection immediately available.

As far as I've seen, the way curl currently works now, if a connection isn't available, or pipelining / multiplexing is full, then the requests returns CURLE_NO_CONNECTION_AVAILABLE and it is put on the pending queue:

https://github.com/curl/curl/blob/3ff09ce777b95ad7f07544325de01983c40e2dc3/lib/multi.c#L1421

I was hoping there might be something like a value for CURLOPT_CONNECTTIMEOUT_MS that could indicate to never wait at all (unfortunately 0 means default not 0ms). As far as reading the documentation it seems like the best that could be done is setting a connection timeout for 1ms.

In my situation, waiting 1ms is already too long. Basically the behaviour I am looking for, is to create a request, and if that request is not able to be serviced immediately (or well, lets say if we know that it cannot be serviced immediately), then it would not be put in the pending connect queue but just immediately fail. Something like a conceptual timeout value of -1 to signify to never wait, never queue.

It is a little bit difficult, and I don't think particularly relevant to this list, to explain the exact details / justification for our situation, but basically we have multiple transport options, and if we know we might have to wait at all for the request in a pending state that we would much prefer to know that right away, fail the request, and to send it out via another channel. You can imagine wanting to do something like this in a load-balancer type situation (where curl is not internally managing all of the connections).

I am not sure if the best proposal would be an additional flag via setopt, or a special value of for the connection timeout setting.

It seems an additional possibility, which I haven't explored, would be to somehow on my application side query the state of the easy handle and try to cancel it immediately once it has gone into the CONNECT_PEND state. The timing here might be tricky from the applications perspective, since it won't go through the state transfer immediately upon the handle being added, the multi action needs to be pumped a bit, so it is sort of fragile to try to do that ones self and know exactly when is the right time to query the handle.

And anyway, additionally I would prefer if it just entirely skipped the timer setup / enqueuing / etc that goes on at the CURLM_STATE_CONNECT state.

I realise this is perhaps beyond typical usage, but I also think it could make sense for other applications as well. I appreciate any feedback. My current thought would be adding some additional flag to indicate that the connection phase should never wait, and fail immediately instead of being queued. I know it is probably not desirable for curl to have a million flags for every possible tiny detail, so I am open for any suggestion about how to do this without compromising efficiency or adding any additional delay or tricky logic around querying the handle state.

Thank you very much,

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-03-21