On Tuesday 13 June 2006 08:25, Daniel Stenberg wrote:

> "separate calculations" ? You mean separate for read and write? Yes it
> does, since it has two different limits and the logic for the callbacks is
> actually somewhat different so it is necessary to do them differently
>

I meant separate from speed calculations done in progress.c I'd like to
see if I can get something to work leveraging progress.c rather than having
similar information calculated independently as is done in the command-line
implementation.

Progress is already calculating both average ul and dl speeds. I just want to
make a simple calculation based on the pre-calculated values from progress.c
to determine a next time to notice...

The other thing is... Curl_readwrite is scarily complex and long. I wanted to
do a calculation outside of that routine, either before or after. trouble
is, I don't know if I am reading or writing at that point. So How do I
figure out which limit to apply?

> Sounds perfect. I can only think of two minor improvements:
>
> 1 - it could work for all states, and when it goes into
> CURLM_STATE_TOO_FAST it could save the previous state so that it can go
> back to the very same one afterwards. This is just an nitpick though since
> I guess this condition will only occur in CURLM_STATE_PERFORM - but it
> would mostly be a matter of writing code that would be more reliable for
> future changes.
>

I would prefer simplest possible first... transition from CURLM_STATE_PERFORM
to CURLM_STATE_TOOFAST and back for now, can always add a stack later.

> 2 - when you calculate for how long the app can/should wait until it
> calls curl_multi_perform() the next time it should set that time with
> Curl_expire() since then nice upcoming apps that use curl_multi_timeout()
> will work just perfectly with this concept too.
>

will look... that's only in CVS... nicer to have a stable base to build
patches from.

> > The thing is... I don´t have an easy way to test the ´easy´ calls / multi
> > routines in libcurl... does someone have something command line I can
> > invoke for testing? All I can check for is lack of breakage in the 500
> > series of tests.
>
> Some of them are using the multi interface, so you could take one of those
> (or one of the docs/examples codes) and convert into a little testing app
> for your own purpose.
>

on separate limits for each direction of transfer:

I don't know the code at all, so as someone far away...

I do not want to touch curl_readwrite if I can possibly avoid it... serious
voodoo happenning there.

I saw that putting the throttle logic before calls to Curl_readwrite (in
transfer.c and multi.c) would work, confirmed with initial (-Z patch) trial.
If I look at both routines, neither differentiates between reading and
writing. I do not see how to guess which direction a particular transfer is
going in order to apply the correct limit. Ideas?
Received on 2006-06-14