昨天下载了 transmission-2.33, 大致浏览的代码。发现很代码的third-party目录里面有个很小巧的dht实现。
只有三个文件就可以实现dht的功能: dht.c dht.h dht-example.c,并且接口很简单,复用性很好。
粗略的阅读了一下代码,把大致的实现思路整理如下(后面会贴出代码):
代码分成三部分:
1、路由表的插入操作。
1)如果节点已经在路由表中,则更新节点,返回。
2)如果桶没有满,则插入,返回。
3)如果发现失效节点,替换,返回。
4)发现可疑节点,则保存新节点到缓存中并且如果该可疑节点没有ping,发出ping_node操作,返回。
5)现在,桶已经充满了好的节点,如果自己的ID没有落在这个桶中,返回。
6)将桶空间分成两半。跳到步骤1)。
2、KAD远程处理调用。
这部分又分成3种,
1)ping/pong操作。
所有的包的tid都使用pg\0\0
2)find_node操作。
所有的包的tid都使用fn\0\0
3)get_peers/annouce_peer操作。
对同一个HASH的一次递归查询中,tid保持不变。
其中只有3)种实现bittorrent的DHT规范里面提到的递归查询操作,1)和2)仅仅用来维护路由表,并且不保存状态。
3、定时器处理:
为了检测路由表中节点的有效性(根据规范,路由表中应该只保存有效节点),在代码中,在执行krpc操作时如果发现时对路由表中的节点操作,那么则保存操作的开始时间 pinged_time,通过操作的开始时间来判断操作是否超时。
expire_stuff_time 超时时,会执行下面的操作:
1、检查路由表中失效的节点(根据pinged_time来判定),并将该节点删除。
2、检查用来保存annoounce_peer的节点是否超过30分钟(这个不打算深入讨论,故不做解析)。
3、检查递归查询操作超时。
rotate_secrets_time 定时器。
用来每隔大约15分左右就更换token(见DHT规范).
confirm_nodes_time 定时器。
查找长期没有活动的桶,然后通过执行一个find_node的krpc操作来刷新它。
search_time定时器。
有可能出现发出的所有的get_peers操作,都没有应答,那么search_time定时器遇到这种情形时负责重发所有请求。(注意: get_peers操作最大未决的krpc请求数是3)
用于维持路由表的ping/pong操作:
在试图插入节点时,发现桶已经满,而存在可疑节点时会触发ping_node操作。未响应的节点会有可疑最终变为失效节点,而被替换。
缺点就是完成整个路由引导的速度比较慢。
其实,我自己也写过一个DHT的实现,不过估计相对来说,应该会需要更多的带宽。
阅读(4724) | 评论(1) | 转发(0) |