乱弹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协议的最大问题。
还有一些的,一时想不起来, 想起来再写吧。
阅读(2694) | 评论(4) | 转发(0) |