我有一个想法,使用现有的BitTorrent DHT实现基于关键字的实时种子搜索机制,我想知道它是否可行和现实。
我们有一个torrent,我们希望能够仅使用DHT从keyword
找到它。
H
是一个具有20字节输出的哈希函数infohash
是torrent(20字节)sub(hash, i)
从字节hash
开始返回i
的2个字节(例如,sub(0x62616463666568676a696c6b6e6d706f72717473, 2) = 0x6463
)announce_peer(hash, port)
发布与假冒info_hash hash
相关联的虚假对等方。假对等方的IP无关紧要,我们使用port
号来存储数据(2个字节)。get_peers(hash)
检索与假冒info_hash hash
相关联的假对等方。我们考虑这个函数只返回一个端口号列表。a ++ b
表示连接a
和b
(例如,0x01 ++ 0x0203 = 0x010203
)id <- sub(infohash, 0)
announce_peer( H( 0x0000 ++ 0x00 ++ keyword ), id )
announce_peer( H( id ++ 0x01 ++ keyword ), sub(infohash, 2 ))
announce_peer( H( id ++ 0x02 ++ keyword ), sub(infohash, 4 ))
announce_peer( H( id ++ 0x03 ++ keyword ), sub(infohash, 6 ))
announce_peer( H( id ++ 0x04 ++ keyword ), sub(infohash, 8 ))
announce_peer( H( id ++ 0x05 ++ keyword ), sub(infohash, 10))
announce_peer( H( id ++ 0x06 ++ keyword ), sub(infohash, 12))
announce_peer( H( id ++ 0x07 ++ keyword ), sub(infohash, 14))
announce_peer( H( id ++ 0x08 ++ keyword ), sub(infohash, 16))
announce_peer( H( id ++ 0x09 ++ keyword ), sub(infohash, 18))
ids <- get_peers(H( 0x0000 ++ 0x00 ++ keyword ))
foreach (id : ids)
{
part1 <- get_peers(H( id ++ 0x01 ++ keyword ))[0]
part2 <- get_peers(H( id ++ 0x02 ++ keyword ))[0]
part3 <- get_peers(H( id ++ 0x03 ++ keyword ))[0]
part4 <- get_peers(H( id ++ 0x04 ++ keyword ))[0]
part5 <- get_peers(H( id ++ 0x05 ++ keyword ))[0]
part6 <- get_peers(H( id ++ 0x06 ++ keyword ))[0]
part7 <- get_peers(H( id ++ 0x07 ++ keyword ))[0]
part8 <- get_peers(H( id ++ 0x08 ++ keyword ))[0]
part9 <- get_peers(H( id ++ 0x09 ++ keyword ))[0]
result_infohash <- id ++ part1 ++ part2 ++ ... ++ part9
print("search result:" ++ result_infohash)
}
我知道会发生与id
的冲突(仅限2个字节),但是使用相对具体的关键字,它应该有效......
我们还可以通过以字母数字顺序连接多个单词来构建更具体的关键字。例如,如果我们将单词A
,B
和C
与torrent相关联,我们就可以发布关键字A
,B
,C
,A ++ B
,A ++ C
,B ++ C
和A ++ B ++ C
。
那么,这个糟糕的黑客是否可行:D?我知道Retroshare is using BitTorrent's DHT。
答案 0 :(得分:1)
它不太可能实用,因为它甚至没有尝试有效(查找次数)或可靠(失败率乘以查找次数)。这是针对单个关键字,而不是布尔查询,这会进一步破坏查找复杂性。
更不用说它甚至无法解决分布式搜索的难题,例如避免垃圾邮件和审查。
其他问题是,每个节点只能在关键字下发布一个torrent,并且需要多个节点以某种方式协调他们在遇到碰撞问题之前在哪个关键字下发布的内容。
当然,您可能能够在少数几个实例中使用它,但这是无关紧要的,因为p2p协议的使用应该以这样的方式设计,使得它们仍然可以在所有节点< / em>以类似方式使用该功能的节点。显然,一个(m * n * 10) - 折叠[m =每个关键字的种子,n =搜索条件的数量]网络流量的爆炸是不可接受的。
如果您对分布式关键字搜索非常感兴趣,我建议您点击google scholar和arxiv并查找现有研究,这是一个非常重要的主题。
对于bittorrent,你还应该超越BEP 5. BEP 44提供任意数据存储,BEP 46,49和51描述了额外的构建块和抽象。但我认为它们都不足以实现实时分布式多关键字搜索,就像人们期望从本地数据库或索引网站那样。