peersim中bittorrent源码分析？

       最近在忙着写毕业论文，只剩一个月了实验还没搞定。。。

方向是网络编码，需要在peersim模拟器下修改BitTorrent源码实现，然后发现官网上BitTorrent源码有个明显的问题为什么没人提啊，让我纠结那么久。

在BT中，发送节点在收到请求节点的请求后会发生所请求的文件块，前提是要发送节点拥有请求节点请求的那个文件块，没有请求节点请求的文件块发个空气啊。

源码中总共有6个地方会发送请求信息，其中5个地方在发送请求信息前都会检查发送节点是否拥有这个文件块，除了1个函数requestNextBlocks调用的地方：

然后发现这个函数在被调用前没有检查过对方是否有这个文件块。

这个函数的最大问题是，函数在发现这个piece没有可请求的块（piece下载完了）的时候，会选择一个新piece开始下载，所以在调用这个函数的时候要检查一下现在正在下载的块对方是不是拥有才对。

当然不排除对方节点在生成请求信息的时候不拥有，在这个请求信息到达对方节点的时候，对方节点正好拥有了这个特殊情况。

但是！当节点收到请求信息后，是直接加到即将服务的请求队列中，在从这个服务队列中取出请求信息是，也没有检查是不是拥有就直接发！送！所谓的文件块了！！！（因为发送的文件块信息只要将请求的文件块ID再发回去就可以了）。怎么可以这样！！！没拥有发送个蛋啊。

所以我在发送文件块信息前，加一条处理判断本节点是否拥有请求的文件块

if(status[piece]！＝16)

continue;

因为在BT中，节点只有拥有完整的piece后才会分发，所以可以通过是否有这个piece的16个文件块判断。

加了这句后，BT性能果然变差了。。。。

我在想要不要把这个continue前面再加一句requestToServe.enqueue(req)会更好？