Quick update:

PUT/upload compression is done manually in our codebase (dunno if
automatic is even possible), thus READ_FUNCTION if enough here (this
app doesn't use form post)

GET/download data can be seen compressed (on HTTP level, not SSL) via
DEBUG_FUNCTION with data_type==3, despite automatic decompression by
libcurl, which is enough too!

Thus the combination of the two is apparently enough to throttle both
uploads and downloads :)

d.

On 25 January 2016 at 00:09, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Fri, 22 Jan 2016, Dima Tisnek wrote:
>
>> I'm trying to code up a multithreaded network throttle. That is I want to
>> throttle total network utilisation, as opposed to a single connection.
>>
>> I'm thinking what's the best way to grab actual number of bytes sent /
>> received on the network.
>>
>> read function / write function are not correct due to possible compression
>
>
> Then you just need to make sure you don't uncompress the data automatically
> and it shouldn't be a problem! TLS compression is considered bad anyway
> these days so I would guess that's now pretty rare.
>
>> I've tried to follow SSL in / out from debug function with verbose 1, but
>> it seems I don't actually get all the data, rather I get ssl headers or
>> something like that (typical data len == 5, apart from a few packets
>> (certificates?))
>
>
> Yeah, the SSL in/out stuff is just some data during the handshake and it is
> not the full payload through the transfer.
>
>> What's correct hook-up here?
>
>
> Don't tell libcurl to uncompress data for you and just use the debugfunction
> I guess.
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2016-01-27