CN100433675C - 完全分布式测量协同问题解决方法 - Google Patents

Abstract

本发明涉及计算机和通信网络中的测量技术领域，特别涉及一种完全分布式测量协同问题的解决方法。包括步骤：产生测量任务的请求节点向协同节点发送第一类测量请求消息；协同节点根据当前状态决定发送否定应答还是保持沉默；如果请求节点超时，则根据当前状态进行下列3类操作中的一种：(1)向协同节点发送第二类测量请求消息；(2)进行环检测；(3)保持沉默；收到第二类测量请求消息的协同节点根据当前状态决定发送否定应答还是肯定应答；接收到肯定应答的请求节点进入测量状态，并开始测量。本发明在网络测量系统上实现了互斥测量协同的能力。现有的网络测量系统均不支持测量协同和测量任务的互斥执行。该方法具有良好的处理冲突任务的能力，使得在任务并发性较强时仍然具有较好的任务执行能力。

Description

完全分布式测量协同问题解决方法

技术领域

本发明涉及计算机和通信网络中的测量技术领域，特别涉及一种完全分布式测量协同问题的解决方法。

背景技术

近几年来，Internet发展速度之快已远远超出了人们的想象。由于Internet的庞大和复杂，采用单一的测量工具在某一个或少量地点已经无法对Internet进行测量，因此国内外许多研究机构研发了能够针对Internet进行大规模测量的网络测量系统。

目前的网络测量系统多为分布式系统，它所包含的节点按照功能不同一般可以划分为三类：控制节点、测量节点和被测节点。其中控制节点负责测量命令的发布和测量结果的回收，测量节点和被测节点协作完成测量命令的执行。测量的一个关键问题是测量结果的精确性。如果一个测量节点同时执行了多个测量，那么这些测量所产生的流量会在网络中相互干扰，从而影响了测量结果的精确度；另一方面，如果测量进程不是运行在系统的内核级，操作系统在调度多个测量进程的过程中，可能会造成测量时间戳记录不准确；同时，有人建议块传输能力的测量应该在一个干净的网络环境中。

综合考虑上面两个方面，则引入了新的问题。如果把测量看成任务，那么一次大规模测量的过程可以看作分布式节点协作完成一系列不断产生的任务。限定测量的互斥进行相当于任意时刻某个节点只能为一个任务服务。节点执行测量进程需要受到自己和其它节点多方面的影响，因此会引起任务冲突、进程死锁等一系列问题，我们称之为测量协同问题(MCP)。

发明内容

本发明的目的是为网络测量系统提供互斥测量协同的能力。而提供一种完全分布式测量协同问题解决方法，为实现该目的，完全分布式的测量协同问题解决方法包括步骤：

●产生测量任务的请求节点向协助执行该任务的协同节点发送第一类测量请求消息；

●如果协同节点不能接受新的请求，则发送否定应答，否则保持沉默；

●如果请求节点超时，则根据当前状态进行下列3类操作中的一种：

(1)如果请求节点处于等待状态2，则向协同节点发送第二类测量请求消息，表明请求节点没有接收到其它请求；所述等待状态2表示该节点刚刚发送了Req消息的状态；

(2)如果请求节点处于等待状态4，且定时器超时，且只有一个节点向请求节点发送请求消息，则发送环检测消息；所述等待状态4表示该节点发送了Req消息后，接收到了来自其它节点Req消息的状态；

(3)所有其它状态，请求节点保持沉默；

●收到第二类测量请求消息的协同节点如果处于等待状态2或等待状态4状态，则发送肯定应答，否则发送否定应答；

●接收到肯定应答的请求节点进入测量状态，并开始和协同节点一起开始进行测量。

使用了两类测量请求消息，节点只有发送了第一类测量请求消息后才能够发送第二类测量请求消息，且肯定应答消息只针对第二类测量请求消息。

不但第一类测量请求消息的接收者可以对该消息作否定应答，而且该消息的发送者也可以对该消息做否定应答。

肯定应答消息只能由协同节点发送并作为对第二类测量请求消息的应答。

节点处于等待状态1和等待状态4时，在定时器没有超时的情况下仍然可以接收第一类测量请求消息；所述等待状态1表示该节点接收了来自其它节点Req消息的状态。

只有当节点有可能在孤立环上的时候，即请求节点处于等待状态4，且定时器超时，且只有一个节点向请求节点发送请求消息，才进行孤立有向环检测。

附图说明

图1节点的状态转移示意图；

图2是多个节点所构成的测量请求图；

图3有向环检测和拆除中的状态转移示意图；

