2017-02-13 15:42 GMT+01:00 Daniel Stenberg <daniel_at_haxx.se>:

> On Mon, 13 Feb 2017, David Requena wrote:
>
> This callback function gets called by libcurl as soon as there is data
>>> received that needs to be saved
>>>
>>
>> But it also says
>>
>> The callback function will be passed as much data as possible in all
>> invokes, but you must not make any assumptions. It may be one
>> byte, it may be thousands.
>>
>
> Yes. Is there a contradiction there you think? The first is comment about
> how soon it'll tell you, the second is how many times you can be expected
> to be told.
>

Not contradiction at all, just saying your doc quote is qualified by the
one y added.

> I think that implies the data is delivered fairly soon after getting
>>> received and not a lot of extra buffering.
>>>
>>
>> I would expect but nothing indicates that's actually the case :-(
>>
>
> I don't understand. Can you elaborate?
>

The implication you mention is *fairly* indefinite. There's nothing in the
docs asserting that "as soon as posible" actually means "soon" at all.

There is no hint about what the triggering conditions for the callback
>> invocation might be (some timeout with no received data, whole chunk
>> received, buffer 90% full, all of the former?, some of them?)
>>
>
> "as soon as possible"
>

There's exactly one absolute interpretation for ASAP in this context: as
soon as 1 byte is received. It's absolutely impossible relaying data before
having it.
Any other interpretation would require qualification as to how much data,
time or whatever other factors involved.

> At this point I'm at a loss. I'll be receiving some small data item every
>> couple seconds and cannot see how I'll be processing them in a timely
>> manner.
>>
>
> Why not?

The use case is the processing of Server Sent Events (plain old http by the
way, nothing fancy here):

- Client sends some http request
- Server sends response headers: content-type text/eventstream, etc
- Server does not close the connection and starts sending small, say 30
bytes a piece, text items every 1 or 2 seconds.
- The client is supposed to act on those events as they are received.

Now, if libcurl is willing to fillup a 16KB data buffer before invoking
CURLOPT_WRITEFUNCTION 16*1024/30 = 546 of those text items (or 18 minutes!)
before I get the chance to process the first one received. All of this
while libcurl remains fully compliant to the ASAP statement in the docs.
Admittedly the 546th item would be delivered to the callback quite fast by
the way

Arguably, setting CURLOPT_BUFFERSIZE to a small enough size would much
alleviate the problem, but that is explicitly not warranted to be honored
by libcurl.

> To me it seems like you're trying very hard to invent a set of problems
> that I don't think libcurl creates for you.

To me it seems your addressing some criticism on my side which is simply
not so.

I'm just asking for some details to see if the library in its current form
is usable for my use case. Alternatively there might be some better
approach which I'm not aware; that would be great.

As a last resort I might look into the sources myself to get my answers and
perhaps do some modifying. I'd rather be sure there's no officially
sanctioned way before taking that route.

-- 
Saludos / Regards,
David Requena

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-02-13