Daniel Stenberg wrote:
> It works fine anyway. This is because when the speed limit is reached,
> libcurl takes away the socket of that too-fast-transfer from the list
> of sockets the app will wait for until the speed is again below the
> threshold and then it gets reinstated.

Aha, ok. And the speed limit is per easy handle then also?

>> Would it be possible to implement a feature that would let a multi
>> user switch off the connetion pool feature of the multi interface,
>> and so to get access to more detailed control over easy handles even
>> in multi mode?
>
> While I figure it would be possible to somehow run
> connetion-pool-less, I don't understand the reasoning. What benefits
> would such an ability provide to apps?

Well, if the speed limit works just as it does in easy mode, then one
reason for disabling connection pooling just disappeared. I have another
reason though, maybe :-) We want to simulate a number of web browsers,
each using a number of TCP connections to fetch objects over HTTP. We
want to limit the amount of TCP connections available to *one* of our
simulated browsers, but the CURLOPT_MAXCONNECTS option will not work in
multi mode. CURLMOPT_MAXCONNECTS, on the other hand, limits the whole
multi handle. We want to limit an easy handle within the multi handle,
but that isn't possible.

I suppose we could use one multi handle for each simulated web browser,
and set CURLMOPT_MAXCONNECTS to the number of TCP sessions a single
simulated browser client may use, but it seems a bit messy when you want
to simulate thousands of browser clients and I'm a little worried that
memory consumption will be high, but I haven't tried it - maybe it won't
be so bad?

Regards,

  /Ragnar
Received on 2009-07-06