图4是多个节点的测量系统和测量协同示意图；

图5是测量协同过程的消息传递时间序列示意图；

具体实施方式

本部分首先详细描述完全分布式测量协同问题解决方法，具体包括：节点间传递的消息、节点状态、节点的数据结构、节点的处理过程、有向环的检测和拆除方法。然后结合附图用一个实际例子说明该方法的处理过程。首先给出一些必要的定义：

定义1：节点

节点是实现一种或多种通信协议的设备，节点可以使用通信协议和其他实现相同通信协议的设备进行通信，从而达到信息交换的目的。例如：计算机、网络测试仪等。

定义2：测量任务

测量任务可以表示为(s，r，t)的三元组，其中s代表测量节点，r为被测节点，t是该任务产生的时刻。

节点间传递的消息

Req    请求消息。用来请求另一个节点一起完成测量。由于测量请求不一定得到满足，定义Req消息的发送方和接收方为测量节点和被测节点是不恰当的。我们称Req消息的发送节点为请求节点，接收节点为协同节点。

Req2    二次请求消息。请求节点使用该消息表明没有额外的节点向自己申请测量。只有发送过Req消息后才能发送Req2消息。

Rst     重置消息。该消息可以由请求节点发送，表明撤销测量请求；也可以由协同节点发送，表明拒绝接受已经收到的Req或Req2消息。

Ack     肯定应答消息。该消息只能由协同节点发送，表示接受已经收到的Req2消息。

Ld      环检测消息。当节点满足环检测条件时，向自己的请求节点报告自己所知道的拓扑信息。因此Ld消息按照逆环方向传送。

由于Req2消息只能在发送了Req消息后才能够发送，因此作为对Req2应答的Ack和Rst消息，相当于应答了Req2消息之前发送的Req消息。消息传递存在时间上限T_trans，任务执行时间存在上限T_exec。

节点状态

idle     空闲状态。表示节点没有执行测量任务，也没有和其它节点进行协商。

busy     繁忙状态。表示节点正在执行测量任务。

wait1    等待状态1。表示该节点接收了来自其它节点的Req消息。

wait2    等待状态2。表示该节点刚刚发送了Req消息。

wait3    等待状态3。表示该节点判定没有其它节点向自己请求测量。

wait4    等待状态4。表示该节点发送了Req消息后，接收到了来自其它节点的Req消息。

节点的数据结构

State       单个变量。存放节点的当前状态(即idle，busy，wait1～wait4)。

Requests    数组。存放节点收到且未应答的Req消息。

Collaborator单个变量。存放节点发送Req消息的目的节点编号。

Priority    单个变量。保存环检测中已发现节点的最大优先级。

Distance    单个变量。环检测中具有最大优先级的节点和发现的最新节点之间的距离(以跳数为单位)。

Nodes       数组。存放节点所知道但尚未报告的拓扑信息。(节点编号)节点的处理过程

1)公共操作

基本操作：节点使用State变量记录它的当前状态。节点发送Req消息时，把该消息发往的节点编号记录在Collaborator变量和Nodes数组的第一个变量中。节点接收到Req消息时，如果没有立即回复Rst消息，就会先把该消息放入Requests数组。

错误处理：如果节点处于某个状态时接收到了下面没有定义的消息，则按照下面的规则处理：如果消息类型是Req或Req2，则应答Rst消息；如果消息类型是Ld，Ack或Rst消息，则保持沉默。错误处理过程中节点的状态不发生改变。

2)busy状态的操作

节点拒绝来自其它任何节点的任何消息。当任务执行完成后，节点自动回到idle状态。

3)idle状态的操作

可以向其它任何节点发送Req消息，启动超时时间为T_trans的定时器，进入状态wait2；

可以接受来自其它任何节点的Req消息，启动超时时间为T_trans-T_send的定时器，进入wait1状态。其中T_send指Req消息的发送时刻。

4)wait1状态的操作

节点只能在定时器没有超时的情况下接收Req消息，超时后接收到的Req消息按错误处理。没有超时的情况下接收Req消息的动作参见公共操作中的说明；

接收Rst消息时，从Requests数组中删除对应的Req消息，如果删除后数组为空，则进入idle状态；

接收到Req2消息时，如果Requests数组中包含了该消息的发送节点曾经发送的Req消息，则应答Ack消息，并对Requests数组中的其它所有Req消息应答Rst消息，最后清空Requests数组，进入busy状态。

5)wait2状态的操作

如果接收到来自Collaborator节点的Rst消息，则进入idle状态；

如果接收到来自其它节点的Req消息，则进入wait4状态；

