In the few downloads with downed trackers I've dealt with, it seems like ktorrent's DHT implementation is pretty awful at finding peers. After giving it 30 minutes, it found 3 peers and a seed, while Azureus on the same torrent was able to find hundreds of peers and seeds.


Is this a problem with mainline DHT or ktorrent's DHT implementation? Perhaps given the situation, Azureus DHT may be a better choice than mainline DHT?

I am using KTorrent 2.0.2, and it claims to have 100 nodes for DHT.

I always have 130-140 nodes here in KTorrent.
For what i see it's like as soon as you have some good nodes to start from, it will find the rest of the proper nodes on the fly.

But i think the difference in nodes is because
the azureus DHT network might still be bigger than mainline (is it, now that utorrent is populair too on the mainline DHT?)


EDIT
I just realized that b) was totally unrelevant seeing it's only the first small step in getting some sources. Deleted is goes....

I have 106 nodes right now, and for fun, I took a torrent that I've been working on, and blocked access to the tracker via iptables.


KTorrent was able to find about 5 peers, while Azureus located around 80. There are around 122 peers in total.

Azureus has a different DHT implementation than ours. If you compare people using Azureus on one side and KTorrent & Mainline on the other, you'll see that there are more people with AZ clients. That should explain more peers from AZ DHT than ours.
On the other side, it depends on the torrent also. Sometimes I get more peers from our DHT than from AZs.

Seeing that there's no official DHT specification (except this draft on bittorrent.org) we agreed that it's better to implement DHT compatible with official client. Also, according to some posts on the forum, uTorrent implementation should not be much different from ours so if we manage to convince uTorrents devs to make them fully compatible (see http://forum.utorrent.com/viewtopic.php ... 04#p185704 to get an idea what I'm talking about) we'll have a lovely swarm from KTorrent, BitTorrent & uTorrent users which is, you'll agree, a very big share of BT network.

Ivan,

Well put, definitely if we can attain utorrent compatibility that'd be awesome.

I can already see myself connecting to utorrent peers via DHT -- does that mean we're already somewhat compatible?

We should be, but I'm not 100% sure. I'm getting uTorrents quite often too...

If we could only persuade uTorrent devs to change that small thing we would know for sure and I think it would work.

Just a quick update: I've just played with this again and by trying one public torrent KT gave me 15 peers almost at the moment and that number is still increasing (I'm still getting incoming connections).

ALL received peers are either uTorrent or BitComet (uTorrent devs claim to have their DHT reverse-engineered from BitComets). This leads me to believe that our DHT implementations are almost perfectly compatible. The only thing left is to get more nodes by recognizing uT as DHT compatible client...

Ivan, in that topic you linked Firon (#4) first said that it was reverse engineered from BitComet's implementation, but then ludde (#12) corrected him and said it was deduced from mainline python source.

Just a little detail you seem to have overlooked - if it isn't me who overlooked something

Yeah, you're right. I forgot about that.
Anyway, it seems that we all have compatible DHT implementations

Hmm, let's think this straight. What could be less pretty on having each peer to be a little DHT source instead of one fixed source from the start? (serious question)
How i see it, the use of the handshake was the last missing part that makes DHT fully working on it's own.

Well, after some more tests where I removed the check for that bit so every client was identified as DHT supported, uT doesn't seem to respond to some DHT packets so we're not quite sure how does uT find the nodes in the first place (except bootstrapping from router.utorrent.com).

Why don't we bootstrap from a known source?

From specification (draft): "Please do not automatically add "router.bittorrent.com" to torrent files or automatically add this node to clients routing tables."

So, router.bittorrent.com isnt possible, but it should for example be possible to use the "known peers" things in dht-only torrents. Or...nobody said that we should not use router.utorrent.com (but I dont think that it will be used)

No need for bootstrapping here. The only 'problem' is that you initially have to connect to at least one DHT supporting client (so far KTorrent or Mainline). DHT nodes number will increase shortly after that, so adding a known source will just speed up this process initially but I don't think there's a need for that specially if we're to use some source that is not maintained by ourselves and we cannot guarantee for it

Pretty odd situation if you ask me. We humans can call ourselves the most intelligent beings on this planet, but yet we end up with one spec and two or three other non-compatible implementations.

I know there was no real specification back then, and that it was reversed engineered by others... so i think it's not really anyones fault or anything. But why having a standard then? I mean, the whole internet is build on specs, why should we abandon that when it's all we have? Dunno how others think about this, but this is my biased view as a user