Okay, That makes complete sense. I would be completely happy with returning
something from CURLOPT_SOCKOPTFUNCTION to indicate I do not want libcurl to
try and connect the socket.

Sorry for the misunderstanding.

Cheers,
Keean.

On 8 February 2011 22:09, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Mon, 7 Feb 2011, Keean Schupke wrote:
>
> Can't we instead add a new return code to the CURLOPT_SOCKOPTFUNCTION
>>>
>>
>> The OPENSOCKETFUNCTION returns the socket as its return value, so unless a
>> structure is returned then I don't see how this can easily be done.
>>
>
> Now, if you look again you'll see that we're not talking about the same
> callback function...
>
>
> We could test the socked with "getpeername" to see if it is connected? If
>> getpeername(...) returns an error the socket is not connected. Something
>> like:
>>
>> if (getpeername(socket, &addr, len) < 0) {
>> rc = connect(socket, &addr, len);
>> }
>>
>
> Right, but that too adds assumptions that the socket is connected in a way
> I rather avoid. If we want to allow the app to provide a file descriptor, I
> would like to make as few assumptions as possible about what the nature of
> that descriptor is (and requirements of what it has to be). It doesn't have
> to be a TCP based socket for all I care...
>
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-02-09