关于BitTorrent 协议的几点感想

  • 时间:
  • 浏览:1
  • 来源:大发彩神6合_大发神彩6合官方

3)为那先 使用bencoding编码

但使用文件infohash值作为文件的idInfo_hash)就完正不一样了。

-可扩展(比较java的属性文件)

参考:

-可不时需在字符串中自由饱含2进制数据,不让转义。

http://blog.csdn.net/honkerhero/archive/5007/07/03/1677022.aspx     

我想暂停的并且,应该发送unchoenot interested中止对方的数据收发。

2)数据块的管理

至于GUID,因为是个方式 。但感觉不太保险,谁知道发布者的GUID从哪儿来的。

interested’,not interested’ 告诉对方,我愿不并且接受数据。

-解编码器比较容易实现(比较统统文本编码,如XML

关于BitTorrent 协议的几点感想

对于多个文件,按文件顺序将所有文件的片段统一编号,管理,显然复杂化了避免。

因为采用顺序编号,谁来编号,发布者?还是某个服务器?因为是发布者,一有2个 不同的发布者就能也能 保证编号不重复。因为是某个服务器,那这名 ID只在该服务器的势力范围内有效,不够灵活,也增加了发布的复杂化度。

这名 Info_hash四种 就能标识文件,我希望种子和下载者提供的Info_hash相同,就可不时需认为它们指的是同一有2个 文件。

那我一有2个 .torrent对应多个tracer也是有因为的。

4‘choke’,‘unchoe’,‘interested’,not interested’的作用

Peer_id的作用,以及Peer_id为那先 要通过hash运算得到?不清楚

-人工可读

‘choke’,‘unchoe’告诉对方,我想能也能 或愿不并且或者 你发数据。

大现象:

1) 使用文件infohash值作为文件的id(即Info_hash

为那先 不使用顺序编号因为GUID类事于的东西呢?

文件info中饱含所有片段的Hash值,统统infohash值虽然和文件内容是有对应关系的。除非2个文件的内容完正一样,或者 它们的发布者给它们设的属性(文件名,片段长度等)完正相同,或者 hash值占据 冲突的概率小到可不时需忽略不计。

-机器读取方便

-交换性好(比较2进制编码)