What is the status of ktorrent's attempts to work out DHT with uTorrent? I think that's a very very important feature, as uTorrent right now does better on downed tracker torrents than KTorrent, and the only explanation I can come up with is that uTorrent being able to talk to other uTorrents is helping it out.

We still need to look at this issue. All we need to know iwhat port µT uses (the same as for regular bittorrent traffic ?). Then we can just ping it and be done with it.

Btw, I have done some improvements to download and upload code, which seems to make things faster (The last BSG episode was downloaded faster then ever)

Any update on this? I don't see any real problem with pinging uTorrent's DHT port like you mentioned...

Hmm, I hacked SVN around a bit to force a DHT ping to every client connected at the UDP port = to TCP port number, and it doesn't seem like it works any better... I tested on an isolated network with a uTorrent dummy client, and looked with a copy of wireshark... uTorrent doesn't seem to respond to DHT ping from ktorrent.

Maybe I'm just doing something blatantly wrong here, but anyway, reverting back to SVN for now

I would need to get it running under linux with wine, so I can have a look at what ports it is using. But this is probably configurable.

Runs fine with WINE, DHT and all.... As far as configuration options, it appears like uTorrent's DHT is hard-coded to run on the UDP port that equals its TCP port...

Runs fine with WINE, DHT and all.... As far as configuration options, it appears like uTorrent's DHT is hard-coded to run on the UDP port that equals its TCP port... Yet as I said, it doesn't seem to respond to me forcing a DHT::Ping()...

This is the very shamefully hackjobbed code I used to force a DHT ping to each client. Would this work in theory?

With my localhost tests, it's at least able to register one node with uTorrent ( the uTorrent client I connected to), but doesn't seem to exchange any other nodes.

A packet sniffer shows that uTorrent's replies somehow have incorrect UDP checksums (?)

This code snippet also doesn't work for incoming connections... port is 0 in this case, causing the UDP packet to be dropped anyway.

Code: Select all

# Bazaar revision bundle v0.8
#
# message:
#   EXPERIMENTAL: DHT ping every client connected. Assumes that every client connected is DHT enabled on the same UDP port as its TCP port. This in turn forces a DHT ping to each client that KTorrent is connected to. An experiment in trying to get KTorrent talking to uTorrent/BitComet's DHT implementation. In my private tests, it at least is able to register the pinged client as +1 DHT node, but it doesn't seem like it allows KTorrent to get uTorrent's 200-some typical DHT nodes exchanged, so it doesn't completely work.
#   
#   This client is NOT designed for general usage, since it ABUSES other clients by sending unsolicited UDP traffic (DHT pings).
#   
# committer: John Dong <john.dong@gmail.com>
# date: Fri 2006-11-03 16:11:13.651999950 -0500

=== modified file libktorrent/mse/streamsocket.cpp
--- libktorrent/mse/streamsocket.cpp
+++ libktorrent/mse/streamsocket.cpp
@@ -51,6 +51,7 @@
                reinserted_data = 0;
                reinserted_data_size = 0;
                reinserted_data_read = 0;
+               port=0;
 
        }
 
@@ -62,6 +63,7 @@
                reinserted_data_size = 0;
                reinserted_data_read = 0;
                sock->setTOS(tos);
+               port=0;
        }
 
        StreamSocket::~StreamSocket()
@@ -181,6 +183,7 @@
                if (ip.isNull() || ip.length() == 0)
                        return false;
 
+               this->port=port;
                // we don't wanna block the current thread so set non blocking
                sock->setNonBlocking();
                if (sock->connectTo(Address(ip,port)))
@@ -214,7 +217,10 @@
        {
                return sock->getPeerName().toString();
        }
