Peersim kademlia manual - note

1

首先感谢这位在Peersim中实现Kademlia的guy。

 

分析：（以作者的Manul为主，稍加个人评论）

1 作者manual中的sections:

• Section2: 首先简要介绍了kademlia协议，分析了其主要特征和一般功能；

• Section 3: peersim实现kademlia的介绍，分了代码以及为了逼真的实现真实场景时所作出的一些选择；

• Section4: 展现了实际模拟，提供了使用的配置和不同情况下的分析；

• Section5: 给出了模拟结果；

• 总结与展望

2 协议分析部分不再介绍，要有兴趣，参看：

http://blog.csdn.net/jo_say/archive/2011/05/09/6405732.aspx

 

3 实现部分：

作者首先声明了：作者跳过了搜素和存储value的实现，专注于如何寻找节点（所有操作的基础）。

并且采用了：event-driven model。 [peersim提供了ed和cd（周期驱动）两种方式]。

驱动协议的事件大部分是信息交换事件，也附带有一些处理网络中失败节点的超时事件。

 

3.1 消息：

和Peersim关联的事件就是Kademlia中的信息交换。每一个msg在实现中都是Message类的一个实例，这个Message类是在Peersim的SimpleEvent基类上扩展得到的。The messages有：

• MSG_FINDNODE: 这个消息将开始一个寻找结点操作
• MSG_ROUTE: 这个消息将驱使邻居节点查询一个结点
• MSG_RESPONSE: 用来相应MSG_ROUTE消息的消息，它会包含K个到达目标结点的邻近结点。

 

3.2 代码介绍

3.2.1 Bootstrap process：

除了包含在Peersim core中的类WireKOut外，还实现了两个其他的类来提供网络的初始化和Bootstrape： CustomDistribution和StateBuilder.这两个类都集成自Peersim.core.control.

最开始，WireKOut类在节点间随机的建立了一些连接来创建一个虚拟网络覆盖层。

然后，CustomDistribution初始了整个网络：给每一个node分配了私有ID（随机产生于0到2的bits方之间），其中BITS是一个来自Kademlia协议的参数，通常为160，但我们也可以看到，在我们的配置文件中，这个参数是可配置的（系统提供的example.cfg中这个参数为32）.

最后StateBuilder类执行了节点的Bootstrap过程来填充所有初始化节点的k桶。其中，初始化过程针对每一个节点，增加了50个随机节点的IDs和50临近结点的IDs。这个幼稚的过程通过一种简单的方式填充了各种路由表，保证了每一个结点都有邻居结点以及其他分布在网络中的随机结点的相关知识。

3.2.2 寻找一个节点

当接收到MSG_FINDNODE消息时，启动寻找节点进程（通过TrafficGenerator类产生，此类的基类也为peersim.core.control）。

第一步执行的操作时建立一个FindOperation对象，这个对象包含了所有指定搜索操作相关的信息。更具体的讲，就是包含了最近的邻居集以及查找节点的信息以及最好的响应结果。

这个类还包含变量：timestamp和nrHops，分别计算持续时间和操作总跳数。

像前面描述的那样，开始有K个最近邻居点从节点K桶中返回。现在，将要平行查询ALPHA个到目标的最近结点，并发送他们一个MSG_ROUTE消息。当一个包含MSG_RESPONSE类型的响应达到时，那么执行FindOperation操作的那个结点的近邻节点就开始更新，如果还有nodes没有查询到，就会发送一个新的请求。需要注意的一点是：在查询其他节点之前，不需要等待所有ALPHA响应全部到达。

当没有更多可用节点用来查询时或者没有更好的请求时，操作终止。

3.2.3 加入这个网络

流程：创建新结点，分配newID，初始化它的空路由（一个存在的随机结点被添加到它的k桶中），结点查询自己（发送MSG_ROUTE信息到随机bootstrap节点），新节点也执行另外的随机请求来丰富路由表。

 

4 使用此模块进行模拟

Kademlia模块通过一个简单的文本配置文件来自定义：定义整个网络的参数和

不同控制。下文将简要描述模块的不同组件，解释它的特征。

4.1 协议

Kademlia协议通过以下参数自定义：

BITS： ID长度（默认160）

K：k桶的维度（默认20）

ALPHA：并行搜索的数量（默认3）

默认的模块下，依赖两个传输层，它们定义了消息如何在网络中传输：

UniformRandomTransport:可靠地发布消息（带着一个随机延迟，最大值和最小

值也可以在配置文件中定义）；

UnreliableTransport：模拟消息的丢失，基于配置的概率。

 

4.2 控制

模块提供了两个不同的控制类：TrafficGenerator以及Turbolence.

