On Mon, 9 Jul 2018, Bernardo Pastorelli wrote:

> Looking at the source code it appears that libcurl retrains full control on
> the read and write operations to the socket. Am I missing any alternative
> that would allow me to gain control of the read and write operations to the
> socket so that I can add the control bytes required by my multiplexing
> implementation?

libcurl doesn't offer that feature, no.

> In case I would try to develop a patch that would allow supporting my
> scenario, which would be the best way to implement it? I was thinking about
> the capability of registering callbacks for the socket recv and send
> operations, as it is currently possible for socket open, close and sockopt.
> The limitation of this approach would be that it would work just for some
> protocols: for example https delegates the read and write to the socket to
> the ssl library (for example openssl) or the ldap protocol uses the ldap
> functions. Anyhow it would work for the plain http protocol. Any other
> alternative?

In a world where HTTP is gradually going away for the benefit of HTTPS, I
would be against adding a feature like this that doesn't work with HTTPS.
Most, if not all, TLS libraries these days support creating the data to send
in a buffer instead of using the socket directly. Supporting HTTPS is of
course a lot more work.

But the send and recv functions might be the easy parts to fix.

Functionality wise, if you replace recv. How can libcurl tell when there's
data to read from the socket that isn't a socket? Or when the socket that
isn't a socket is ready to get data sent to it? Those are rather fundamental
parts of the library and they too are currently using the socket API functions
directly now.

Don't you need pretty much all socket-API functions libcurl use to be
callbacks too for this to work?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html