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
