On Thu, 16 Sep 2010, Mehmet Bozkurt wrote:

> First, in the case of CURLSOCKTYPE_IPCXN the client is supposed to return a
> valid socket which is later used for a connection. But in my particular
> scenario, I'm only interested in checking the data channel ip, and will
> return CURL_SOCKET_BAD if the check fails and a 'dummy' socket, which is not
> used on return and is thrown away, if the client should continue with the
> accept. So for CURLSOCKTYPE_IPCXN I return something that is used in the
> calling code but for CURLSOCKTYPE_FTPDATACXN fail/pass is returned. So it
> feels like the semantics of the callback isn't consistent. Or?

I agree, it feels awkward. I don't think we should introduce a way that forces
the application to do such a useless create-socket-just-to-get-it-closed
stunt.

Would it be possible to instead use CURLOPT_SOCKOPTFUNCTION?

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