• 其中TrafficGenerator: 产生寻找node信息（从随机源中选择随机ID来搜索）
• Turbolence：通过一个指定的概率，模拟节点的增加或者去除(失败），这个概率可以通过以

下参数配置：

p_idle(默认为0）：当前执行不增不减；

p_add(默认0.5）：一个新节点被添加的概率

p_rem(默认0.5): 导致存在节点失效的概率

 

4.3 观察者

模块还提供了一个观察者（KademliaObserver).这个类是用来收集关于协议行

为的简单策略。它跟踪跳数、时间以发送消息的数量，以及协议中执行

find_node操作的数量。

对应可供修改参数STEP：定义输出频率of stderr.

 

4.4 模块编译

这个模块联合Peersim库，可以使用提供的Makefile文件来编译（在Kademlia文件夹根目录下）。不过，也可以通过执行以下命令进行人工编译：

[1]

java -g / -classpath .:jep-2.3.0.jar:djep-1.0.0.jar /'find . -name "*.java"'

[2]

rm -f peersim-1.0.jar 删除老的jar文件

[3]

./make jar

创建一个新的jar发布 of peersim

4.5 运行模拟：

java -Xmx500M -cp /"peersim-1.0.jar:jep-2.3.0.jar:djep-1.0.0.jar" /peersim.Simulator example.cfg

其中参数 -Xmx500M 被用来增加内存到模拟器（500M对于25000个结点足够了）

 

*********这里把Makefile文件内容也写出来，可以对比以下：

 

.PHONY: all clean doc compile

 

LIB_JARS=`find -L lib/ -name "*.jar" | tr [:space:] :`

 

compile:

    mkdir -p classes

    javac -sourcepath src -classpath $(LIB_JARS) -d classes `find -L -name "*.java"`

 

doc:

    mkdir -p doc

    javadoc -sourcepath src -classpath $(LIB_JARS) -d doc peersim.kademlia

 

run:

    java -Xmx500m -cp $(LIB_JARS):classes peersim.Simulator example.cfg

 

all: compile doc run

 

clean:

    rm -fr classes doc

************

 

5 结果：

我们提供一些使用Kademlia模块的模拟结果，我们分析了进行搜索操作的性能分析，改变了网络大小和分析了有波动

时的行为。更具体点，我们报告了每个操作中的平均信息交换数量，以及平均操作时长。在Kademlia paper中，提出

了一个定性值，关于期望的执行时间对于多数搜索操作是：[log n]+c ,c是一个小常量。

In the graphs, apart from the obtained values, 同样指出了理论性能以及关于画图时使用的常量c的实际值。

 

5.1 模拟参数

我们选择了一个可靠地频道（通过制定unreliableTransport with drop=0 以及 uniformRandomTransport with 100

ms path delay) 作为网络模型，为了模拟面向TCP类似协议的连接。

 

我们做了网络大小在128到65536之间的模拟，doubling the number of nodes at each round （?). A round持续1

小时（总模拟时间）。搜索请求的数量依赖节点的数量。在模拟实践中，平均来讲，每个结点开始了一个相同数量的 查询操作。具体来讲，在案例example文件中：traffic step is:

TRAFFIC_STEP (SIM_TIME)/SIZE

相当于每个节点1次find操作。

The turbolence步骤配置：5% ，模拟中结点掉线的概率。

 

5.2 稳定环境中的结点搜索性能

[1] 没有扰乱时 in absence of churn的消息数目:

图2 描绘了每个搜索对应的消息数目（在没有扰乱的情况下通过不同网络大小比较）。

[2] 没有扰乱时 in absence of churn的延迟时间:

【作者的图中title可能存在错误，按照大标题这里时没有churn的。】图3给出了理论值与模拟值的延迟的对比。可见，两者还是比较相似（尤其是node比较多的时候），因为Kademlia本身就是针对于百万级节点的网络的。

 

5.3 有扰乱时的搜索性能

和图3类似，但是加上了 Turbulance控制，其被配置为同样的增加和丢失概率。Idle概率被设置为0.

作者认为：图4基本上和图3一致（从数字上看， 我感觉还是有一定区别的），可见Kademlia对churn的支持还是不错的，事实上性能也只是有一点点差而已。

 

6 总结：

本文做的事就不说了，即使上面的了。说说作者的未来工作：

由于当前模块的简易，未来工作的方向用来完善module本身，增加存储和搜索处理过程，以及一些文章中描述的优化措施。另外的兴趣就是，开发一个新的turbulence类来考虑决定哪个结点被关闭的时间。有了这样的新模型，就可能针对Kademlia和其他DHT协议进行不均匀结点失败情况下的对比。