如果定时器超时，则向Collaborator节点发送Req2消息，进入wait3状态。

6)wait3状态的操作

如果接收到来自Collaborator节点的Rst消息，则进入状态idle；

如果接收到来自Collaborator节点的Ack消息，则进入busy状态。

7)wait4状态的操作

节点只能在定时器没有超时的情况下接收Req消息，超时后接收到的Req消息按错误处理。没有超时的情况下接收Req消息的动作参见公共操作中的说明；

接收Rst消息时，如果Rst消息来自Collaborator节点，则进入wait1状态；如果该消息和Requests数组中的某个Req消息匹配，则把该消息从数组中删除，如果删除后数组为空，则向Collaborator节点发送Req2消息并进入wait3状态；

接收Req2消息时，如果Requests数组中包含了该消息的发送节点曾经发送的Req消息，则应答Ack消息，并对dest节点和Requests数组中的所有其它节点发送Rst消息，最后清空Requests数组，进入busy状态；

如果定时器超时，则节点执行有向环检测和拆除操作(参见0节)。

8)接收Ld消息的操作

参见有向环的检测和拆除。

图1给出了节点的状态转移示意图。该图为携带动作的有限状态机，其中问号“？”表示发送，感叹号“！”表示接收。动作(如果有)和转移条件之间使用斜线“/”分割开。处理过程中的许多细节，如wait1和wait4状态的超时、有向环的检测和拆除以及不发生状态转移的条件等都没有在图上表现出来。该图给出了节点之间大致的处理流程。

有向环的检测和拆除

定义3：测量请求图

测量请求图G＝(V，E)是一个有向图。其中V代表系统中的节点集合，

，即系统中的每个测量请求对应G中的一条有向边。

图2给出了一个测量请求图，图中节点1请求和节点3进行测量，节点2请求和节点3进行测量，节点3请求和节点4进行测量，节点4请求和节点5进行测量，节点5请求和节点6进行测量，节点6请求和节点4进行测量。

如果某个时刻系统对应的测量请求图存在有向环，则环上节点的Requests数组均不为空，不会有节点主动发送Req2消息，系统可能存在死锁。如果该环所在的连通子图包含其它节点，那么不在环上的节点有可能给环上的节点发送Req2消息，从而引起有向环的拆除。即有向环不一定会引起死锁，只有孤立的有向环才会引起死锁。因此只需要检测孤立的有向环。如果节点处于孤立的有向环上，则节点的入度为1，即Requests数组中恰好只包含一个Req消息，令该消息的发送者为Superior。按照节点的处理过程，在进行有向环检测时，节点处于wait4状态，且定时器已经超时。

定义4：孤立有向环检测条件

如果节点处于wait4状态，定时器超时，且Requests数组长度为1，则称该节点满足孤立有向环检测条件。

完整的有向环检测和拆除操作如下：

1)Ld消息的发送

如果节点满足孤立有向环检测条件，且Nodes数组长度大于0，则

●节点比较Nodes数组中的成员和自己，根据定义更新Priority和Distance变量；

●节点构造Ld消息，消息体中携带Nodes数组；

●该节点把构造好的Ld消息报告给Superior节点，并清空Nodes数组。

2)Ld消息的接收

节点处于wait2或wait4状态时可以接收Ld消息。(其它状态也不可能接收到Ld消息)

●节点首先把Ld消息中携带的数组放到Nodes数组中的尾部；

●如果在Nodes数组中发现了自己，则说明发现了有向环。节点更新计算Priority和Distance变量，并执行拆环操作；

●如果节点满足孤立有向环检测条件，则进行Ld消息的发送操作(参见Ld消息发送)。

3)拆环操作

考虑到协同节点的Ld消息中发现自己的节点。如果该节点的Requests数组中元素数目大于1，则该节点从未发送过Ld消息。也就是说，只有该节点自己知道存在有向环。设该节点为a₀，环上的其他节点分别为a₁，…，a_n-1，环的方向沿节点下标从小到大。根据a₀的最终状态不同，拆环可以分为下面两种情况：

如果a₀不在环上的请求节点向a₀发送Req2消息，那么根据节点处理过程，a₀应答Ack并向所有其它邻居节点(包括a₁和a_n-1)发送Rst消息，该有向环被拆除；

如果上述节点均向a₀发送Rst消息，则该有向环成为孤立有向环，由于环上节点中只有a₀知道该环的存在，因此拆环工作由a₀来完成。此时a₀向a₁发送Req2消息，向a_n-1发送Rst消息，并进入wait3状态，从而孤立有向环被拆除。

