久久久亚洲AV波多野结衣,亚洲爆乳大丰满无码专区,五月天婷亚洲天综合网精品偷

Thu, 18 Jan 2007 16:24:00 GMT

概要
上一节我们分析了BT客户端与tracker之间的通信�q�程。通过�?tracker 的通信�Q�客��L(f��ng)��获得了参与下载的其它peers 的列表。有了这�?peers 的信息，客户端就可以��d��向它们发赯��接，��一步从它们那里获取所需要的文�g片断做好准备。这些连接称�?#8220;��d��q�接”。因��接的发�v�Ҏ(gu��)��客户端自己�?br> 同时�Q�每个客��L(f��ng)��在启动以后，都会监听某个端口�Q�用于接受其�?peers 的连接请求。P2P的核心理念就�?#8220;公��^、对�{?#8221;�Q�你向别人有所求（下蝲�Q�，��必��L��付出�Q�上传）。客��L(f��ng)��在接受外来的�q�接��h��之后�Q�就会��生一个新的连接，�U�C��?#8220;被动�q�接”�Q�因��接的发�v�Ҏ(gu��)��其它 peer�?br> 无论是被动连接，�q�是��d��q�接�Q�一旦连接徏立之后，双方��p��q�行“BT对等协议”的握手。握手成功之后，双方才可以通过�q�个�q�接互相传递消息了。�ؓ什么要�q�行握手了？主要目的是�ؓ了防止一些错误的�q�接。这��好比地下党接头�Q�暗号对上了�Q�彼此才建立信�Q�?/p>

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

客户端主动发赯��?br>【Encrypter.py�?br> 上一节的最后，我们看到调用 Encoder::start_connection() 来向其它 peer 发�v�q�接。所以，从这里开始看赗��?/p>

class Encoder:
# start_connection() 需要两个参敎ͼ�
dns�Q�对方的ip、port 的组合�?br>id�Q?�Ҏ(gu��)��?id。每个BT客户端都要创��Z��个唯一�?id ��P��q�且把这�?id ��h��告给 tracker。Id号唯一标识了一个客��L(f��ng)��。Id ��L(f��ng)��计算方式�?download.py 中�?br>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 是自己，不连�?br>            if id == self.my_id:
                return
            # 如果已经和这个peer建立了连接，也不再徏立连接�?br>            for v in self.connections.s():
                if v.id == id:
return
  # 如果当前�q�接数过多，暂时不发赯��?br>        if len(self.connections) >= self.max_initiate:
# self.spares 起到�~�存的作用。在当前�q�接数过多的情况下，把本�ơ要�q�接�?peer �?ip、port �~�存��h��。一旦当前连接数��于讑֮��?max_initiate�Q?则可以从 spares 中取出备用的 peers�?br>            if len(self.spares) < self.max_initiate and dns not in self.spares:
                self.spares.append(dns)
            return
        try:
# 调用 RawServer::start_connection()�Q�发�?TCP 的连接。RawServer的代码分析请参看“服务器源码分�?#8221;�p�d��文章�Q�不再赘�q?br># �q�回�?c 是一�?SingleSocket 对象�Q�它?y��u)��装�?socket 句柄
            # 如果出错�Q�抛�?socketerror 异常
            c = self.raw_server.start_connection(dns)
# 成功建立 TCP �q�接。构造一�?Connection对象�Q�加�?connections 字典中。注意，最后一个参数是 True�Q�它表面�q�条�q�接是由客户端主动发起徏立的。我们立��d��?Connection �cȝ��构�?br>            self.connections[c] = Connection(self, c, id, True)
        except socketerror:
            pass

【Encrypter.py�?br>class Connection:
�?nbsp; def __init__(self, Encoder, connection, id, is_local):
        self.encoder = Encoder
        self.connection = connection #�q�个 connection �?SingleSocket 对象�Q�就是上�? RawServer::start_connection() �q�回的��|��它封装了对socket句柄的操作。名字�v的不好，�Ҏ(gu��)��弄�؜淆�?br>        self.id = id
        self.locally_initiated = is_local #�q�个�q�接是否由本地发��P��
        self.complete = False
        self.closed = False
        self.buffer = StringIO()
        self.next_len = 1
        ⑦self.next_func = self.read_header_len

# 如果由本地发��P��那么�l�对方发送BT对等�q�接的握手消息�?br>        ④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)

客户端被动接受外来连�?br>�? ��L(f��ng)��在与 tracker 通信的时候，已经把自��q�� ip 和监听的 port 报告�l�了 tracker。这��P��其它 peers ��可以通过�q�个 ip �?port 来连接它了。例如上图中的C�Q�就��d��l?A 发一个连接，从C的角度来��_��它是“��d��q�接”�Q�但从A的角度，它是“被动�q�接”�?br>一旦有外来�q�接��h��Q�就会调�?RawServer::handle_events()�Q�下面是摘录�?#8220;Tracker 服务器源码分析之二：RawServer�c?#8221;中的一�D�c�?/p>

最后调用的�?Handle �?external_connection_made()�Q�对客户端来��_��q�个Handle �?Encoder �c�d��象。所以，外来�q�接建立成功后，最后调用的�?Encoder:: external_connection_made()�Q?/p>

③def external_connection_made(self, connection):
# 同样是创��Z��个新�?Connection �c�，�q�加�?connections 字典中。但不同之处在于最后一个参数是 False�Q�表明这个连接是由外部发��L(f��ng)��?br>self.connections[connection] = Connection(self, connection, None, False)

BT对等�q�接握手�Q�第一�?/p>

如果是主动连接，那么一旦连接徏立成功之后，��q��Ҏ(gu��)��发送一个握手消息，我们折回�ȝ��序号�?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协议规范》中�Q�如此描�q�握手消息：
对等协议�׃��个握手开始，后面是��@环的消息��，每个消息的前面，都有一个数字来表示消息的长度。握手的�q�程首先是先发�?9�Q�然后发送协议名�U?#8220;BitTorrent protocol”�?9��是“BitTorrent protocol”的长度�?br>后箋的所有的整数�Q�都采用big-endian 来编码�ؓ4个字节�?br>在协议名�U�C��后，�?个保留的字节�Q�这些字节当前都讄��?�?br>接下来对元文件中�?info 信息�Q�通过 sha1 计算后得到的 hash��|��20个字节长。接收消息方�Q�也会对 info �q�行一�?hash �q�算�Q�如果这两个�l�果不一��P��那么说明双方要下载的文�g不一��_��会切断连接�?br>接下来是20个字节的 peer id�?br>�? 以看刎ͼ�最后两��就�?Encoder::download_id �? Encoder::my_id。download_id是如何得来的�Q�它是首先对 torrent 文�g�?info 关键字所包含的信息进�? Bencoding 方式的编码（��L(f��ng)��《BT协议规范》关�?Bencoding的介�l�）�Q�然后再通过 sha 函数计算出的 hash�Q�摘要）倹{��（相关代码都在 download.py 中）。在一�ơ下载过�E�中�Q�所有的下蝲者根�?torrent 文�g计算出的�q�个 download_id应该都是一��L(f��ng)��Q�否则就说明不处于同一个下载过�E�中�?br>至于 peer_id�Q�可以看出是可选的。它的计��方式也�?download.py 中：
myid = 'M' + version.replace('.', '-')
myid = myid + ('-' * (8 - len(myid))) + b2a_hex(sha(repr(time()) + ' ' + str(getpid())).digest()[-6:])
seed(myid)

它用来唯一标识一�?peer�?br>握手�q�程已经完成了第一步，�q�需要第二步�Q�接收到�Ҏ(gu��)��的握手消息，握手�q�程才算完成。所以接下去看在有数据到来的时候，是如何处理的�?/p>

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

【Encoder�?br>⑤def data_came_in(self, connection, data):
self.connections[connection].data_came_in(data)

