在这个示意图中，客户端 A 与 其它 peers B、C、D、E 都建立了连接。通过箭头来表示连接建立的方向。A主动与 B、D、E 建立连接；A被动接收C的连接。同时C与D、E与D、B与D之间也都有连接。这样，所有下载者之间就形成了一个网状的结构。
 同时，这些下载者都要与 tracker 之间不断通信。
 无论是被动连接，还是主动连接，一旦在“BT对等握手”成功之后，它们就没有任何区别了。下载通过这个连接进行，上传也是通过这个连接进行。
 
 本文重点分析BT客户端如何主动向其它 peers 发起连接；BT客户端如何被动接收其它 peers 的连接请求；以及在连接建立成功之后，如何进行BT对等协议握手的过程。

客户端主动发起连接
【Encrypter.py】
 上一节的最后，我们看到调用 Encoder::start_connection() 来向其它 peer 发起连接。所以，从这里开始看起。

class Encoder:
# start_connection() 需要两个参数：
dns：对方的ip、port 的组合。
id： 对方的 id。每个BT客户端都要创建一个唯一的 id 号，并且把这个 id 号报告给 tracker。Id号唯一标识了一个客户端。Id 号的计算方式在 download.py 中。
myid = 'M' + version.replace('.', '-')
myid = myid + ('-' * (8 - len(myid))) + b2a_hex(sha(repr(time()) + ' ' +
str(getpid())).digest()[-6:])
seed(myid)
①def start_connection(self, dns, id):
        if id:
            # 如果 id 是自己，不连接
            if id == self.my_id:
                return
            # 如果已经和这个peer建立了连接，也不再建立连接。
            for v in self.connections.s():
                if v.id == id:
return
  # 如果当前连接数过多，暂时不发起连接
        if len(self.connections) >= self.max_initiate:
# self.spares 起到缓存的作用。在当前连接数过多的情况下，把本次要连接的 peer 的 ip、port 缓存起来。一旦当前连接数小于设定值 max_initiate， 则可以从 spares 中取出备用的 peers。
            if len(self.spares) < self.max_initiate and dns not in self.spares:
                self.spares.append(dns)
            return
        try:
# 调用 RawServer::start_connection()，发起 TCP 的连接。RawServer的代码分析请参看“服务器源码分析”系列文章，不再赘述
# 返回的 c 是一个 SingleSocket 对象，它封装了 socket 句柄
            # 如果出错，抛出 socketerror 异常
            c = self.raw_server.start_connection(dns)
# 成功建立 TCP 连接。构造一个 Connection对象，加入 connections 字典中。注意，最后一个参数是 True，它表面这条连接是由客户端主动发起建立的。我们立刻去看 Connection 类的构造
            self.connections[c] = Connection(self, c, id, True)
        except socketerror:
            pass
 
【Encrypter.py】
class Connection:
  ②  def __init__(self, Encoder, connection, id, is_local):
        self.encoder = Encoder
        self.connection = connection #这个 connection 是 SingleSocket 对象，就是上面 RawServer::start_connection() 返回的值，它封装了对socket句柄的操作。名字起的不好，容易弄混淆。
        self.id = id
        self.locally_initiated = is_local #这个连接是否由本地发起？
        self.complete = False
        self.closed = False
        self.buffer = StringIO()
        self.next_len = 1
        ⑦self.next_func = self.read_header_len
  
# 如果由本地发起，那么给对方发送BT对等连接的握手消息。
        ④if self.locally_initiated:
            connection.write(chr(len(protocol_name)) + protocol_name +
                (chr(0) * 8) + self.encoder.download_id)
            if self.id is not None:
                connection.write(self.encoder.my_id)

客户端被动接受外来连接
客 户端在与 tracker 通信的时候，已经把自己的 ip 和监听的 port 报告给了 tracker。这样，其它 peers 就可以通过这个 ip 和 port 来连接它了。例如上图中的C，就主动给 A 发一个连接，从C的角度来说，它是“主动连接”，但从A的角度，它是“被动连接”。
一旦有外来连接请求，就会调用 RawServer::handle_events()，下面是摘录的“Tracker 服务器源码分析之二：RawServer类”中的一段。

最 后调用的是 Handle 的 external_connection_made()，对客户端来说，这个Handle 是 Encoder 类对象。所以，外来连接建立成功后，最后调用的是 Encoder:: external_connection_made()：

③def external_connection_made(self, connection):
 # 同样是创建一个新的 Connection 类，并加入 connections 字典中。但不同之处在于最后一个参数是 False，表明这个连接是由外部发起的。
self.connections[connection] = Connection(self, connection, None, False)

BT对等连接握手：第一步

如果是主动连接，那么一旦连接建立成功之后，就给对方发送一个握手消息，我们折回去看序号为 4 的代码：
if self.locally_initiated:
     connection.write(chr(len(protocol_name)) + protocol_name +
                (chr(0) * 8) + self.encoder.download_id)
        if self.id is not None:
     connection.write(self.encoder.my_id)

在《BT协议规范》中，如此描述握手消息：
对等协议由一个握手开始，后面是循环的消息流，每个消息的前面，都有一个数字来表示消息的长度。握手的过程首先是先发送19，然后发送协议名称“BitTorrent protocol”。19就是“BitTorrent protocol”的长度。
后续的所有的整数，都采用big-endian 来编码为4个字节。
在协议名称之后，是8个保留的字节，这些字节当前都设置为0。
接下来对元文件中的 info 信息，通过 sha1 计算后得到的 hash值，20个字节长。接收消息方，也会对 info 进行一个 hash 运算，如果这两个结果不一样，那么说明双方要下载的文件不一致，会切断连接。
接下来是20个字节的 peer id。
可 以看到，最后两项就是 Encoder::download_id 和 Encoder::my_id。download_id是如何得来的？它是首先对 torrent 文件中 info 关键字所包含的信息进行 Bencoding 方式的编码（请看《BT协议规范》关于 Bencoding的介绍），然后再通过 sha 函数计算出的 hash（摘要）值。（相关代码都在 download.py 中）。在一次下载过程中，所有的下载者根据 torrent 文件计算出的这个 download_id应该都是一样的，否则就说明不处于同一个下载过程中。
至于 peer_id，可以看出是可选的。它的计算方式也在 download.py 中：
myid = 'M' + version.replace('.', '-')
myid = myid + ('-' * (8 - len(myid))) + b2a_hex(sha(repr(time()) + ' ' + str(getpid())).digest()[-6:])
seed(myid)

它用来唯一标识一个 peer。
握手过程已经完成了第一步，还需要第二步，接收到对方的握手消息，握手过程才算完成。所以接下去看在有数据到来的时候，是如何处理的。

BT对等连接握手：第二步
当TCP连接上有数据到来的时候， RawServer 会调用到 Encoder:: data_came_in()

【Encoder】
⑤def data_came_in(self, connection, data):
        self.connections[connection].data_came_in(data)

进一步调用 Connection::data_came_in()