如果a₀的Requests数组中元素数目等于1，由于只有满足有向环检测的节点才发送Ld消息，因此a₀，...，a_n-1构成了孤立有向环。另外，有可能多个节点均检测到了有向环，这时多个节点必须有全局一致的拆环动作。在这种情况下，设P是节点的权值函数，且不同节点的权值不同，那么从权值最大的节点开始拆环。即如果P(a_i)＝max{P(a_k)|0≤k≤n-1}，那么所有检测到环的节点一致同意a_i和

进行组合，其中

为模n加法，并沿环的方向依次匹配。为了加快拆环速度，所有检测到孤立有向环的节点可以进行拆环。节点a_k根据自己的判断可能有以下三种动作：

如果a_k判断自己应该和进行测量协同，则向

发送Req2消息，向

发送Rst消息，并进入wait3状态；

如果a_k判断自己应该和进行测量协同，则向

发送Rst消息；等待

发来的Req2消息；

如果a_k判断没有节点和自己测量协同，必然有

a_k向a_i和

发送Rst消息，并进入idle状态。

节点在有向环检测和拆除过程中的状态转移如图3所示。与图1相比，图3增加了从wait4直接到idle的转移，wait4到wait1和wait3的转移条件也有了扩充。增加了这些以后，只有节点在wait4时的状态转移发生了影响，节点当且仅当进入wait3才伴随发送Req2消息的性质依然保持。

从节点的拆环动作可以看出：节点只使用了环检测中已发现节点的最大优先级Priority和具有最大优先级的节点和发现的最新节点之间的距离Distance作为拆环的依据，因此节点无须存储所有拓扑信息就可以有全局一致的拆环动作。

下面将结合附图用一个实际例子说明该方法的处理过程。

图4是一个包括6个节点的测量系统。图中每个节点均向其他节点发送了测量请求。图5为处理过程的消息传递时间序列示意图。其中竖实线代表时间轴，越靠下说明时间越晚，时间轴上面的节点编号代表该时间轴刻划该节点的事件。不同时间轴的刻度和起点相同，即如果用一个水平线和时间轴相交，那么不同的交点代表相同的时刻。时间轴之间的带箭头线段代表消息的传递：线段从某个时间轴开始，到另一个时间轴终止，起点所在的时间轴对应的节点代表消息的发送方，起点对应消息的发送时刻；终点所在的时间轴对应的节点代表消息的接收方，终点对应接收时刻。下面对该过程作详细解释：

步骤1，t₀时刻，所有节点处于状态idle。

步骤2，t₁时刻，节点1产生测量任务(1，3，t₁)，并向节点3发送Req消息，切换到状态wait2。

步骤3，t₂时刻，节点3产生测量任务(3，4，t₂)，并向节点4发送Req消息，切换到状态wait2。

步骤4，t₃时刻，节点6产生测量任务(6，4，t₃)，并向节点4发送Req消息，切换到状态wait2。

步骤5，t₄时刻，节点4产生测量任务(4，5，t₄)，并向节点5发送Req消息，切换到状态wait2。

步骤6，t₅时刻，节点2产生测量任务(2，3，t₅)，并向节点3发送Req消息，切换到状态wait2。

步骤7，t₆时刻，节点3收到节点1发来的Req消息，切换到状态wait4。

步骤8，t₇时刻，节点5产生测量任务(5，6，t₇)，并向节点6发送Req消息，切换到状态wait2。

步骤9，t₈时刻，节点4收到节点3发来的Req消息，切换到状态wait4。

步骤10，t₉时刻，节点4收到节点6发来的Req消息。

步骤11，t₁₀时刻，节点5收到节点4发来的Req消息，切换到状态wait4。

步骤12，t₁₁时刻，节点3收到节点2发来的Req消息。

步骤13，t₁₂时刻，节点6收到节点5发来的Req消息，切换到状态wait4。

步骤14，t₁₃时刻，节点1超时，向节点3发送Req2消息，切换到状态wait3。

步骤15，t₁₄时刻，节点6超时，向节点5发送环检测消息。

步骤16，t₁₅时刻，节点2超时，向节点3发送Req2消息，切换到状态wait3。

步骤17，t₁₆时刻，节点3收到节点1发来的Req2消息，切换到状态busy，并向节点1发送Ack消息，向节点2和节点4发送Rst消息。

步骤18，t₁₇时刻，节点5超时，向节点4发送环检测消息。

步骤19，t₁₈时刻，节点5收到节点6发来的环检测消息，更新自己相应的变量，并向再次节点4发送环检测消息。

