&&&&&&& 去年10月份开始研究相关的协议与资料，中途乱七八糟的事情差点没坚持下来，寒假里修修补补上礼拜把发布了，经过社交网络的推广之后，上线第三天UV就达到了两万多，也算是对这几个月工作的一点肯定吧。
&&&&&&& 如果你想下载对应的文件，电脑里面需要安装一款支持磁力链接的软件，例如迅雷，QQ旋风，BitComet等。
DHT Protocal
&&&&&&& 一个种子主要包含元信息（文件标题、文件大小、文件列表等）和Tracker服务器信息，每当一个用户想要下载一个文件，客户端会先询问Tracker服务器，目前有哪些电脑正在下载这个文件，这些电脑被称为&peer&，然后客户端会向这些peer分别请求文件的各个片段，等每个片段都下载完成之后再组合成一个完整的文件，至此整个下载过程完毕。
&&&&&&& 由此可见，Tracker服务器相当于提供了一种&路由&服务，在整个下载过程中挥舞着指挥棒。但近年来由于打击盗版等原因，一些Tracker服务器开始陆续关闭，没有Tracker用户还怎么用种子下载文件呢？后来bt协议进行了扩充， ，它把Tracker的路由服务分散到了BT网络中的每个节点，那么一个种子由哪个或哪些节点负责路由服务呢？
&&&&&&& 首先，每个种子都有一个对应的20字节的hash，这个hash有sha1算法得到，每个节点也有一个20字节的id，通常是随机的20字节。如果这时有两个节点A和B，怎么判断这个种子放在A好还是B好呢？通过计算种子hash和节点id的异或值（称为距离），异或值最小（距离最近）的那个节点更适合提供这个种子的路由。
&&&&&& 那整个网络之间的节点是如何进行沟通的呢？根据DHT Protocal，主要有四种请求：ping，find_node，get_peers，announce_peer。这四种消息其实都是字典类型，要经过之后才能被对方正确的处理，使用UDP协议进行发送，这四种请求都会影响自己维护的一张路由表。
&&&&&&& 路由表主要用于存储跟自己打过交道的节点信息，节点信息包含IP、Port和节点ID信息。而路由表由一个个的吊桶（Bucket）组成，在这里我简称它为&桶&。每个桶只能存储一定节点ID在一定范围的节点信息，并且桶的容量有限，一般规定一个桶只能存储8个节点。起初路由表里面只有1个桶，这个桶能存储的节点ID范围在2^0至2^160，也就是任何节点它都能保存，等这个桶满了之后怎么办？&&分裂。例如桶(min, max)分裂为两个桶后，两个桶能保存的范围分别为(min, max/2), (max/2, max)，原先的那个桶里面的8个节点也要重新分配到分裂后的两个桶中。
&&&&&&& 伟大的毛主席说过，只要有一拨人，就分左中右。节点也是这样，分为good、questionable和bad，&good&指过去15分钟内该节点跟我有过联系，如果15分钟内该节点没有跟我联系过，它会变成&questionable&状态，客户端就会向它发出几个ping，如果没有收到回应，它就变为&bad&，可以把它从路由表中删除。
KPRC Protocal
&&&&&&& 注意这里的ping，不是你用cmd黑框框里面的ping。这个请求主要用户询问对方是否在线，比较简单，主要用于维护自己路由表里面的节点。
2. find_node
&&&&&&& 顾名思义，find_node就是为了查询节点，它根据对方节点的id询问DHT网络，收到这个请求的节点，会把自己路由表中与该节点距离最接近的8个节点返回。
3. get_peers
&&&&&&& get_peers用于查找一个资源hash对应的peer，它询问路由表中与该hash最接近的8节点，收到该请求的节点如果发现自己知道对应的peer，返回这些peer的信息，否则返回它自己路由表中跟该hash最近的8个节点信息。发起get_peers的节点在收到peer信息了，则跟peer建立连接，正式开始下载文件片段。如果收到的是节点信息，则选出这些节点中跟hash最近的几个节点，递归的get_peers，直到发现peer。有两种情况要控制这种递归的返回：1. 超时，在一定时间内如果没有发现peer，则放弃。2. 已经发现了跟该hash最近的节点，但它没有peer信息。
4. announce_peer
&&&&&&& announce_peer用于在自己get_peers发现peers之后发送，发送的对象是先前回复过自己get_peers的节点，告诉对方自己发现了peer，你们也可以&备份&一下，减小整个网络查询该hash的次数。
&&&&&&& 以前一个种子对应一个文件，现在一个hash对应一个文件，通过hash构造的磁力链接就可以下载一个文件。磁力链接的构造方式如下：
magnet:?xt=urn:btih:{hash}
&&&&&&& 磁力链接中的hash就是一个40个字符组成的字符串，由20字节的hash计算得来：
public static string ToHexString(byte[] hash)
var sb = new StringBuilder();
foreach (var b in bytes)
sb.Append(b.ToString("X2"));
return sb.ToString();
&&&&&&& 例如构造了一个磁力链接：magnet:?xt=urn:btih:EAE833FFE5A06B42B9B8C3F579C8A3 ，用迅雷打开后，迅雷就会下载对应的种子，然后下载该资源。
Btbook是什么
&&&&&&& Btbook主要由DHT网络爬虫，种子下载分析器，一个搜索网站组成。
&&&&&&& DHT网络爬虫用一些&交友策略&，例如我可以递归的find_node，尽可能多的认识DHT网络中的节点，让自己加入到对方的路由表中。剩下的事情就是等待对方的请求，所有的请求都正常的给予回复，对于announce_peer请求，则记录下资源的hash，交给种子下载分析器处理。
&&&&&&& 种子下载分析器通过hash下载对应的种子文件，从种子文件中获取文件标题、文件列表、文件大小等元信息，保存到索引文件中。
&&&&&&& 搜索网站用ASP.NET MVC搭建，用于处理用户的搜索，对用户的搜索内容进行分词，对一些敏感词汇进行过滤，从索引文件中获取标题与搜索内容最匹配的结果，默认按资源的创建时间进行排序，突出&新&。
&&&&&&& 因为整个过程是实时的，一旦网络中有人分享了东西被我捕获的话，我就能发现这个资源，所以一些最新的资源往往都能被索引，是&追剧者&的神器。
使用Btbook
&&&&&&& 如果你用电脑访问btbook，你的电脑安装了支持磁力链接的软件即可。如果你使用的是移动设备，你可以安装迅雷手机版之类的软件(&手雷&)，把btbook添加进收藏，在手雷中打开btbook，就可以直接在手机中下载文件了。Btbook的网址是： ，考虑了移动版浏览器兼容性，have fun！
& & & & 目前服务器配置较低，如果有园友有带宽较好的VPS，愿意帮助提高btbook体验的话，请与我联系。
阅读(...) 评论()&&»&& &
&&»&& Findit – Node.js实现的磁力搜索引擎
Findit – Node.js实现的磁力搜索引擎
Posted in ,
On 日 Views: 956
废话写前头
2013底的时候，我从上一家公司离职，由于各种原因休息了一段时间，年后才入职新公司。休息的这段时间，除了搭建这个、看书、帮以前学校完成一个CMS系统（目前没有使用，使用ASP.NET实现的，后面可能会把代码放到Github上）外，还有一个大的发现，就是写的一个磁力链接搜索引擎。相信大家都知道这是干什么的，粗略看完Xiaoxia写的介绍后，真是脑洞打开，兴趣满满。本打算自己开发一个出来玩玩，奈何对ASP.NET/C#缺乏深入了解，写起来很累，又打算投入新的工作中，所以只得作罢。
2014年加入新公司后，频繁的使用了Node.js，渐渐的发现Node的强大，磁力搜索引擎的想法又重新浮现。可以说，这一年我大部分的学习都是围绕“Findit磁力搜索引擎”展开的，看我博客写的文章就会发现：Redis、Mongodb、PM2、Elasticsearch、甚至Centos和Nginx，都是Findit使用到的技术。在实践中学习，这本身也是花大力气做这件事的目的。
网站正式上线。域名是，在上使用了三台VPS：
第一台部署了Findit站点本身（express.js、nginx）和单个节点的Elasticsearch
第二台部署了Mongodb数据库（目前有300W数据库，每日新收录1W+的数据）
第三台部署了AntColony磁力链接爬虫（后面细说）
但是好景不长，不用说大家也知道，使用BT种子下载的都是什么东西，盗版、色情充斥其中。本来还想放点Google AdSense实现自负盈亏的，结果还没一个月就收到了警告邮件，要求我整改，深知此问题无法解决，索性也就把广告给下了，每个月一两百的VPS钱还是出得起的（呵呵）。
另外一点就是，14年12月，“带头大哥”海盗湾被瑞典警方连窝端了，什么？你说这个关我p事？当然关我的事了。AntColony从DHT网络中收集到资源的infohash后，要去种子托管网站下载种子文件，读取文件内容，收录到系统中才能被用户搜索到。海盗湾被查封的同时Zoink和Torrage这两个种子托管站也被封了（目前Zoink还活着），这就影响到了资源的收录。
海盗湾事件更重要的影响是，我的信念被动摇了。很多国家禁止使用BT下载盗版资源，而国内大多数人用来干什么大家都懂的（我看的到用户搜索的关键字）。还有就是BT本身的特性，要大家一起下载才快，Findit收录的资源，可能已经没人下载了，用户使用搜索到的磁力链接下载资源，很可能根本没有速度。这些都让我怀疑“磁力链接搜索引擎”存在的意义，只能以“重在过程”聊以自慰了：开发过程中，我确实学到不少。所以，可能不久的将来，findit会被关闭，但我希望代码可以被留存下来，帮到需要它的人。好了废话到此为止。
这部分我不打算细说，google都能搜出来，我只列一下我觉得比较好的资料：
最关键的就是BitTorrent.org上的
最初提到的Xiaoxia的，粗略的提到了实现原理。
Kevin Lynx写的
大概就这些了。
AntColony（）是findit磁力搜索引擎的核心。用来在DHT网络中，收集活跃资源的infohash，下载并解析资源的种子文件，存入数据库等。AntColony是若干功能的合集，也可以单独运行其中的部分功能，所以起“蚁群”这个名字也是很贴切的（没错，我就是爱动物世界）。主要分一下几块：
worker：爬虫，收集资源infohash，可以同时启动多个进程的worker，提高效率
male：根据收集来的infohash去下载种子文件
female：将种子文件录入数据库
queen：简单的入口，启动pm2运行worker，male和female
先来张AntColony和谐运行的靓照：
目前启动5个worker使用的端口，2个male和1个female。
使用Mongodb储存数据，这没什么好说的；使用pm2维护和监控node进程，也没太多要说的，重点说下Redis。Redis里暂存的数据大概是这样的：
比较大的一个K桶（bucket）；infohash就是已经收集到的infohashs（worker收集来的，male会用来下载种子）；remoteNodes是worker新认识的节点，会依次“拜访”的，目前只保存最新的10w个（一方面我的VPS内存小，另一方面真没必要记录太多）；sysInfo会记录一些统计信息，例如发出多少次请求，累积收集多少infohashs，目前已经发出15亿次Request，这个频率是可控的，worker太疯狂的话，VPS扛不住。
下面简单说下运行方法，安装好node，pm2，redis，mongodb之后，执行npm install 下载依赖的包，在根目录运行node startup worker 3000 启动一个worker监听3000端口；运行node startup male 1 启动id为1的male（female同理）。
mongodb-to-elasticsearch
刚才说AntColony的时候没提到Elasticsearch。是一个非常赞的实时分布式搜索引擎，惊人的强大和便捷，可以方便的在Node环境中使用操作。但是在实际使用中发现个问题，female将种子文件解析好后，存储在mongodb，再存储在Elasticsearch，这个过程效率很低。经常会堆积大量种子文件处理不过来。另一方面，没有必要那么“实时”，既浪费资源有增加了Elasticsearch的压力。所以就搞了mongodb-to-elasticsearch这个小工具，每天执行一次mongodb到Elasticsearch的数据同步。代码很简单，有兴趣的可直接看上的代码。
Findit是基于Express.js开发的一个小网站，只有一个简单的功能，就是查Elasticsearch。有了AntColony和mogodb-to-elasticsearch就有了数据，想怎么玩都随你了，不多说。
存在的问题
虽然稳定运行中，但是任然存在几个问题：
1、需要足否大的内存运行AntColony。目前AntColony的VPS内存是1G，Redis占用了一部分，剩下可用的内存是500M左右，如果大于遇到700K的种子文件（大概的），female就会卡住解析不存在，内存占用率不断提高，直到被PM2重启。
由于female是随机取出种子文件解析的，所以一段时间后还会遇到问题文件，继续卡住，如此不断的重复……，目前的解决办法，就是移走大文件，在自己电脑上运行female解析。当然不差钱的人可以用性能更强悍的机器。
2、目前mongodb-to-elasticsearch是手动执行的。先停止female，然后程序会把上次执行时间节点后，新增的数据同步过来。效率还不错，1W多的数据几十秒就好了。但是手动执行还是太麻烦，下一步优化的方向是定时执行或者优化female，直接同步Elasticsearch。
前面也提到了，可能不久后会把关闭，如果大家有好的想法可以留言讨论。
原文链接：
转载请保留原文链接
按日期查看
2015年五月
11121314151617
18192021222324
25262728293031有爱屋磁力搜索 - 做最全的资源搜索引擎 - 没有搜不到，只有想不到！}