【Connection】
⑥def data_came_in(self, s):
 #这个循环处理用来对BT对等连接中的消息进行分析
        while True:
            if self.closed:
                return
            i = self.next_len - self.buffer.tell()
            if i > len(s):
                self.buffer.write(s)
                return
            self.buffer.write(s[:i])
            s = s[i:]
            m = self.buffer.get()
            self.buffer.reset()
            self.buffer.truncate()
            try:
                x = self.next_func(m) #调用消息分析函数，第一个被调用的是read_header_len
            except:
                self.next_len, self.next_func = 1, self.read_dead
                raise
            if x is None:
                self.close()
                return
            self.next_len, self.next_func = x

⑧def read_header_len(self, s):
 # 协议的长度是否为 19？
        if ord(s) != len(protocol_name):
            return None
        return len(protocol_name), self.read_header # 下一个处理函数

def read_header(self, s):
 # 协议名称是否是“BitTorrent protocol”？
        if s != protocol_name:
            return None
        return 8, self.read_reserved # 下一个处理函数

def read_reserved(self, s):
 #8个保留字节
        return 20, self.read_download_id # 下一个处理函数

def read_download_id(self, s):
 对方 download_id 和自己计算出的是否一致？
        if s != self.encoder.download_id:
return None
  检查完 download_id，就认为对方已经通过检查了。
这里很关键！！！，需要仔细体会。这实际上就是在被动连接情况下，完成握手过程的处理。如果连接不是由本地发起的（被动接收到一个握手消息），那么给对方回一个握手消息。这里的握手消息发送处理和第一步是一样的
        if not self.locally_initiated:
            self.connection.write(chr(len(protocol_name)) + protocol_name +
                (chr(0) * 8) + self.encoder.download_id + self.encoder.my_id)
        return 20, self.read_peer_id #下一个处理函数

def read_peer_id(self, s):
# Connection 类用来管理一个 BT 对等连接。在握手完成之后，就用对方的 peer_id 来唯一标识这个 Connection。这个值被保存在 self.id 中。显然，在握手完成之前，这个 id 还是空值。
        if not self.id:
  
   # 对方的peer_id 可千万别跟自己的一样
            if s == self.encoder.my_id:
                return None
   唔，如果 peer_id 已经收到过，也不继续下去了
            for v in self.encoder.connections.s():
                if s and v.id == s:
return None
   用对方的 peer_id 为 self.id 赋值，唯一标识这个 Connection
            self.id = s
            if self.locally_initiated:
                self.connection.write(self.encoder.my_id)
            else:
                self.encoder.everinc = True
        else:
   
   if s != self.id:
                return None
  # OK，握手完成！！！
        self.complete = True
        self.encoder.connecter.connection_made(self)
        return 4, self.read_len #下一个处理函数。从此以后，就是对其它BT对等消息的处理过程了。这是我们下一节分析的问题。

  这一节我们分析BT客户端与 tracker 服务器的通信过程。在整个下载过程中，客户端必须不断的与 tracker 通信，报告自己的状态，同时也从 tracker 那里获取当前参与下载的其它 peers 的信息（ip地址、端口等）。一旦不能与 tracker 通信，则下载过程无法继续下去。
 客户端与 tracker 之间采用 HTTP 协议通信，客户端把状态信息放在 HTTP协议的GET命令的参数中传递给 tracker，tracker 则把 peers列表等信息放在 中传递给 客户端。这种设计非常简捷巧妙。采用HTTP协议也更使得穿越防火墙的阻拦更容易（不过实际应用中，tracker通常不会使用 80 端口）。
 请务必参考服务器端源码分析的几篇相关文章（论坛中有）。
 Rerequester 类全权负责与 tracker 的通信任务，我们首先看客户端主程序 download.py中相应的代码：

