记录DHT网络主要功能步骤
经过不停止的查找相关资料，基本上实现DHT网络的基本操作。现记录下来，供以后参考。
协议
Kad定义了节点之间的交互协议。这些协议支撑了整个DHT网络里信息分布式存储的实现。这些协议都是使用UDP来传送。其协议格式使用一种称为bencode的编码方式来编码协议数据。bencode是一种文本格式的编码，它还用于种子文件内的信息编码。
Kad协议具体格式可参考BitTorrent的定义：DHT Protocol。这些协议包括4种请求：ping，find_node，get_peer，announce_peer。在有些文档中这些请求的名字会有不同，例如announce_peer又被称为store，get_peer被称为find_value。这4种请求中，都会有对应的回应消息。其中最重要的消息是get_peer，其目的在于在网络中查找某个资源对应的peer列表。
值得一提的是，所有这些请求，包括各种回应，都可以用于处理该消息的节点构建路由表。因为路由表本质就是存储网络中的节点信息。
ping
用于确定某个节点是否在线。这个请求主要用于辅助路由表的更新。
find_node
用于查找某个节点，以获得其地址信息。当某个节点接收到该请求后，如果目标节点不在自己的路由表里，那么就返回离目标节点较近的K个节点。这个消息可用于节点启动时构建路由表。通过find_node方式构建路由表，其实现方式为向DHT网络查询自己。那么，接收该查询的节点就会一直返回其他节点了列表，查询者递归查询，直到无法查询为止。那么，什么时候无法继续查询呢？这一点我也不太清楚。每一次查询得到的都是离目标节点更接近的节点集，那么理论上经过若干次递归查询后，就无法找到离目标节点更近的节点了，因为最近的节点是自己，但自己还未完全加入网络。这意味着最后所有节点都会返回空的节点集合，这样就算查询结束？
实际上，通过find_node来构建路由表，以及顺带加入DHT网络，这种方式什么时候停止在我看来并不重要。路由表的构建并不需要在启动时构建完成，在以后与其他节点的交互过程中，路由表本身就会慢慢地得到构建。在初始阶段尽可能地通过find_node去与其他节点交互，最大的好处无非就是尽早地让网络中的其他节点认识自己。
get_peer
通过资源的infohash获得资源对应的peer列表。当查询者获得资源的peer列表后，它就可以通过这些peer进行资源下载了。收到该请求的节点会在自己的路由表中查找该infohash，如果有收录，就返回对应的peer列表。如果没有，则返回离该infohash较近的若干个节点。查询者若收到的是节点列表，那么就会递归查找。这个过程同find_node一样。
值得注意的是，get_peer的回应消息里会携带一个token，该token会用于稍后的announce_peer请求。
announce_peer
该请求主要目的在于通知，通知其他节点自己开始下载某个资源。这个消息用于构建网络中资源的peer列表。当一个已经加入DHT网络的P2P客户端通过种子文件开始下载资源时，首先在网络中查询该资源的peer列表，这个过程通过get_peer完成。当某个节点从get_peer返回peer时，查询者开始下载，然后通过announce_peer告诉返回这个peer的节点。
announce_peer中会携带get_peer回应消息里的token。关于这一点，我有一个疑问是，在P2P中DHT网络介绍文档中提到：
(announce_peer)同时会把自己的peer信息发送给先前的告诉者和自己K桶中的k个最近的节点存储该peer-list信息
不管这里提到的K的最近的节点是离自己最近，还是离资源infohash最近的节点，因为处理announce_peer消息时，有一个token的验证过程。但是这K个节点中，并没有在之前创建对应的token。我通过transmission中的DHT实现做了个数据收集，可以证明的是，announce_peer消息是不仅仅会发给get_peer的回应者的。
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网络
- DHT必须把自己电脑当服务器,别人才能够知道自己是谁,所以需要通过UDP绑定端口。
- DHT需要生成一个自己的20位ID号,当然可以通过随机一个数值,然后通过SHA1来生成20位的ID号.
- 初始化他人服务器的IP信息,这样我们就可以从他们那里查询我们要的信息.
- 对服务器进行PING操作,服务器就会回应PONG操作,这样就表明服务器活动正常.
- 我们需要直接向服务器发送Findnode和Get_Peer操作.
- 接下来的事情就是等待别人返回的信息进行分析就可以了,当然DHT类代码已经全部为我们做好的.
- 接下来就是将上面的操作步骤进行循环.
参考资料
目前个人已经初步搭建了一个小网站SOSOBT.com,也正式增加了对磁力网站的了解。
后面有空继续记录DHT相关的资料。