On Fri, 15 Aug 2008, Andrew Barnert wrote:

> I've been investigating incorporating HTTP tunneling into a
> boost-asio-centered tool. Writing all the HTTP stuff myself is no fun; I'd
> much rather use libcurl. But I need the same asio engine to manage all of
> the sockets, concurrency, etc., whether they're curl-tunneled or native.
> After looking over the libcurl APIs, there appears to be no way to do what I
> want.

I have no idea what you want. I don't know boost nor boost-asio.

> I found a thread from 2005 (http://curl.haxx.se/mail/lib-2005-11/0011.html)
> where Cory Nelson tried to explain exactly this problem to Daniel, but they
> never quite connected; the conversation went onto a side-track about
> threading and cancellation, but the real problem was never mentioned-- ready
> notifications (or non-blocking sync I/O) vs. completion notifications (or
> async I/O, aka "overlapped" in MS terminology).

Well, at the time I was planning the socket API and what Cory then suggested
and talked about didn't match with what I was going to write. I must admit I
still don't know what IOCP is or how it works.

> Ultimately, if your API is designed right, the difference is just where the
> buffers go. So, here's what would need to be changed: Add a new callback
> curl_socket_async_callback (and a new CURLMOPT). This takes an extra (void
> *)buffer and (size_t)len. It does the async, and it's expected to do an
> async read, write, or both, then call curl_multi_socket_async_action on
> completion. This takes (size_t)bytes (actually read or written), and uses
> the existing buffer instead of reading or writing, but is otherwise the
> same.

I don't quite understand this brief description. Can you add some more psuedo
code for a client using this suggested API?

In my view, asynchronous is mostly just another word for running the stuff in
another thread until it has something, and then have a means of telling the
first thread when it is done. And you can use libcurl fine already for doing
exactly that.

> There's only one problem: SSL, SSH, and Kerberos.

That sounds like three problems to me! ;-)

> These are all wrapped by using their send/recv replacements, and you
> obviously can't just tell Windows or boost.asio to do an overlapped OpenSSL
> SSL_send call.

Now you lost me again. Are you saying that you need to base this functionality
on same particular magic functions of the OS to make it working? Or why can't
these other protocols be made to work the same way?

And do note that we support SSL with several other libs as well, not just
OpenSSL...

> Anyway, I think it may make sense for me to hack up libcurl myself to do
> what I want, and just break the SSL, SSH, and Kerberos support. But I doubt
> that has any use to the rest of the community, except maybe as a proof of
> concept for how things could be done properly.

Right, adding an API or mechanisms for libcurl that doesn't work for SSL, SSH,
and Kerberos seems like something I'd have a hard time to accept.

-- 
  / daniel.haxx.se