-
+       Uint16 StreamSocket::getPort() const
+       {
+               return port;
+       }
        void StreamSocket::setRC4Encryptor(RC4Encryptor* e)
        {
                if (enc)

=== modified file libktorrent/mse/streamsocket.h
--- libktorrent/mse/streamsocket.h
+++ libktorrent/mse/streamsocket.h
@@ -103,7 +103,7 @@
 
                /// Get the IP address of the remote peer
                QString getIPAddress() const;
-
+               Uint16 getPort() const;
                /**
                 * Reinsert data, this is needed when we read to much during the crypto handshake.
                 * This data will be the first to read out. The data will be copied to a temporary buffer
@@ -151,7 +151,7 @@
                bool monitored;
                net::SocketReader* rdr;
                net::SocketWriter* wrt;
-
+               Uint16 port;
                static Uint8 tos;
        };
 

=== modified file libktorrent/torrent/authenticatebase.cpp
--- libktorrent/torrent/authenticatebase.cpp
+++ libktorrent/torrent/authenticatebase.cpp
@@ -135,6 +135,7 @@
                        Out(SYS_CON|LOG_NOTICE) << "Peer supports DHT" << endl;
                        dht_support = true;
                }
+               dht_support=true;
 
                if (handshake[27] & 0x04)
                {

=== modified file libktorrent/torrent/peer.cpp
--- libktorrent/torrent/peer.cpp
+++ libktorrent/torrent/peer.cpp
@@ -31,6 +31,8 @@
 #include "packetwriter.h"
 #include "peerdownloader.h"
 #include "peeruploader.h"
+#include <kademlia/dhtbase.h>
+
 
 using namespace net;
 
@@ -62,7 +64,7 @@
 
                connect_time = QTime::currentTime();
                //sock->attachPeer(this);
-               stats.client = peer_id.identifyClient();
+               stats.client = peer_id.identifyClient();
                stats.ip_addresss = getIPAddresss();
                stats.choked = true;
                stats.download_rate = 0;
@@ -86,6 +88,13 @@
                {
                        sock->startMonitoring(preader,pwriter);
                }
+                   if(Globals::instance().getDHT().isRunning())
+                   {
+                           gotPortPacket(getIPAddresss(),sock->getPort());
+                Globals::instance().getDHT().portRecieved(getIPAddresss(),sock->getPort());
+        }
+        else
+          Out() << "DHT not running!" << endl;
        }
 
 
@@ -122,6 +131,7 @@
                const Uint8* tmp_buf = packet;
                //Out() << "Got packet : " << len << " type = " << type <<  endl;
                Uint8 type = tmp_buf[0];
+
                switch (type)
                {
                        case CHOKE:

=== modified directory  // last-changed:john.dong@gmail.com-20061103211113-ca9b
... 87e1eb426ee6
# revision id: john.dong@gmail.com-20061103211113-ca9b87e1eb426ee6
# sha1: 9855a26083b6b2e30454fbab249be1370d6d6d18
# inventory sha1: 5c40954261ee107c61c9e58a38e0a6ce9508d121
# parent ids:
#   john.dong@gmail.com-20061103205617-709106065c28c320
# base id: john.dong@gmail.com-20061103205617-709106065c28c320
# properties:
#   branch-nick: trunk-compilable



Regarding my last statement, it does indeed appear like uTorrent and KTorrent talk with that hack.

I started by putting my test box on a new IP, so that no "stray" UDP DHT packets fly into either client and "accidentally" seed DHT.

Next, I created a torrent and tracker where the only members are my uTorrent and KTorrent boxes. I let the uTorrent box start first, and it seeded to 30 or so nodes (the box is UDP-firewalled).

Next, I started the torrent on KTorrent, and immediately I got one node. Within 30 seconds, KTorrent was up to around 40 nodes.


This convinces me that KTorrent is getting nodes from my uTorrent, and that it wasn't just an accidental discovery.

Well, I think you're right. And according to uT devs our DHT implementations should be compatible.

The only thing left is to somehow convince uT devs to play by the rules... You've seen this thread, right? http://forum.utorrent.com/viewtopic.php?id=10655&p=1

Maybe you'll have a good argument to post there

Lets just add jdong's hack or a slightly modified version of it. If they don't won't to turn on one bit in the handshake, then that is their problem.

If we just ping all peers by default on the same port number, we might get even more nodes then the µTorrent ones.

Ivan wrote:Well, I think you're right. And according to uT devs our DHT implementations should be compatible.

The only thing left is to somehow convince uT devs to play by the rules... You've seen this thread, right? http://forum.utorrent.com/viewtopic.php?id=10655&p=1

Maybe you'll have a good argument to post there

I saw that thread... And to me it looks like uTorrent won't budge. Also to note, uTorrent based their DHT off BitComet, who KTorrent can't talk to either. So, we'd have to convince THEM too

Lets just add jdong's hack or a slightly modified version of it. If they don't won't to turn on one bit in the handshake, then that is their problem.

If we just ping all peers by default on the same port number, we might get even more nodes then the µTorrent ones.

I think that's a decent workaround for now until uTorrent and BitComet comes to their senses. My hack doesn't address the case of incoming connections, and also it puts DHT ticks by every peer. If it's possible to only tick DHT after getting a DHT response from a peer, that'd be better too, but those are just tiny details. Heck I'd rather show a DHT "X" by uTorrent and other misbehaving clients...

DHT is very separate from the bittorrent code, there is no feedback between the two wether or not a ping was successfull.
And there is no connection between a node in the DHT routing table and the peers of a torrent.

So it would require some changes to turn on the tick in the GUI, and we are not gonna do that, as they do not fully support the standard.

I agree with both of you. Let's ping all peers.

And for those DHT marks in peerView -> we simply won't set them for peers that don't fully support DHT protocol

Yep, upon re-thinking that, I think it is a much better idea not to show DHT ticks for non-compliant clients.


BTW, is there any way in the UI to present more DHT stats? Maybe I'm just too nerdy, but DHT is very fascinating stuff to me, and I'd like to see more about what DHT activity is going on. The log viewer with all DHT messages turned on is pretty nice, but I'd still like to see more stats.