BT服务器源码分析4:bnbt的tracker announce

由上篇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.cpp的CTracker.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