Shareaza

Extesion for BitTorrent client to search file by URN in BitTorrent DHT.
Расширение BitTorrent клиента для поиска файла по URN в BitTorrent DHT.


Client generate bencode dictionary
Клиент создаёт bencode словарь.

[urn name|имя urn][binary hash or value of urn| бинарный хеш или другое значение urn]

Sha1 hash of that dictionary use to public and search sources in BitTorrent DHT.
Sha1 хеш этого словаря используется для публикации и поиска источников в BitTorrent DHT.

urn names | имена urn

urn:tree:tiger: (preferred | предпочитаемый)
urn:sha1:
urn:ed2k:
urn:md5:
urn:btih: (is it need? | нужен ли он?)

Пример | example:
d15:urn:tree:tiger:24:[хеш в RAW виде|Hash in Raw]e

[urn name|имя urn][binary hash or value of urn| бинарный хеш или другое значение urn]["protocol"][protocol]

protocol:
ed2k
uri-res (G2)
Gnutella
BitTorrent (How? Need some extension) (default)

Пример словаря:
d15:urn:tree:tiger:24:[хеш в RAW виде|hash in RAW]8:protocol7:uri-rese


Extesion for Peer to get BTIH by URN

Relatedly, dht:// web links do need to be supported.

However, the above post is more technical in nature.
Less a feature request than a step towards specific implementation.

I like it. I always felt that Shareaza should use the fact that Kademlia based DHTs work on binary strings and don't really care what the bits mean for cross-network support. And Ivans suggestion is pretty clean and "BitTorrentish" way to do it. But... since when did we have BitTorrent DHT?

Declined. Don't use BitTorrent DHT for everything except BTH searching.

Need create new dht to be universal?

How many DHT we need?

No one.

Why? It's easy way to find sources.

No need to share all your library in DHT. Share only what you downloading.

For me, I would say one is more than enough. I say one because, in my perfect world I dream of a Shareaza without the burden of extra protocols. Only two networks would coexist, one being G2 and the other being BT which is a network that is only on when being used. This would allow Shareaza to adopt mainline DHT, for BT. G2 can use mainline dht as well, we just avoid as much crosstalk as possible, it's only hashes, and they only match one file. What is the harm if we use mainline DHT to find hashes within G2 whether it is SHA1 or TTH. This would improve our swarms and ability to cohesively integrate a search functionality into Bit-torrent. This would be the next revolution ... or the next scandal in either case p2p needs it.

The only way to know if a client is posting keys in a DHT other clients don't support is to read the source code. In theory posting multiple hashes would multiply the chance of hash collisions, but several times an insignificantly small chance is still an insignificantly small chance. There is no discernible difference.

In any case, if you accept .torrents and .metalinks with ED2K and SHA1 hashes included, you really should support BT DHT search by ED2K and SHA1 and BT download from the found sources by ED2K or SHA1 hash. This would allow batch torrents with identical parts to share sources, which would be useful to everyone. I don't really see why this would be bad for BT as long as we enforce the normal auto-seeding rules. It is not any different from just downloading a part of batch torrent as far as the network is concerned. And that is already allowed.

I am sure the BT people would much prefer something that is unique to BT and useless to anyone using other networks, but objectively SHA1 and ED2K sharing is actually pretty good solution to sharing identical parts between torrents and does count as a legit BT feature.

If we search for BT sources file would be treated as a torrent that contain this urn.

To get it info_hash we do litle extension.

It use:
Extension Protocol

Handshake:

{
'm':
{
'rz_urn_to_btih':id
}
}

Если клиент соединился по urn_hash то сервер сразу после рукопожатия должен вернуть результат или ошибку.

If client connect by urn_hash then server after handshake must return result or error.

(bencoded dictionary)
{
'urn': (ansver only)
{
[urn name|имя urn]:[binary hash or value of urn| бинарный хеш или другое значение urn]
},
'btih': (ansver only)
{
[RAW BTIH],
[RAW BTIH],
...
},
'peers': (optional for ansver)
{
[compact peer list for first BTIH]
[compact peer list for second BTIH]
...
}
'request': (request and optional for ansver)
{
[urn name|имя urn]:[binary hash or value of urn| бинарный хеш или другое значение urn]
}
'error': (on error)
{
'id':error_id,
'msg':msg_to_user
}
}

Если пир соединился по urn_hash он должен сбросить соединение после окончания получения/передачи информации. Соединится уже как стандартный пир используя один из перечисленных хешей.

If client connect by urn_hash then it must drop connection after end recive/send information. Then it reconect as normal peer by one of btih in btih list.


urn_hash:
sha1 hash of urn dictionary.
sha1 хеш от urn словаря.
peer use urn_hash to serch and announce in DHT or other places.
peer использует urn_hash для поиска и объявления источников в DHT и других местах.

btih:
btih list of info dictionary that contain this urn.
btih список от info поля которые содержат в себе этот urn.

urn names = analog in info dictionary| имена urn = аналог в info словаре:

urn:tree:tiger: = tiger (preferred | предпочитаемый)
urn:sha1: = sha1
urn:ed2k: = ed2k
urn:md5: = md5sum
urn:btih:

Other user. It source that found in DHT by urn_hash.

Original BT DHT is for search sources by known info_hash. You find sources only for this torrent.

This extension allow to search sources by known urn (any type of hash).

It allow to find info_hash (not only one) by using magnet or torrent whith other hash then btih. And use many torrents as source for one download.

Extesion for BitTorrent client to search file by URN in BitTorrent DHT
Extesion for Peer to get BTIH by URN

I publuc this on bittorrent forums.