BitTorrent 协议规范（BT协议集合）二二

昨天重新读了BT协议和客户端代码,发现对协议本身部分比较熟悉了,但是对BT在实际运行期间各种行为的发生情景还非常模糊,有些步骤还想清楚,大家一起来讨论一下.

我们来一起描述一下BT各种消息的发送情景. 有些不是特别肯定的我没有加上,大家在这个基础上进行增加或者修改.

其中client指本机上运行的BT客户端.peer指tracker返回的远程客户端.
piece指torrent文件中的20byte SHA1 hash代表的数据段. block指每次向其他peer请求的数据段(子分片).

[3-16更新]
1. client->tracker的GET消息.
<1>第一次启动后发送(携带event为started).
<2>以后根据tracker reponse中的interval定时发送.
<3>某种事件发生(stopped, completed)时发送.
<4>需要更多的peer列表时发送.

2.tracker->client的reponse
<1>每次收到client的GET请求后发送.

3.client->peer的handshake消息
<1> client主动向peer发起TCP连接并成功建立，client主动发起handshake.
<2> peer主动向client发起TCP连接并成功建立, client收到peer的handshake后回应handshake.

4.peer->client的handshake消息
<1> peer主动向client发起TCP连接并成功建立，peer主动发起handshake.
<2> client主动向peer发起TCP连接并成功建立, peer收到handshake的handshake后回应handshake.

5.client->peer的bitField消息
<1> 如果client主动发起连接,client收到peer的handshake回应后,发送bitField消息.
<2> 如果peer主动发起连接,client回应完handshake后发送bitField消息.

6.peer->client的bitField消息
<1> 如果peer主动发起连接,peer收到client的handshake回应后,发送bitField消息.
<2> 如果client主动发起连接,peer回应完handshake后发送bitField消息.

7.client->peer的keep-alive消息
<1>定时发送(2分钟一次)

8.peer->client的keep-alive消息
<1>定时发送(2分钟一次)

9.client->peer的choke消息
<1> 每隔30秒扫描一次peer列表，对不符合条件??的peer发送choke ???
<2> 如果接到peer的无效request请求,向peer发送choke

10.peer->client的choke消息
<1> 每隔30秒扫描一次peer列表，对不符合条件??的peer发送choke ???
<2> 如果接到client的无效request请求,向client发送choke

11.client->peer的unchoke消息
<1> 每隔30秒扫描一次peer列表，对符合条件??的peer发送unchoke ???

12.peer->client的unchoke消息
<1> 每隔30秒扫描一次peer列表，对符合条件??的peer发送unchoke ???

13.client->peer的interested消息
<1> 收到peer的bitField消息后,根据本地情况进行判断是否向peer发送interested消息.
<2> 收到peer的have消息后,根据本地情况进行判断是否向peer发送interested消息.

14.peer->client的interested消息
<1> 收到client的bitField消息后,根据本地情况进行判断是否向client发送interested消息.
<2> 收到client的have消息后,根据本地情况进行判断是否向client发送interested消息.

15.client->peer的not interested消息
<1> 收到peer的bitField消息后,根据本地情况进行判断是否向peer发送not interested消息.
<2> 收到peer的piece消息后,根据本地情况进行判断是否向peer发送not interested消息.

16.peer->client的not interested消息
<1> 收到client的bitField消息后,根据本地情况进行判断是否向client发送not interested消息.
<2> 收到client的piece消息后,根据本地情况进行判断是否向client发送not interested消息.

17.client->peer的have消息
<1>client下载某个piece完成并且校验后发送.

18.peer->client的have消息
<1>peer下载某个piece完成并且校验后发送.

19.client->peer的request消息
<1>client收到peer的unchoke消息,根据本地情况进行判断是否向peer发送request
<2>client收到peer的have消息,根据本地情况进行判断是否向peer发送request
<3>client收到peer的piece消息,根据本地情况进行判断是否向peer发送request

20.peer->client的request消息
<1>peer收到client的unchoke消息,根据本地情况进行判断是否向client发送request
<2>peer收到client的have消息,根据本地情况进行判断是否向client发送request
<3>peer收到client的piece消息,根据本地情况进行判断是否向client发送request

21.client->peer的piece消息
<1>client收到peer的request消息后,并且发现自己并没有choke对方时发送.

22.peer->client的piece消息
<1>peer收到client的request消息后,并且发现自己并没有choke对方时发送.

23.client->peer的cancel消息
<1>client在即将完成下载阶段(endgame),向所有peer发送request消息(是向所有没有choke自己的peer??), 如果某个peer最先返回了请求的block(piece消息),则向其他未返回的peer发送cancel消息.

也就是说这个阶段client端还是可能收到重复的block.

24.peer->client的cancel消息
<1>peer在即将完成下载阶段(endgame),向所有peer发送request消息(是向所有没有choke自己的peer??), 如果某个peer最先返回了请求的block(piece消息),则向其他未返回的peer发送cancel消息.
也就是说这个阶段如果client还没有给peer发送piece消息,那么会收到cancel消息.
并且可能在client刚刚给peer发送出piece消息后就收到了cancel消息.

以上的场景描述都是基于个人理解,可能有些地方是错误的,希望大家指出来.

另外对于client端在什么时候开始发送request请求(主动发送还是被动发送),还有就是如何进行上载速率控制(对那些peer分配多少上载带宽,本地上载带宽限制)等问题,我还比较模糊,希望大家指教.尤其象小马哥这样的分析过源码的DX多多发言.

问题:
1.在libBT中,收到unchoke消息后,也会发送interested/not interested消息,但是我觉得没有必要这样做,在bitField/have消息后更新状态已经保证了每个peer的interested/not interested状态真实有效.
2.什么情况下认为一个peer应该被choke/unchoke?
3.client初始化为 local_interested = 0 //client对peer不感兴趣
local_choking = 1 //client is choking peer
remote_interested = 0 //peer对client不感兴趣
remote_choking =1 //peer is choking client
因此,应该说client是在收到某个peer的unchoke后才开始从这个peer处下载.然后根据不停的have消息和piece消息完成从某个peer处的连续下载.
问题在于什么条件下remote peer会给client发送unchoke?? 相同的问题也就是client什么情况下会给peer开始发送unchoke消息??
从code中可以看到,每个定长时间(30 seconds),检查哪些peer符合unchoke条件(Client没有被peer怠慢，并且Peer对Client感兴趣).但是每个peer的初始状态被设置为了怠慢. 所以不知道如何才能让client去unchoke peer???