Registered Member
|
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".
|
Moderator
|
|
Registered Member
|
|
Registered Member
|
|
Registered Member
|
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 |
Registered Member
|
|
Moderator
|
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. |
Registered Member
|
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? |
Registered Member
|
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?
I don't think so. I never saw any of them supporting DHT even before we implemented fast extensions. |
Moderator
|
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. |
Registered Member
|
|
Registered Member
|
|
Registered Member
|
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 |
Registered users: Bing [Bot], blue_bullet, Google [Bot], rockscient, Yahoo [Bot]