On Wed, 4 Dec 2002 RBramante_at_on.com wrote:

> I put a freeware ftpd on that windows machine and the xfer takes about 5
> seconds, so the curl ftp xfer is abount 3x faster than the http one.

Indeed an interesting result, even if it matches my own tests. So how can the
ftp upload run so much faster when it is the same code in curl that is
executed?

> Very strange indeed. I also wrote a very dumb c app to do the http put and
> tested that. Again, it takes ~2 seconds to do the 1.6. So both the java
> app and my c app do it about the same. You can use it for testing. There
> is no error checking and it breaks about 100 rules of network programming,
> but it should serve its purpose for comparison.

Thanks for doing this. I'll run your test-program on the same machine I did
my previous tests on later tonight and see what happens.

> Since we spend so much time in select() I'm wondering how we do the
> read/writes. For example for write (since this is the current problem)
> when select() returns the socket as writable, do we do one send() and then
> go back and select() again, or do we send() until we get an EWOULDBLOCK and
> then go back and select()? If we are doing the former it might explain
> some of the latency. The same would apply for recv(). If readable, recv()
> until EWOULDBLOCK and only then go to the select().

Right. curl does it the "bad" way:

 1 - select()
 2 - when a writeable socket is detected:
 3 - read() data to send away (unless previous data wasn't sent off)
 4 - send() data
 5 - GOTO 1

I figure step 5 should be remade to a GOTO 3 until the send returns
EWOULDBLOCK.

The only weird thing is of course that ftp uploading is done the very same
way...

I'll do this:

First, I'll compile, build and run your test program on my test server. It'll
give me a good comparison on how fast it *should* be (at least it should be
in the same neighborhood).

Then, I'll rewrite the inner loop of the transfer logic to see if we can
achieve it that way.

I'll report my findings as soon as I have anything to share.

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf