Bug#384949: Doesn't handle forgetfull (buggy) clients well
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]
Bug#384949: Doesn't handle forgetfull (buggy) clients well
[EMAIL PROTECTED] writes: 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. 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. 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. 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? Rakshasa MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384949: Doesn't handle forgetfull (buggy) clients well
Jose Luis Rivas Contreras [EMAIL PROTECTED] writes: Goswin von Brederlow escribió: Jose Luis Rivas Contreras [EMAIL PROTECTED] writes: [EMAIL PROTECTED] escribió: This should be fixed in the latest release, but I didn`t test it very much. Rakshasa On Mon, September 25, 2006 04:18, Jose Luis Rivas Contreras wrote: 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 Furu-Furu-Furu Moon! 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!! 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 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!! 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
Bug#384949: Doesn't handle forgetfull (buggy) clients well
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 package rtorrent tags 384949 confirmed severity 384949 wishlist thanks Goswin von Brederlow escribió: Jose Luis Rivas Contreras [EMAIL PROTECTED] writes: Goswin von Brederlow escribió: Jose Luis Rivas Contreras [EMAIL PROTECTED] writes: [...] Thanks and Cheers!! 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 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!! 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. Thanks for your report! Cheers!! - -- ~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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFIc22OKCtW8rKsRgRAr7EAJ9+PSs0XdWiuNzC5NrEsaki3k8l3wCghsLH 2v103JMoqYrbQLYrL2/E2q0= =wcJ3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384949: Doesn't handle forgetfull (buggy) clients well
Jose Luis Rivas Contreras [EMAIL PROTECTED] writes: [EMAIL PROTECTED] escribió: This should be fixed in the latest release, but I didn`t test it very much. Rakshasa On Mon, September 25, 2006 04:18, Jose Luis Rivas Contreras wrote: 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 Furu-Furu-Furu Moon! 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!! 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
Bug#384949: Doesn't handle forgetfull (buggy) clients well
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Goswin von Brederlow escribió: Jose Luis Rivas Contreras [EMAIL PROTECTED] writes: [EMAIL PROTECTED] escribió: This should be fixed in the latest release, but I didn`t test it very much. Rakshasa On Mon, September 25, 2006 04:18, Jose Luis Rivas Contreras wrote: 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 Furu-Furu-Furu Moon! 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!! 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 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!! - -- ~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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFHa6lOKCtW8rKsRgRAlUrAJ42351J5tIz0lPb6T6gWr1J4VToEgCePzIW flTFBBew5jgaWExiirRlPZ8= =lNCl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384949: Doesn't handle forgetfull (buggy) clients well
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] escribió: This should be fixed in the latest release, but I didn`t test it very much. Rakshasa On Mon, September 25, 2006 04:18, Jose Luis Rivas Contreras wrote: 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 Furu-Furu-Furu Moon! 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!! - -- ~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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFHHUuOKCtW8rKsRgRAsRyAKC4koKySmfSmZ38r93fOTpN5X1B5ACfW8xZ TDWIpJ332gu7ZtB7h1uXyWk= =U8Dv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384949: Doesn't handle forgetfull (buggy) clients well
This should be fixed in the latest release, but I didn`t test it very much. Rakshasa On Mon, September 25, 2006 04:18, Jose Luis Rivas Contreras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFFzx+OKCtW8rKsRgRAmzwAKCZI5SwUU3NbpY1eesVpV5l3wfyiwCgtw8V 2lOFCkvEMLPdu4dtLGlbOe0= =71mR -END PGP SIGNATURE- Furu-Furu-Furu Moon! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384949: Doesn't handle forgetfull (buggy) clients well
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFFzx+OKCtW8rKsRgRAmzwAKCZI5SwUU3NbpY1eesVpV5l3wfyiwCgtw8V 2lOFCkvEMLPdu4dtLGlbOe0= =71mR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384949: Doesn't handle forgetfull (buggy) clients well
Package: rtorrent Version: 0.6.1-1 Severity: normal 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]kKkKKK 496 [P: 2 F: 0]KK 503 [P: 2 F: 0]KKKKKK 508 [P: 2 F: 0]KK 645 [P: 2 F: 0]KKkkkkkKKK 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 ks. 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 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-frosties-2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages rtorrent depends on: ii libc6 2.3.6-16 GNU C Library: Shared libraries ii libcomerr21.39-1 common error description library ii libcurl3 7.15.5-1 Multi-protocol file transfer libra ii libgcc1 1:4.1.1-5 GCC support library ii libidn11 0.6.5-1GNU libidn library, implementation ii libkrb53 1.4.3-8MIT Kerberos runtime libraries ii libncurses5 5.5-2 Shared libraries for terminal hand ii libsigc++-2.0-0c2a2.0.16-3 type-safe Signal Framework for C++ ii libssl0.9.8 0.9.8b-2 SSL shared libraries ii libstdc++64.1.1-5The GNU Standard C++ Library v3 ii libtorrent9 0.10.1-1 a C++ BitTorrent library ii zlib1g1:1.2.3-13 compression library - runtime rtorrent recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