【download.py】
①rerequest = Rerequester(response['announce'], config['rerequest_interval'],
        rawserver.add_task, connecter.how_many_connections,
        config['min_peers'], encoder.start_connection,
        rawserver.add_task, storagewrapper.get_amount_left,
        upmeasure.get_total, downmeasure.get_total, listen_port,
        config['ip'], myid, infohash, config['http_timeout'], errorfunc,
        config['max_initiate'], doneflag, upmeasure.get_rate,
downmeasure.get_rate,
        encoder.ever_got_incoming
②rerequest.begin()

Rerequester 类的构造函数中传递了一大堆参数，重点是 rawserver.add_task和 encoder.start_connection（rawserver和encoder 这两个对象，在上一节中，我们已经看到了它们的构造过程），分别对应RawServer::add_task() 和 Encoder::start_connection()，稍后会看到它们的作用。
一切从 Rerequest::begin() 开始。

【rerequester.py】

class Rerequester:
 # 这个构造函数传递了一大堆参数，现在没必要搞的那么清楚，关键是 sched 和 connect 这两个参数，对照前面的代码，很容易知道它们是什么。
    def __init__(self, url, interval, sched, howmany, minpeers,
            connect, externalsched, amount_left, up, down,
            port, ip, myid, infohash, timeout, errorfunc, maxpeers, doneflag,
            upratefunc, downratefunc, ever_got_incoming):
        self.url = ('%s?info_hash=%s&peer_id=%s&port=%s&key=%s' %
            (url, quote(infohash), quote(myid), str(port),
            b2a_hex(''.join([chr(randrange(256)) for i in xrange(4)]))))
        if ip != '':
            self.url += '&ip=' + quote(ip)
        self.interval = interval
        self.last = None
        self.trackerid = None
        self.announce_interval = 30 * 60
        self.sched = sched # －》RawServer::add_task()
        self.howmany = howmany # 当前有多少个连接 peer
        self.minpeers = minpeers
        self.connect = connect #－》 Encoder::start_connection()
        self.externalsched = externalsched
        self.amount_left = amount_left
        self.up = up
        self.down = down
        self.timeout = timeout
        self.errorfunc = errorfunc
        self.maxpeers = maxpeers
        self.doneflag = doneflag
        self.upratefunc = upratefunc
        self.downratefunc = downratefunc
        self.ever_got_incoming = ever_got_incoming
        self.last_failed = True
        self.last_time = 0

④ def c(self):
  # 再调用一次 add_task()，把自身加入到客户端的任务队列中，这样就形成了任务循环，每隔一段时间，就会执行这个函数。从而，客户端与 tracker 的通信能够持续的进行下去。
        self.sched(self.c, self.interval)
       
        if self.ever_got_incoming():
            # 如果曾经接受到过外来的连接，那么说明这个客户端是可以接受外来连接的，也就是说很可能处于“公网”之中，所以并非很迫切的需要从 tracker 那里获取 peers 列表。（既可以主动连接别人，也可以接受别人的连接，所以有点不紧不慢的味道）。
            getmore = self.howmany() <= self.minpeers / 3
        else:
            # 如果从来没有接受到过外来的连接，那么很有可能处于内网之中，根本无法接受外来的连接。这种情况下，只有主动的去连接外部的 peers，所以要尽可能的向 tracker 请求更多的 peers。（只能去连接别人，所以更迫切一些）。
            getmore = self.howmany() < self.minpeers
        if getmore or time() - self.last_time > self.announce_interval:
            # 如果有必要从 tracker 那里获取 peers 列表，且任务执行时间已到，则调用 announce() 开始与 tracker 通信
            self.announce()

③    def begin(self):
        # 调用前面提到的 RawServer::add_task()，把 Rerequester::c() 加入到 rawserver对象的任务队列中
        self.sched(self.c, self.interval)
  # 宣布与 tracker 的通信开始。。。。
        self.announce(0)

⑤    def announce(self, event = None):
        self.last_time = time()
  # 传递给 tracker 的信息，放在 HTTP GET 命令的参数中。所以，首先就是构造这个参数。
  # 传递给 tracker 的信息，必须包括 uploaded、downloaded、left 信息。其它入 last、trackerid、numwant、compact、event 是可选的。这些参数的解释请看 BT协议规范。
        s = ('%s&uploaded=%s&downloaded=%s&left=%s' %
            (self.url, str(self.up()), str(self.down()),
            str(self.amount_left())))
        if self.last is not None:
            s += '&last=' + quote(str(self.last))
        if self.trackerid is not None:
            s += '&trackerid=' + quote(str(self.trackerid))
        if self.howmany() >= self.maxpeers:
            s += '&numwant=0'
        else:
            s += '&compact=1'
        if event != None:
            s += '&event=' + ['started', 'completed', 'stopped'][event]
        set = SetOnce().set

  # 函数中可以嵌套定义函数，这是 python 语法特别的地方。
  # 调用 RawServer::add_task() 把 checkfail() 加入到任务队列中。在 timeout 时间之后，检查向 tracker 发的GET命令是否失败。
        def checkfail(self = self, set = set):
            if set():
                if self.last_failed and self.upratefunc() < 100 and self.downratefunc() < 100:
                    self.errorfunc('Problem connecting to tracker - timeout exceeded')
                self.last_failed = True
        self.sched(checkfail, self.timeout)

        # 创建一个线程，执行 Rerequester::rerequest()
  # 可见，客户端与 tracker之间的通信是由单独的线程完成的
        Thread(target = self.rerequest, args = [s, set]).start()

⑥    def rerequest(self, url, set):
        try:
   # 调用 urlopen() ，向 tracker 发送命令
h = urlopen(url)
# read() 返回 tracker 的响应数据。
            r = h.read()
            h.close()
            if set():
                def add(self = self, r = r):
self.last_failed = False
# 从 tracker 响应回来的数据，由 postrequest() 处理。
self.postrequest(r)
# externalsched() 同样是调用 RawServer::add_task()，这样，由主线程调用 postrequest() 函数，处理 tracker 响应的数据。（不要忘记，我们现在是处在一个单独的子线程中。）
                self.externalsched(add, 0)
        except (IOError, error), e:
            if set():
                def fail(self = self, r = 'Problem connecting to tracker - ' + str(e)):
                    if self.last_failed:
                        self.errorfunc(r)
                    self.last_failed = True
                self.externalsched(fail, 0)

⑦    def postrequest(self, data):
        try:
   # 对服务器响应的数据解码。请参看BT协议规范。
r = bdecode(data)
# 检查 peers 有效性？
            check_peers(r)
            if r.has_key('failure reason'):
                self.errorfunc('rejected by tracker - ' + r['failure reason'])
            else:
                if r.has_key('warning message'):
self.errorfunc('warning from tracker - ' + r['warning message'])

 # 根据 tracker 的响应，调整BT客户端的参数。
                self.announce_interval = r.get('interval', self.announce_interval)
                self.interval = r.get('min interval', self.interval)
                self.trackerid = r.get('tracker id', self.trackerid)
                self.last = r.get('last')

    # 将其它下载者的信息保存到 peers 数组中。
                p = r['peers']
                peers = []
                if type(p) == type(''):
                    for x in xrange(0, len(p), 6):
                        ip = '.'.join([str(ord(i)) for i in p[x:x+4]])
                        port = (ord(p[x+4]) << 8) | ord(p[x+5])
                        peers.append((ip, port, None))
                else:
                    for x in p:
                        peers.append((x['ip'], x['port'], x.get('peer id')))
                ps = len(peers) + self.howmany()
                if ps < self.maxpeers:
                    if self.doneflag.isSet():
                        if r.get('num peers', 1000) - r.get('done peers', 0) > ps * 1.2:
                            self.last = None
                    else:
                        if r.get('num peers', 1000) > ps * 1.2:
                            self.last = None
                # 这里的 connect，即前面的Encoder::start_connection()，
    # 至此，已经成功的完成了一次与 tracker 服务器的通信，并且从它那里获取了 peers 列表；下面就与这些 peers 挨个建立连接；至于建立连接的过程，就要追踪到 Encoder 类中了，且听下回分解。
                for x in peers:
                    # x[0]:ip, x[1]:port, x[2]:id
                    self.connect((x[0], x[1]), x[2])
        except Error, e:
            if data != '':
                self.errorfunc('bad data from tracker - ' + str(e))

小结：
  这篇文章，我们重点分析了BT客户端与 tracker 服务器通信的过程。我们知道了，客户端要每隔一段时间，就去连接 tracker 一次，它是以一个单独的线程执行的。这个线程在接受到 tracker 的响应数据后，交给主线程（既主程序）来进行分析。主程序从响应数据中，获得 peers 列表。然后调用 Encoder::start_connection() 挨个与这些 peers 尝试建立连接。

class Connection:
    ②def __init__(self, Encoder, connection, id, is_local):
        self.encoder = Encoder
        self.connection = connection
如果是本地发起连接，那么 id 是对方的 id，否则 id 为 None
        self.id = id
如果连接是由本地发起的，那么 is_local 为 True，否则为 False
        self.locally_initiated = is_local
        self.complete = False
        self.closed = False
        self.buffer = StringIO()
        self.next_len = 1
        self.next_func = self.read_header_len
如果连接是由本地主动发起建立的，那么需要向对方发送一个握手消息。（如果不是由本地主动发起的，那么就是被动建立的，那么不能在这里发送握手消息，而必须在分析完对方的握手消息之后，再去回应一个握手西消息，请看read_download_id() 中的处理。
        if self.locally_initiated:
            connection.write(chr(len(protocol_name)) + protocol_name +
                (chr(0) * 8) + self.encoder.download_id)
            if self.id is not None:
                connection.write(self.encoder.my_id)

    def get_ip(self):
        return self.connection.get_ip()

    def get_id(self):
        return self.id

    def is_locally_initiated(self):
        return self.locally_initiated

    def is_flushed(self):
        return self.connection.is_flushed()

    ⑦def read_header_len(self, s):
        if ord(s) != len(protocol_name):
            return None
        return len(protocol_name), self.read_header

    def read_header(self, s):
        if s != protocol_name:
            return None
        return 8, self.read_reserved

    def read_reserved(self, s):
        return 20, self.read_download_id

    def read_download_id(self, s):
        if s != self.encoder.download_id:
            return None
这一步很重要， 如果连接是由对方发起的，那么，给对方发送一个握手消息。为什么不在读完了 peer id 之后才发送这个消息了？这是因为 peer id 是可选的，所以只要分析完 download id 之后，就要立即发送握手消息。
        if not self.locally_initiated:
self.connection.write(chr(len(protocol_name)) +
protocol_name +
(chr(0) * 8) +
self.encoder.download_id + self.encoder.my_id)
        return 20, self.read_peer_id

    def read_peer_id(self, s):
        if not self.id:
            如果 peer id 是自己，那么出错了
            if s == self.encoder.my_id:
                return None
            for v in self.encoder.connections.s():
                如果已经跟该 peer 建立了连接了，那么也出错了
                if s and v.id == s:
                    return None
            self.id = s
            if self.locally_initiated:
                self.connection.write(self.encoder.my_id)
            else:
                self.encoder.everinc = True
        else:
            如果 peer id 和 xxx 不符，那么出错了。
            if s != self.id:
                return None

“BT对等连接”的握手过程正式宣告完成，此后，双方就可以通过这个连接互相发送消息了。
        self.complete = True

调用Connecter::connection_made()，这个函数的意义，我们到分析 Connecter 类的时候，再记得分析。
        self.encoder.connecter.connection_made(self)

下面进入 BT 消息的处理过程。
        return 4, self.read_len

    def read_len(self, s):
        l = toint(s)
        if l > self.encoder.max_len:
            return None
        return l, self.read_message

消息处理，交给了 Connecter::got_message()，所以下一篇我们要分析 Connecter 类。
    def read_message(self, s):
        if s != '':
            self.encoder.connecter.got_message(self, s)
        return 4, self.read_len

    def read_dead(self, s):
        return None

    def close(self):
        if not self.closed:
            self.connection.close()
            self.sever()

    def sever(self):
        self.closed = True
        del self.encoder.connections[self.connection]
        if self.complete:
            self.encoder.connecter.connection_lost(self)

    def send_message(self, message):
        self.connection.write(tobinary(len(message)) + message)

⑤在 Encoder::data_came_in() 中调用下面这个函数，表示某个连接上有数据可读。如果有数据可读，那么我们就按照 BT 对等协议的规范来进行分析。。。
def data_came_in(self, s):

进入协议分析循环。。。
        while True:
            if self.closed:
                return

self.next_len表示按照BT对等协议规范，下一段要分析的数据的长度
self.buffer.tell() 表示缓冲区中剩下数据的长度
那么 i 就表示：为了完成接下来的协议分析，还需要多少数据？
i = self.next_len - self.buffer.tell()
如果 i 大于所读到的数据的长度，那表示数据还没有读够，无法继续协议分析，需要等读到足够多的数据才能继续，所以只能退出。
            if i > len(s):
                self.buffer.write(s)
                return
否则表示这次读到的数据已经足够完成一步协议分析。
只取满足这一步协议分析的数据放入 buffer 中（因为 buffer中可能还有上一步协议分析后留下的一些数据，要加在一起），剩下的数据保留在 s 中。
            self.buffer.write(s[:i])
s = s[i:]

从 buffer 中取出数据，这些数据就是这一步协议分析所需要的数据。然后把 buffer 清空。
            m = self.buffer.get()
            self.buffer.reset()
self.buffer.truncate()

next_func 就是用于这一步协议分析的函数。
返回的 x 是一个二元组，包含了下一步协议分析的数据长度和协议分析函数。这样，就形成了一个协议分析循环。
            try:
                x = self.next_func(m)
            except:
                self.next_len, self.next_func = 1, self.read_dead
                raise
            if x is None:
                self.close()
                return
从 x 中分解出 next_len和 next_func。
self.next_len, self.next_func = x
⑥那么BT对等协议分析的第一步是什么了？
请看初始化函数：
self.next_len = 1
self.next_func = self.read_header_len
显然，第一步协议分析是由 read_header_len() 来完成的。
在BT源码中，有多处采用了这种协议分析的处理方式。

class Encoder:
    def __init__(self, connecter, raw_server, my_id, max_len,
            schedulefunc, keepalive_delay, download_id,
            max_initiate = 40):
        self.raw_server = raw_server
        self.connecter = connecter
        self.my_id = my_id
        self.max_len = max_len
        self.schedulefunc = schedulefunc
        self.keepalive_delay = keepalive_delay
        self.download_id = download_id
        最大发起的连接数
        self.max_initiate = max_initiate
        self.everinc = False
       
        self.connections = {}
        self.spares = []
       
        schedulefunc(self.send_keepalives, keepalive_delay)

为了保持连接不因为超时而被关闭，所以可能需要随机的发送一些空消息，它的目的纯粹是为了保证连接的“活力”
    def send_keepalives(self):
        self.schedulefunc(self.send_keepalives, self.keepalive_delay)
        for c in self.connections.s():
            if c.complete:
                c.send_message('')

③主动向对方发起一个连接，这个函数什么时候调用？
请看 download.py 中 Rerequester 类的初始化函数，其中传递的一个参数是 encoder.start_connection。
再看 Rerequester.py 中，Rerequester::postrequest() 的最后，
for x in peers:
self.connect((x[0], x[1]), x[2])
这里调用的 connect() 就是初始化的时候传递进来的 encoder.start_connection，也就是下面这个函数了。
也就是说，当客户端从 tracker 服务器那里获取了 peers 列表之后，就逐一向这些 peers 主动发起连接。
    def start_connection(self, dns, id):
        if id:
            跟自己不用建立连接。
            if id == self.my_id:
                return
            如果已经与对方建立起连接，也不再建立连接
            for v in self.connections.s():
                if v.id == id:
                    return

        如果当前连接数，已经超过设定的“最大发起连接数”，那么就暂时不建立连接。
  
        if len(self.connections) >= self.max_initiate:
如果空闲连接数还小于 “最大发起连接数”，那么把对方的 ip 先放到spares中，等以后网络稍微空闲一点的时候，再从 spares 中取出来，实际去建立连接。
            if len(self.spares) < self.max_initiate and dns not in self.spares:
                self.spares.append(dns)
            return
        try:
调用 RawServer::start_connection 与对方建立TCP连接
            c = self.raw_server.start_connection(dns)
           
创建 Connection 对象，加入到 connections 字典中，注意，最后一个参数是 True，表示是这个连接是由本地主动发起的。这样，在 Connection 的初始化函数中，会与对方进行 BT 对等协议的握手。

            self.connections[c] = Connection(self, c, id, True)
        except socketerror:
            pass
   
这个内部函数好像没有用到
    def _start_connection(self, dns, id):
        def foo(self=self, dns=dns, id=id):
            self.start_connection(dns, id)
       
        self.schedulefunc(foo, 0)
       
    def got_id(self, connection):
        for v in self.connections.s():
            if connection is not v and connection.id == v.id:
                connection.close()
                return
        self.connecter.connection_made(connection)

    def ever_got_incoming(self):
        return self.everinc

①在 RawServer 中，当从外部发起的一个TCP成功建立后，调用此函数。
这里传递进来的参数 connection 是 SingleSocket 类型
def external_connection_made(self, connection):
 创建一个 Connection 对象，加入到 connections 字典中。
        self.connections[connection] = Connection(self, connection, None, False)

    def connection_flushed(self, connection):
        c = self.connections[connection]
        if c.complete:
            self.connecter.connection_flushed(c)

关闭连接的时候调用此函数
    def connection_lost(self, connection):
        self.connections[connection].sever()
关闭一个连接之后，连接数量可能就没有达到“最大连接数”，所以如果 spares 中有一些等待建立的 ip ，现在可以取出来，主动向对方发起连接。
        while len(self.connections) < self.max_initiate and self.spares:
            self.start_connection(self.spares.pop(), None)

BT客户端的 main() 函数：
 C 和c++的可执行程序，通常都有一个 main() 函数，一切从这里开始。而 python 这种解释性语言，并没有 main() 函数的概念。你传递给解释器一个 .py 扩展名的python源码文件，解释器就会顺序去解释执行这个文件中的代码。所以，BT客户端的执行，是从最先被 python 解释器解释执行的那个文件开始的。这个文件应该是 btdownloadheadless.py，至于谁又来通知让 python 解释器执行这个文件的，我们以后再讨论。

【btdownloadheadless.py】（在BT源码的根目录下）
②def run(params):
    try:
        import curses
        curses.initscr()
        cols = curses.COLS
        # endwin() De-initialize the library, and return terminal to normal status
        curses.endwin()
    
    except:
        cols = 80
h = HeadlessDisplayer()
# 调用 download.py 中的 download 函数，我们的重点将转移到 download.py 文件，注意，该文件及以后要分析的代码都在 BT源码的 BitTorrent 子目录下。
③    download(params, h.chooseFile, h.display, h.finished, h.error, Event(), cols, h.newpath)
    if not h.done:
        h.failed()

 # 所有的 python的入门书籍中，都会告诉你下面这段代码的含义。这就是最先被解释执行的代码所在。
①if __name__ == '__main__':
run(argv[1:])

【download.py】
这个文件中，最主要的就是 download() 函数，客户端所有的一切都是从这里开始。这个函数代码比较多，我必须挑出其中最重要的代码，其它的部分，后续再分析。

④rawserver = RawServer(doneflag, config['timeout_check_interval'], config['timeout'], errorfunc
= errorfunc, maxconnects = config['max_allow_in'])

# 选择一个可用的端口作为监听端口
for listen_port in xrange(config['minport'], config['maxport'] + 1):
try:
     rawserver.bind(listen_port, config['bind'])
        break
except socketerror, e:
     pass
else:
errorfunc("Couldn't listen - " + str(e))
return

encoder = Encoder(connecter, rawserver,
myid, config['max_message_length'], rawserver.add_task,
config['keepalive_interval'], infohash, config['max_initiate'])

rawserver.listen_forever(encoder)

客 户端的核心类就是 RawServer，这个类我在“服务器端源码分析”（可在论坛中找到）文章中分析过它的作用，这里不再赘述。通过调用它的 listen_forever() 函数，BT 客户端就进入了一个循环之中。此后，所有的下载、上传、文件存储以及其它工作都在这一次次的循环之中完成。
注意到，在进入循环之前，调用了 RawServer::bind() 函数，BT客户端会选择一个可用的端口，然后通过监听这个端口，从而可以接受其它 peer 的连接请求（也就是BT对等连接）。这个端口可以称为“监听端口”。如果你有网络服务器的编程经验，从它的循环处理逻辑、监听端口的处理可以知道，这显然 就是一个典型的网络服务器的表现。所以，我在以前的文章中曾经说过，BT客户端同时也是一个服务器。
一旦在监听端口上有某个peer发来连接请 求，BT客户端会创建一个新的端口，这个端口用来与请求者建立连接；有几个peer请求连接，就会创建几个端口。我们可以说这是一些“被动端口”。在循环 的处理过程中，BT客户端还会根据情况，向其它 peer主动发出连接请求，每个连接也需要一个端口，这些端口可以称为“主动端口”。其实，这些都是网络编程中最基本的概念，不清楚的朋友还是首先要去看 看这方面的书籍。
这样，就有了一个“监听端口”，几个“被动端口”和几个“主动端口”，BT客户端通过 select() 函数来监视这些端口，一旦“监听端口”或者“被动端口”上有数据到来，或者有数据需要从“主动端口”上发送出去，那么select() 都可以及时感知并进行处理（其实是一个轮询的过程），这就称为“I/O多路复用”。如果“被动端口”上有数据到来，那么这是BT对等连接的协议数据，需要 按照BT对等协议进行分析，并根据分析结果进行相应处理，这个分析处理的工作就是由 Encoder 类来完成的。所以在 listen_forever() 函数中传递的参数就是一个 Encoder 类对象。关于对 Encoder 类的分析，以后分析到BT对等协议的处理的时候再说。

小结：
 通过这篇文章，我们了解了BT客户端是从哪里执行的，相应的源码在哪 里。同时我们知道了BT客户端是以一个服务器循环的形式运行的，它需要监听一个端口，用于接受其它peers的连接请求；在循环过程中，它通过 select 来实现“I/O多路复用”；并由 Encoder 类来完成BT对等协议的分析处理。

概述：
相对于 tracker 服务器来说，BT客户端要复杂的多，Bram Cohen 花了一年 full time 的时间来完成 BT，我估计其中大部分时间是用在 BT 客户端的实现和调试上了。
由 于 BT 客户端涉及的代码比较多，我不能再象分析 tracker 服务器那样，走上来就深入到细节之中去，那样的话，我写的晕晕糊糊，大家看起来也不知所云。所以第一篇文章先来谈谈客户端的功能、相关协议，以及客户端的 总体架构和相关的类的层次结构。这样，从整体上把握之后，大家在自己分析代码的过程中，就能做到胸有成竹。

客户端的功能：

不看代码，只根据 BT 的相关原理，大致可以推测，客户端需要完成以下功能：
1、解析 torrent 文件，获取要下载的文件的详细信息，并在磁盘上创建空文件。
2、与 tracker服务器 建立连接，并交互消息。
3、根据从 tracker 得到的信息，跟其它 peers 建立连接，并下载需要的文件片断
4、监听某端口，等待其它peers 的连接，并提供文件片断的上传。

相关协议：
对客户端来说，它需要处理两种协议：
1、与 tracker 服务器交互的 track HTTP协议。
2、与其它 peers 交互的 BT 对等协议。

总体架构：
从总体上来看，BT客户端实际是以一个服务器的形式在运行。这一点似乎有些难以理解，但确实是这样。
为什么是一个服务器了？
客 户端的主要功能是下载文件，但作为一种P2P软件，同时它必须提供上传服务，也就是它必须守候在某一个端口上，等待其它peers 的连接请求。从这一点上来说，它必须以一个服务器的形式运行。我们在后面实际分析代码的时候，可以看到，客户端复用了 RawServer 类用来实现网络服务器。
客户端的代码，是从 download.py 开始的，首先完成功能1，之后就进入服务器循环，在每一次循环过程中，完成功能 2、3、4。其中，Rerequester 类负责完成功能2，它通过 RawServer::add_task()，向 RawServer 添加自己的任务函数，这个任务函数，每隔一段时间与 tracker 服务器进行通信。而Encoder、Connecter 等多个类组合在一起，完成功能3和4。

类层次结构：

BT 客户端涉及的类比较多，我首先大致描述一下这些类的功能，然后给出它们的一个层次结构。

1、RawServer：负责实现网络服务器

2、Rerequester：负责和 tracker 通信。它调用 RawServer::add_task() ，向 RawServer 添加自己的任务函数 Rerequester::c()。

3、Encoder：一种 Handler类（在分析 tracker 服务器时候提到），负责处理与其它peers建立连接和以及对读取的数据按照BT对等协议进行分析。

Encoder 类在Encrypter.py中，该文件中，还有一个 Connection 类，而在 Connecter.py 文件中，也有一个 Connection 类，这两个同名的 Connection 类有些蹊跷，为了区分，我把它们重新命名为 E-Connection 和 C-Connection。

3.1、E-Connection：负责 TCP 层次上的连接工作
这两个 Connection 是有区别的，这是因为BT对等协议需要在两个层次上建立连接。首先是 TCP 层次上的连接，也就是经过 TCP 的三次握手之后，建立连接，这个连接由 E-Connection 来管理。在 Encoder:: external_connection_made() 函数中可以看到，一旦有外部连接到来，则创建一个 E-Connection 类。

3.2、C-Connection：管理对等协议层次上的连接。
在 TCP 连接之上，是 BT对等协议的连接，它需要经过BT对等协议的两次“握手”，握手的细节大家去看BT对等协议。过程是这样的：
为了便于述说，我们假设一个BT客户端为 A，另一个客户端为 X。
如 果是X主动向A发起连接，那么在TCP连接建立之后，A立刻利用这个连接向X发送BT对等协议的“握手”消息。同样，X在连接一旦建立之后，向 A发送BT对等协议的“握手”消息。A一旦接收到X的“握手”消息，那么它就认为“握手”成功，建立了BT对等协议层次上的连接。我把它叫做“对等连 接”。A 发送了一个消息，同时接收了一个消息，所以这个握手过程是两次“握手”。
同样，对X 来说，因为连接是它主动发起的，所以它在发送完“握手”消息之后，就等待A的“握手”消息，如果收到，那么它也认为“对等连接”建立了。
一旦“对等连接”建立之后，双方就可以通过这个连接传递消息了。

这样，原来我所疑惑的一个问题也就有了答案。就是：如果 X 需要从 A 这里下载数据，那么它会同 A 建立一个连接。假如 A 又希望从 X 那里下载数据，它需不需要重新向 X 发起另外一个连接了？答案显然是不用，它会利用已有的一条连接。

也就是说，不管是X主动向A发起的连接，还是 A 主动向 X发起的连接，一旦建立之后，它们的效果是一样的。这个同我们平时做 C/S结构的网络开发是有区别的。

我们可以看到在 E-Connection的初始化函数中，会主动连接的另一方发送“握手”消息，在 E-Connection::data_came_in() 中，会首先对对方的“握手”消息进行处理。这正是我上面所描述的情形。
在 E-Connection::read_peer_id() 中，是对“握手”消息的最后一项 peer id进行处理，一旦正确无误，那么就认为“对等连接”完成，

self.encoder.connecter.connection_made(self)

在 Connecter::connection_made() 函数中，就创建了管理“对等连接”的 C-Connectinon类。所以，更高一层的“对等连接”是由 C-Connection 来管理的。

3.3、Connecter：连接器，管理下载、上传、阻塞、片断选择、读写磁盘等等。

下载和上传不是孤立的，它们之间相互影响。下载需要有片断选择算法，上传的时候要考虑阻塞，片断下载之后，要写到磁盘上。上传的时候，也需要从磁盘读取。
这些任务，是由 Connecter 来统一调度的。

类层次结构，我用缩进来表示一种包含关系。

Encoder:
    E-Connection
        C-Connection
            Upload
            SingleDownloader
        Connecter
            Choker：负责阻塞的管理
            Downloader：
                SingleDownloader
                Picker：片断选择策略
                StorageWrapper：

先写这些吧，有什么我再补充进来。

RawServer 这个类的作用是实现一个网络服务器。关于网络编程的知识，《 unix 网络编程：卷 1 》是最经典的书籍，你如果对这块不了解，建议抽时间看看这本书。 RawServer 实现的是一种事件多路复用、非阻塞的网络模型。它使用的是 poll() （而不是我们常见的 select() ，关于 poll 和 select 的比较，也在《 unix 网络编程：卷 1 》中有介绍）函数，处理过程大致是这样的：

首先创建一个监听 socket ，然后将这个 socket 加入 poll 的事件源；

随后进入服务处理循环，即：

调用 poll() 函数，这个函数会阻塞，直到网络上有某些事件发生或者超时才返回给调用者；

在 poll() 返回之后，先检查一下是否有没有处理的任务，如果有，那么先完成这些任务。然后根据事件类型进行处理。

如果是连接请求（监听 socket 上的 POLLIN 事件）到来，它 accept 这个请求，如果 accept 成功，那么就和一个 client 建立了连接，于是将 accept() 新创建的 socket 加入 poll 的事件源；

如果在已经建立的连接上（连接 socket 上的 POLLIN 事件），有数据可读，那么将数据从 client 端读过来，做进一步处理；

如果已经建立的连接已经准备好（连接 socket 上的 POLLOUT 事件），可以发送数据，则检查是否有数据需要发送，如果有，那么发送数据给 client 端。

（所以， tracker 是一个单进程的服务器，并没有用到线程。）

Bram Cohen 认为软件的可维护性非常重要，使代码易于维护的重要一条就是设计可重用的类， RawServer 在设计的时候，充分考虑到了可重用性，集中表现在两个地方：

1、  将网络 I/O 和数据分析处理分离。

网络服务器的事件多路复用、网络 I/O 部分通常是固定不变的，而数据在读取之后，进行分析处理的过程则是可变的。 RawServer 将可变的数据处理工作，交给另外一个抽象的类 Handler （实际上并没有这么一个类）来处理。比如，在 tracker 服务器的实现中，具体使用的就是 HTTPHandler 类，而在 以后将要分析的 BT client 实现代码中，用到的具体的 Handler 是 Encoder 类。

2、  采用任务队列来抽象出任务处理的过程。

RawServer 维护了一个任务队列 unscheduled_tasks （实际是一个二元组的 list ，二元组的第一项是一个函数，第二项是超时时间）。在初始化的时候，首先向这个队列中加入一个任务： scan_for_timeouts() ，这样，每隔一段时间，服务器就会去检查一下是否有连接超时。如果有其它

RawServer 的成员函数中，对外暴露的有：

u       __init__ ：（初始化函数）

u       add_task() ：

       在任务列表中增加一项任务（一个任务是一个函数以及一个指定的超时时间的组合）

u       bind() ：

       首先创建一个 socket ，然后设置 socket 的属性： SO_REUSEADDR 和 IP_TOS, ，这两个属性的具体含义请参考《 unix 网络编程：卷 1 》，另外还将 socket 设置为非阻塞的。相对于阻塞的 socket 来说，非阻塞的 socket 在网络 I/O 性能上要提高许多，但是与此同时，编程的复杂度也要提高一些。象 tracker 这种可能同时要处理成千上万个并发连接的服务器，只能采用非阻塞的 socket 。

       然后将该 socket 和指定 ip 已经端口绑定；

       最后把这个 socket 加入 poll 的事件源。

u       start_connection() ：

       对外主动建立一个连接，这个函数在处理 NAT 穿越的时候用到了，我们后面分析到 NAT 穿越的时候，再具体讲解。

u       listen_forever() ：

       这个函数的功能就是实现了我在前面描述的网络服务器的处理过程。我们看到，它唯一的参数是 handler ， handler 的作用就是封装了对数据的具体处理。

listen_forever() 把对网络事件的处理过程，交给了 handle_events() 。

其它函数，包括 handle_events() ，都是内部函数（也就是外部不会直接来调用这些函数）。 Python 没有 c++ 那样 public 、 protected 、 private 这样的保护机制， python 类的内部函数命名的惯例是以下划线开始，例如 RawServer 中的 _close_dead() 等。

u       handle_events() ：

事件处理过程，主要是根据三种不同的网络事件分别处理，一是连接事件，二是读事件、三是写事件。

if sock == self.server.fileno()

这段代码判断发生事件的 socket 是否是监听 socket ，如果是，那么说明是连接事件。

连接事件的处理：

通过 accept 来接受连接，并将新建立的 socket 设置为非阻塞。

判断当前连接数是否已经达到了最大值（为了限制并发连接的数目，在初始化 RawServer 的时候，需要指定最大连接数目），如果已经达到最大值，那么关闭这个新建的连接。

否则，根据新的 socket 创建一个 SingleSocket 对象，（ SingleSocket 封装了对 socket 的操作。）将这个对象加入内部的列表 single_sockets 中，以备后用。

将这个新 socket 加入 poll 的事件源

最后，调用 Handler 的 external_connection_made() 函数，关于这个函数，在后面分析 HTTPHandler 时再讨论。

if (event & POLLIN) != 0:

这段代码判断是否是读事件

读事件的处理：

首先刷新一下连接的最后更新时间 （ last_hit ）。

然后读取数据；

如果什么也没读到，那么说明连接被关闭了（在网络编程中，如果一个连接正常的被关闭，那么，也会触发读事件，只不过什么也读不到）

否则，调用 Handler 的 data_came_in() 函数来处理读到的数据。

if (event & POLLOUT) != 0 and s.socket is not None and not s.is_flushed():

这段代码判断是否是写事件，而且确实有数据需要发送。在一个连接可以写的时候，就会发生写事件。

写事件的处理：

实际代码是在 SingleSocket 的 try_write() 函数中。

在一个非阻塞的连接上发送指定大小的数据，很可能在一次发送过程中，数据没有被完全发送出去（只发送了一部分）就返回了，所以，每次 write 之后，必须判断是否完全发送了数据。如果没有发送完，那么下次有读事件的时候，还得回来继续发送未完得数据。这也是这个函数叫做 try_write 的原因吧。

try_write() 在最后，要重新设置 poll 的事件源。如果数据全部发送完毕了，那么只需要监听读事件（ POLLIN ）否则，既要监听读事件，也要监听写事件（ POLLOUT ），这样，一旦连接变的可写，可以继续将剩下的数据发送出去。

u       scan_for_timeouts() ：

任务处理函数，它首先把自身加入未处理任务队列中，这样，经过一段时间，可以保证这个函数再次被调用，从而达到周期性调用的效果。

它检查每个连接是否超过指定时间没有被刷新，如果是，则该连接可能已经僵死，那么它关闭这个连接。

u       pop_unscheduled() ：

从任务列表中弹出一个未处理的任务。

与 RawServer 配合使用的是 SingleSocket 类，这是一个辅助类，主要目的是封装对 socket 的处理吧。包括数据的发送，都交给它来处理了。这个类比较简单，大家可以自己去看，我就不罗嗦了。

以上是对 RasServer 的具体实现的一个分析，可能读者看的还是晕晕糊糊，没办法，还是必须自己去看源代码，然后在遇到问题的时候，回头再来看这篇文章，才会有帮助。如果不亲自看源码，终究是纸上谈兵。

我们再来小结一下。

RawServer 封装了网络服务器的实现细节，它实现了一种事件多路处理、非阻塞的网络模型。它主要负责建立新的连接，从网络读取和发送数据，而对读到的数据的具体处理工作，交给 Handler 类来处理，从而把网络 I/O 和数据处理分离开来，使得 RawServer 可以重用。 Handler 类是在调用 listen_forever() 的时候，由调用者传递进来的，具体到 tracker 服务器，就是 HTTPHandler 。有了 RawServer ， tracker 就可以作为一个网络服务器运行了。

下一节，我们开始分析具体实现 tracker HTTP 协议处理的 HTTPHandler 类和 Tracker 类。

上一篇我们讲到， RawServer 只负责网络 I/O ，也就是从网络上读取和发送数据，至于读到的数据如何分析，以及应该发送什么样的数据，则交给 Handler 类来处理。如果是用 c++ 来实现的话，那么 Handler 应该是一个接口类（提供几个虚函数作为接口），但是 python 动态语言的特性，并不需要专门定义这么一个接口类，所以实际上并没有 Handler 这么一个类。任何一个提供了以下成员函数的类，都可以作为一个 Handler 类来与 RawServer 配合，它们是：

external_connection_made() ：在建立新的连接的时候被调用

data_came_in() ：连接上有数据可读的时候被调用

connection_flushed() ：当在某个连接上发送完数据之后被调用

       HTTPHandler 就是这样一个 Handler 类，它具备以上接口。

       HTTPHandler 代码很少，因为它把主要工作又交给 HTTPConnection 了。

       我们看 HTTPHandler 类的这几个函数：

l         external_connection_made() ：

每当新来一个连接的时候，就创建一个 HTTPConnection 类。

l         data_came_in() ：

当连接上有数据可读的时候，调用 HTTPConnection::data_came_in() 。我们接下去看 HTTPConnection::data_came_in() 。

我们知道， BT client 端与 tracker 服务器之间是通过 tracke HTTP 协议来进行通信的。 HTTP 协议分为请求（ request ）和响应（ response ），具体的协议请看相关的 RFC 文档。我这里简单讲一下。

对 tracke 服务器来说，它读到的数据是 client 端的 HTTP 请求。

HTTP 请求以行为单位，行的结束符是“回车换行”，也就是 ascii 字符 “ \r ”和“ \n ”。

第一行是请求的 URL ，例如：

GET              /announce?ip=aaaaa;port=bbbbbbb       HTTP/1.0

这行数据被空格分为三部分，

第一部分 GET 表示命令，其它命令还有 POST 、 HEAD 等等，常用的就是 GET 了。

第二部分是请求的 URL ，这里是 /announce?ip=aaaaa;port=bbbbbbb 。如果是普通的上网浏览网页，那么 URL 就是我们要看的网页在该 web 服务器上的相对路径。但是，这里的 URL 仅仅是交互信息的一种方式， client 端把要报告给 tracker 的信息，放在 URL 中，例子里面是 ip 和 port ，更详细的信息请看“ BT 协议规范”中 tracker 协议部分。

第三部分是 HTTP 协议的版本号，在程序中忽略。

接下来的每一行，都是 HTTP 协议的消息头部分，例如：

Host:www.sina.com.cn

Accept-encoding:gzip

通过消息头， tracker 服务器可以知道 client 端的一些信息，这其中比较重要的就是 Accept-encoding ，如果是 gzip ，那么说明 client 可以对 gzip 格式的数据进行解压，那么 tracker 服务器就可以考虑用 gzip 把响应数据压缩之后再传回去，以减少网络流量。我们可以在代码中看到相应的处理。

在消息头的最后，是一个空行，表示消息头结束了。对 GET 和 HEAD 命令来说，消息头的结束，也就意味着整个 client 端的请求结束了。而对 POST 命令来说，可能后面还跟着其它数据。由于我们的 tracker 服务器只接受 GET 和 HEAD 命令，所以在协议处理过程中，如果遇到空行，那么就表示处理结束。

HTTPConnection::data_came_in() 用一个循环来进行协议分析：

首先是寻找行结束符号：

i = self.buf.index('\n')

（我认为仅仅找 “ \n ”并不严谨，应该找 “ \r\n ”这个序列）。

如果没有找到，那么 index() 函数会抛出一个异常，而异常的处理是返回 True ，表示数据不够，需要继续读数据。

如果找到了，那么 i   之前的字符串就是完整的一行。于是调用协议处理函数，代码是：

self.next_func = self.next_func(val)

在 HTTPConnection 的初始化的时候，有这么一行代码：

self.next_func = self.read_type

next_func 是用来保存协议处理函数的，所以，第一个被调用的协议处理函数就是 read_type() 。它用来分析 client 端请求的第一行。在 read_type() 的最后，我们看到：

return self.read_header

这样，在下一次调用 next_func 的时候，就是调用 read_header() 了，也就是对 HTTP 协议的消息头进行分析。

下面先看 read_type() ，

它首先把 GET 命令中的 URL 部分保存到 self.path 中，因为这是 client 端最关键的信息，后面要用到。

然后检查一下是否是 GET 或者 HEAD 命令，如果不是，那么说明数据有错误。返回 None ，否则 return self.read_header

接下来我们看 read_header() ，

这其中，最重要的就是对空行的处理，因为前面说了，空行表示协议分析结束。

在检查完 client 端是否支持 gzip 编码之后，调用：

r = self.handler.getfunc(self, self.path, self.headers)

通过一层层往后追查，发现 getfunc() 实际是 Tracker::get() ，也就是说，真正对 client 端发来的请求进行分析，以及决定如何响应，是由 Tracker 来决定的。是的，这个 Tracker 在我们 tracker 服务器源码分析系列的第一篇文章中就已经看到了。在创建 RawServer 之后，马上就创建了一个 Tracker 对象。所以，要了解 tracker 服务器到底是如何工作的，需要我们深入进去分析 Tracker 类，那就是我们下一篇文章的工作了。

在调用完 Tracker::get() 之后，返回的是决定响应给 client 端的数据，

if r is not None:

self.answer(r)

最后，调用 answer() 来把这些数据发送给 client 端。

对 answer() 的分析，我们在下一篇分析 Tracker 类的文章中一并讲解。

l         connection_flushed() ：

tracker 服务器用的是非阻塞的网络 I/O ，所以不能保证在一次发送数据的操作中，把要发送的数据全部发送出去。

这个函数，检查在某个连接上需要发送的数据，是否已经全部被发送出去了，如果是的话，那么关闭这个连接的发送端。（为什么仅仅关闭发送端，而不是完全关闭这个连接了？疑惑）。

       client 向 tracker 发一个 HTTP 的 GET 请求，并把它自己的信息放在 GET 的参数中；这个请求的大致意思是：我是 xxx （一个唯一的 id ），我想下载 yyy 文件，我的 ip 是 aaa ，我用的端口是 bbb 。。。

       tracker 对所有下载者的信息进行维护，当它收到一个请求后，首先把对方的信息记录下来（如果已经记录在案，那么就检查是否需要更新），然后将一部分（并非全部，根据设置的参数已经下载者的请求）参与下载同一个文件（一个 tracker 服务器可能同时维护多个文件的下载）的下载者的信息返回给对方。

       Client 在收到 tracker 的响应后，就能获取其它下载者的信息，那么它就可以根据这些信息，与其它下载者建立连接，从它们那里下载文件片断。

关于 client 和 tracker 之间通信协议的细节，在“ BT 协议规范”中已经给出，这里不再重复。下面我们具体分析 tracker 服务器的实现细节。

从哪里开始？

       要建立一个 tracker 服务器，只要运行 bttrack.py 程序就行了，它最少需要一个参数，就是 –dfile ，这个参数指定了保存下载信息的文件。 Bttrack.py 调用 track.py 中的 track() 函数。因此，我们跟踪到 track.py 中去看 track() 函数。

Track.py ： track()

       这个函数首先对命令行的参数进行检查；然后将这些参数保存到 config 字典中。在 BT 中所有的工具程序，都有类似的处理方式。

接下来的代码：

       r = RawServer(Event(), config['timeout_check_interval'], config['socket_timeout'])

    t = Tracker(config, r)

    r.bind(config['port'], config['bind'], True)

    r.listen_forever(HTTPHandler(t.get, config['min_time_between_log_flushes']))

    t.save_dfile()

首先是创建一个 RawServer 对象，这是一个服务器对象，它将实现一个网络服务器的一些细节封装起来。不仅 tracker 服务器用到了 RawServer ，我们以后还可以看到，由于每个 client 端也需要给其它 client 提供下载服务，因此也同时是一个服务器， client 的实现中，也用到了 RawServer ，这样， RawServer 的代码得到了重用。关于 RawServer 的详细实现，在后面的小节中进行分析。

接着是创建一个 Tracker 对象。

然后让 RawServer 绑定在指定的端口上（通过命令行传递进来）。

最后，调用 RawServer::listen_forever() 函数，使得服务器投入运行。

最后，在服务器因某些原因结束运行以后，调用 Tracker::save_dfile() 保存下载信息。这样，一旦服务器再次投入运行，可以恢复当前的状态。

其它信息：

1、  BT 源码的分布：

把 BT 的源码展开之后，可以看到有一些 python 程序，还有一些说明文件等等，此外还有一个 BitTorrent 目录。这些 python 程序，实际是一些小工具，比如制作 file 的 btmakefile.py 、运行 tracker 服务器的 bttrack.py 、运行 BT client 端的 btdownloadheadless.py 等等。而这些程序中，用到的一些 python 类的实现，都放在子目录 BitTorrent 下面。我们的分析工作，通常是从工具程序入手，比如 bttrack.py ，而随着分析的展开，则重点是看 BitTorrenet 子目录下的代码。

BT 作者 Bram Cohen 在谈到如何开发可维护的代码的一篇文章中（ http://www.advogato.org/article/258.html ），其中提到的一条就是开发一些小工具以简化工作，我想 BT 的这种源码结构，也正是作者思想的一种体现吧。

2、  我们看到， python 和我们以前接触的 c/c++ 不一样的第一个地方就是它的函数在定义的时候，不用指定参数类型。既然这样，那么，在调用函数的时候，你可以传递任意类型的参数进来。例如这样的函数：

def foo(arg):

        print type(arg)

       你可以这样来调用：

       a = 100

       b = “hello world”

       foo(a)

       foo(b)

       输出结果是：

       <type ‘int’>

       <type ‘str’>

       这是因为，第一次调用 foo() 的时候，传递的是一个整数类型，而第二次调用的时候，传递的是一个字符串类型。

这种参数具有动态类型的特性，是 c/c++ 等传统的语言是所不具备的。这也是 python 被称为动态语言的一个原因吧。 C++ 的高级特性模板，虽然也使得参数类型可以动态化，但使用起来，远没有 python 这么简单方便。