On Sun, Jan 09, 2005 at 02:46:06PM +0100, Robert Lemmen wrote: > - zsync fails if the server returns less ranges than requested. i have > not yet reproduced that one as i didn't get around to talk my web > server into returning less ranges, but i think the proper handling > would be to remember how many ranges were returned and request only > that many from now on.
Interesting; this has lots of potential interactions with HTTP pipelining and HTTP/1.0 vs HTTP/1.1 negotiation (e.g. if we have already sent pipelined requests to the server for later ranges before we find out that earlier ones are unsatisfied). The current code can cope with this particular case, as we don't send a second request until we see the response headers of the first - but this is going to be slow, if the server is sending only one block per response. HTTP is not a very efficient transport for the data zsync needs if the server doesn't do multipart responses - it raises the overhead from HTTP headers a lot, as discussed in <http://zsync.moria.org.uk/paper/ch02s04.html>. It's even worse for HTTP/1.0 only servers, as they will only be able to transfer one block per connection. The overhead of a connection per 1024 or 2048 block will be quite intolerable. What web server are you seeing this no-multipart behaviour with - is it a particular configuration of a common server, or a standard behaviour of an uncommon httpd, or what? Anyway, the current failure is unintentional and I will fix it, but I bet the performance is still very sub-optimal. I may well blacklist servers with certain zsync-unfriendly behaviour - I don't want it connection-flooding bad web servers - if we find these are a problem. I have fixed the proxy-string bug for the next release BTW (#289424). -- Colin Phipps <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
