DHT节点的完整实现是比较繁琐的,涉及到查询以及繁杂的各种对象的超时(节点、桶、infohash),而超时的处理并不是粗暴地做删除操作。因为本身是基于UDP协议,你得对这些超时对象做进一步的查询才能正确地进一步做其他事情。而搜索也是个繁杂的事情,递归地查询节点,感觉上,你不一定离目标越来越近,由于被查询节点的不确定性(无法确定对方是否在玩弄你,或者本身对方就是个傻逼),你很可能接下来要查询的节点反而离目标变远了。
在我第一次的DHT实现中,我使用了类似transmission里DHT实现的方法,不断无脑递归,当搜索有太久时间没得到响应后终止搜索。第二次实现时,我就使用了etorrent里的实现。这个搜索更聪明,它记录搜索过的节点,并且检查是否离目标越来越远。当远离目标时,就认为搜索是不太有效的,不太有效的搜索尝试几次就可以放弃。
在我第一次的DHT实现中,我使用了类似transmission里DHT实现的方法,不断无脑递归,当搜索有太久时间没得到响应后终止搜索。第二次实现时,我就使用了etorrent里的实现。这个搜索更聪明,它记录搜索过的节点,并且检查是否离目标越来越远。当远离目标时,就认为搜索是不太有效的,不太有效的搜索尝试几次就可以放弃。
实际上,爬虫的实现并不需要完整地实现DHT节点的正常功能。爬虫作为一个DHT节点的唯一动机仅是获取网络里其他节点的查询。而要完成这个功能,你只需要装得像个正常人就行。这里不需要保存infohash对应的peer列表,面临每一次查询,你随便回复几个节点地址就可以。但是这里有个责任问题,如果整个DHT网络有2000个节点,而你这个爬虫就有1000个节点,那么你的随意回复,就可能导致对方根本找不到正确的信息,这样你依然得不到有效的资源。(可以利用这一点破坏DHT网络)
找了台服务器将磁力链接爬虫架设起来http://www.51bt.cc(51搜索)大家可以看下。