�q�一步调�?Connection::data_came_in()

【Connection�?br>⑥def data_came_in(self, s):
#�q�个循环处理用来对BT对等�q�接中的消息�q�行分析
        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) #调用消息分析函数�Q�第一个被调用的是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�Q?br>        if ord(s) != len(protocol_name):
            return None
        return len(protocol_name), self.read_header # 下一个处理函�?/p>

def read_header(self, s):
# 协议名称是否�?#8220;BitTorrent protocol”�Q?br>        if s != protocol_name:
            return None
        return 8, self.read_reserved # 下一个处理函�?/p>

def read_reserved(self, s):
#8个保留字�?br> return 20, self.read_download_id # 下一个处理函�?/p>

def read_download_id(self, s):
�Ҏ(gu��)�� download_id 和自��p��出的是否一��_��
        if s != self.encoder.download_id:
return None
  ��查完 download_id�Q�就认�ؓ�Ҏ(gu��)��已经通过��查了�?br>�q�里很关键！�Q�！�Q�需要仔�l�体会。这实际上就是在被动�q�接情况下，完成握手�q�程的处理。如果连接不是由本地发�v的（被动接收��C��个握手消息）�Q�那么给�Ҏ(gu��)��回一个握手消息。这里的握手消息发送处理和�W�一步是一��L(f��ng)��
        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 #下一个处理函�?/p>

def read_peer_id(self, s):
# Connection �cȝ��来管理一�?BT 对等�q�接。在握手完成之后�Q�就用对方的 peer_id 来唯一标识�q�个 Connection。这个��D��保存�?self.id 中。显�Ӟ��在握手完成之前，�q�个 id �q�是�I�倹{�?br>        if not self.id:

   # �Ҏ(gu��)��的peer_id 可千万别跟自��q��一�?br>            if s == self.encoder.my_id:
                return None
   唔，如果 peer_id 已经收到�q�，也不�l�箋下去�?br>            for v in self.encoder.connections.s():
                if s and v.id == s:
return None
   用对方的 peer_id �?self.id 赋��|��唯一标识�q�个 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�Q�握手完成！�Q�！
        self.complete = True
        self.encoder.connecter.connection_made(self)
        return 4, self.read_len #下一个处理函数。从此以后，��是对其它BT对等消息的处理过�E�了。这是我们下一节分析的问题�?/p> ��结�Q?br> �q�篇文章重点分析了BT客户端主动发赯��接和被动接收�q�接的过�E�，以及在这两种情况下，如何�q�行BT对等握手的处理�?br> 在BT对等握手完成之后�Q�连接的双方��可以互相发送BT对等消息了，�q�是下一节的内容�?

苦笑�?/a> 2007-01-19 00:24 发表评论

BT客户端源码分析之七：客户端与tracker通信�q�程

Thu, 18 Jan 2007 16:23:00 GMT

概要
上一节我们分析了BT客户端主�E�序的框�Ӟ��一个��@环的服务器程序。在�q�个循环�q�程中，客户端要完成如下��d��Q?br>? �?tracker �? 务器通信�Q�汇报自��q��状态，�? 时获取其�?peers 的信息；
? 接受其它 peers 的连接请求；
? ��d��向某�?peers 发�v�q�接��h��Q?br>? 对BT对等协议的分析处理；
? 启用片断选择��法�Q? 通过�q�些��d��或被动的�q�接��M��载所需要的片断�Q?br>? 为其�?peers 提供片断上传�Q�启用阻塞算法，? ��d��某些 peers 的上传请求；
? ��下载的片断写入��盘�Q?br>? 其它��d��Q?/p>

�q�一节我们分析BT客户端与 tracker 服务器的通信�q�程。在整个下蝲�q�程中，客户端必��M��断的�?tracker 通信�Q�报告自��q��状态，同时也从 tracker 那里获取当前参与下蝲的其�?peers 的信息（ip地址、端口等�Q�。一旦不能与 tracker 通信�Q�则下蝲�q�程无法�l�箋下去�?br> 客户端与 tracker 之间采用 HTTP 协议通信�Q�客��L(f��ng)��把状态信息放�? HTTP协议的GET命��o的参��C��传递给 tracker�Q�tracker 则把 peers列表�{�信息放�?中传递给客户端。这�U�设计非常简捷��y妙。采用HTTP协议也更使得�I�越防火墙的��L��更容易（不过实际应用中，tracker通常不会使用 80 端口�Q��?br> 请务必参考服务器端源码分析的几篇相关文章�Q�论坛中有）�?br> Rerequester �c�d��权负责与 tracker 的通信��d��Q�我们首先看客户端主�E�序 download.py中相应的代码�Q?/p>

【download.py�?br>①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 �cȝ��构造函��C��传递了一大堆参数�Q�重�Ҏ(gu��)�� rawserver.add_task�? encoder.start_connection�Q�rawserver和encoder �q�两个对象，在上一节中�Q�我们已�l�看��C��它们的构造过�E�）�Q�分别对应RawServer::add_task() �? Encoder::start_connection()�Q�稍后会看到它们的作用�?br>一切从 Rerequest::begin() 开始�?/p>

【rerequester.py�?/p>

class Rerequester:
# �q�个构造函��C��递了一大堆参数�Q�现在没必要搞的那么清楚�Q�关键是 sched �?connect �q�两个参敎ͼ�对照前面的代码，很容易知道它们是什么�?br>    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 # �Q�》RawServer::add_task()
        self.howmany = howmany # 当前有多��个�q�接 peer
        self.minpeers = minpeers
        self.connect = connect #�Q��?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

�?nbsp;def c(self):
  # 再调用一��?add_task()�Q�把自��n加入到客��L(f��ng)��的�Q务队列中�Q�这样就形成了�Q务��@环，每隔一�D�|��_��׃��执行�q�个函数。从而，客户端与 tracker 的通信能够持箋的进行下厅R�?br>        self.sched(self.c, self.interval)

        if self.ever_got_incoming():
            # 如果曄��接受到过外来的连接，那么说明�q�个客户端是可以接受外来�q�接的，也就是说很可能处�?#8220;公网”之中�Q�所以�ƈ非很�q�切的需要从 tracker 那里获取 peers 列表。（既可以主动连接别人，也可以接受别人的�q�接�Q�所以有点不紧不慢的味道�Q��?br>            getmore = self.howmany() <= self.minpeers / 3
        else:
            # 如果从来没有接受到过外来的连接，那么很有可能处于内网之中�Q�根本无法接受外来的�q�接。这�U�情况下�Q�只有主动的去连接外部的 peers�Q�所以要��可能的�?tracker ��h��更多�?peers。（只能去连接别人，所以更�q�切一些）�?br>            getmore = self.howmany() < self.minpeers
        if getmore or time() - self.last_time > self.announce_interval:
            # 如果有必要从 tracker 那里获取 peers 列表�Q�且��d��执行旉��已到�Q�则调用 announce() 开始与 tracker 通信
            self.announce()

�?nbsp;   def begin(self):
        # 调用前面提到�?RawServer::add_task()�Q�把 Rerequester::c() 加入�?rawserver对象的�Q务队列中
        self.sched(self.c, self.interval)
  # 宣布�?tracker 的通信开始。。。�?br>        self.announce(0)

�?nbsp;   def announce(self, event = None):
        self.last_time = time()
  # 传递给 tracker 的信息，攑֜� HTTP GET 命��o的参��C��。所以，首先��是构造这个参数�?br>  # 传递给 tracker 的信息，必须包括 uploaded、downloaded、left 信息。其它入 last、trackerid、numwant、compact、event 是可选的。这些参数的解释��L(f��ng)�� BT协议规范�?br>        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

  # 函数中可以嵌套定义函敎ͼ��q�是 python 语法特别的地斏V�?br>  # 调用 RawServer::add_task() �?checkfail() 加入��C�Q务队列中。在 timeout 旉��之后�Q�检查向 tracker 发的GET命��o是否��p�|�?br>        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)

        # 创徏一个线�E�，执行 Rerequester::rerequest()
  # 可见�Q�客��L(f��ng)��?tracker之间的通信是由单独的线�E�完成的
        Thread(target = self.rerequest, args = [s, set]).start()

�?nbsp;   def rerequest(self, url, set):
        try:
   # 调用 urlopen() �Q�向 tracker 发送命�?br>h = urlopen(url)
# read() �q�回 tracker 的响应数据�?br>            r = h.read()
            h.close()
            if set():
                def add(self = self, r = r):
self.last_failed = False
# �?tracker 响应回来的数据，�?postrequest() 处理�?br>self.postrequest(r)
# externalsched() 同样是调�?RawServer::add_task()�Q�这��P��׃��U�程调用 postrequest() 函数�Q�处�?tracker 响应的数据。（不要忘记�Q�我们现在是处在一个单独的子线�E�中。）
                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)

