> > for url in urls
> > do
> > curlObj->set(url)
> > curlObj->perform()
> > do whatever you want with the data retrieved
> > done
>
> Which sends one header, waits for the round robin, read all the
> data, send second header, wait for the round robin, read, send, wait,
> read, send, wait, read.
>
> Notice all that waiting? If I have to do 10000+ requests all that
> waiting accumulates to a severe performance penalty.
No actually I dont notice it sorry because it doesnt happen.
It depends what do you call 'round robin' but nevertheless with any method
of load balancing you use (dns/cookie whatever): once the TCP connection is
made on the chosen server it is still open for the next transactions (what
you call send header/read data).
It is the purpose of the keepAlive thinggy and the difference between curl
and lot of other similar get programs is that curl doesnt cut the connection
between perform !

So unless you have a weird and innefficient load balancer the pseud code
above will do :
Make a tcp connection/waits for your round robin
sends header
read data
sends header
read data
...

until either your server close the connection because of internal
configuration / waited too much / client disconnect / network pbs. (which
may happen if you have 10000+ requests) but curl will still be able to
recreate the connection when needed or r-e-u-s-e the previous one if it is
available.

> Which sends one header, waits for the round robin, read all the
> data, send second header, wait for the round robin, read, send, wait,
Actually with curl or any other program that internally does what you say
only one perfom with 10000+ files plz give us how http will handle this in
only ONE header/read data, data, data, data.

Dont mix HTTP layer and TCP layer.
____________________
<Gu>[W]ill[i]a<u>m<e>
http://www.lacde.net
----- Original Message -----
From: "Goswin von Brederlow" <brederlo_at_informatik.uni-tuebingen.de>
To: "libcurl development" <curl-library_at_cool.haxx.se>
Sent: Friday, November 26, 2004 12:19 PM
Subject: Re: libcurl question, Range support for http

> "Guillaume Arluison" <ga_at_lacde.net> writes:
>
> >> > 1. Any support for Range in libcurl I didn't see?
> >> >
> >> > I saw that you can add custom headers but would libcurl handle the
> > server
> >> > responces right?
> >>
> >> It depends on what you think is "right". It will pass the response-body
to
> >> you unaltered.
> > In fact with "more details" it's the server that will handle your
request
> > differently with a Range present and should send to curl only the bits
you
> > wanted (only if 1.1 actually), curl doesnt see and doesnt care the
> > difference : it's raw data for him anyway. So you ll have the wanted
100Kb
> > of your mp3 instead of having 3 Mb in return, it's up to you what you do
> > with them. :)
> >
> >> > 3. Can I queue up a multitude of requests onto one easy_handler and
then
> >> > perform them all?
> >>
> >> Nope.
> > To be even more precise to this and the other mail from Dan, what you
ask is
> > exactly what an easy_handler can do for you it's just that YOU have to
> > manage the loop of elements to download instead of having it "inside
curl".
> > Actually it is much more efficient this way :)
> > Which means depending on your binding :
> > for url in urls
> > do
> > curlObj->set(url)
> > curlObj->perform()
> > do whatever you want with the data retrieved
> > done
>
> Which sends one header, waits for the round robin, read all the
> data, send second header, wait for the round robin, read, send, wait,
> read, send, wait, read.
>
> Notice all that waiting? If I have to do 10000+ requests all that
> waiting accumulates to a severe performance penalty.
>
> > And curl is clever enough to reuse the same connection in the curlObj so
if
> > your server doesnt close it (or any rare pb on the network) you ll be
stick
> > to only one server with no dns/conenction delays for the other
transfers.
> >
> > Hope this helps.
>
> Nope, I knew I could do that already.
>
> MfG
> Goswin
>

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.789 / Virus Database: 534 - Release Date: 09/11/2004