> > 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?
>

Yes, sockopt is a better alternative. I have attached a patch using this
callback instead.

Best regards,
Mehmet.

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