Re: libCurl does not send data using multi interface on high latency connections
Date: Thu, 13 Sep 2018 09:05:36 +0200 (CEST)
On Wed, 12 Sep 2018, Nicolás Bagnasco wrote:
> Sadly I am the maintainer of an old app which is not mine, and some parts of
> the networking code that handles http connections uses the same code from
> the asiohiper example.
It reminds us of the importance to make sure the examples are correct and
working as they should. It is tricky, because we also want to have a low bar
in accepting new examples as examples are a very good way to show people how
the library can be used...
>> In that situation libcurl should've already told your app that it wants to
>> wait on that socket to become writable and when it does (when it can send the
>> request over it), you should've called libcurl telling it about that fact. Did
>> that happen or not?
> I'm not sure about what you are trying to tell me here but I assume
> that you are referring to CURLMOPT_SOCKETFUNCTION.
> If that's the case, I think I need to understand what's going on with
> the CURL_POLL_IN and CURL_POLL_OUT events because it seems that it's
> handled in the example, I don't know however if it's handled the way
> it should.
The CURLMOPT_SOCKETFUNCTION is informed by libcurl that "hey, please wait for
WRITABILITY (CURL_POLL_OUT) on socket X" after the connection has been
established, and once boost::asio then notices that the socket is ready for
"writing", your application should call curl_multi_socket_action() telling
libcurl about this event.
That's pretty much the gist of how the event-based API works. libcurl tells
the app what to wait for (and a timeout). The app then tells libcurl about the
event when it happens.
When you say libcurl never sends the request of the connection, we need to
figure out what activities (CURL_POLL_IN / CURL_POLL_OUT) curl asked you to
wait for and what activities on that socket you told libcurl to act on with
-- / daniel.haxx.se
Received on 2018-09-13