由上篇bnbt tracker执行流程,我们知道bt tracker的核心是/announce。BT客户端与tracker之间的通讯以及tracker内部是如何处理的呢?

我们从BT客户端发起请求开始。BT协议的具体内容不多说,参见这里

BT客户端首先读torrent文件,例如:
d8:announce35:http://192.168.0.1:2222/announce10:created by13:BitComet/0.9213:creation datei1192120049e8:encoding3:GBK4:infod4:ed2k16:魖趸?[T,胕@驋8:filehash20:廹C<`鮾}瀽穤茕蛯]6:lengthi43e4:name11:AUTORUN.INF10:name.utf-811:AUTORUN.INF12:piece lengthi32768e6:pieces20:廹C<`鮾}瀽穤茕蛯]ee

其中,”http://192.168.0.1:2222/announce”是tracker URL,”AUTORUN.INF”是文件名,中间的乱码是文件的hash值,其他信息还有片段(piece)的长度(32K)、片段数、创建的软件、时间等。

BT客户端据此向tracker发送GET请求,例如:
GET http://192.168.0.1:2222/announce?info_hash=w%3D%1E%FB%A2%09%8C%E5k%2A%9F%A03PQ%3E%12%2CMq&peer_id=-BC0092-%89v%5E%0A%8Cf%EB%90%B1%0D%EE%DE&port=14479&natmapped=1&localip=192.168.0.65&port_type=lan&uploaded=0&downloaded=0&left=0&numwant=200&compact=1&no_peer_id=1&key=31526&event=started HTTP/1.1

其中,主要是文件的hash值(info_hash)、希望返回的bt客户端数量(numwant),以及本客户端的信息(peer id、port、已上传下载字节数等)。

bnbt在tracker_announce.cppCTracker.serverResponseAnnounce()函数中处理这个请求,具体流程是:

  1. 调用tracker.cpp中的CTracker.Announce()函数,将该BT客户端添加到该BT文件对应的peer列表中。peer列表无数量上限。
  2. 确定返回的peer数量,在tracker设置和BT客户端要求中取数值小者。
  3. 如果cache列表(pCacheList)中的peer数小于返回的peer数量,则将peer列表全部加到cache中。否则,跳到5
  4. 将cache列表顺序随机打乱
  5. 从cache列表开头依次取peer,加入到返回列表中,然后从cache中删除。

serverResponseAnnounce的处理过程比我想象的简单得多,它只是尽可能保证返回peer数量,并未对peer进行任何选择。换言之,tracker并不考虑返回的是seed,还是lecher。实际上,tracker根本就没有记录哪个peer是seed。因为BT客户端之间是建立双向传输连接互相传输数据的,所以BT的作者显然是想通过无为而治来达到自然的上下载平衡。

但在某些特殊的场景中,达不到这种理想平衡。比如,大量peer集中下载1个新文件,seed很少,绝大多数是完全没有数据的空lecher。seed就会被淹没在空lecher的海洋中。每个peer得到的都是一堆空lecher,都不能下载到任何数据。而seed反而因为只有很少的peer连接过来而空闲,从而使整个BT下载体系陷入停顿的状态,如同一个果料果冻,少数果料被包裹分隔,发挥不出作用。所以,我叫它“果冻效应”。后面我们将重点讨论果冻效应及其解决。

转载请注明来自:jijian91与小z - 编程

永久链接:https://jijian91.com/blog20071019/bnbt-tracker-announce.html