This forum has been archived. All content is frozen. Please use KDE Discuss instead.

KTorrent 540904 freezes regularly.

Tags: None
(comma "," separated)
imported4-Tomasu
Registered Member
Posts
302
Karma
0

KTorrent 540904 freezes regularly.

Mon May 15, 2006 1:52 am
I've noticed kt freezing solid fairly regularly. Not sure where the problem is. Also, the GUI seems to get interupted often, and freezes temporarily while ktorrent is doing something, that imo, should be done "behind the scenes".
George
Moderator
Posts
5421
Karma
1

Mon May 15, 2006 5:16 pm
Have you got DHT enabled ?

Try it with the latest version, I have made some fixes yesterday..
imported4-Tomasu
Registered Member
Posts
302
Karma
0

Mon May 15, 2006 10:08 pm
I belive DHT is enabled, I'm updating to 541312. I'll post again if I have issues.

edit, update, DHT is enabled, but showing 0 nodes, and 0 tasks.
imported4-ddv
Registered Member
Posts
22
Karma
0

Tue May 30, 2006 6:27 pm
I have the same problem 0 nodes and 0 task

using Ktorrent 2 beta and ubuntu breezy
imported4-ddv
Registered Member
Posts
22
Karma
0

Thu Jun 01, 2006 1:09 pm
I have done a little research and for some reason it seems that the only peers that I can get DHT from is the ones which uses the Mainline Bittorrent client. No matter what torrent I downloaded, stranges since both bitcomet and utorrent should use the same DHT implementation.

At the same time the speed is very slow!! for instance I downloaded the new ubuntu 6.06 and both with azureus in Linux and utorrent in XP the speed was about my max download speed at 120 kb/s

Tried the advice I found here http://ktorrent.org/forum/viewtopic.php ... ed&start=0
stoeptegel
Registered Member
Posts
1075
Karma
0

Thu Jun 01, 2006 4:42 pm
ddv wrote:stranges since both bitcomet and utorrent should use the same DHT implementation.


I'd rather think this is not a bug ;)
George
Moderator
Posts
5421
Karma
1

Thu Jun 01, 2006 5:33 pm
0 nodes ... do you guys actually see peers supporting DHT ?

As for bitcomet and µtorrent, I haven't really payed attention to which clients support DHT, though a quick test with the dapper drake iso only gives me mainline clients supporting DHT.

Maybe BC and µtorrent get confused by the fast extensions ? Support for fast extensions and DHT are indicated by setting a bit in the handshake, those two bits are in the same byte and the for DHT it is the last bit. Maybe this second bit from the fast extensions confuses them.
imported4-Tomasu
Registered Member
Posts
302
Karma
0

Thu Jun 01, 2006 5:50 pm
I've updated to the latest svn just a couple hours ago. DHT works fairly decent. 111 nodes. Though it doesn't compare to say a client that does DHC, like azureus that lists several hundred thousand nodes.

Speaking of DHC, will it be supported? Can it be supported? If Azerus's dhc is pretty handy, I'd be using Az if it wern't such a horrible CPU and RAM hog on linux.

I have a suspision about Az, I swear it uses a thread per connection established, which would easily explain its memory and cpu usage issues. anyone know for sure?
imported4-Ivan
Registered Member
Posts
819
Karma
0

Thu Jun 01, 2006 7:43 pm
As for bitcomet and µtorrent, I haven't really payed attention to which clients support DHT, though a quick test with the dapper drake iso only gives me mainline clients supporting DHT.


I've seen only mainline clients supporting DHT. Actually, there was just this one time I saw libtorrent client with DHT, if I remember correctly.

uTorrent website shows "Mainline DHT implementation" but I never saw uTorrent nor BC marked as supported with KT. Maybe they have a different implementation considering there was no official documentation for DHT until recently?

Maybe BC and µtorrent get confused by the fast extensions ?

I don't think so. I never saw any of them supporting DHT even before we implemented fast extensions.
George
Moderator
Posts
5421
Karma
1

Fri Jun 02, 2006 5:46 pm

Maybe BC and µtorrent get confused by the fast extensions ?

I don't think so. I never saw any of them supporting DHT even before we implemented fast extensions.


Still it is a very easy mistake to make :

Byte 28 of the handshake is 0x5 when you support both DHT and fast ext and it is 0x1 if you only support DHT.

If a client doesn't check on bits but on bytes, because they assume that no other bits of that byte will be on and they just do this :

if (handshake[27] == 1)
Yay, client supports DHT ...

They are going to think KT doesn't support DHT. Fast extensions is very recent (the spec was put online maybe 3 weeks ago) and as far as I know only mainline and KT supports this.
imported4-Ivan
Registered Member
Posts
819
Karma
0

Sat Jun 03, 2006 6:39 pm
Ah, I see. I don't know really. Maybe we could try contacting uTorrent devs and talk with them? It would be really awesome to get some of their DHT nodes since uTorrents are taking large part of the swarm now...
imported4-ddv
Registered Member
Posts
22
Karma
0

Sun Jun 04, 2006 7:20 am
Thanx for the quick replies

Yes I think this would be a great idea to contact µtorrent
Moshroum
Registered Member
Posts
63
Karma
0

Fri Jun 09, 2006 9:30 am
George wrote:Byte 28 of the handshake is 0x5 when you support both DHT and fast ext and it is 0x1 if you only support DHT.


Maybe I am wrong (I dont have enough time to read the whole spec, but did a quick search on "handshake"). it seems like the last (not the first) bit must be set in the handshake:

[quote="DHT-Draft"]Peers supporting the DHT set the last bit of the 8-byte reserved flags exchanged in the BitTorrent protocol handshake[/qote]

So it would be 0x80 when only dht is supported. I need to check it against the bittorrent/ktorrent/bitcomet sources when I get home, but feel free to correct me.


EDIT: Ok, I am at home right now and looked at the bittorrent sources. I was definitly wrong, because the last bit in the draft = the least significant bit. So 0x01 = bitflag for dht


Bookmarks



Who is online

Registered users: Bing [Bot], blue_bullet, Google [Bot], rockscient, Yahoo [Bot]