关于BitTorrent 协议的几点感想

skykiker

               

  Normal
  0
  
  0
  2
  
  false
  false
  false
  
   
   
   
   
   
   
   
   
   
   
   
   
  
  MicrosoftInternetExplorer4



/* Style Definitions */
table.MsoNormalTable
        {mso-style-name:標準の表;
        mso-tstyle-rowband-size:0;
        mso-tstyle-colband-size:0;
        mso-style-noshow:yes;
        mso-style-parent:"";
        mso-padding-alt:0mm 5.4pt 0mm 5.4pt;
        mso-para-margin:0mm;
        mso-para-margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:10.0pt;
        font-family:Century;
        mso-ansi-language:#0400;
        mso-fareast-language:#0400;
        mso-bidi-language:#0400;}
关于BitTorrent
协议的几点感想
1） 使用文件info的hash值作为文件的id（即Info_hash）
为什么不使用顺序编号或者GUID之类的东西呢？
如果采用顺序编号，谁来编号，发布者？还是某个服务器？如果是发布者，两个不同的发布者就不能保证编号不重复。如果是某个服务器，那这个ID只在该服务器的势力范围内有效，不够灵活，也增加了发布的复杂度。
至于GUID，可能是个办法。但感觉不太保险，谁知道发布者的GUID从哪儿来的。
但使用文件info的hash值作为文件的id（Info_hash）就完全不一样了。
文件info中包含所有片段的Hash值，所以info的hash值其实和文件内容是有对应关系的。除非2个文件的内容完全一样，并且它们的发布者给它们设的属性(文件名，片段长度等)完全相同，否则hash值发生冲突的概率小到可以忽略不计。
这个Info_hash本身就能标识文件，只要种子和下载者提供的Info_hash相同，就可以认为它们指的是同一个文件。
这样一个.torrent对应多个tracer也是有可能的。

2）数据块的管理
对于多个文件，按文件顺序将所有文件的片段统一编号，管理，显然简化了处理。

3）为什么使用bencoding编码
-交换性好（比较2进制编码）
-机器读取方便
-解编码器比较容易实现（比较其他文本编码，如XML）
-可以在字符串中自由包含2进制数据，不用转义。
-可扩展(比较java的属性文件)
-人工可读

4）‘choke’,‘unchoe’,‘interested’,’not interested’的作用
‘choke’,‘unchoe’告诉对方，我能不能或愿不愿意给你发数据。
interested’,’not interested’ 告诉对方，我愿不愿意接受数据。
我想暂停的时候，应该发送’unchoe’和’not interested’中止对方的数据收发。

疑问：
Peer_id的作用，以及Peer_id为什么要通过hash运算得到？不清楚
参考：
http://blog.csdn.net/honkerhero/archive/2007/07/03/1677022.aspx
      


               
               
               
               
               

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