Re: [Help-gnunet] INDIRECTION_TABLE_SIZE and download speed

[Tracy R Reed]

On Fri, Sep 06, 2002 at 01:40:10PM -0500, Christian Grothoff spake thusly:
> So probably the files were not available (or only fragments were, or they 
> were 
> on a node that went offline (or on- and offline)), this is p2p, so it's 
> possible that the other side is not available. And since it's anonymous p2p, 
> you can't just "test" if the other side is available since you're not 
> supposed to be able to tell who it is. 

I see. They seem to take off fairly quickly at first and then really slow
down and stop.

1900544 of  6815347 (last: DF22BFDB897E671F917E51664E4A5AE1122F3A2C) at 785 bps 
(average), 6260s to go

And it's pretty much come to a halt. Is it unreasonable to try downloading
an mp3 at this stage? Would larger blocksize help? 1k seems kinda small
anyhow.

> The reason is, that we get the blocks in random order. The code also checks 
> if 
> we already have an idenitical file on the drive, and if yes, these pieces are 
> not downloaded again. Since the pre-existing file may be longer than the new 
> file, the first thing we do is truncate (or lengthen) it to the "right" size. 
> This is what you observed.

Makes sense. Thanks.

-- 
Tracy Reed      http://www.ultraviolet.org

pgp3DGG7XUGLm.pgp
Description: PGP signature