> 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?
 
Was the transfer type of FTP binary, or was it ASCII?
 
> 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.
 
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.
 
rick jones

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-12-05