On Thu, 5 Dec 2002, Rick Jones wrote:

> > 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?
>
> Does a server have to scan all the bytes of an HTTP put?

No. A HTTP PUT is just headers and then a binary stream of data. The headers
even contain size information.

> Was the transfer type of FTP binary, or was it ASCII?

I used binary. But I'll follow up in a second mail and you'll see this was
only due to Apache being slower than the ftp server.

> Something like that - but I'd probably start with step three and not
> step one. So:
>
> 1) read() data to be sent away (unless previous data remains unsent)
> 2) send() data
> 3) if not all data sent, select() else return
> 4) when socket writable goto 1

> I suspect that before one gets an EWOULDBLOCK send() would return a length
> of bytes written that was < the requested len, so perhaps checking for that
> first would be better as it would then avoid a send() call that would
> simply return EWOULDBLOCK.

I've now done some modfications, and it now works like this:

 1. select() until socket is writable
 2. read() data to send (unless data was left from previous round)
 3. send() as much as possible, if less than full buffer GOTO 1
 4. GOTO 2

Another mail coming in a sec.

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