#384949 rtorrent: Doesn't handle forgetfull (buggy) clients well

Package:
rtorrent
Source:
rtorrent
Description:
ncurses BitTorrent client based on LibTorrent from rakshasa
Submitter:
Goswin von Brederlow
Date:
2010-04-14 12:12:28 UTC
Severity:
wishlist
#384949#5
Date:
2006-08-28 07:42:55 UTC
From:
To:
Hi,

some clients seem to have bugs in the queueing code and forget
requests made to them. In particular I see this with a BitComet client
in the Transfer list view:

452 [P: 2 F: 0]KKKKKKKKKKKKKKKKkkkkkkkkkKKKKKKKKKKKKKKKKKKKKKKKKKkkkkkKKKKKKK
496 [P: 2 F: 0]KKKKKkkkkKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
503 [P: 2 F: 0]KKKKKkkkkKKKKKKKKKKKKKKKKKKKKKKkkkkkkkkKKKKKKKKKKKKKKKKKKKKKKK
508 [P: 2 F: 0]KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
645 [P: 2 F: 0]KKkkkkkkkkkkkkkkkKKKKKKKKKKKKKKKKKKKKKKKKkkkkkkKKKKKKKKKKKKKKK

The client is happily uploading at 20-50K/s to me but every now and
then it jumps a few chunks as you can see by the "k"s. This leaves
those blocks incomplete while it starts on more and more new blocks.

Rtorrent should notice that requests aren't replied to in the order
queued up and re-request the left out chunks.

MfG
	Goswin
#384949#10
Date:
2006-09-25 02:18:39 UTC
From:
To:
package rtorrent
tags 384949 upstream
thanks

Hi,

I'm letting know the upstream about this issue.

Jaris please see [1] for further information about the problem.

Thanks and Cheers!
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384949
--

~ghostbar @ linux/debian 'unstable' on i686 - Linux Counter# 382503
http://ghostbar.ath.cx/ - irc.freenode.net #talug #velug #debian-es
http://debianvenezuela.org.ve - irc.debian.org #debian-es #debian-ve
San Cristobal - Venezuela. TALUG -- http://linuxtachira.org
CHASLUG -- http://chaslug.org.ve - irc.unplug.org.ve #chaslug
Fingerprint = 3E7D 4267 AFD5 2407 2A37  20AC 38A0 AD5B CACA B118
#384949#17
Date:
2006-09-27 10:39:10 UTC
From:
To:
This should be fixed in the latest release, but I didn`t test it very much.

Rakshasa


Furu-Furu-Furu Moon!
#384949#22
Date:
2006-09-29 01:21:50 UTC
From:
To:
jaris@student.matnat.uio.no escribió:

Hi, are you having this problem yet? upstreams have sent an email
telling this is probably fixed in the last release (0.6.2)

Thanks and Cheers!!
#384949#25
Date:
2006-09-29 01:21:50 UTC
From:
To:
jaris@student.matnat.uio.no escribió:

Hi, are you having this problem yet? upstreams have sent an email
telling this is probably fixed in the last release (0.6.2)

Thanks and Cheers!!
#384949#30
Date:
2006-09-29 21:16:31 UTC
From:
To:
Jose Luis Rivas Contreras <ghostbar38@gmail.com> writes:

I still see the problem but not rtorrent stalling on it
currently. Could just be the torrent.

What was fixed? The forgetting or the stalling part?

MfG
        Goswin
#384949#35
Date:
2006-09-29 23:39:17 UTC
From:
To:
Goswin von Brederlow escribió:
I don't know wich part exactly, I think both cause he says that this
probably should be fixed by last version. Have you seen any of this in
rtorrent? Do you think is problem of the torrent a not of the app?

Thanks and Cheers!!
#384949#40
Date:
2006-10-02 20:52:00 UTC
From:
To:
Jose Luis Rivas Contreras <ghostbar38@gmail.com> writes:

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
#384949#45
Date:
2006-10-03 02:40:54 UTC
From:
To:
package rtorrent
tags 384949 confirmed
severity 384949 wishlist
thanks
Goswin von Brederlow escribió:
[...]
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.

Thanks for your report!
Cheers!!
#384949#54
Date:
2006-10-03 09:34:29 UTC
From:
To:
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
#384949#59
Date:
2006-10-04 00:17:12 UTC
From:
To:
jaris@student.matnat.uio.no writes:

Too much data?

You usualy have 5-20 chunks active and about as many clients. In the
problem cases as little as one for the chunk.

The "transfere list" still shows the skiped fragments for a while
after the skip while the "peer list" shows a 0 queue, so you seem to
already remember it somewhere. You also remember what fragment of each
chunk was downloaded from what peer. Given that the skips are usualy
small compared to the number of fragments in a chunk (say 5 in 200)
that doesn't seem like much data.

Now, instead of just forgetting the skipped requests they could be
rerequested from the same client while ignoring the chunk availability
of that client. I think that could already do the trick.

What I see is that I have clients in the "peer list" with 100% done
status but the "chunks seen" display shows gaps in the torrent with 0
availability. I'm assuming those are super-seeders, right?

MfG
        Goswin