一个基于超级节点覆盖拓扑的健壮协议----实验分析.pptVIP

A Robust Protocol for BuildingSuperpeer Overlay Topologies（建立在超级节点覆盖拓扑之上的健壮协议） 实验结果及总结 实验 实验 所有图都是使用20次独立的实验绘制的。所有参数都是固定的：网络规模是100000节点，最大容量是500；newcast中使用的局部视图s的大小是30。这些值都可以适用于现实情况， 实验结果 图4展示随着时间的推移算法的执行情况。初始化配置下，我们选择一个与目标拓扑差距最大的情况：一个随机的拓扑结构，所有的节点都充当超级节点，任何一个都不负责任何客户节点。需要几个周期达到目标拓扑结构（最坏55），已经是相当快的速度了。不考虑分布情况：在至少15周期后，实验结果的拓扑结构已经与目标拓扑非常相近了。 实验结果 实验结果 图6和7显示通过NEWCAST交换的最大容量Cmax和局部视图s的信息是如何影响算法的性能的。 在两种情况下，结果都达到了预期效果。容量越大，目标拓扑结果所包含的超级节点越少，算法达到这样的拓扑结构所需要的周期数就越大。另一方面，用于随机选择的节点样本越大，就会有更好的性能，但是需要更大的通信开销。 实验结果 算法总的通信消耗通过系统多层交换的信息数量总和给出。NEWCAST管理的三个集合，继承了协议良好的属性。在NEWCAST中，每个节点每周期交换量可以通过随机变量1+ ф， ф为参数为1的泊松分布。因此，平均的，每个节点有两个交换（一个是初始的一个来自另一节点），这两个差异很小。这意味着这些层都是民主的（公平），所有节点每轮需要收发成百比特的数据。 第四个，client集合，只由超级节点管理。考虑到两方面的通信消耗：在RandomPeer方法中发送的探针总数；执行转移的客户节点的总数。图8展示了不同规模网络的耗费情况。 图表展示每个节点平均只有两个探针发送，然而每个客户节点转移了约9次。后者可被认为是一个相对高的值，总的来说，耗费主要与转移相关。 实验结果 为了完成通信消耗的评估，我们测量出在一个周期中一个超级节点完成操作的最大量，以容量区分相应的节点。图9证明了没有任何一个结点因为通信消耗而超载。 实验结果 最后的图展示了协议的鲁棒性。图10表示一个灾难性情况：第30周期，50%的超级节点被移除。在初始化阶段后当所有的客户端的超级节点崩溃了而自己成为了超级节点，协议表现的还跟正常一样，从剩下的节点中选择新的超级节点修复覆盖拓扑。 实验结果 算法已经运行了几周期了，每一轮替代一定百分比的节点，产生了一个摆动的超级节点数。 为了完成通信消耗的评估，我们测量出在一个单轮中一个超级节点完成操作的最大数量，除以相应的节点的容量。图9证明了没有任何一个结点因为通信消耗而超载。 图7显示了加入和稳定化的伪代码，它取代图6来处理并发加入的情况。 //?n加入网络，只设置自己的后继，简单?? n.join(n’)?? ???predecessor?=?nil;?? ???successor?=?n’.find_successor(n);?//?RPC?? //?周期性检查后继，告诉后继自己的存在?? n.stabilize()?? ???x?=?successor.predecessor;?//?RPC查询?? ???if(x?IN?(n,?successor))?? ??????successor?=?x;?? ???successor.notify(n);?//?RPC???? //?n’认为它应该是n的predecessor n.notify(n’)??? ???if(predecessor?IS?nil?OR?n’?IN?(predecessor,?n))?? ??????predecessor?=?n’;?? ????? //?周期性的刷新finger?table?? n.fix_fingers()?? ???//?finger_t[1].node就是后继，不需要在这里刷新?? ???i=random?index??1?IN?finger?tables;?? ???finger_t[i].node?=?find_successor(finger_t[i].start);? 一个简单的例子，假设节点n加入系统，并且ID在np和ns之间，n将会选择ns作为它的后继。节点ns在收到n的通知时将会把前驱指针更新为n。接下来当np运行stabilization时，它将向ns询问它的前驱结点（现在是n），【注：np并不知道n的加入，所以它的后继指针仍然指向ns】np将会选择n作为后继。最终np将会通知n，并且n将会选择np作为它的前驱。到此为止，所有前趋和后继指针都正确了。 定理4 一旦一个节点可以成功的解决一次查询，那么它以后也都