�?nbsp;   def postrequest(self, data):
        try:
   # �Ҏ(gu��)��务器响应的数据解码。请参看BT协议规范�?br>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'])

# �Ҏ(gu��)�� tracker 的响应，调整BT客户端的参数�?br>                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 数组中�?br>                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
                # �q�里�?connect�Q�即前面的Encoder::start_connection()�Q?br>    # ��x��Q�已�l�成功的完成了一�ơ与 tracker 服务器的通信�Q��ƈ且从它那里获取了 peers 列表�Q�下面就与这�?peers 挨个建立�q�接�Q�至于徏立连接的�q�程�Q�就要追�t�到 Encoder �c�M��了，且听下回分解�?br>                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))

��结�Q?br> �q�篇文章�Q�我们重点分析了BT客户端与 tracker 服务器通信的过�E�。我们知道了�Q�客��L(f��ng)��要每隔一�D�|��_��去�q�接 tracker 一�ơ，它是以一个单独的�U�程执行的。这个线�E�在接受�?tracker 的响应数据后�Q�交�l�主�U�程�Q�既�ȝ��序）来进行分析。主�E�序从响应数据中�Q�获�? peers 列表。然后调�?Encoder::start_connection() 挨个与这�?peers ��试建立�q�接�?/p>

苦笑�?/a> 2007-01-19 00:23 发表评论

Thu, 18 Jan 2007 16:22:00 GMT

摘要: PiecePicker 用于实现“片断选择��法”�Q�片断选择��法在《Incentives Build Robustness in BitTorrent》一文中有介�l�，我把相关内容列出来�? BT的片断选择��法�Q�综合下面几�U�策略�? l &nbs... 阅读全文

苦笑�?/a> 2007-01-19 00:22 发表评论

Thu, 18 Jan 2007 16:22:00 GMT

Encoder 是一�U?Handler �c�（关于 Handler�c�，请参看前面的分析文章�Q�。它�?download.py 中被初始化。它�?Connection�c�M��P��完成“BT对等�q�接”的徏立，以及“BT对等协议”的分析�?br>��Z��有助于理解，我添加了一些用圆圈括�v来的序号�Q�徏议你按照�q�个��序去阅诅R�?/p>

class Connection:
    ②def __init__(self, Encoder, connection, id, is_local):
        self.encoder = Encoder
        self.connection = connection
如果是本地发赯��接，那么 id 是对方的 id�Q�否�?id �?None
        self.id = id
如果�q�接是由本地发�v的，那么 is_local �?True�Q�否则�ؓ 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
如果�q�接是由本地��d��发�v建立的，那么需要向�Ҏ(gu��)��发送一个握手消息。（如果不是由本��C��动发��L(f��ng)��Q�那么就是被动徏立的�Q�那么不能在�q�里发送握手消息，而必��d��分析完对方的握手消息之后�Q�再��d��应一个握手西消息�Q�请看read_download_id() 中的处理�?br>        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
�q�一步很重要�Q?如果�q�接是由�Ҏ(gu��)��发�v的，那么�Q�给�Ҏ(gu��)��发送一个握手消息。�ؓ什么不在读完了 peer id 之后才发送这个消息了�Q�这是因�?peer id 是可选的�Q�所以只要分析完 download id 之后�Q�就要立卛_��送握手消息�?br>        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 是自己，那么出错�?br>            if s == self.encoder.my_id:
                return None
            for v in self.encoder.connections.s():
                如果已经跟该 peer 建立了连接了�Q�那么也出错�?br>                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 不符�Q�那么出错了�?br>            if s != self.id:
                return None

“BT对等�q�接”的握手过�E�正式宣告完成，此后�Q�双方就可以通过�q�个�q�接互相发送消息了�?br> self.complete = True

调用Connecter::connection_made()�Q�这个函数的意义�Q�我们到分析 Connecter �cȝ��时候，再记得分析�?br> self.encoder.connecter.connection_made(self)

下面�q�入 BT 消息的处理过�E��?br> 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

消息处理�Q�交�l�了 Connecter::got_message()�Q�所以下一��我们要分析 Connecter �c�R�?br>    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() 中调用下面这个函敎ͼ�表示某个�q�接上有数据可读。如果有数据可读�Q�那么我们就按照 BT 对等协议的规范来�q�行分析。。�?br>def data_came_in(self, s):

�q�入协议分析循环。。�?br>        while True:
            if self.closed:
                return

self.next_len表示按照BT对等协议规范�Q�下一�D�要分析的数据的长度
self.buffer.tell() 表示�~�冲��Z��剩下数据的长�?br>那么 i ��p��C�：��Z��完成接下来的协议分析�Q�还需要多��数据？
i = self.next_len - self.buffer.tell()
如果 i 大于所��d��的数据的长度�Q�那表示数据�q�没有读够，无法�l�箋协议分析�Q�需要等��d��_��多的数据才能�l�箋�Q�所以只能退出�?br>            if i > len(s):
                self.buffer.write(s)
                return
否则表示�q�次��d��的数据已�l��够完成一步协议分析�?br>只取满��q�一步协议分析的数据攑օ� buffer 中（因�ؓ buffer中可能还有上一步协议分析后留下的一些数据，要加在一��P��Q�剩下的数据保留�?s 中�?br>            self.buffer.write(s[:i])
s = s[i:]

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

next_func ��是用于�q�一步协议分析的函数�?br>�q�回�?x 是一个二元组�Q�包含了下一步协议分析的数据长度和协议分析函数。这��P��Ş成了一个协议分析��@环�?br>            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�?br>self.next_len, self.next_func = x
⑥那么BT对等协议分析的第一步是什么了�Q?br>��L(f��ng)��初始化函敎ͼ�
self.next_len = 1
self.next_func = self.read_header_len
昄��Q�第一步协议分析是�?read_header_len() 来完成的�?br>在BT源码中，有多处采用了�q�种协议分析的处理方式�?/p>

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
        最大发��L(f��ng)��q�接�?br>        self.max_initiate = max_initiate
        self.everinc = False

        self.connections = {}
        self.spares = []

        schedulefunc(self.send_keepalives, keepalive_delay)

��Z��保持�q�接不因��时而被关闭�Q�所以可能需要随机的发送一些空消息�Q�它的目的纯�_Ҏ(gu��)��Z��保证�q�接�?#8220;�z�d��”
    def send_keepalives(self):
        self.schedulefunc(self.send_keepalives, self.keepalive_delay)
        for c in self.connections.s():
            if c.complete:
                c.send_message('')

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

        如果当前�q�接敎ͼ�已经��过讑֮��?#8220;最大发赯��接数”�Q�那么就暂时不徏立连接�?br>
        if len(self.connections) >= self.max_initiate:
如果�I�闲�q�接数还��于 “最大发赯��接数”�Q�那么把�Ҏ(gu��)��?ip 先放到spares中，�{�以后网�l�稍微空闲一点的时候，再从 spares 中取出来�Q�实际去建立�q�接�?br>            if len(self.spares) < self.max_initiate and dns not in self.spares:
                self.spares.append(dns)
            return
        try:
调用 RawServer::start_connection 与对方徏立TCP�q�接
            c = self.raw_server.start_connection(dns)

创徏 Connection 对象�Q�加入到 connections 字典中，注意�Q�最后一个参数是 True�Q�表�C�是�q�个�q�接是由本地��d��发�v的。这��P��?Connection 的初始化函数中，会与�Ҏ(gu��)��q�行 BT 对等协议的握手�?/p>

            self.connections[c] = Connection(self, c, id, True)
        except socketerror:
            pass

�q�个内部函数好像没有用到
    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 中，当从外部发�v的一个TCP成功建立后，调用此函数�?br>�q�里传递进来的参数 connection �?SingleSocket �c�d��
def external_connection_made(self, connection):
创徏一�?Connection 对象�Q�加入到 connections 字典中�?br> 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)

关闭�q�接的时候调用此函数
    def connection_lost(self, connection):
        self.connections[connection].sever()
关闭一个连接之后，�q�接数量可能��没有达�?#8220;最大连接数”�Q�所以如�?spares 中有一些等待徏立的 ip �Q�现在可以取出来�Q�主动向�Ҏ(gu��)��发�v�q�接�?br>        while len(self.connections) < self.max_initiate and self.spares:
            self.start_connection(self.spares.pop(), None)

④某个连接上�Q�无��q�接上主动徏立还是被动徏立的�Q�有数据可读的时候，调用此函数。在 RawServer 中被调用。�{而去�?Connection::data_came_in()�?br> def data_came_in(self, connection, data):
self.connections[connection].data_came_in(data)

苦笑�?/a> 2007-01-19 00:22 发表评论

Thu, 18 Jan 2007 16:22:00 GMT

前言�Q?br> 自从7月䆾写完“客户端源码分析之五：Encoder �?Connection �c?#8221;后，我就停止了��l�对BT源码的分析。原因很多，最主要的还是懒惰吧。��(f��)到岁末，�l�于下定军_��Q�无论如何，要完成这一�p�d��的文章，对自�׃��有个交待�?br> 前面的几��文章，都是深入到源码的某一部分�l�节之中�Q�虽然很清晰�Q�但无助于读者对整体构架的把握（其实我自己当时也比较�p�涂�Q�。这一�ơ重新开始读源码�Q�重炚w��着几条�U�烦往下读�Q�感觉原来杂乱无序的代码�H�然变得清晰明了��h��Q�呵呵，其实不是代码杂�ؕ�Q�只是我原来的阅��L��\比较混�ؕ的缘故�?br> 读者可以抛开前面几篇文章�Q�从�q�一��开始往下读�Q�希望能有所收获�?br> 源码分析�cȝ��文章�Q�比较难写，��马哥毕竟没有候捷的春�U�笔法（甚至�q�作文都写不好）�Q�能把一个深奥复杂的STL源码分析的如此透彻�Q�所以只好尝试一些傻办法�Q�这些傻办法包括�Q?br>在源码上直接加注释。但我只寚w��点的部分增加一些注释，�l�节的东西就不再��q��Q�这��h��助于写作的进度�?br>用①、②、③�q�样的序��h��指引代码的阅�ȝ��?br>用不同颜色标注出代码中值得注意的地斏V�?br>你有什么好的徏议，�Ƣ迎提出来�?br>好，我们�q�入正题�?/p>

BT客户端的 main() 函数�Q?br> C 和c++的可执行�E�序�Q�通常都有一�?main() 函数�Q�一切从�q�里开始。�?python �q�种解释性语�a��Q��ƈ没有 main() 函数的概��c��你传递给解释器一�?.py 扩展名的python源码文�g�Q�解释器��׃��序去解释执行这个文件中的代码。所以，BT客户端的执行�Q�是从最先被 python 解释器解释执行的那个文�g开始的。这个文件应该是 btdownloadheadless.py�Q�至于谁又来通知�?python 解释器执行这个文件的�Q�我们以后再讨论�?/p>

【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 函数�Q�我们的重点��{�U�d�� download.py 文�g�Q�注意，该文件及以后要分析的代码都在 BT源码�?BitTorrent 子目录下�?br>�?nbsp;   download(params, h.chooseFile, h.display, h.finished, h.error, Event(), cols, h.newpath)
    if not h.done:
        h.failed()

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

【download.py�?br>�q�个文�g中，最主要的就�?download() 函数�Q�客��L(f��ng)��所有的一切都是从�q�里开始。这个函��C��码比较多�Q�我必须挑出其中最重要的代码，其它的部分，后箋再分析�?/p>

④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)

�? ��L(f��ng)��的核心类��是 RawServer�Q�这个类我在“服务器端源码分析”�Q�可在论坛中扑ֈ��Q�文章中分析�q�它的作用，�q�里不再赘述。通过调用它的 listen_forever() 函数�Q�BT 客户端就�q�入了一个��@环之中。此后，所有的下蝲、上传、文件存储以及其它工作都在这一�ơ次的��@环之中完成�?br>注意刎ͼ�在进入��@环之前，调用�? RawServer::bind() 函数�Q�BT客户端会选择一个可用的端口�Q�然后通过监听�q�个端口�Q�从而可以接受其�?peer 的连接请求（也就是BT对等�q�接�Q�。这个端口可以称�?#8220;监听端口”。如果你有网�l�服务器的编�E�经验，从它的��@环处理逻辑、监听端口的处理可以知道�Q�这昄�� 是一个典型的�|�络服务器的表现。所以，我在以前的文章中曄��说过�Q�BT客户端同时也是一个服务器�?br>一旦在监听端口上有某个peer发来�q�接�? 求，BT客户端会创徏一个新的端口，�q�个端口用来与请求者徏立连接；有几个peer��h��q�接�Q�就会创建几个端口。我们可以说�q�是一�?#8220;被动端口”。在循环的处理过�E�中�Q�BT客户端还会根据情况，向其�? peer��d��发出�q�接��h��Q�每个连接也需要一个端口，�q�些端口可以�U�Cؓ“��d��端口”。其实，�q�些都是�|�络�~�程中最基本的概念，不清楚的朋友�q�是首先要去�? 看这斚w��的书�c��?br>�q�样�Q�就有了一�?#8220;监听端口”�Q�几�?#8220;被动端口”和几�?#8220;��d��端口”�Q�BT客户端通过 select() 函数来监视这些端口，一�?#8220;监听端口”或�?#8220;被动端口”上有数据到来�Q�或者有数据需要从“��d��端口”上发送出去，那么select() 都可以及时感知�ƈ�q�行处理�Q�其实是一个轮询的�q�程�Q�，�q�就�U�Cؓ“I/O多�\复用”。如�?#8220;被动端口”上有数据到来�Q�那么这是BT对等�q�接的协议数据，需�? 按照BT对等协议�q�行分析�Q��ƈ�Ҏ(gu��)��分析�l�果�q�行相应处理�Q�这个分析处理的工作��是�?Encoder �c�L��完成的。所以在 listen_forever() 函数中传递的参数��是一�?Encoder �c�d��象。关于对 Encoder �cȝ��分析�Q�以后分析到BT对等协议的处理的时候再说�?/p>

��结�Q?br> 通过�q�篇文章�Q�我们了解了BT客户端是从哪里执行的�Q�相应的源码在哪里。同时我们知道了BT客户端是以一个服务器循环的�Ş式运行的�Q�它需要监听一个端口，用于接受其它peers的连接请求；在��@环过�E�中�Q�它通过 select 来实�?#8220;I/O多�\复用”�Q��ƈ�?Encoder �c�L��完成BT对等协议的分析处理�?/p>

苦笑�?/a> 2007-01-19 00:22 发表评论

Thu, 18 Jan 2007 16:21:00 GMT

摘要: StorageWrapper 的作用：把文件片断进一步切割�ؓ子片断，�q�且��些子片断发�? request 消息。在获得子片断后�Q�将数据写入��盘�? ��L(f��ng)��? Storage �cȝ��分析来看�? 几点说明�Q? 1�?nbsp; ��Z��获取传输性能�Q?BT 把文件片断切割�ؓ多个子片断�? 2�?nbsp; BT ��取一... 阅读全文

苦笑�?/a> 2007-01-19 00:21 发表评论

Thu, 18 Jan 2007 16:20:00 GMT

摘要: 作者：��马�? 日期�Q?2004-6-28 �׃�� Storage �c�L��较简单，我直接在源码基础上进行注释。掌�?Storage �Q��ؓ�q�一步分�? StorageWrapper �c�L��下基��? 几点说明�Q? 1�?nbsp; Storage �c?.. 阅读全文

苦笑�?/a> 2007-01-19 00:20 发表评论

BT客户端源码分析之一�Q�总述

Thu, 18 Jan 2007 16:19:00 GMT

BT客户端源码分析之一�Q�总述
作者：��马�?br>日期�Q?004-6-24

概述�Q?br>相对�?tracker 服务器来��_��BT客户端要复杂的多�Q�Bram Cohen �׃��一�q?full time 的时间来完成 BT�Q�我估计其中大部分时间是用在 BT 客户端的实现和调试上了�?br>�? �?BT 客户端涉及的代码比较多，我不能再象分�?tracker 服务器那��P��C��来就深入到细节之中去�Q�那��L(f��ng)��话，我写的晕晕糊�p�，大家看�v来也不知所云。所以第一��文章先来谈谈客��L(f��ng)��的功能、相兛_��议，以及客户端的 ��M��架构和相关的�cȝ��层次�l�构。这��P��从整体上把握之后�Q�大家在自己分析代码的过�E�中�Q�就能做到胸有成竏V�?/p>

客户端的功能�Q?/p>

不看代码�Q�只�Ҏ(gu��)�� BT 的相兛_��理，大致可以推测�Q�客��L(f��ng)��需要完成以下功能：
1、解�?torrent 文�g�Q�获取要下蝲的文件的详细信息�Q��ƈ在磁盘上创徏�I�文件�?br>2、与 tracker服务�?建立�q�接�Q��ƈ交互消息�?br>3、根据从 tracker 得到的信息，跟其�?peers 建立�q�接�Q��ƈ下蝲需要的文�g片断
4、监听某端口�Q�等待其它peers 的连接，�q�提供文件片断的上传�?/p>

相关协议�Q?br>对客��L(f��ng)��来说�Q�它需要处理两�U�协议：
1、与 tracker 服务器交互的 track HTTP协议�?br>2、与其它 peers 交互�?BT 对等协议�?/p>

��M��架构�Q?br>从��M��上来看，BT客户端实际是以一个服务器的�Ş式在�q�行。这一点似乎有些难以理解，但确实是�q�样�?br>��Z��么是一个服务器了？
�? ��L(f��ng)��的主要功能是下蝲文�g�Q�但作�ؓ一�U�P2P软�g�Q�同时它必须提供上传服务�Q�也��是它必��d��候在某一个端口上�Q�等待其它peers 的连接请求。从�q�一点上来说�Q�它必须以一个服务器的�Ş式运行。我们在后面实际分析代码的时候，可以看到�Q�客��L(f��ng)��复用�?RawServer �cȝ��来实现网�l�服务器�?br>客户端的代码�Q�是�?download.py 开始的�Q�首先完成功�?�Q�之后就�q�入服务器��@环，在每一�ơ��@环过�E�中�Q�完成功�?2�?�?。其中，Rerequester �c�负责完成功�?�Q�它通过 RawServer::add_task()�Q�向 RawServer ��d��自己的�Q务函敎ͼ��q�个��d��函数�Q�每隔一�D�|��间与 tracker 服务器进行通信。而Encoder、Connecter �{�多个类�l�合在一��P��完成功能3�?�?/p>

�c�d��ơ结构：

BT 客户端涉及的�c�L��较多�Q�我首先大致描述一下这些类的功能，然后�l�出它们的一个层�ơ结构�?/p>

1、RawServer�Q�负责实现网�l�服务器

2、Rerequester�Q�负责和 tracker 通信。它调用 RawServer::add_task() �Q�向 RawServer ��d��自己的�Q务函�?Rerequester::c()�?/p>

3、Encoder�Q�一�U?Handler�c�（在分�?tracker 服务器时候提刎ͼ��Q�负责处理与其它peers建立�q�接和以及对��d��的数据按照BT对等协议�q�行分析�?/p>

Encoder �c�d��Encrypter.py中，该文件中�Q�还有一�?Connection �c�，而在 Connecter.py 文�g中，也有一�? Connection �c�，�q�两个同名的 Connection �c�L��些蹊��P��Z��区分�Q�我把它们重新命名�ؓ E-Connection �? C-Connection�?/p>

3.1、E-Connection�Q�负�?TCP 层次上的�q�接工作
�q�两�? Connection 是有区别的，�q�是因�ؓBT对等协议需要在两个层次上徏立连接。首先是 TCP 层次上的�q�接�Q�也��是�l�过 TCP 的三�ơ握手之后，建立�q�接�Q�这个连接由 E-Connection 来管理。在 Encoder:: external_connection_made() 函数中可以看刎ͼ�一旦有外部�q�接到来�Q�则创徏一�?E-Connection �c�R�?/p>

3.2、C-Connection�Q�管理对�{�协议层�ơ上的连接�?br>�?TCP �q�接之上�Q�是 BT对等协议的连接，它需要经�q�BT对等协议的两��?#8220;握手”�Q�握手的�l�节大家�ȝ��BT对等协议。过�E�是�q�样的：
��Z��便于�q�说�Q�我们假设一个BT客户端�ؓ A�Q�另一个客��L(f��ng)��?X�?br>�? 果是X��d��向A发�v�q�接�Q�那么在TCP�q�接建立之后�Q�A立刻利用�q�个�q�接向X发送BT对等协议�?#8220;握手”消息。同��P��X在连接一旦徏立之后，�? A发送BT对等协议�?#8220;握手”消息。A一旦接收到X�?#8220;握手”消息�Q�那么它?y��u)��p��?#8220;握手”成功�Q�徏立了BT对等协议层次上的�q�接。我把它叫做“对等�q? �?#8221;。A 发送了一个消息，同时接收了一个消息，所以这个握手过�E�是两次“握手”�?br>同样�Q�对X 来说�Q�因��接是它主动发��L(f��ng)��Q�所以它在发送完“握手”消息之后�Q�就�{�待A�?#8220;握手”消息�Q�如果收刎ͼ�那么它也认�ؓ“对等�q�接”建立了�?br>一�?#8220;对等�q�接”建立之后�Q�双方就可以通过�q�个�q�接传递消息了�?/p>

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

也就是说�Q�不��是X��d��向A发�v的连接，�q�是 A ��d��?X发�v的连接，一旦徏立之后，它们的效果是一��L(f��ng)��。这个同我们�q�x��?C/S�l�构的网�l�开发是有区别的�?/p>

我们可以看到�?E-Connection的初始化函数中，会主动连接的另一方发�?#8220;握手”消息�Q�在 E-Connection::data_came_in() 中，会首先对�Ҏ(gu��)��?#8220;握手”消息�q�行处理。这正是我上面所描述的情形�?br>�?E-Connection::read_peer_id() 中，是对“握手”消息的最后一��?peer id�q�行处理�Q�一旦正��无误，那么��p��?#8220;对等�q�接”完成�Q?/p>

self.encoder.connecter.connection_made(self)

�?Connecter::connection_made() 函数中，��创��Z��理“对等�q�接”�?C-Connectinon�c�R��所以，更高一层的“对等�q�接”是由 C-Connection 来管理的�?/p>

3.3、Connecter�Q�连接器�Q�管理下载、上传、阻塞、片断选择、读写磁盘等�{��?/p>

下蝲和上传不是孤立的�Q�它们之间相互媄响。下载需要有片断选择��法�Q�上传的时候要考虑��d��Q�片断下载之后，要写到磁盘上。上传的时候，也需要从��盘��d��?br>�q�些��d��Q�是�?Connecter 来统一调度的�?/p>

�c�d��ơ结构，我用�~�进来表�C�Z��U�包含关�p�R�?/p>

Encoder:
    E-Connection
        C-Connection
            Upload
            SingleDownloader
        Connecter
            Choker�Q�负责阻塞的��理
            Downloader�Q?br>                SingleDownloader
                Picker�Q�片断选择�{�略
                StorageWrapper�Q?/p>

先写�q�些吧，有什么我再补充进来�?/p>

苦笑�?/a> 2007-01-19 00:19 发表评论

Thu, 18 Jan 2007 16:18:00 GMT

�q�篇文章�Q�我们来分析 RawServer 以及一些相关的�c�R�?/span> RawServer �cȝ��实现代码�Q�在 BitTorrent 子目录的 RawServer.py �?/span>

RawServer �q�个�cȝ��作用是实��C��个网�l�服务器。关于网�l�编�E�的知识�Q��?/span> unix �|�络�~�程�Q�卷 1 》是最�l�典的书�c�，你如果对�q�块不了解，��抽时间看看这本书�?/span> RawServer 实现的是一�U�事件多路复用、非��d��的网�l�模型。它使用的是 poll() �Q�而不是我们常见的 select() �Q�关�?/span> poll �?/span> select 的比较，也在�?/span> unix �|�络�~�程�Q�卷 1 》中有介�l�）函数�Q�处理过�E�大致是�q�样的：

首先创徏一个监�?/span> socket �Q�然后将�q�个 socket 加入 poll 的事件源�Q?/span>

随后�q�入服务处理循环�Q�即�Q?/span>

调用 poll() 函数�Q�这个函��C��d��Q�直到网�l�上有某些事件发生或者超时才�q�回�l�调用者；

�?/span> poll() �q�回之后�Q�先��查一下是否有没有处理的�Q务，如果有，那么先完成这些�Q务。然后根据事件类型进行处理�?/span>

如果是连接请求（监听 socket 上的 POLLIN 事�g�Q�到来，�?/span> accept �q�个��h��Q�如�?/span> accept 成功�Q�那么就和一�?/span> client 建立了连接，于是��?/span> accept() 新创建的 socket 加入 poll 的事件源�Q?/span>

如果在已�l�徏立的�q�接上（�q�接 socket 上的 POLLIN 事�g�Q�，有数据可读，那么��数据从 client 端读�q�来�Q�做�q�一步处理；

如果已经建立的连接已�l�准备好�Q�连�?/span> socket 上的 POLLOUT 事�g�Q�，可以发送数据，则检查是否有数据需要发送，如果有，那么发送数据给 client 端�?/span>

�Q�所以， tracker 是一个单�q�程的服务器�Q��ƈ没有用到�U�程。）

Bram Cohen 认�ؓ软�g的可�l�护性非帔R��要，使代码易于维护的重要一条就是设计可重用的类�Q?/span> RawServer 在设计的时候，充分考虑��C��可重用性，集中表现在两个地方：

1�?span style="font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> ��网�l?/span> I/O 和数据分析处理分��R�?/span>

�|�络服务器的事�g多�\复用、网�l?/span> I/O 部分通常是固定不变的�Q�而数据在��d��之后�Q�进行分析处理的�q�程则是可变的�?/span> RawServer ��可变的数据处理工作�Q�交�l�另外一个抽象的�c?/span> Handler �Q�实际上�q�没有这么一个类�Q�来处理。比如，�?/span> tracker 服务器的实现中，具体使用的就�?/span> HTTPHandler �c�，而在以后��要分析�?/span> BT client 实现代码中，用到的具体的 Handler �?/span> Encoder �c�R�?/span>

RawServer �l�护了一个�Q务队�?/span> unscheduled_tasks �Q�实际是一个二元组�?/span> list �Q�二元组的第一��Ҏ(gu��)��一个函敎ͼ��W�二��Ҏ(gu��)��时旉��Q�。在初始化的时候，首先向这个队列中加入一个�Q务： scan_for_timeouts() �Q�这��P��每隔一�D�|��_��服务器就会去��查一下是否有�q�接��时。如果有其它

RawServer 的成员函��C��Q�对外暴露的有：

u __init__ �Q�（初始化函敎ͼ�

u add_task() �Q?/span>

在�Q务列表中增加一��Q务（一个�Q务是一个函��C��及一个指定的��时旉��的组合）

u bind() �Q?/span>

首先创徏一�?/span> socket �Q�然后设�|?/span> socket 的属性： SO_REUSEADDR �?/span> IP_TOS, �Q�这两个属性的具体含义请参考�?/span> unix �|�络�~�程�Q�卷 1 》，另外�q�将 socket 讄��为非��d��的。相对于��d��?/span> socket 来说�Q�非��d��?/span> socket 在网�l?/span> I/O 性能上要提高许多�Q�但是与此同�Ӟ��~�程的复杂度也要提高一些。象 tracker �q�种可能同时要处理成千上万个�q�发�q�接的服务器�Q�只能采用非��d��?/span> socket �?/span>

然后��该 socket 和指�?/span> ip 已经端口�l�定�Q?/span>

最后把�q�个 socket 加入 poll 的事件源�?/span>

u start_connection() �Q?/span>

对外��d��建立一个连接，�q�个函数在处�?/span> NAT �I�越的时候用��C��Q�我们后面分析到 NAT �I�越的时候，再具体讲解�?/span>

u listen_forever() �Q?/span>

�q�个函数的功能就是实��C��我在前面描述的网�l�服务器的处理过�E�。我们看刎ͼ�它唯一的参数是 handler �Q?/span> handler 的作用就是封装了�Ҏ(gu��)��据的具体处理�?/span>

listen_forever() 把对�|�络事�g的处理过�E�，交给�?/span> handle_events() �?/span>

其它函数�Q�包�?/span> handle_events() �Q�都是内部函敎ͼ�也就是外部不会直接来调用�q�些函数�Q��?/span> Python 没有 c++ 那样 public �?/span> protected �?/span> private �q�样的保护机�Ӟ�� python �cȝ��内部函数命名的惯例是以下划线开始，例如 RawServer 中的 _close_dead() �{��?/span>

u handle_events() �Q?/span>

事�g处理�q�程�Q�主要是�Ҏ(gu��)��三种不同的网�l�事件分别处理，一是连接事�Ӟ��二是��M��件、三是写事�g�?/span>

if sock == self.server.fileno()

�q�段代码判断发生事�g�?/span> socket 是否是监�?/span> socket �Q�如果是�Q�那么说明是�q�接事�g�?/span>

�q�接事�g的处理：

通过 accept 来接受连接，�q�将新徏立的 socket 讄��为非��d��?/span>

判断当前�q�接数是否已�l�达��C��最大��|��Z��限制�q�发�q�接的数目，在初始化 RawServer 的时候，需要指定最大连接数目）�Q�如果已�l�达到最大��|��那么关闭�q�个新徏的连接�?/span>

否则�Q�根据新�?/span> socket 创徏一�?/span> SingleSocket 对象�Q�（ SingleSocket ��装了对 socket 的操作。）��这个对象加入内部的列表 single_sockets 中，以备后用�?/span>

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

最后，调用 Handler �?/span> external_connection_made() 函数�Q�关于这个函敎ͼ�在后面分�?/span> HTTPHandler 时再讨论�?/span>

if (event & POLLIN) != 0:

�q�段代码判断是否是读事�g

��M��件的处理�Q?/span>

首先��h��一下连接的最后更新时�?/span> �Q?/span> last_hit �Q��?/span>

然后��d��数据�Q?/span>

如果什么也没读刎ͼ�那么说明�q�接被关闭了�Q�在�|�络�~�程中，如果一个连接正常的被关闭，那么�Q�也会触发读事�g�Q�只不过什么也��M��刎ͼ�

否则�Q�调�?/span> Handler �?/span> data_came_in() 函数来处理读到的数据�?/span>

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

�q�段代码判断是否是写事�g�Q�而且��实有数据需要发送。在一个连接可以写的时候，��׃��发生写事件�?/span>

写事件的处理�Q?/span>

实际代码是在 SingleSocket �?/span> try_write() 函数中�?/span>

在一个非��d��的连接上发送指定大��的数据�Q�很可能在一�ơ发送过�E�中�Q�数据没有被完全发送出去（只发送了一部分�Q�就�q�回了，所以，每次 write 之后�Q�必��d��断是否完全发送了数据。如果没有发送完�Q�那么下�ơ有��M��件的时候，�q�得回来�l�箋发送未完得数据。这也是�q�个函数叫做 try_write 的原因吧�?/span>

try_write() 在最后，要重新设�|?/span> poll 的事件源。如果数据全部发送完毕了�Q�那么只需要监听读事�g�Q?/span> POLLIN �Q�否则，既要监听��M��Ӟ��也要监听写事�Ӟ�� POLLOUT �Q�，�q�样�Q�一旦连接变的可写，可以�l�箋��剩下的数据发送出厅R�?/span>

u scan_for_timeouts() �Q?/span>

��d��处理函数�Q�它首先把自�w�加入未处理��d��队列中，�q�样�Q�经�q�一�D�|��_��可以保证�q�个函数再次被调用，从而达到周期性调用的效果�?/span>

它检查每个连接是否超�q�指定时间没有被��h��Q�如果是�Q�则该连接可能已�l�僵死，那么它关闭这个连接�?/span>

u pop_unscheduled() �Q?/span>

从�Q务列表中弹出一个未处理的�Q务�?/span>

�?/span> RawServer 配合使用的是 SingleSocket �c�，�q�是一个辅助类�Q�主要目的是��装�?/span> socket 的处理吧。包括数据的发送，都交�l�它来处理了。这个类比较��单，大家可以自己�ȝ��Q�我��׃��|�嗦了�?/span>

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

我们再来��结一下�?/span>

RawServer ��装了网�l�服务器的实现细节，它实��C��一�U�事件多路处理、非��d��的网�l�模型。它主要负责建立新的�q�接�Q�从�|�络��d��和发送数据，而对��d��的数据的具体处理工作�Q�交�l?/span> Handler �c�L��处理�Q�从而把�|�络 I/O 和数据处理分��d��来，使得 RawServer 可以重用�?/span> Handler �c�L��在调�?/span> listen_forever() 的时候，��p��用者传递进来的�Q�具体到 tracker 服务器，��是 HTTPHandler 。有�?/span> RawServer �Q?/span> tracker ��可以作��Z��个网�l�服务器�q�行了�?/span>

下一节，我们开始分析具体实�?/span> tracker HTTP 协议处理�?/span> HTTPHandler �c�d�� Tracker �c�R�?/span>

苦笑�?/a> 2007-01-19 00:18 发表评论

Thu, 18 Jan 2007 16:18:00 GMT

本篇文章分析 HTTPHandler �c�，它在 HTTPHandler.py 文�g中�?/span>

上一��我们讲刎ͼ� RawServer 只负责网�l?/span> I/O �Q�也��是从网�l�上��d��和发送数据，至于��d��的数据如何分析，以及应该发送什么样的数据，则交�l?/span> Handler �c�L��处理。如果是�?/span> c++ 来实现的话，那么 Handler 应该是一个接口类�Q�提供几个虚函数作�ؓ接口�Q�，但是 python 动态语�a�的特性，�q�不需要专门定义这么一个接口类�Q�所以实际上�q�没�?/span> Handler �q�么一个类。�Q何一个提供了以下成员函数的类�Q�都可以作�ؓ一�?/span> Handler �c�L��?/span> RawServer 配合�Q�它们是�Q?/span>

external_connection_made() �Q�在建立新的�q�接的时候被调用

data_came_in() �Q�连接上有数据可�ȝ��时候被调用

connection_flushed() �Q�当在某个连接上发送完数据之后被调�?/span>

HTTPHandler ��是�q�样一�?/span> Handler �c�，它具备以上接口�?/span>

HTTPHandler 代码很少�Q�因为它把主要工作又交给 HTTPConnection 了�?/span>

我们�?/span> HTTPHandler �cȝ��q�几个函敎ͼ�

l external_connection_made() �Q?/span>

每当新来一个连接的时候，��创��Z��?/span> HTTPConnection �c�R�?/span>

l data_came_in() �Q?/span>

当连接上有数据可�ȝ��时候，调用 HTTPConnection::data_came_in() 。我们接下去�?/span> HTTPConnection::data_came_in() �?/span>

我们知道�Q?/span> BT client 端与 tracker 服务器之间是通过 tracke HTTP 协议来进行通信的�?/span> HTTP 协议分�ؓ��h��Q?/span> request �Q�和响应�Q?/span> response �Q�，具体的协议请看相关的 RFC 文档。我�q�里��单讲一下�?/span>

�?/span> tracke 服务器来��_��它读到的数据�?/span> client 端的 HTTP ��h��?/span>

HTTP ��h��以行为单位，行的�l�束�W�是“回�R换行”�Q�也��是 ascii 字符 “ \r ”�?#8220; \n ”�?/span>

�W�一行是��h��?/span> URL �Q�例如：

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

�q�行数据被空格分��Z��部分�Q?/span>

�W�一部分 GET 表示命��o�Q�其它命令还�?/span> POST �?/span> HEAD �{�等�Q�常用的��是 GET 了�?/span>

�W�二部分是请求的 URL �Q�这里是 /announce?ip=aaaaa;port=bbbbbbb 。如果是普通的上网��览�|�页�Q�那�?/span> URL ��是我们要看的网��在�?/span> web 服务器上的相对�\径。但是，�q�里�?/span> URL 仅仅是交互信息的一�U�方式， client 端把要报告给 tracker 的信息，攑֜� URL 中，例子里面�?/span> ip �?/span> port �Q�更详细的信息请�?#8220; BT 协议规范”�?/span> tracker 协议部分�?/span>

�W�三部分�?/span> HTTP 协议的版本号�Q�在�E�序中忽略�?/span>

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

Host:www.sina.com.cn

Accept-encoding:gzip

通过消息��_�� tracker 服务器可以知�?/span> client 端的一些信息，�q�其中比较重要的��是 Accept-encoding �Q�如果是 gzip �Q�那么说�?/span> client 可以�?/span> gzip 格式的数据进行解压，那么 tracker 服务器就可以考虑�?/span> gzip 把响应数据压�~�之后再传回去，以减��网�l�流量。我们可以在代码中看到相应的处理�?/span>

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

HTTPConnection::data_came_in() 用一个��@环来�q�行协议分析�Q?/span>

首先是寻找行�l�束�W�号�Q?/span>

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

�Q�我认�ؓ仅仅�?/span> “ \n ”�q�不严�}�Q�应该找 “ \r\n ”�q�个序列�Q��?/span>

如果没有扑ֈ��Q�那�?/span> index() 函数会抛��Z��个异常，而异常的处理是返�?/span> True �Q�表�C�数据不够，需要��l�读数据�?/span>

如果扑ֈ�了，那么 i 之前的字�W�串��是完整的一行。于是调用协议处理函敎ͼ�代码是：

self.next_func = self.next_func(val)

�?/span> HTTPConnection 的初始化的时候，有这么一行代码：

self.next_func = self.read_type

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

return self.read_header

�q�样�Q�在下一�ơ调�?/span> next_func 的时候，��是调用 read_header() 了，也就是对 HTTP 协议的消息头�q�行分析�?/span>

下面先看 read_type() �Q?/span>

它首先把 GET 命��o中的 URL 部分保存�?/span> self.path 中，因�ؓ�q�是 client 端最关键的信息，后面要用到�?/span>

然后��查一下是否是 GET 或�?/span> HEAD 命��o�Q�如果不是，那么说明数据有错误。返�?/span> None �Q�否�?/span> return self.read_header

接下来我们看 read_header() �Q?/span>

�q�其中，最重要的就是对�I��的处理，因�ؓ前面说了�Q�空行表�C�协议分析结束�?/span>

在检查完 client 端是否支�?/span> gzip �~�码之后�Q�调用：

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

通过一层层往后追查，发现 getfunc() 实际�?/span> Tracker::get() �Q�也��是��_��真正�?/span> client 端发来的��h��q�行分析�Q�以及决定如何响应，是由 Tracker 来决定的。是的，�q�个 Tracker 在我�?/span> tracker 服务器源码分析系列的�W�一��文章中��已�l�看��C��。在创徏 RawServer 之后�Q�马上就创徏了一�?/span> Tracker 对象。所以，要了�?/span> tracker 服务器到底是如何工作的，需要我们深入进��d��?/span> Tracker �c�，那就是我们下一��文章的工作了�?/span>

在调用完 Tracker::get() 之后�Q�返回的是决定响应给 client 端的数据�Q?/span>

if r is not None:

self.answer(r)

最后，调用 answer() 来把�q�些数据发送给 client 端�?/span>

�?/span> answer() 的分析，我们在下一��分�?/span> Tracker �cȝ��文章中一�q�讲解�?/span>

l connection_flushed() �Q?/span>

tracker 服务器用的是非阻塞的�|�络 I/O �Q�所以不能保证在一�ơ发送数据的操作中，把要发送的数据全部发送出厅R�?/span>

�q�个函数�Q�检查在某个�q�接上需要发送的数据�Q�是否已�l�全部被发送出��M��Q�如果是的话�Q�那么关闭这个连接的发送端。（��Z��么仅仅关闭发送端�Q�而不是完全关闭这个连接了�Q�疑惑）�?/span>

苦笑�?/a> 2007-01-19 00:18 发表评论

Thu, 18 Jan 2007 16:18:00 GMT

摘要: 本篇文章分析 Tracker �c�，它在 track.py 文�g中�? 在分析之前，我们把前几篇文章的内容再回顾一下，以理清思�\�? BT 的源码，主要可以分�ؓ两个部分�Q�一部分用来实现 tracker 服务器，另一部分用来实现 BT 的客��L(f��ng)��。我们这个系列的文章围绕 tracker 服务器的实现来展开�? BT ... 阅读全文

苦笑�?/a> 2007-01-19 00:18 发表评论

Tracker 服务器源码分析之一�Q�总述

Thu, 18 Jan 2007 16:17:00 GMT

tracker 服务器是 BT 下蝲中必��ȝ��角色。一�?/span> BT client 在下载开始以及下载进行的�q�程中，要不停的�?/span> tracker 服务器进行通信�Q�以报告自己的信息，�q�获取其它下�?/span> client 的信息。这�U�通信是通过 HTTP 协议�q�行的，又被�U�Cؓ tracker HTTP 协议�Q�它的过�E�是�q�样的：

client �?/span> tracker 发一�?/span> HTTP �?/span> GET ��h��Q��ƈ把它自己的信息放�?/span> GET 的参��C��Q�这个请求的大致意思是�Q�我�?/span> xxx �Q�一个唯一�?/span> id �Q�，我想下蝲 yyy 文�g�Q�我�?/span> ip �?/span> aaa �Q�我用的端口�?/span> bbb 。。�?/span>

tracker �Ҏ(gu��)��有下载者的信息�q�行�l�护�Q�当它收��C��个请求后�Q�首先把�Ҏ(gu��)��的信息记录下来（如果已经记录在案�Q�那么就��查是否需要更斎ͼ��Q�然后将一部分�Q��ƈ非全部，�Ҏ(gu��)��讄��的参数已�l�下载者的��h��Q�参与下载同一个文�Ӟ��一�?/span> tracker 服务器可能同时维护多个文件的下蝲�Q�的下蝲者的信息�q�回�l�对斏V�?/span>

Client 在收�?/span> tracker 的响应后�Q�就能获取其它下载者的信息�Q�那么它?y��u)��可以根据这些信息，与其它下载者徏立连接，从它们那里下载文件片断�?/span>

关于 client �?/span> tracker 之间通信协议的细节，�?#8220; BT 协议规范”中已�l�给出，�q�里不再重复。下面我们具体分�?/span> tracker 服务器的实现�l�节�?/span>

从哪里开始？

要徏立一�?/span> tracker 服务器，只要�q�行 bttrack.py �E�序��p��了，它最��需要一个参敎ͼ��是 –dfile �Q�这个参数指定了保存下蝲信息的文件�?/span> Bttrack.py 调用 track.py 中的 track() 函数。因此，我们跟踪�?/span> track.py 中去�?/span> track() 函数�?/span>

Track.py �Q?/span> track()

�q�个函数首先对命令行的参数进行检查；然后��这些参��C��存到 config 字典中。在 BT 中所有的工具�E�序�Q�都有类似的处理方式�?/span>

接下来的代码�Q?/span>

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()

首先是创��Z��?/span> RawServer 对象�Q�这是一个服务器对象�Q�它?y��u)��实��C��个网�l�服务器的一些细节封装�v来。不�?/span> tracker 服务器用��C�� RawServer �Q�我们以后还可以看到�Q�由于每�?/span> client 端也需要给其它 client 提供下蝲服务�Q�因此也同时是一个服务器�Q?/span> client 的实��C��Q�也用到�?/span> RawServer �Q�这��P�� RawServer 的代码得��C��重用。关�?/span> RawServer 的详�l�实玎ͼ�在后面的��节中进行分析�?/span>

接着是创��Z��?/span> Tracker 对象�?/span>

然后�?/span> RawServer �l�定在指定的端口上（通过命��o行传递进来）�?/span>

最后，调用 RawServer::listen_forever() 函数�Q��得服务器投入�q�行�?/span>

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

其它信息�Q?/span>

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

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

2�?span style="font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> 我们看到�Q?/span> python 和我们以前接触的 c/c++ 不一��L(f��ng)��W�一个地方就是它的函数在定义的时候，不用指定参数�c�d��。既然这��P��那么�Q�在调用函数的时候，你可以传递�Q意类型的参数�q�来。例如这��L(f��ng)��函数�Q?/span>

def foo(arg):

print type(arg)

你可以这��h��调用�Q?/span>

a = 100

b = “hello world”

foo(a)

foo(b)

输出�l�果是：

�q�是因�ؓ�Q�第一�ơ调�?/span> foo() 的时候，传递的是一个整数类型，而第二次调用的时候，传递的是一个字�W�串�c�d��?/span>

�q�种参数��h��动态类型的�Ҏ(gu��)��，�?/span> c/c++ �{�传�l�的语言是所不具备的。这也是 python 被称为动态语�a�的一个原因吧�?/span> C++ 的高�U�特性模板，虽然也��得参数类型可以动态化�Q�但使用��h��Q�远没有 python �q�么��单方�ѝ�?/span>

苦笑�?/a> 2007-01-19 00:17 发表评论