步骤20，t₁₉时刻，节点3收到节点2发来的Req2消息，由于节点3此时处于busy状态，因此向节点2发送Rst消息。

步骤21，t₂₀时刻，节点4收到节点3发来的Rst消息，节点4判断自己满足环检测条件，因此向节点6发送环检测消息。

步骤22，t₂₁时刻，节点1收到节点3发来的Ack消息，进入busy状态。

步骤23，t₂₂时刻，节点4收到节点5首次发来的环检测消息，更新自己相应的变量，并向节点6再次发送环检测消息。

步骤24，t₂₃时刻，节点2收到节点3发来的Rst消息，从wait3状态进入idle状态。

步骤25，t₂₄时刻，节点4收到节点5第二次发来的环检测消息，更新自己相应的变量，发现环存在。由于节点6是环上权值最大的节点，因此节点4按照规则向节点5发送Rst消息，进入wait1状态。

步骤26，t₂₅时刻，节点6收到节点4首次发来的环检测消息，更新自己相应的变量，并向节点5再次发送环检测消息。

步骤27，t₂₆时刻，节点2收到节点3发来的Rst消息，由于节点2处于idle状态，因此节点2忽略该Rst消息。

步骤28，t₂₇时刻，节点6收到节点4第二次发来的环检测消息，更新自己相应的变量，发现环存在。由于自己是环上权值最大的节点，因此节点6按照规则向节点5发送Rst消息，向节点4发送Req2消息，进入wait3状态。

步骤29，t₂₈时刻，节点5收到节点4发来的Rst消息，按照规则，节点5切换到wait3状态，并向节点6发出Req2消息。

步骤30，t₂₉时刻，节点5收到节点6第二次发来的环检测消息，由于节点5此时处于wait3状态，因此节点5忽略该消息。

步骤31，t₃₀时刻，节点4收到节点6发来的Req2消息，切换到状态busy，并向节点6发送Ack消息。

步骤32，t₃₁时刻，节点6收到节点5发来的Req2消息，由于节点6处于wait3状态，因此节点6向节点5发送Rst消息。

步骤33，t₃₂时刻，节点6收到节点4发来的Ack消息，进入busy状态。

步骤34，t₃₃时刻，节点5收到节点6发来的Ack消息，进入idle状态。

本发明在网络测量系统上实现了互斥测量协同的能力。现有的网络测量系统均不支持测量协同和测量任务的互斥执行。该方法具有良好的处理冲突任务的能力，使得在任务并发性较强时仍然具有较好的任务执行能力。

Claims (6)

1.一种完全分布式的测量协同问题解决方法，其特征在于，该方法包括以下步骤：

●产生测量任务的请求节点向协助执行该任务的协同节点发送第一类测量请求消息；

●如果协同节点不能接受新的请求，则发送否定应答，否则保持沉默；

●如果请求节点超时，则根据当前状态进行下列3类操作中的一种：

(1)如果请求节点处于等待状态2，则向协同节点发送第二类测量请求消息，表明请求节点没有接收到其它请求；所述等待状态2表示该节点刚刚发送了Req消息的状态；

(2)如果请求节点处于等待状态4，且定时器超时，且只有一个节点向请求节点发送请求消息，则发送环检测消息；所述等待状态4表示该节点发送了Req消息后，接收到了来自其它节点Req消息的状态；

(3)所有其它状态，请求节点保持沉默；

●收到第二类测量请求消息的协同节点如果处于等待状态2或等待状态4状态，则发送肯定应答，否则发送否定应答；

●接收到肯定应答的请求节点进入测量状态，并开始和协同节点一起开始进行测量。

2.根据权利要求1所述的方法，其特征在于，使用了两类测量请求消息，节点只有发送了第一类测量请求消息后才能够发送第二类测量请求消息，且肯定应答消息只针对第二类测量请求消息。

3.根据权利要求1所述的方法，其特征在于，不但第一类测量请求消息的接收者可以对该消息作否定应答，而且该消息的发送者也可以对该消息做否定应答。

4.根据权利要求1所述的方法，其特征在于，肯定应答消息只能由协同节点发送并作为对第二类测量请求消息的应答。

5.根据权利要求1所述的方法，其特征在于，节点处于等待状态1和等待状态4时，在定时器没有超时的情况下仍然可以接收第一类测量请求消息；所述等待状态1表示该节点接收了来自其它节点Req消息的状态。

6.根据权利要求1所述的方法，其特征在于，只有当节点有可能在孤立环上的时候，即请求节点处于等待状态4，且定时器超时，且只有一个节点向请求节点发送请求消息，才进行孤立有向环检测。

Images