On Tue, October 3, 2006 04:40, Jose Luis Rivas Contreras wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > package rtorrent > tags 384949 confirmed > severity 384949 wishlist > thanks >> I now think it is a combination of things: >> >> 1. clients sometimes forget requests, they skip ahead. >> 2. rtorrent tries to reget those holes after a while (which seems to >> work much better now) >> 3. super-seeder hide chunks they have served >> >> If you combine those 3 it seem that rtorrent looses a source for the >> chunk with the hole and if there aren't any other sources the block >> will remain incomplete and stall the download till the superseeder >> resets itself. At least that is what it looks like now. >> >> >> I'm not sure what to do about this. It isn't really a bug in rtorrent >> but we can't fix every other client out there. >> >> Rtorrent could better remember that some client did have that chunk >> and re-request it even if that client now says it isn't available >> anymore. I.e. ignore the super-seeder hack. Unless the super-seeder >> will NAK such requests. >> >> MfG >> Goswin >> > Ok, so since this isn't a problem of rtorrent, but you add a request for > feature to rtorrent I'm changing this to severity wishlist. > > Plus, I'm sending this to upstreams.
That's too much data to keep around, so it won't be implemented. It might be an idea to add a limit on request pipe-line size on a per-client type basis, so I added a ticket (#484) for that. The super-seeder can't really hide chunks, so it must be a problem of the super-seeder restarting/being reconnected. Anyway, it would have to be a bad super-seeder implementation, not to mention super-seeding has been superseded by Fast Extension so the incentive isn't really there to use resources to fix this. Rakshasa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
