[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hashsum mismatch prevention strategies



David Kalnischkies wrote:
[...]
> (Unfortunately nobody at Google noticed the irony yet that they enable
>  pipelining in chromium by default ~3 weeks ago, but deliver chromium
>  over a broken server… not to mention SPDY which has an emphasis on
>  multiplexing and pipelining…)

Filing a report against chromium (.org) might help. At least it is easier to 
ask somebody who works at Google to try to contact somebody who might me 
able to do something about it once there's a report somewhere.

> In the end apt-get (and friends) breaks unreproducible "sometimes" with
> a pretty indistinguishable errormessage, so a user will properly never
> understand what is going on. The benefit from pipelining isn't that great
> to ratify this - at least in my eyes (after all, high latency connection
> with a high bandwidth aren't that common - usually you have low/high or
> high/low combination. In the later the benefit from pipelining is easily
> eaten up by the size of the files we need to acquire in general).

Do you happen to know what are the usual symptons besides the out of order 
responses?

I'm thinking that given that the downloaded data has already been hashed 
(and hence the mismatch is detected), the method could check if it maches 
the hash of one of the other requested files.
There might be some issues with the cyclic queues that are used, but they 
shouldn't be too hard to fix.

What do you think?

> Also, currently pdiffs aren't downloaded in a pipelineable fashion, so
> this isn't even a regression in this regard, but would be an added
> improvement in case we come to a point in which pipeline is enabled by
> default again.

Yes, hence my comment about not gaining _that much_ if all the necessary 
pdiffs are known in advance, if pipelining is disabled.


P.S. I really should file a wish bug about adding support for RFC6249. I've 
coded some bits already, mainly focusing on a way to reduce the number of 
requests to, say http.d.n, for .diff/ files.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net



Reply to: