用Python教你如何“养”一只DHT爬虫(1)(2)

实现一个DHT客户端, 不用都要实现ping, find_node, get_peers, announce_peer操作了, 做一个爬虫, 仅仅只需要实现find_node功能就能达到目的了. 因为我们只想不停地交朋友而已.

要想加入DHT网络, 首先得认识第一个已知的node, 这个node最好是长期在线的, 又稳定的. 我这里就认识一个, dht.transmissionbt.com:6881, 由于UDP的原因, 只能接受ip, 所以请提前解析出ip地址.

然后使用DHT协议说的那个find_node操作, 现在解释一下某些key的潜在意义吧

t: transaction ID的简称, 传输ID. 起什么作用呢? 由于UDP无3次握手这个机制, 所以任何人都可随便发送信息给你, 根本就不需与你提前进行连接. 想想这么个情况, 你发送了一请求数据给某node, 然后收到DHT说的回复类型的数据, 即y=r, 但是, 你怎么知道回应的是你之前的哪个请求呢? 所以就要靠t了, 当你发送时, t=aa的话, 对方回应这个请求时, 回应消息的t绝对是aa, 这样你就能区分了. 在发送之前, 要为该t值注册一个处理函数, 当收到回应时, 调用该函数进行处理. 记得设置一个定时器, 时间一到, 立马删除该函数, 不然你内存飙升. 如果超时后才收到信息的话, 很遗憾, 没了处理函数, 直接忽略. 我建议定时器设定到5秒. 当然, 随便你. 一定要保证成功收到第一个node的find_node回复, 不然失败, 就没法继续find_node了.即: 认识不到第一个朋友, 就别想认识第二个朋友.

id: 就是自身node ID了, 是node_id()函数生成的哈, 样子绝不是DHT协议例子中的样子, 这主要是为了方便演示而已

target: 这个也是自身的node ID, 作用是问某node离我最近的都有哪些node.

收到对方回复后, 把那key为nodes给解析出来, 按DHT协议说的, 每个node是以4字节ip+2字节port+20字节node ID组成, 那么nodes的字节数就会是26的倍数. "解码"node和"编码"node的Python代码如下:

from struct import unpack  
 
def num_to_dotted(n):  
    d = 256 * 256 * 256 
    q = []  
    while d > 0:  
        m, n = divmod(n, d)  
        q.append(str(m))  
        d /= 256 
    return '.'.join(q)  
 
def decode_nodes(nodes):  
    n = []  
    nrnodes = len(nodes) / 26 
    nodes = unpack("!" + "20sIH" * nrnodes, nodes)  
    for i in range(nrnodes):  
        nid, ip, port = nodes[i * 3], num_to_dotted(nodes[i * 3 + 1]), nodes[i * 3 + 2]  
        n.append((nid, ip, port))  
    return n  
 
decode_nodes函数的反作用函数如下:  
def dotted_to_num(ip):  
    hexn = ''.join(["%02X" % long(i) for i in ip.split('.')])  
    return long(hexn, 16)  
 
def encode_nodes(nodes):  
    n = []  
    for node in nodes:  
        n.extend([node.nid, dotted_to_num(node.ip), node.port])  
    return pack("!" + "20sIH" * len(nodes), *n) 

解析出来后, 插入到路由表里, 然后使用find_node继续向刚解析出来的node进行请求, target还是自身node ID, 以此循环. 这样就能认识很多很多的node啦. 细节就不说了, 自己看着办.

第三步, 实现DHT服务器端, 协议文档说得很清楚了, 我只列出几个需要注意的问题:

1, 服务器端得实现处理node发来的ping, find_node, get_peers, announce_peer请求.

2, 回应信息里的t的值是对方的t值, 不是自己随便写的.

3, 最好要实现那个token机制, 这样就减少被捣乱的几率, 此token就按协议那种方式就行, 每5分钟变换一次, 10分钟内的有效.

4, 一定要记得前面说的那句"当该bucket负责的node有请求, 回应操作; 删除node; 添加node; 更新node; 等这些操作时, 那么就刷新该bucket".

5, 由于是做DHT爬虫, 所以处理get_peers请求和find_node请求差不多一样, 都是返回最近的node. 当然, 你闲得蛋疼的话, 可以来得标准点, 做能返回peers那种, 不过, 没必要.

6, announce_peer请求里的port就是对方提供下载种子的端口, 监听于TCP, 不是DHT连接的端口. 还有请求消息里的id就仅仅指的是对方的node ID, 我看博客园某人写的文章说是对方的peer ID, 我表示很不解.

第四步, 定时刷新路由表

按协议所说, 过一段时间后, 路由表里的node不全都是活跃了, 所以要定时刷新路由表. 说下大概思路, 遍历路由表中的bucket列表, 看看bucket的last_accessed是不是超过了比如说15分钟, 如果超过了, 说明有可能不"新鲜"了, 那么从该bucket随机选择一个node, 向该node发送find_node操作, 接着就不管了. 笔者为了简单, 就采用这么简单的方式了, 没有去确认可疑node是否还"活"着. 你可以严格按照协议文档那么写.

你可能会问的问题:

1, 怎么知道一个资源的下载速度?

答: 有句话这么说: 下载人数越多, 下载速度越快. 那么, 如果某一个资源的infohash出现的announce_peer次数越高, 那么就说明下载人数就越多, 人数越多就越快. 这个下载速度就没法用绝对速度表示, 不过可以使用相对速度.

2, 怎么在众多的资源中过滤出影视资源?

答: 得到种子, 如果有files字段话, 遍历它进行正则匹配, 看看有木有后缀名是rmvb, avi, mp4等什么的, 如果有, 那它大部分情况就是影视了. 如果没有files字段, 就对name字段进行正则匹配吧.

3, 为什么那些影视资源总是些"很黄很暴力"?

答: 这个就不是很清楚了, 我想, 使用BT的人大多数都是些撸管男吧.

4, infohash这个词是根据什么而来的?

答: 种子文件中info字段的hash值

5, 如何认识更多的node?

答: 多开启几个node实例.

6, 什么情况下, 对方把我给加入到对方的路由表里?

答: 当你向对方find_node时. 也许你的ping, get_peers也能让对方把你添加到路由表里. 同理, 当你接到ping, find_node, get_peers时, 就把对方给添加到路由表里, 至少收到find_node请求时, 就要把对方给添加到路由表里.

7, 如何长期保存node?

答: 数据库, 文件都行, 我不建议长期保存node, 你只要一直在线, 使用内存存储最好不过了, 速度快, 代码简单.