Jump to content

problem with the up-to-date versions of BitTorrent client

Recommended Posts

That's not misbehaving. That's normal behavior for DHT traffic.

According to the specification:

If the queried node has no peers for the infohash, a key "nodes" is returned containing the K nodes
in the queried nodes routing table closest to the infohash supplied in the query.
In either case a "token" key is also included in the return value.
Example Packets:
Response with peers = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "values": ["axje.u", "idhtnm"]}}
bencoded = d1:rd2:id20:abcdefghij01234567895:token8:aoeusnth6:valuesl6:axje.u6:idhtnmee1:t2:aa1:y1:re

Response with closest nodes = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "nodes": "def456..."}}
bencoded = d1:rd2:id20:abcdefghij01234567895:nodes9:def456...5:token8:aoeusnthe1:t2:aa1:y1:re

There are two different answers (peers/closest nodes) for two the different cases (exactly know that we can get info-hash from nodes/otherwise).

Link to comment
Share on other sites

Just because a specific torrent's infohash isn't in your active torrent list, it doesn't mean your DHT table doesn't have peers for it.

Sorry, nothing misbehaving.

OK. It sounds good, but it is strange that for almost any sequence of random info-hashes (each of which has probability current_number_of_torrents_in_DHT_network/2^160 ~ 0)

we got 'Response with peers' and the retrieved peers know nothing about requested info-hash.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...