> I can't but to think that if we'd make an effort to better
> support this,
> wouldn't it make sense to make the flow-control more
> detailed? I mean perhaps
> set a "receive window" that tells libcurl how much data you
> allow to be sent
> to the callback and libcurl will not deliver any more until
> you set it again
> to something > 0 ? Or is that just to overdo it?

I'm sure it could be made arbitrarily complex. For my purposes, I was just
looking for the guarantee that a single call to curl_multi_perform() would
not give my application more than CURLOPT_BUFFERSIZE bytes of data. In
order to accomplish this, I turn off decompression by setting
curl_easy_setopt(easyhandle, CURLOPT_HTTP_CONTENT_DECODING, 0) and I made
those two modifications to libcurl.

If you made a sliding window, it would have to be on an easyhandle basis,
and you might end up with a lot of calls to curl_multi_perform that would
return little or no data. I don't see a big benefit coming from this
complexity.

I think for maximum efficiency, and consistent with the "pull" philosophy,
an application should only call curl_multi_perform when it is ready to
accept CURLOPT_BUFFERSIZE bytes of data from each easy handle in the
multiset.

I would then focus on streamlining the code path so that curl_multi_perform
can return and then resume as quickly as possible the next time it is
called, with minimal overhead. This would reduce the penalty of repeated
calls to curl_multi_perform and make more complex optimizations like a
receive window unnecessary.
Received on 2007-06-25