乱弹BT协议的不足

writer15

乱弹BT协议的不足
作者：wrtier15   writer15(a_t)163.com
首先要肯定的是BT协议是一个成功的协议。
但站在程序员的角度来说，我就觉得BT协议不怎么友好了。因为BT协议中有很多让程序员摸不着头的地方，对于不同的程序
来说要解决这些问题得花费不少的时间。
下面是我对BT协议的几点不满。
为什么要用bencode？
    在python中实现bencode很简单，但是对于其它非脚本语言来说要实现就非得下一翻功夫。
为什么.torrent要分成单文件模式和多文件模式
    我对于这点是最摸不着头，统一用多文件模式不是更好？
实现文件选择下载功能很复杂
    对于这点不能责怪BT协议，因为它的的设计就没有考虑这点，因为这样会导致torrent的分布率不平衡。
    但是我不得不报怨一下BT协议实现文件选择下载功能有多么的复杂
   
    因为BT协议将所有文件看成一个巨大的文件，并把这个文件分成piece，而校检一个piece可以通过
    可以通过对比.torrent中的hash实现。但是文件选择下载时，只需要下载一个piece的一部份，但这样
    却不能进行校检。所以必须下载整个piece，但是多出来的部分保存在哪？
    不下载是不行的，因为这样并不能确保下载的数据的正确性，而且对 重新检测完整性 功能的实现带来更多的问题；
    保存在内存中更不可行，因为数据太多的时候必然占用太多宝贵的内存；
    所以只能保存在磁盘上了，但是要实现运行时 下载/取消下载文件，文件格式的会相当复杂，而且实现这个格式的读写
估计比实现piece的读写更复杂，这样根本就是本末倒置了！
      
    如果.torrent提供每个文件头尾piece的hash，就不用下载不需要的slice，更不需要考虑保存的问题，重新检测完整性
功能实现起来也很简单。
和tracker通信为什么要用http协议？
    火星人都知分析字符串是一件多么烦人的事情，和tracker服务器通信使用http协议必然把复杂度增加一个极别……
    我个人倾向于使用数据包方式，不论服务器还是客户瑞的程序实现起来也很简单（只要定义结构和定义好字节顺序），
而且也加大了服务器的负载程度（因为不用解释http协议的字符串）。

2007年7月5日追加
torrent之间没有联系，数据存活时间短
    很多时间很多torrent中有相同的文件（特别是连载之后又推出合集的），但是因为没有提供每个文件的hash，所以就没有办法确定这些torrent有关系了。如果每个torrent中的文件都提供hash，这些torrent就可以互相交换数据，随之而来的是数据存活时间的增加长。

2007年7月21日追加
一个peer只有一个piece的一部分数据，它不能告诉其它peer它有这份slice。如果这个slice刚好在某个文件的头尾piece，而或者有peer缺少这个slice才能组成一个文件，那是不是很悲哀？当然BT协议设计怎么没想到有其它客户端会实现文件选择下载功能……最后导致这样一个问题~~~
总之，不以文件为传输单位，是BT协议的最大问题。


还有一些的，一时想不起来， 想起来再写吧。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/36381/showart_333871.html