CN1914609A - 分布式计算机系统 - Google Patents

Abstract

一种分布式计算机系统，具有存储数据项目的计算机，各个数据项目被分配给多个虚拟目录之一。各个计算机具有至少一个用于目录查找的虚拟网(10)的节点，所述节点具有包括与同一虚拟目录相关联的其它节点的地址的链接数据和软件，该软件响应于查询消息，依据该节点是否与查询消息中指定的目录相关，要么进行识别它自己的回复，要么将该消息转发到网络(10)的另一个节点。类似地，各个计算机对于它存储的各个项目，具有用于项目查找的虚拟网的节点，该节点具有包括与分配给同一虚拟目录的项目相关的其它这样的节点的地址的链接数据，从而这些链接数据一起定义了多个用于项目查找的多个虚拟网，各个虚拟网对应于各个不同的虚拟目录。该节点还具有软件，该软件响应于查询消息，依据该节点是否与查询消息中指定的项目相关联，要么用所寻找的项目进行回复(或者为了之后的项目检索，识别它自己)，要么将该消息转送到网络的另一个节点。介绍了用在本系统中的，或者独立使用的，借助与同一目录名(或其它标签)匹配的多个节点的地址(25)的检索机制。与给定标签(21a)匹配的各个节点具有用于包含该标签的与其相关联的数据存储区域，并且可响应于查询消息返回与同一标签匹配的其它节点的地址的列表。第一检索装置响应于标签的输入而识别与该标签匹配的节点的地址，而第二检索装置然后向第一检索装置识别的地址发送查询消息并且在接收到响应的时候，向具有包含在针对该查询消息的响应中的地址的节点迭代地发送其它的查询消息，或者或视情况向针对后续查询消息的响应中包含的地址发送查询消息。

Description

分布式计算机系统

技术领域

本发明涉及计算机网络，并且特别地，但非排它地，涉及诸如对等系统的分布式系统环境下，尤其是非集中式存储或控制的分布式系统环境下的信息检索。

在权利要求书中定义了本发明的各个方面。

附图说明

现在将参照附图借助示例介绍本发明的一些实施例，其中：

图1是本发明的一个实施例中使用的计算机的框图；

图1A是说明图1的计算机的操作的流程图；

图2是示出了虚拟网的节点之间的链接的示意图；

图2到16是更加详细地解释该系统的操作的其它流程图；

图17是示出了分配给目录和文件的节点的示意图；和

图18到20是其它流程图。

具体实施方式

节点

在本说明书中，将对具有处理、存储和通信能力的运算节点进行说明。运算节点可以是计算机或其它装置，或者是计算机上运行的独立程序或处理(注意单个计算机可以具有多个这样的程序或处理)。存储的数据的项目也可以看作是特殊的节点，即使多个这样的项目可以由单个程序或处理来加以维护。

本说明书假设各个运算节点与某种通信基础设施相连，从而可以将消息发送给它，该通信基础设施可以例如是诸如IP(网际协议)网络之类的电信网络。这样，各个运算节点还构成了通信基础设施内的节点。

还将对属于虚拟网的虚拟节点进行说明。区别是很重要的，因为运算节点能够使两个或更多个虚拟节点(可能属于不同的虚拟网)与其相关联。顾名思义，虚拟节点从物理层面上讲并不存在：而是，如马上会变得更加明晰的，它的存在是由定义了虚拟节点之间的链接(因此，还定义了它所属的虚拟网)的存储数据建立的。

必然地，虚拟节点必须与运算节点相联合，运算节点为其提供处理、存储和通信能力：提到由虚拟节点进行的消息的发送、接收和处理就是指由运算节点代表虚拟节点进行的这种发送、接收或处理。

图1中给出了一个示例。计算机具有通常的组成部分，即，处理器1、存储器2、显示器3、键盘4和用于通过网络10进行通信的通信接口5。

存储器2包含操作系统和其它程序(未示出)以及诸如所示的文本文件20这样的数据文件。它还具有存储区域21，存储区域21包含与文本文件20相对应的标签21a及其自身的地址21b。此外，它具有地址列表22和支持程序23，它们一起在计算机上定义了虚拟网的节点的存在。这个节点具有地址24。还示出了地址列表25和支持程序26，它们一起在计算机上定义了另一个虚拟网的节点的存在。这个节点具有地址27。存储在列表22、25中的地址是同一虚拟网中的其它节点的地址。

查询系统

我们现在将介绍分布式查询系统，不过这仅仅是本发明的应用的一种可行的示例而已。该系统使用户能够将评论与网页联系起来。在用户访问这个网页时，他还具有查看其它用户做出的评论的机会。评论存储在作出该评论的用户的计算机上(例如，存储为文本文件)。

查看网页的用户(更加确切地说，他的计算机)具有该网页的全球资源定位器(URL)，并且所需要的是一种机制，借助这种机制，他能够检索这些评论。在这个示例中，该机制是这样的：

将文本文件存储在作出评论的用户的计算机上，并且使其与在我们的国际专利申请WO03/034669[代理人案号A30044]中介绍的那种类型的虚拟网的节点关联起来，该文本文件也可以是包含与其它网页相关的评论的其它文本文件，并且也有可能是其它不相关的文件。该虚拟网(在本说明书的上下文中称为主虚拟网，或者简称为主网络)用来使人们能够在不知道节点地址的情况下向该节点发送消息，只要其具有标识该节点的标签即可。虽然这种类型的网络能够利用唯一的标签(每节点一个)运作，但是在这个示例中这些标签不是唯一的：而是，与包含与特定网页有关的评论的文本文件相关联的所有节点都具有相同的标签。这个标签是网页的URL的哈希(hash)函数。该虚拟网给出了仅仅到达一个节点的检索机制。

该文本文件还与第二虚拟网的节点相关联。该第二虚拟网(辅虚拟网)仅仅包含与包含关于该个特定网页的评论的文本文件相关联的节点。

不过，请注意，虽然按照我们前面提到的国际专利申请，使用主网络是优选的，但并不是必须的。实际上，根本不必使用虚拟网；取而代之，可以使用接收标签并且返回与所述标签相应的一个节点的地址的其他主检索机制。

发布评论的计算机是如图1中所示的计算机并且必须

●在主网络中创建节点。这个节点具有标签21a和网络地址24。

●在辅网络中创建节点。这个节点具有网络地址27。

最开始，地址列表22、25是空的，但列表22包含引导链接。稍后将会介绍用于确保列表22包含主网络的某些其它节点的标签和地址并且确保列表25包含辅网络的某些其它节点的地址而进行的网络自组织。目前，在假设这些标签和地址都存在的基础上介绍该系统。

这里与地址有关的少数词是按顺序的。由文本文件20形成的节点、主虚拟网的节点和辅虚拟网的节点，虽然在概念上具有单个本体，但是具有它们自己的地址。在通信网络10中为各个节点分配独特地址是可以的，但在实践中这并不是特别方便。按照我们的优选实施方式，各个节点具有由下述三部分组成的地址：

●因特网地址，该因特网地址“定位”运算节点。例如，130.146.209.15

●端口号，该端口号定位运算节点上的具体通信端口。端口是因特网地址的标准部分。它们例如使不同的独立的应用程序能够独立地发送和接收消息。即，各自接收其自己端口上的消息，而不会接收打算送给其它应用程序的消息或者受到这样的消息的“骚扰”。可以将因特网地址与端口号一起看作网络地址(因为它是所使用的通信协议(比如TCP/IP)的一部分)。对于所有的主节点和辅节点，网络地址可以是相同的，不过，并非必须如此。例如，可以在与接收辅消息的端口不同的端口上接收主节点的所有消息(这是区分这些消息的一种方法)。

●节点标识符(整数值)，该节点标识符定位消息所送往的特定节点，例如，即使主网络上的所有消息都是在专用端口上接收的，仍然存在与各个节点相关联的本地唯一标识符。所以，在有多个节点的时候，很清楚要将消息送往哪个节点。该节点标识符是应用专用地址扩展(不是标准因特网协议的一部分)。它简单地包含在所发出的消息中。接收它的处理“知道”这一点并且将会检查这个节点标识符，以确定应当将消息转送到哪个节点。

两个节点具有相同的网络地址是可行的，但无需如此。不是每个节点都将具有它自己的端口(部分因为可用端口的数量受到一定程度的限制)，但是一个节点有理由可以具有两个端口(并且因此具有两个不同的网络地址)：一个用于主网络，而另一个用于辅网络。典型地，将会有多个辅网络，这些辅网络可以全部使用相同的端口。

应当强调一下，在下文中，提到节点地址就是指该节点的完整地址。

尤其有吸引力的途径是假定文本文件和主辅节点全部具有相同的节点标识符(和IP地址)，只有端口号是不同的。这样的编址协议可以提供简化某些处理的机会，因为，在有了一个节点的地址而又需要与其相关联的另一个节点的地址的情况下，后一个节点的地址可以由前一个节点的地址推断出来，而不用去查询。不过，在下面的介绍中，没有进行这样的简化，从而这些处理对任何地址协议都是有效的。

查看网页的计算机通过下述过程来检索相关的评论：

●对URL应用相同的哈希函数来获得标签

●在主虚拟网发出查询(包括标签)，以获得一个节点的地址

●使用所找到的地址，在辅虚拟网上发出查询，以获得辅虚拟网上的更多(乃至全部)所有其它节点的地址

●使用这些地址取回评论来进行显示

注意，检索计算机不必必须包含虚拟网的节点；它可以是装有用来实施检索处理的软件的传统计算机，并且配有通信接口，从而它能够与虚拟网的节点所在的计算机进行通信。在图1A的流程图中示出了这一处理，并且是按如下地进行的：

步骤30：在用户输入URL(或调用超级链接)之后，计算机检索相应的网页。这个步骤完全是常规的。

步骤31：对该URL应用哈希函数，以获得标签。如在我们的在先国际专利申请中讨论的那样，这可以使用SHA-1算法。

步骤32：将包含这一标签和该检索计算机的网络地址的‘Find(查找)’消息发送到主网络的节点。显然，该计算机需要拥有至少一个这样的地址。

步骤33：检索计算机从主网络接收到‘Found(所找到的)’消息。这个消息包含已经找到的节点的标签和地址以及辅网络的相关联节点的地址，还有评论的地址。可以引入超时机制，以便如果在合理的时间内没有接收到“Found”消息，则中断该处理。

步骤34：在这个示例中，将主网络设置成，它总是返回具有与包含在Find消息中的标签最接近的标签的节点的标签和地址。所以要进行检查，来看一看所返回的标签是否与所寻找的标签相同，并且如果不是，则处理终止。“最接近”含义的解释见下文。

步骤35：假设标签匹配，则检索计算机执行这样的处理(下文中将详细介绍)：借助该处理，它使用由“Found”消息返回的地址，利用辅网络检索进一步的地址。

步骤36：然后使用这些地址来从“提交”计算机中取回包含评论的文本文件。

辅虚拟网

这个网络的目标是将一组节点自组织成单个虚拟网，随后可以使用该虚拟网来发现作为该组的一部分的所有节点。主要的要求是，所得的网络包含所有的节点。另一个要求是，创建和维持该网络的系统负担要等同地散布在所有节点上。这不仅是最“公平的”(在不同用户将他们的资源贡献给分布式应用的时候“公平”是很重要的)，而且有助于保护系统不致过载。

因此，该网络具有下述属性：

●由各个节点保持的链接数量最好是相同的。

●所有链接都是双向的。结果，对各个节点而言，到节点的链接的数量也是相同的。这是很重要的，因为这会影响节点接收和必须处理的消息的数量。

●它具有“平面”结构。节点并不以分级方式安排自己。结果，系统负担得以等同地分布在所有节点上。

各个节点的结构

各个节点具有下列与其相关联的数据：

●到其它节点的数个链接。各个链接简单地是另一个节点的地址。与各个链接相关的是状态，该状态可以是“已确认”和“未确认”。各个节点仅仅能够保持最大数量的链接，这个最大数量是由系统宽参数L给出的。L的典型值例如是6。这个参数不必对所有节点都相同；但是使它们不同并不会得到什么好处。

●备份链接列表，或者简称为备份。各个备份简单地是另一个节点的地址。自组织处理使用这些备份来建立虚拟网。在节点被通知另外的节点不能加为链接的时候，会将节点加为备份，不能加为链接的原因要么是因为它已经与该节点链接，要么是因为它已经具有了最大数量的链接。节点可以保持的备份数量也是有限的，并且由系统宽参数S给出。S的典型值例如是3。备份链接列表一般来说不是必须的，但是对于提供使不能被本地接纳的链接能够被传播到虚拟网中的某些其它点的附加机制是很有价值的。不过在到来的Notify(通知)消息总是到达辅网络的同一节点(或者非常少量的节点中的一个)的系统中，需要使用备份链路(或者类似的传播机制)。

消息

为了自组织成网络并且发现哪个节点是给定网络的一部分，节点向另一个节点发送消息：辅网络使用下列类型的消息：

●AddLink(添加链接)消息，具有：

●发送方地址

●接收方地址

它由节点(发送方)发送到另一个节点(接收方)来请求相互链接。

●ChangeLink(改变链接)消息，具有：

●发送方地址

●接收方地址

●目标地址

它由节点(X)发送到另一个节点(Y)，以请求Y将它的链接之一(Z)改变为到自己(X)的链接。该协议是这样的：X将会向Z发送类似的消息，请求Z将它到Y的链接改变为到自己(X)的链接。这样，事实上，X请求将自己插入到当前介于Y和Z之间的链接中。

●LinkAdded(链接已添加)消息，具有：

●发送方地址

●接收方地址

它用于通知节点：发送方刚刚增加了到它的链接。

●LinkError(链接差错)消息，具有

●发送方地址

●接收方地址

●目标地址

●错误代码

它用于通知节点它的链接之一看起来有问题了。例如，目标节点可能没有响应，或者链接可能不是相互的。它包括错误代码，用来指明错误的类型。

●Links(全部链接)消息，具有：

●发送方地址

●接收方地址

●所有链接的地址

●参考值

●Links消息还可以包含来自发送方节点的某些其它数据。在网页评论的示例中，这是相关评论的地址

它包含发送方节点的所有当前链接。它总是响应于LinksQuery(链接询问)消息而发出的。参考值可以用于区分所响应的具体询问。

●LinksQuery(链接询问)消息，具有

●发送方地址

●接收方地址

●参考值

它用于请求节点来发送答复中的Links(链接)消息(包括其当前的链接)。

●Notify消息，具有：

●发送方地址

●接收方地址

●目标地址

●通知等级

它用于通知一节点网络中的另一个节点。通知等级用于控制和限制Notify消息的传播。在这里的介绍中，没有使用发送方地址，但是可用于调试或者如果希望的话可以用于发送收到应答。

建立辅网络

该系统令一组节点自组织成单个虚拟网，从而如果具有一个节点的地址，就能够找到该组中其它节点的地址。这一节介绍如何在发现了应当属于同一辅网络的节点的时候创建新的链接。这可以分为两个部分：

发现应当属于同一辅网络的节点对。用于将节点分组到同一网络中的准则是针对具体应用的。在网页注释的示例中，应当将给出关于同一URL的评论的所有节点一起分组到辅网络中。如何发现应当一起分组的节点也是针对具体应用的。示例是简要给出的。

作为发现节点的结果，对辅网络进行更新/扩展。当发现一对节点应当属于同一辅网络的时候，作为结果，该系统可以建立一个或更多个新的链接。该新链接并非必须介于该对节点之间，而可以例如处于这两个节点所链接到的节点之间。稍后将详细介绍如何创建新的链接。

初始Notify消息

辅网络的组织预先假定存在到来的‘Notify’消息，该消息可以例如识别现有和新的组成员(虽然在早些时候，有可能没有任何一个节点是该组的一部分，可是，在自组织处理过程中，两个节点可能都已经是该组的一部分了)。这持续到由系统的另一部分告知辅网络：节点属于它。可以采用多种方式来完成。这里我们给出了在与我们的在先国际专利申请中介绍的那种类型的主网络相结合地使用辅网络的时候如何完成这一过程的示例。在网页注释的示例中，各个评论将其自己公布为主网络中基于相应网页的URL的标签下的节点。这样，可以使用主网络来查找给定URL的评论，如果该评论存在的话。为了示出针对给定URL的所有评论，各个评论还具有与其相关联的辅网络的节点。与关于同一URL的评论相对应的节点自组织成专属于该URL的辅网络。这样，一旦使用主网络找到了关于URL的单独一个评论，就可以使用辅网络来找出与同一URL有关的其它评论。

所以在这种情况下，应当分组在一起的辅网络的节点是各自公布在主网络中的同一标签下的。下面将会介绍这样一种机制：借助该机制，在主网络中，节点周期性地执行‘Push’更新来建立和保持链接，包括这样的改进：只要节点知道了同一标签下公布的另一个节点，就会产生所需的Notify消息。

处理Notify消息

当节点接收到与它还没有链接到的节点有关的Notify消息的时候，将会发生下列情况中的一种：

如果接收节点已经具有了最大数量的容许链接，它将其加作备份(除非它已经将其作为备份)。如果在这样做的过程中，该节点超出了它的最大备份数量，则它将会去除一个备份。然后它还可以将Notify消息转送到它所去除的备份。它是否这样做取决于通知等级的值。每次转送都会将通知等级减小，以防止消息无止境地传送下去。

否则，如果目标节点仍未具有最大链接数量，则接收节点尝试着创建两个节点之间的相互链接。这在图2的图a和b中得到了图解说明。这里，L＝3并且节点1接收到了关于节点2的Notify消息。因为两个节点仅仅具有两个链接，因此在节点1和节点2之间创建链接。

否则，当目标节点已经具有了最大链接数量时，不可能简单地创建两个节点之间的相互链接。所以将会发生的是，接收节点尝试着将其自己插入在现有的链接中。在图2的图c和d中对此进行了图解说明。这里，将节点2和节点3之间的链接打破，但是用两个新的链接代替所打破的链接：节点1与节点2之间的链接和节点1与节点3之间的链接。所以链接总数增加了一。即使在节点2和节点3已经具有了最大链接数量的时候这也是有效的。不过，要想成功完成这一过程，需要节点1能够创建两个新的链接。在图3到图9的流程图中更详细解释说明了这一处理过程。

图3示出了节点如何处理到来的Notify消息。这里，判断是否应当创建新的链接，并且如果需要，则决定如何创建(通过加入新的链接还是通过将现有的链接变成两个链接)。如果不创建新的链接，则可以更新备份集合并且可以发出另一个Notify消息。

在步骤300中，接收Notify消息，该消息包含发出它的节点(发送方)的地址、目标节点的地址和传播限制值notifylevel(通知等级)。接收节点首先检查是否有空间建立新的链接(301)，如果有，检查是否已经有了到目标节点的链接(302)。如果没有，则尝试着建立与目标节点的链接。

在步骤303中，向目标节点发送LinkQuery消息，并且在步骤304中，等待回复。一旦接收到回复一Links消息，则再次检查是否仍然有空间建立新链接(以防它在此期间接收并处理了任何其它消息并且作为结果创建了链接)(305)。如果有空间，则检验所接收到的Links消息，以检查目标节点是否有空间建立新的链接(306)。如果有，则在步骤307和308中，接收节点将目标节点的地址加到它的链接列表中(但是标注为“未确认”)并且向目标节点发送AddLink消息。

不过，如果在步骤306中判定目标节点不能接受更多的链接，则接收节点尝试着象此前参照图2介绍的那样将其自己插入到现有的链接中。第一个步骤(309)检查接收节点是否有用于两个链接的空间；如果没有，则处理终止。不过如果有，则接收节点从所接收到的Links消息中的链接列表中随机选择一个链接(但不是接收节点已经有链接的节点)，就是说，目标节点和另一个节点(此处称为另一节点)之间的链接。然后接收节点通过下列步骤尝试着将其插入到这一链接中：

步骤311：将目标节点的地址(未确认)加入到其链接列表中；

步骤312：将另一节点的地址(未确认)加入到其链接列表中；

步骤313：向目标节点发送包括另一节点地址的ChangeLink消息；

步骤314：向另一节点发送包含目标节点地址的ChangeLink消息。

不过设想在步骤310中判定接收节点没有加入链接的空间，或者在步骤302中已经有了到目标节点的链接，则该处理检查接收节点是否应当将链接加入到其备份链接列表中。在步骤315中，如果发现目标节点已经在备份列表中，则处理终止。在步骤316中，检查是否有将链接加入到备份列表中的空间，并且如果有，则在步骤317中适当地加入。如果没有，则在步骤318中随机选择备份列表的一个现有备份链接，并且在步骤319中将其去除，从而在步骤317中可以用到目标节点的链接代替它。而且，在步骤320中将变量notifylevel递减，并且如果(步骤321)仍为非零，则在步骤322中将具有这一新的notifylevel值的原始Notify消息转送到通过随机选择现有链接而选中的节点(称为替换节点)。

这一处理的效果是，当已经具有完整链接集合的节点A接收到请求它链接到目标节点B的Notify消息的时候，将B的地址记录为备份链接。这个链接保持暂停状态，直到A的备份链接列表全满。然后，当A接收到之后的请求它链接到节点C的Notify消息，并且在步骤318中选择了到节点B的备份链接的时候，在步骤322中产生的新的Notify消息实际上是请求节点B创建从它自己到节点C的链接的请求。

还提供了这样一种机制(但是流程图中没有示出)：借助这种机制，在链接未得到确认并且接收节点在给定时间段内没有接收到确认(借助LinkAdded消息，将在下文中参照图6加以介绍)的时候，将会删除未确认消息。注意，当接收节点具有仍然具有“未确认”状态的链接时，它将会响应于LinksQuery消息返回这些未确认链接(当然，还有确认链接)，使其它节点能够确认它正在尝试着建立该链接。

在图3中，步骤305和309的“否”出口导致处理终止：不过如果希望，可以使它们转到步骤315中进行的“备份链接”处理，这样在效率上会有轻微提高。

在步骤309到314中，节点有效地打破了目标节点的链接之一，并且将其自己插入其间。另一种可能的可选方案(在流程图中未示出)可以是让节点打破它自己的链接之一(当然是假设它已经有了至少一个链接)并且将目标节点插入其间。如果实施这种可选方案，应该在步骤301的‘否’出口之后立即试着实施该方案。首先，接收节点需要检查目标节点是否具有少于L-1个链接、随机选择它自己的(到其它节点的)链接之一、用到目标节点的未确认链接替换这个选定链接并且向目标节点发送AddLink消息。为了在目标节点和另一节点之间建立双向链接，然后它要(a)向目标节点发送要求目标节点将另一节点作为未确认链接无条件地加入到其链接列表中的专用AddLink消息和(b)向另一节点发送将接收节点作为要去除的旧链接并且将目标节点命名为所要添加的新链接的专用ChangeLink消息。这种可选方案可以与步骤309到314一起被包含在内，或者可以代替步骤309到314。

接收节点打破其自己的链接之一的另一种可选方案是它(首先已经验证了目标节点具有少于L-1个链接)向目标节点发送将其自己命名为目标节点的Notify消息。这样做会得到相同的结果，但是牵涉到稍微大一些的消息发送开销。

图4示出了节点如何处理到来的ChangeLink消息。这些消息是在接收到Notify消息的节点X想要将现有链接改变成两个新的链接的时候发出的(见图2)。接收节点Y在步骤400中接收将节点Z作为目标节点的Notify消息，即，请求节点Y将其现有的到节点Z的链接替换为到节点X的链接。如果已经有了到X的链接，则不再做其它动作(401)，而如果(402)它实际上不拥有到节点Z的链接，则它向发送方X发送(403)错误消息。

假设一切良好，则它向发送方X发送LinkQuery消息(404)并且等待来自发送节点X的作为回复的Links消息(405)，以检查后者是否确实创建了两个在改变目标链接之前应当已经创建好的新链接。如果这些检查(406，407)是结果良好的，则接收节点去除它到Z的链接(408)、将X添加为得到确认的链接(409)并且向发送方X返回LinkAdded消息(410)。

图5示出了节点如何处理到来的AddLink消息。这些消息是在节点想要与一个节点创建新的链接的时候发出的(见图1)。在步骤501中已经接收到该消息，节点在步骤502中检查是否有用于另一个链接的空间并且如果没有，则在503中返回错误消息。否则，它向发送方发送LinksQuery消息(504)并且等待来自发送节点的作为回复的Links消息(505)，从而它可以在506中检查后者是否确实已经创建了到接收节点的链接。如果没有，则它拒绝添加该链接并且终止，但是如果已经创建了，则它将发送方添加为得到确认的链接(507)并且为了确认而向发送方返回LinkAdded消息(508)。

图6示出了节点如何处理到来的LinkAdded消息。这些消息是在另一个节点接受了与接收节点的链接的时候或者响应于ChangeLink或AddLink消息而发出的。当在步骤600中接收到表明链接已经被接受的LinkAdded消息时，在步骤601中将其状态改为“已确认”。然后将会保持该链接，直到它由于新的链接而得到改变(响应于ChangeLink)或者该链接遭到打破。

图7示出了节点如何处理到来的LinkError消息。这些消息是在接收节点请求相互链接(经由ChangeLink或AddLink消息)之后节点不能创建到接收节点的链接或者链接看起来遭到了打破(处于另一端的节点可能没有对消息做出响应，或者链接可能不是相互的)的时候发出的。打破的链接不是由自组织处理检测到的，而是在客户遍历辅网络的时候检测到的(稍后将对此进行解释说明)。

在步骤700中接收到消息之后，判断该消息是否与接收节点的未确认链接所链接到的节点有关(701)。如果是，并且它携带有表明所请求的链接创建失败的错误代码(702)，则在步骤703中将该链接去除。不过，如果该消息不与接收节点的未确认链接所链接到的节点有关，则接收节点向目标节点发送LinksQuery消息(704)、等待作为回复的Links消息(705)、在步骤706中对该回复进行检查，以检查目标节点是否具有到它自己的链接，并且如果没有，则在步骤703中去除它到目标节点的链接。

图8示出了节点如何处理到来的LinksQuery消息。这些消息是在另一个节点想要知道接收节点的链接的时候发出的，并且在步骤800中接收节点在接收到这些消息的时候，在步骤801中用Links消息做出响应。

图9示出了节点如何处理到来的Links消息。如何对其进行处理完全取决于为什么要发出相应的LinksQuery消息。如图3、图4、图5和图7中所示的(非穷举)，这因不同的原因而发生。所以所发生的是，当发出LinksQuery消息的时候，给定了本地唯一的参考并且使消息处理器与该参考相关联。然后，当接收到Links消息时(900)，识别合乎要求的消息处理器，并且在步骤902中将该消息转送到合乎要求的消息处理器，从而该消息处理器以正确的方式对待该消息。

当然也有可能发生这样的情况：未接收到响应于LinksQuery的Links消息，例如因为接收节点已经被关闭。因此，如果在给定的时段之后还没有接收到Links消息，则去除相应的消息处理器。虽然这没有在这里介绍的任何一个流程图中明确给出，但是简单来说它意味着，当链接查询超时的时候，就不再采取进一步的动作，并且整个流程“完成”。

对节点进行检索

给出了辅网络的单独一个节点的地址，就有可能找到网络中其它的、有可能是全部的节点。能够完成这一检索过程的方法非常简单。向已知节点发送LinksQuery消息，以请求了解它所有的链接。该节点用Links消息做出回复，该Links消息包含所有它链接到的节点的地址。然后可以依次联系这些节点中的各个节点，请求它们的链接并且这样就获得了它们所有链接的地址。通过按照这种方法继续进行，就遍历了该网络并且逐步地发现了它所包含的所有节点。

图10更加详细地给出了该处理。将会理解，这是在图1A中所示的检索步骤35中使用的处理。将已经成功进行了联系的所有已知节点的地址放到“已确认”列表中。同时可以取回数据。在“网页评论”示例的情况下，相关的数据项是评论的地址，并且将评论的地址也与节点地址并列地输入到已确认列表中。于是已确认列表提供图1A中的“检索”评论步骤(36)所需的地址。另一方面，“未确认”列表包含还没有联系的已知节点的地址。最后，“已知”列表包含所有已知节点的地址。它包括“已确认”和“未确认”列表中的所有地址，但是还包括已经进行了联系并且没有做出响应的节点的地址。对于输入到已知列表中的各个地址，已知列表还具有额外的字段用来包含源地址，即，这样的节点的地址：从该节点的列表中获得当前指针指向的地址，用于报告错误之用。

检索处理在哪里发生并非实质性问题：它可以在节点中发生或者在此之外的某处发生。在步骤1000中，连同起始地址(即，已确定属于所考察的虚拟网的一个节点的地址)一起，接收到检索节点地址的请求。在步骤1002中，将地址指针(当前指针)初始设置为这一地址，而第二地址指针(源指针)初始为空(1003)。

在步骤1004和1005中，向由当前指针给出的地址发送LinksQuery消息，并且等待回复。当接收到Links消息时，将当前指针与来自Links消息的评论地址一并加入到已确认列表中(步骤1006)。

在步骤1007中，进入子处理，该子处理是针对包含在Links消息中的各个地址进行的。如果(1008)该地址已经存在于已知列表中，则处理步骤转到下一个地址。否则将该地址加入到已知列表中并且加到未确认列表中(步骤1009，1010)。而且，将当前指针中的地址输入到已知列表中，作为所加入地址的来源(1011)。

一旦完成了该子处理，然后(除非未确认列表是空的，在这种情况下，处理过程在步骤1012处终止)在步骤1013中从未确认列表中随机选择一个地址。这个地址变成了新的当前地址，并且将其从未确认列表中删除。下一个步骤(1014)是在已知列表中查找当前指针，以检索与其相关联的源地址，并且将这个地址输入到源指针中。并非必须进行随机选择。例如，可以将当前指针选择为未确认列表中“最旧”的节点，或者可以按照另一种准则(例如，节点的地址)对列表进行排序，并且当前指针可以总是这个列表中的“第一个”节点。不过，随机选择当前指针有它的好处。它将负荷分散在系统中(尤其是如果不总是检索所有的节点)，并且还分散了网络链接的测试，从而能够更加迅速地发现遭打破的链路。

然后该处理再次从步骤1004开始继续进行并且重复，直到未确认列表空了，即，不能再找到其它新的地址。

检索处理的附加效果是，它发现遭打破的链接。例如，在节点无响应或链接不相互的情况下可能发生了链接遭打破。链接不相互是节点A链接到节点B但是节点B的链接表中并没有节点A时的情况。在发现了遭打破链接的时候，借助LinkError消息通知作为链接“源”的节点。如图7中已经示出的，源节点随后可以自己检查该链接(以确认错误报告的准确性)并且可以据此去除该链接。没有响应的节点是通过在设定的超时时段内接收Links消息的步骤1005中的故障来识别的，并且在步骤1015将包含当前指针的地址和“无回复”错误代码的错误消息发送给源节点，随后控制返回到步骤1012。链接的非相互性是通过在确定从当前节点接收到的Links消息是否包含源节点的地址的步骤1016中进行的测试来识别的：如果不包含源节点地址，则将包含当前节点地址和“不相互”错误代码的错误消息发送(步骤1017)给源节点，但是检索处理象前面那样继续进行，因为源节点的责任是采取补救措施(按照图7的处理过程)。如果源指针为空，则跳过步骤1016中进行的测试。

注意，即使多个得到确认的节点可能与不对Links消息做出响应的节点链接，也仅仅通知首先对该链接做出贡献的节点(源节点)存在“未回复”。这部分地是因为它使得流程图更易于理解。不过，可以证明还有另一个实际的好处。情况有可能是节点因为它暂时过载而不(及时)回复。在这种情况下，我们可能不希望多个节点同时发给它LinksQuery消息，来测试是否有错误(如图7中那样)。另外的方式，如果希望，在发现这样的链接的时候，将节点检索算法更新为对所有受到遭打破链接影响的已知节点进行通知是比较直截了当的。

在图10中，在联系完所有已知节点之前，节点检索不会停止。在实践中，我们可能希望早些终止该处理。例如，如果用户正在寻找下载文件的地点，那么为他或她提供十个可能的下载地址的选择可能就足够了，而不用提供所有成千上万个下载地址。

图10中的算法是完全按照连续的方式给出的。一次仅联系一个节点。仅仅在已经接收到对前一节点的回复(或者已经超时)之后，才发送另一个LinksQuery消息。不过在实践中，我们更希望通过并行地发出多个LinksQuery消息来加快检索的速度。也可以是这样的情况，在方框1000处，由图10的处理的多个实例同时处理多个检索请求。

讨论

自组织的成功

与几个不相关联的网络不同，辅虚拟网的目标是对应当一起组成单独一个网络的所有节点进行自组织。不管怎样，这是在很大程度上取决于如何产生初始Notify消息的情况。例如，如果有一组十二个应当全部分组在一起的节点，但是这个组中有五个节点仅仅接收到了与这个组中的这五个节点的其它节点有关的通知，并且其它七个节点都没有接收到与这五个节点有关的通知，那么这些节点就不可能自组织成单独一个网络。取而代之，它们排列成两个独立的网络，五个节点组合一个网络，而另七个节点组成一个网络。不过，只要初始通知不至于使节点不能自组织成单独一个网络，那么自组织处理就会使节点不太可能不能自组织成单独一个网络。自组织得到单独一个网络的概率的计算是很复杂的并且取决于产生初始通知的机制。不过，在模拟过程中，我们用数种不同的初始通知机制进行了试验，并且到目前为止节点从未不能自组织成单独一个网络。

对恶意节点的强健性

到目前为止，都是假设所有节点都服从协议。不过，有可能存在不按规则行事的恶意节点。它们可能试图打破由其它节点保持的链接和/或试图获得过多的到它们的链接。希望整个系统对这种违规行为尽可能地强健。

到目前为止介绍地系统已经对恶意节点相当强健了。这是因为各个节点在改变它自己的链接之前总是通过LinksQuery-Links消息的交换来检查由其它相关节点保持的链接。例如，当节点接收到AddLink消息时(见图3)，它在将发送方加为它自己的链接之前首先检查发送节点是否实际上已经与其链接。

不过，这种系统仍然有相对薄弱的地方。按照实际情况来说，节点在它们用Links消息做出响应的时候能够轻松地“撒谎”。通常节点会发送LinksQuery消息来检查接收节点是否与其链接。知道了这一点，接收节点就能够用被修改成总是包含Links消息的发送方作为一个链接的虚假Links消息来进行回复。这使得节点能够具有远多于允许数量L的与其链接的节点。结果，这将会减少系统中“良好”链接的总数。

幸运的是，有办法解决这一薄弱环节。如果节点通过代理节点发出它们的LinksQuery，就能够解决这一问题。这些代理是每次节点想要发送查询的时候随机选择的。各个节点可以例如使用它当前链接的节点作为代理。这样，想要知道另一个节点(B)的链接情况的节点(A)是节点B所不知道的，这是因为它是从代理节点(C)那里接收到的LinksQuery消息，并且节点B从节点C接收到的消息根本没有提及节点A。因此节点B没有好办法发送对整个系统有明显影响的虚假消息。

当然，还有恶意代理造成的影响的问题。虽然很明显恶意代理节点具有有害的影响(不可避免地，不服从协议的节点会在一定程度上影响性能)，但是这种影响是有限的。原因是，它们只能恶意处理请求它们转送的LinksQuery，并且这些请求粗略均等地分布在所有节点上。另一方面，在不使用代理节点的时候，恶意节点能够通过处于非常活跃的状态而造成很大的破坏。如果这些节点发送很多虚假的AddLink消息，并且伪造它们随后发送的很多Links消息，则对整个系统的影响相当大。

主虚拟网

在我们的前面提到的国际专利申请中详细介绍了主网络。这里，将介绍基本检索和自组织机制，同时还将介绍能够实现用于驱动辅网络的自组织的Notify消息的产生的修改方案。

首先需要解释一下由这种机制使用的虚拟坐标空间的概念。已经提到了各个节点具有标签。将该标签转换成虚拟空间中的坐标。该空间可以是一维、二维或更高维数的空间。精确的转换机制并非非常关键：对于一维空间，可以将标签看作二进制数字而直接用作坐标。对于二维或更多维，优选方法是，将标签看作位串，划分成两个或多个等长的组，被看作二进制数字的各个组构成坐标之一。将各个坐标(或一维空间中该坐标)缩放成处于范围[0，1]之内。

在这个虚拟空间中，两个标签之间的距离是两个坐标组之间的欧几里德距离(Euclidean distance)(不过如果希望，也可以使用其它距离，比如城市街区距离(通常称为曼哈顿距离(Manhattan distance)))。该坐标空间包围起来，从而x₁与x₂之间沿x方向的距离是

Min{(1-|x₁-x₂|)，|x₁-x₂|}

并且因此点(x₁，y₁)与(x₂，y₂)之间的二维欧几里德距离是

$\sqrt{\{{\left[\mathrm{Min}\right\{(1-|x_1-x_2\left|\right),|x_1-x_2|\left\}\right]}^2+{\left[\mathrm{Min}\right\{(1-|y_1-y_2\left|\right),|y_1-y_2|\left\}\right]}^2\}}$

我们此刻还会回忆起各个节点具有列表22(图1)，该列表具有多个代表到其它节点的链接的条目。各个条目由这种另一个节点的标签和地址构成。最初，这个列表是空的，并且因此该节点具有第二个类似的引导链接(即，少量(典型地是四个)的链接)的列表，从而它一开始就能够与网络的其它节点进行联系。除列表22中的链接(称为短程链接)之外，节点还可以具有额外的分级排列的这样的链接，和/或远程链接的列表。在我们的之前的国际专利申请中介绍了这些链接，但是，因为它们是可选的，因此这里不做介绍。

消息

首先，使用下列消息(注意，主虚拟网中使用的消息不同于、并且完全独立于辅虚拟网中使用的消息)：

FIND(查找)消息用于启动和实现节点查找并且用于支持“PULL(挽)”更新。它们包含：

●目标节点的标签

●发起查询的节点的地址

FOUND(所找到的)消息用于返回查询的结果。它们包含：

●目标节点的地址

●所找到节点的标签

●所找到节点的地址

●与所找到节点相关联的辅网络的节点的地址

●应用专用数据一在这种情况下，是与所找到的节点相关联的评论节点的地址

PUSH(推)消息将节点的标签通报给其它节点。它们包含：

●目标节点的标签

●目标节点的地址

●到达目标节点所要经过的跳(hop)数

NOTIFY(通知)消息用于传播PUSH更新。它们包含：

●目标节点的标签

●目标节点的地址

检索

图11示出了各个节点如何处理到来的Find消息。原则上，接收节点寻找比它自己更加接近Find消息中指定的目标节点的节点，并且如果成功找到，则传递Find消息。如果不成功，则返回它自己的地址和标签。它通过执行下述步骤来完成这一过程：

步骤1100：节点接收包含目标节点标签和发起节点地址的Find消息；

步骤1105：节点将目标节点的标签转换成标签空间中的坐标并且计算它记录的所有链接(节点)中的哪个在标签空间中最接近目标节点。将相关节点指定为最接近节点。

步骤1110：该节点将其自己的坐标和目标节点的坐标之间的距离与最接近节点的坐标和目标节点的坐标之间的距离进行比较；

步骤1115：如果它自己的坐标与目标节点的坐标之间的距离较小(或相等)，则该节点经由网络10向发起节点发送包含它自己的标签和地址的Found消息。

步骤1120：如果最接近节点的坐标与目标节点的坐标之间的距离较小，则该节点将Find消息转送到最接近节点。

在步骤1115中返回的节点的地址要么是具有目标标签的节点的地址，要么是在标签空间中最接近目标标签的节点的地址。当所返回的标签不与目标标签匹配时，可能意味着目标节点不存在，或者虚拟网没有成功完成自组织。

Push(推)

各个节点自发地发起Push更新。例如，各个节点可能周期性地开始Push更新处理。在Push更新中，节点通过随机的节点串发出带有它自己的标签和地址的Push消息，对该节点串的长度设置上限。该节点串中最后一个节点向发起节点发回Notify消息。图12、13和14示出了这一处理的各个部分。

图12示出了节点如何使用下列步骤发起Push更新：

步骤1200：该节点从其引导链接当中随机地选取链接并且将由选定链接指定的节点的地址输入为下一个消息的转发地址；

步骤1205：该节点为Push消息中的字段‘要经过的跳’输入小的正随机数；

步骤1210：该节点将其自己的标签和地址输入为Push消息中的目标节点的标签和地址，并且使用网络10将Push消息发送给转发地址处的节点。

图13和14示出了如何更新短程链接。与Notify消息一起使用Push消息来更新短程链接。在这一更新过程中有两个阶段。在第一个阶段中，各个节点随机转发Push消息，直到所接收到的‘要经过的跳’中的值为“0”。如果‘要经过的跳’中的值为“0”，则接收节点将会通过发出Notify消息开始Push更新的第二个阶段。在第二个阶段中，将Notify消息连续地转发到在虚拟空间中标签逐步接近目标节点的标签的节点。如果不能找到具有更接近标签的节点，则如果需要，对最后找到的节点的链接进行更新。这经常是否则不能找到给定的目标节点时的情况，例如因为它还没有建立短程链接。然后，最后找到的节点也向同样有可能改善它们的链接组的那些节点发送额外的Notify消息。

参照图13，Push更新的第一个阶段(应对到来的Push消息)涉及下列步骤：

步骤1300：节点接收Push消息。该Push消息将包含作为目标节点的发起节点的标签和地址并且具有字段‘要经过的跳’中的值；

步骤1305：接收节点从其引导链接当中随机选取链接并且将由选定链接指定的节点的地址输入为下一个消息的转发地址；

步骤1310和1315：接收节点将字段‘要经过的跳’中的值减1并且检查减小之后的‘要经过的跳’的值是否仍然大于零；

步骤1320：如果减小后的值仍然大于零，则节点将Push消息转发到所输入的转发地址；

步骤1325：如果该值为零，则节点改为输入(接收到的Push消息中给出的)发起节点的标签和地址，作为Notify消息中的目标节点，并且将该Notify消息发送到所输入的转发地址。

参照图14，处理Push更新的第二个阶段(应对Notify消息)涉及下列步骤：

步骤1400：节点接收包含作为目标节点的节点的标签和地址的Notify消息；

步骤1401：接收节点检查Notify消息的‘目标节点’是否具有与接收节点相同的标签；

步骤1402：如果是，则接收节点检查Notify消息的‘目标节点’是否具有与接收节点相同的地址。在具有相同地址的情况下，不再进行其它的动作。

不过，如果Notify消息的‘目标节点’是标签与接收节点的相同而地址与接收节点的地址不同的节点，则会发生两个事件。首先(步骤1403)，接收节点向到来的Notify消息的目标节点发送将从接收节点自己的短程链接列表中随机选择的节点命名为目标节点的Notify消息。其次，步骤1404促使产生用于由辅网络发生动作的Notify消息。不过，接收节点不能直接产生这样的消息。一般来说，我们倾向于避免通过通信网络在不同虚拟网之间发送消息，但是主要问题是，接收节点不仅需要辅网络自己节点的地址，而且需要与目标节点相关联的辅网络的节点的地址。接收节点没有这一地址。因此，使用了两个阶段的处理。

首先，接收节点向到来的Notify消息中被指定为‘目标节点’的主网络的节点发送专用的CrossNotify(交叉通知)消息。这个消息包含：

●发送方地址，该地址被设置为接收节点(即，接收到来的(主网络)消息的节点)的地址；

●接受方(或目的地)地址，该地址被设置为包含在到来的Notify消息中的地址；

●目标地址，该地址被设置为与接收节点相关联的辅网络的节点的地址。

注意，前两个地址是主网络上的节点的地址，而第三个地址是辅网络上的节点的地址。

其次，接收到CrossNotify消息的主网络的节点有效地将它转发到辅网络的相关节点。如果需要，转发节点可以将该消息的格式重新编制为辅网络中使用的格式并且用辅网络的相关节点的地址替换(主网络的)接受方地址。然后将完全按照图3中所示的那样处理该消息。我们说“有效地”的原因是，在实践中，我们更喜欢接收到CrossNotify消息的主网络的节点仅仅向其辅网络的相关节点发送包含CrossNotify消息的‘目标地址’字段所指定地址的简单的本地消息。在这种情况下，应该将图3的处理修改成包括将notifylevel设置为适当值的步骤。

将参照图15借助示例解释说明这一处理，在图15中，方框代表节点，而箭头代表消息。假设在图14的步骤1400中主网络的节点P1接收到包含作为‘目标节点’的主网络的节点P2的标签L_P2和地址A_P2的Notify消息。在节点P1处，识别出(图14中的步骤1401、1402)目标节点具有与P1相同的标签(即，L_P1＝L_P2)但是具有不同的地址(A_P1≠A_P2)。节点P1知道其辅网络节点S1的地址A_S1，并且产生(在图14的步骤1404中)具有发送方地址A_P1、接收方地址A_P2和目标地址A_S1的CrossNotify消息。在主网络的节点P2处接收到这一消息，并且这个节点将具有地址A_S1的LocalNotify消息发送到辅网络的相关节点S2。另选地，辅网络的节点S2在接收到LocalNotify消息的时候可以不按照图3的处理创建链接本身，而是产生另一个(辅网络的)Notify消息(由图12中的虚线所示)，它将该消息发送到节点S1，将它自己命名为目标节点。然后在节点S1处理Notify消息，然后节点S1使用图3的处理。这种可选方案涉及到额外的消息，但是具有这样的优点：在开始执行图3的处理的时候，Notify消息实际上是由地址在该消息的‘目标节点’字段中的节点发出的，并且目标节点因此自然地被确认为仍然存在。

现在返回到图14：步骤1405：接收节点将目标节点的标签转换为坐标并且计算它所记录的哪个短程链接会导向在虚拟空间中坐标最接近目标节点的坐标的节点标签。将相应节点指定为最接近节点。

步骤1415：接收节点将其自己的坐标与目标节点的坐标之间的距离和最接近节点的坐标与目标节点的坐标之间的距离进行比较。

如果，在步骤1415中，发现接收节点与目标节点之间的距离相同等或较小，则接收节点将目标节点的标签和地址添加为它自己的短程链接组中的链接((步骤1420)；下文中将参照图16进一步讨论这一处理)，向目标节点发送包含接收节点的标签和地址的Notify消息(步骤1430)并且向最接近节点发送包含目标节点的标签和地址的Notify消息(步骤1435)；

如果，在步骤1415中，发现最接近节点与目标节点之间的距离较大，则接收节点回转到步骤1435，在该步骤中，它向最接近节点发送包含目标节点的标签和地址的Notify消息。

图16详细示出了节点在更新其短程链接的时候的行为。它将新的链接加入到其短程链接中并且去除由这个链接取代的所有短程链接。

参照图16，节点可能需要将新的链接加入到其短程链接列表中，例如作为图14中步骤1420的结果。

步骤1600：更新节点(就是说，对其短程链接组进行更新的节点)得到用于新链接的节点的标签和地址；

步骤1605：更新节点识别与比更新节点更接近新节点的节点相关的所有现有链接。要对这些识别出来的链接进行取代。为了识别这些链接，更新节点针对各个现有链接计算新节点的坐标与其现有链接中指定的节点的坐标之间的距离。将各个这些距离与其自己的坐标和相应现有链接中指定的节点的坐标之间的距离进行比较；

步骤1610：从短程链接中去除相对于新节点的距离小于相对于更新节点的距离的所有链接；

步骤1620：更新节点将用于新节点的链接加入到其短程链接中。

我们现在转而介绍这种技术的另一种应用，即，文件在对等系统中的分布式存储。文件的实际性质对本发明并不重要：它们例如可以是文本文件、图像、声音或视频。各个文件存储在运算节点上，并且被看成是存在于虚拟目录结构的目录中。文件在运算节点上的实际存储方式可以是在该节点上的目录结构之内：本地目录结构可以或可以不反映虚拟目录结构，但是这对本发明并不重要。除非另有明确说明，在本说明书中提到“目录”是指虚拟目录结构。基本特征是，文件可以存储在任何目录中，不管在物理上它存储在哪里。

基本思想是，避免对运算节点之间的分级关系的任何需求，或者对集中式功能的任何需求，而是使用完全分布式的查询系统来实现对文件的访问和使用目录结构来引导用户探察可用文件。

目录和项目名

各个文件，或者更加一般地说，项目，都具有由两个部分组成的逻辑名：目录名和该项目的本地名。目录给出了将相关项目分组在一起的途径。这种分组仅仅是逻辑上的。可以使同一目录内的项目隶属于不同的运算节点，并且同一运算节点上的项目可以全部在不同的目录中。本地名用于在目录内的项目之间进行区分，不过同一目录内的项目有可能具有一样的名称。

除项目之外，目录还可以包含子目录。对本说明书的目的而言，我们假设目录是严格分级的，即，目录总是排列成树状结构。不过，本文介绍的系统没有理由不支持任意的目录结构，有点类似于在基于Unix的文件系统中使用软链接所能够实现的。

可以使用不同的句法来命名目录和项目，并且从技术的角度讲，使用哪种句法都没有太大关系。在下面的介绍中，我们假设下列句法：

IDENTIFIER＝[a-zA-Z][a-zA-Z0-9]^*

DIRECTORY_NAME＝IDENTIFIER|(DIRECTORY_NAME″/″IDENTIFIER)

LOCAL_ITEM_NAME＝IDENTIFIER

ITEM_NAME＝DIRECTORY_NAME″：″LOCAL_ITEM_NAME

所以标识符由字母开始，并且由字母和数字组成。目录名是单独一个标识符(当它是项级目录时)或者由多个由斜杠符号分开的标识符构成。项目名由目录名、冒号和代表该项目在目录内的名称的标识符组成。例如，有效目录名为“foo/bar/foobar”，该目录是“foo/bar”目录的子目录。有效项目名为“foo/bar：abc”，该项目相当于“foo/bar”目录中具有本地名“abc”的项目。尤其注意，术语“目录”除其它情况外指的是子目录。如果运算节点存储有某一目录的一个或更多个项目，我们就说该运算节点“掌管”了该目录，但这并不意味着该运算节点的状态不同于存储有同一目录的项目(也称为“掌管”了该目录)的其它运算节点的状态。

这可以借助示例来加以阐明。表1示出了由三个运算节点(节点1到节点3)组成的系统的示例结构。各个节点掌管三个项目。对于节点2，各个项目处于不同的目录中，而节点3的所有项目都存在于“foo”目录中。

表1.共享不同项目的三个节点的示例结构

位置	项目
		节点1	foo：abcfoo：deffoo/bar：def

节点2	foo/bar：abctan：xyztan/kai：def
		节点3	foo：abcfoo：ghifoo：xyz

查找网络

系统的核心是多个不同的虚拟网，用于查找的用途。注意，虽然这里提到了有用于某种目的的查找网络，但是应当理解，查找网络具有如上所述的主虚拟网，并且还可以具有多个辅虚拟网。

●目录查找网络。仅有一个目录查找网络，所有运算节点为该网络做贡献。对于它掌管的各个目录，运算节点具有代表目录查找网络中的目录的(主网络的)本地节点。由目录名产生标签，并且所示的值(即，节点响应于查询首先返回的数据)原则上是目录位置(即，掌管该目录的运算节点的地址)。给定了这里使用的寻址方案，则没有必要将值与主网络节点关联起来，因为响应于Find查询返回的Found消息包括节点的地址，所以与主网络节点相关联的目录节点的地址可以由后者的地址导出。在使用不同的寻址方案(不提供推导地址的能力)的时候，与主目录查找网络中的节点相关的值应该是相应目录节点的地址。每个运算节点负责公布它掌管的目录。目录查找网络的目的是，在给出目录名的前提下，能够识别出掌管该目录的一个运算节点。对于项目检索，不必要使用辅网络，但是在这个示例中，提供了辅网络来使得能够产生目录内容的清单，稍后将对此进行介绍。

表2示出了上述示例的目录查找网络的内容。在这种情况下，“值”那一栏是空的，因为(如我们将介绍的)通过在本例中使用的寻址方案，地址可以由(所返回的)目录节点的地址推演出来。虽然目录内容列在单独一个表格中，但是实际的查找网络是分布在三个节点上的主虚拟网。对于表格中的各行，有一个虚拟节点，该虚拟节点位于“位置”栏中列出的运算节点上。

表2.目录查找网络

标签＝下列名称的哈希	值	位置
			tan		节点2
tan/kai		节点2
			foo		节点1
foo		节点3
			foo/bar		节点1
foo/bar		节点2

注意，只有在运算节点具有处于目录内的项目的情况下，才将该运算节点看成掌管了该目录。节点2并不需要foo目录的目录节点，因为(虽然它掌管了子目录foo/bar)它并没有掌管该目录内的任何项目。

●子目录查找网络。只有一个子目录查找网络，所有的运算节点都对该网络做贡献。对于它掌管的各个目录，运算节点公布该目录的子目录条目。标签由父目录的名称产生。与各个条目相关的值是子目录的名称。例如，节点1上的目录“foo/bar”应该在标签“foo”下公布具有值“foo/bar”的子目录，并且这个子目录应该在节点1处掌管。这个子目录条目采取主虚拟网的节点和辅虚拟网的节点的形式。结果，子目录查找网络具有一个主虚拟网以及和目录一样多的辅虚拟网，这些目录具有处于它们之内的子目录(包括所有顶级目录存在于其中的根目录或空目录)。

表3示出了子目录查找网络的内容。再一次，所有三个节点对这一网络做贡献。

表3.子目录查找网络

标签＝下列名称的哈希	值	位置
			(空)	foo	节点1
(空)	tan	节点2
			(空)	foo	节点3

tan	tan/kai	节点2
			foo	foo/bar	节点1
foo	foo/bar	节点2

●多个项目查找网络。对于系统中的各个目录有一个项目查找网络，只有掌管该目录中的项目的节点对该网络做贡献。标签是本地项目名的哈希，并且值是项目位置。对于它所掌管的各个项目，运算节点公布该项目在用于该项目所在目录的项目查找网络中的位置。项目查找网络的用途是，在给出项目名的前提下，能够识别出掌管该项目的运算节点。这样，项目查找网络并不包括任何辅网络，不过如果出于某种原因而希望的话，可以提供这些辅网络，以识别出特定项目的不止一个来源。

注意，有可能只有单独一个项目查找网络。在这种情况下，标签可以是整个项目名(即，包括目录名)的哈希。不过，对于大的系统，这将会变得效率不高。

表4到7示出了各个项目查找网络的内容。对某一网络做贡献的运算节点的数量取决于有多少节点掌管查找网络所对应的目录中的项目。例如，只有节点2掌管目录“tan”中的项目，所有只有一个运算节点对“tan”项目查找网络做贡献，这可以在表4中看出。

表4.“tan”目录的项目查找网络

标签＝下列名称的哈希	值	位置
			xyz		节点2

表5.“tan/kai”目录的项目查找网络

标签＝下列名称的哈希	值	位置
			def		节点2

表6.“foo”目录的项目查找网络

标签＝下列名称的哈希	值	位置
			abc		节点1

abc		节点3
			def		节点1
ghi		节点3
			xyz		节点3

表7.“foo/bar”目录的项目查找网络

标签＝下列名称的哈希	值	位置
			abc		节点2
def		节点1

在介绍查找处理的操作之前，将参照图17更加详细地介绍运算节点的组织结构，图17明确示出了存在于上面给出的示例的节点1上的节点。如前面所讨论的，如果希望的话，每个节点可以具有与其它节点的地址不相关的独特地址。不过，这里我们以前面讨论的方式使用端口构想了下述寻址协议。这样，运算节点具有一个IP地址和四个端口(即，总共四个网络地址)：

●一个端口(主端口)接收所有送往主虚拟网的节点的消息。这一节点具有由IP地址、端口号和节点标识符组成的地址。

●另一个端口(辅端口)接收所有送往辅虚拟网的节点的消息。这一节点具有由IP地址、端口号和节点标识符组成的地址。

●另一个端口(目录端口)接收所有送往目录节点的消息。这一节点具有由IP地址、端口号和节点标识符组成的地址。我们设想端口号可以在整个系统中都是相同的，并且节点标识符应该是整个目录名的哈希，从而，给定了运算节点的地址和目录名，就能够推演出目录节点的地址。

●另一个端口(项目端口)接收所有送往项目节点的消息。这一节点具有由IP地址、端口号和节点标识符组成的地址。我们设想端口地址应该在整个系统中都是相同的，并且节点标识符应该是整个项目名的哈希，从而，给定了运算节点的地址和项目名，就能够推演出目录节点的地址。

各个目录具有与其相关联的：

●目录查询网络的主虚拟网的节点；因此目录foo具有主目录查找节点PDL1。

●目录查询网络的辅虚拟网的节点；因此目录foo具有辅目录查找节点SDL1。

●目录节点，对于foo来说是DN1。

●子目录查找网络的主虚拟网的节点；因此目录foo具有主子目录查找节点PSL1。

●子目录查找网络的辅虚拟网的节点；因此目录foo具有辅子目录查找节点SSL1。

类似地，目录foo/bar具有节点PDL2、SDL2、PSL2、SSL2、DN2。

各个项目具有与其相关联的：

●项目所在的目录的项目查找网络的主虚拟网的节点。因此项目foo：abc具有主项目查找节点PILa：1，而项目foo：def具有主项目查找节点PILa：2。这两个节点都属于针对目录foo的同一主虚拟网。项目foo/bar：def具有主项目查找节点PILb：1，该节点属于针对目录foo/bar的不同主虚拟网。

●项目节点；因此项目foo：abc具有与其相关联的节点IN1，项目foo：def具有项目节点IN2，而项目foo/bar：def具有项目节点IN3。

主目录查找节点是由下列存储数据定义的：

●它自己的标签。

●它自己的地址。

●链接列表

●应用专用数据，即，相应辅节点的地址。

由这一节点接收到的消息以及它产生的响应已经做过介绍了。

辅目录查找节点是由下列数据定义的：

●它自己的地址。

●链接列表

由这一节点接收到的消息以及它产生的响应已经做过介绍了。

主子目录查找节点是由下列存储数据定义的：

●它自己的标签。

●它自己的地址。

●链接列表

●应用专用数据，即，它代表的目录名的哈希(例如，表3中第四行的“tan/kai”的哈希)，或者可选地为目录的相对名称(例如“kai”)，如果它足够短的话。后者有这样的优点：目录节点不需要额外的消息就能够建立目录的名称。

●和相应辅节点的地址。

由这一节点接收到的消息以及它产生的响应已经做过介绍了。

辅子目录查找节点是由下列数据定义的：

●它自己的地址。

●链接列表

由这一节点接收到的消息以及它产生的响应已经做过介绍了。

目录节点是由下列数据定义的：

●目录的名称

●目录中本地掌管的项目的列表

它能够通过产生下列回复对下列消息做出响应：

到来的消息	回复消息
		GetSummary	Summary
GetContents	Contents-目录中项目的本地名称的列表
		GetSecondaryNodeAddress	SecondaryNodeAddress-目录查找网络中节点的地址(所以对于DN1是SDL1)

项目节点是由下列数据定义的：

●项目的名称

●项目的数据大小(以字节为单位)

●对项目内容的哈希(这可以用于快速确定不同运算节点上的两个大项目是否相同，而不用首先将它们下载下来)

●项目在物理存储器上的位置(从而其可以响应于下载请求而被检索)

它能够通过产生下列回复对下列消息做出响应：

到来的消息	回复消息
		GetSummary	该项目的摘要数据(完整名称、长度、日期等)
GetContents	项目本身

项目检索

图18是要在运算节点上执行的、在给出名称的前提下实现项目检索的处理的流程图。这本质上是两个阶段的处理，首先使用目录查找网络来识别出掌管项目所在目录的运算节点，并且其次使用项目查找网络来找到掌管所查找的项目的运算节点。注意，这个处理并没有利用任何辅虚拟网络。

当然，在已经知道了掌管给定目录的运算节点的位置的时候，可以省略第一个步骤。这意味着，同一目录内的很多项目的检索能够有效地完成，这是因为路径查找仅仅需要进行一次。此外，项目查找网络相对较小，并且仅仅涉及到一部分运算节点，从而项目查找处理可以进行得相对较快。

该处理由请求检索项目的请求所启动。这个请求可以是手工输入的，或者是由需要该项目的程序产生的。不管请求是通过哪种方式产生的，在步骤1800中，在运算节点处接收到指定项目‘目录：名称’的检索请求。在图18中，在接收到请求的运算节点处执行的操作在矩形方框中给出；主要或完全在其它节点执行操作在圆角方框中给出。这里假设接收到请求的运算节点掌管至少一个虚拟目录，并且因此包含主目录查找网络的节点。因此，将会说明到这个虚拟节点的“本地”消息(即，方法或函数调用)。不过，如果运算节点并不掌管虚拟目录，则可以将这些消息改为发送到掌管虚拟目录的节点。

在步骤1802中，运算节点产生本地Find消息并且将其发送到主目录查找网络的节点。在图17中所示的节点1的情况下，这个节点是节点PDL1或PDL2：是哪个节点并不重要。我们假设它是PDL1。这个Find消息包含目录的哈希，作为目标标签。

在步骤1804中，这导致前面参照图11介绍的分布式查找处理的执行，得到包含所找到的节点的标签和地址的Found消息。在1806中，发出Find消息的节点(例如，PDL1)接收到这一Found消息。在步骤1808中，检查所返回的标签是否与目标节点的标签匹配，并且如果不匹配，则该处理过程以未成功告终。如果一切良好，则知道了掌管期望目录的运算节点(比如说，节点X)的地址(由Found消息返回的地址的前端部分)。

下一个步骤是发起期望目录的项目查找网络上的查找。因此，在步骤1810中，产生将项目名称的哈希指定为目标的另一个Find消息并且将其发送到刚刚识别出的运算节点X。实际上，这个消息必须要到达X处的项目查找节点之一。将简要介绍实现这个过程的不同方式。

在步骤1812中，这个Find消息再次发起图11中所示的分布式查找处理，并且导致在项目查找节点处接收(1814)Found消息，该项目查找节点然后将该Found消息转发到发起查询的运算节点。在这里描述的方式中，主网络的节点可以接受外部的Find查询，外部的Find查询是来自不是同一主网络一部分的节点(或者甚至来自于不属于主网络的节点)的查询。在这种情况下，如果接收到查询，则它应该会在本地保持对查询的记录，该记录包括它应当将回复发送到的地址(即，发起查询的运算节点的地址)。当它接收到Found消息时，它找到相应的查询记录并且转发该消息且删除该查询记录。如果查询超时(即，没有按时接收到Found消息)，也会删除该查询记录。可以借助包含在给定的Found消息中的目标节点的标签找到与该消息相应的查询。

另选地，发起查询的运算节点可以通过经主网络发送Find消息本身(到X处的项目查找节点)来发起查询。在这种情况下，可以将回复地址设置成这样：使所得到的Found消息直接发送到它自己(不用借助X处的项目查找节点进行发送)。注意，在这种情况下，Find消息不是从主节点发起的(或者至少，不是从作为同一查找网络的一部分的主节点发起的)，不过，这并不是问题，只要它能够适当处理Found消息即可。

和前面一样，对Found消息进行检查(1816)，以查看所返回的标签是否与目标节点的标签匹配，并且如果不匹配，则处理终止。

如果获得了匹配，则包含在Found消息中的地址是与所希望的项目相关联的项目查找节点的地址。不过，为了检索项目本身，需要项目节点的地址。这个地址可以由项目查找节点保存并且在Found消息中返回，但是利用本例中使用的编址协议，并不需要这样，因为所要求的地址可以通过简单地用项目端口的端口号替换项目查找节点地址的端口号而从项目查找节点地址产生。

下一个步骤(1820)是向这一地址发送请求检索项目本身的消息，然后在步骤1822中适时地接收。

在上面的说明中，我们省略了说明在步骤1806中已经接收到来自掌管目录的运算节点的Find消息的情况下，如何获得针对该目录的项目查找节点的地址，在步骤1810中要向该地址发送Find消息。或许最简单的方法是规定，各个主目录查找节点(比如PDL1、PDL2)还包含作为额外的应用专用数据的这一节点的地址；例如foo目录的节点PDL1可以包含项目查找节点PILa：1(或PILa：2)的地址。Find消息于是可以返回这一地址，然后可以将该地址直接插入到在步骤1810中产生的Find消息中，作为目的地地址。

更加完善的解决方案(假设是上面介绍的寻址协议)是取得在1806中由Found消息返回的主目录查找节点地址，并且通过将端口号改为目录端口号和将节点标识符改为目录名的哈希来将其转换成相关联目录节点的地址。如果各个目录节点具有在运算节点上的针对该目录的项目查找节点的列表，则在步骤1810中可以将Find消息发送到具有这一地址的目录节点(即，在节点X处)，然后该节点将这一消息转发到其项目查找节点之一。

浏览目录

图19是要在运算节点上执行的、产生目录内存储的项目的列表的处理的流程图。这一处理使用主目录查找网络来识别掌管所关心目录的运算节点，以获得该运算节点所具有的针对该目录的项目的列表，并且然后(如果需要，反复地)使用辅目录查找网络来找出掌管该目录的其它运算节点。

在步骤1900中，在运算节点处接收到指定了目录的检索请求。

在步骤1902中，该运算节点产生本地Find消息并且将其发送到主目录查找网络的节点。这个Find消息包含目录名的哈希，作为目标标签。

在步骤1904中，这导致上面参照图11介绍的分布式查找处理的执行，得到包含所找到的节点的标签和地址的Found消息。在1906中，在发出该Find消息的节点处接收到这一Found消息。为了表达的简明，标签匹配检查类似于图18中的步骤1808中进行的标签匹配检查，将其看成在方框1904内发生。

下一个步骤(1910)是向所找到的运算节点发送GetContent消息，以便由它的与目录相对应的目录节点做出动作。所要求的目的地地址是根据步骤1906中由Found消息返回的目录查找节点地址，通过将端口号改为目录端口号并且将节点标识符改为目录名的哈希而产生的。

目录节点以目录中项目的列表做出响应。在步骤1912中接收到项目列表时，将这个列表上的项目名复制到结果列表中。

为了组成目录中项目的完整列表，当然需要询问掌管目录的其它节点。对这些其它节点的搜索利用了辅目录查找网络，并且出于这一原因，各个主目录查找节点包含辅目录查找网络中它的相关联节点(例如，图18中的节点SDL1或SDL2)的地址，该地址也是由它发送的Found消息返回的。在步骤1914中执行辅目录查找网络的搜索。这个处理与参照图10介绍过的处理相同。虽然有可能运行图10的处理来得到结论，以找到所有掌管目录的运算节点，但是在本例中，只要将新的节点输入到“已确认”列表中，就将图10的处理挂起。[可以用挂起和恢复点标注图10]。一旦找到另一个辅目录查找节点，则控制返回到步骤1906，在这里以和前面一样的方式使用这个节点的地址。当处理过程再次到达步骤1914时，恢复图10的搜索处理，并且重复进行这一循环，直到再也找不到掌管目录的节点。当达到这一点时，结果列表将会包含保存在所关注目录中的项目的完整列表，不管这些项目存储在哪里。

该图示出了顺序算法。在实践中，可以部分并行的进行实施。例如，可以同时联系多个运算节点，以获得它们在给定目录内的项目列表。此外，在展示给用户目录列表之前，没有必要等待处理完成。可以在建立目录列表的同时将其显示出来。这使得用户能够开始遍览该目录。她可以开始检索她喜欢的项目。

图20示出了如何获得给定目录内的子目录的列表。图20与图19类似，不同之处在于，使用的是子目录查找网络，而不是目录查找网络。它包括类似于图19中的步骤1900到1914的步骤2000到2014。步骤2004使用主子目录查找网络，步骤2014使用辅子目录查找网络。不过没有与步骤1910对应的步骤，因为没有必要直接联系掌管给定子目录的节点，因为所有要求的信息(即，子目录的名称和位置)都可以在子目录的相关节点得到。

注意，为了得到目录的完整内容(即，其中的项目和子目录)，可以执行图19和图20中的两种处理。可以相继执行这两种处理，或者可以并行地执行这两种处理。不过，图19和图20中的算法不必总是结合起来使用。例如，为了取得所使用的整个虚拟目录树，仅仅需要反复执行图20。

Claims (21)

1.一种分布式计算机系统，其包括多个计算机：

其中所述计算机存储着数据项目，各个数据项目被分配给多个虚拟目录中的一个；

其中各个其上存储有所述数据项目的计算机具有至少一个用于目录查找的虚拟网的节点，所述节点包括

-用于识别出多个虚拟目录中与该节点相关联的一个虚拟目录的数据；

-链接数据，包括其它这样的节点的地址；和

-进行下列操作的软件：

(a)响应于识别多个虚拟目录中的另一个虚拟目录的查询消息，将该消息转送到该网络的另一个节点；

(b)响应于识别与该节点相关联的虚拟目录的查询消息，产生识别计算机的回复消息；

其中各个其上存储有所述数据项目的计算机，对于其上存储的各个项目，具有用于项目查询的虚拟网的节点，所述节点包括

-用于识别与该节点相关联的项目的数据；

-链接数据，包括各自与分配给同一虚拟目录的项目相关联的其它这样的节点的地址，由此所述链接数据一起定义了用于项目查找的多个虚拟网，各个虚拟网对应于各个不同的虚拟目录；和

-进行下列操作的软件：

(a)响应于识别项目中的另一个项目的查询消息，将该消息转送到该网络的另一个节点；

(b)响应于识别与该节点相关联的项目的查询消息，产生包括该项目的回复消息；

其中至少一个计算机具有对接收到的识别目录和该目录内的项目的查询做出下列的响应的检索装置：

(i)向用于目录查找的虚拟网的节点发送识别该目录的查询消息；

(ii)在接收到发给它的回复消息的时候，向回复消息中识别的计算机发送识别该项目的查询消息；

(iii)接收包含该项目的回复消息。

2.一种分布式计算机系统，包括多个计算机：

其中所述计算机存储着数据项目，各个数据项目被分配给多个虚拟目录中的一个；

其中各个其上存储有所述数据项目的计算机具有至少一个用于目录查找的虚拟网的节点，所述节点包括

-用于识别出多个虚拟目录中与该节点相关联的一个虚拟目录的数据；

-链接数据，包括其它这样的节点的地址；和

-进行下列操作的软件：

(a)响应于识别多个虚拟目录中的另一个虚拟目录的查询消息，将该消息转送到该网络的另一个节点；

(b)响应于识别与该节点相关联的虚拟目录的查询消息，产生识别计算机的回复消息；

其中其上存储有所述数据项目的各个计算机，对于其上存储的各个项目，具有用于项目查询的虚拟网的节点，所述节点包括

-识别出与该节点相关联的项目的数据；

-链接数据，包括各自与分配给同一虚拟目录的项目相关联的其它这样的节点的地址，由此所述链接数据一起定义了用于项目查找的多个虚拟网，各个网络对应于各个不同的虚拟目录；和

-进行下列操作的软件：

(a)响应于识别多个项目中的另一个项目的查询消息，将该消息转送到该网络的另一个节点；

(b)响应于识别与该节点相关联的项目的查询消息，产生识别计算机的回复消息；

(c)响应于识别与该节点相关联的项目的请求消息，产生包含该项目的回复消息；

其中至少一个计算机具有可对接收到的识别目录和该目录内的项目的查询做出下列的响应的检索装置：

(i)向用于目录查找的虚拟网的节点发送识别该目录的查询消息；

(ii)在接收到发给它的回复消息的时候，向回复消息中识别的计算机发送识别该项目的查询消息；

(iii)在接收到发给它的回复消息的时候，向回复消息中识别的计算机发送请求该项目的消息。

3.根据权利要求1或2所述的计算机系统，其中具有检索装置的该计算机或各计算机还包括辅检索装置，该辅检索装置可进行这样的操作：

(a)在接收到识别出具有特定目录内的一个或更多个项目的计算机的回复消息的时候，识别其它具有该目录中的一个或更多个项目的计算机；和

(b)创建该目录内项目的列表。

4.根据权利要求3所述的计算机系统，其中其上存储有所述数据项目的各个计算机还具有用于目录查找的辅虚拟网的至少一个节点，从而所述节点一起形成了对应于各虚拟目录的相应辅虚拟网，其中所述节点包括用于包含具有同一目录内的项目的辅虚拟网的其它节点的地址的列表的数据存储区域，并且所述节点响应于查询消息返回包含所述地址的列表的消息；

并且其中辅检索装置进行下列用来识别其它具有所关注的目录内的一个或更多个项目的计算机的操作：向由回复消息识别出的节点发送查询消息，并且在接收到响应的时候，迭代地向针对该查询消息的响应中包含的地址发送查询消息，或视情况向针对后续查询消息的响应中包含的地址发送查询消息。

5.根据权利要求1、2、3或4所述的计算机系统，其中将所述多个目录中的一部分作为子目录分配给所述多个目录中的另一个目录，并且其中具有检索装置的该计算机或各计算机还包括：

第一子目录检索装置，响应于目录名的输入而识别具有分配给该目录的至少一个子目录中的项目的运算节点；和

第二子目录检索装置，被连接以用来接收由第一子目录检索装置识别出的地址并且响应于此而进行这样的操作：识别具有分配给同一目录的至少一个子目录中的项目的其它运算节点。

6.一种在包括多个计算机的分布式计算机系统中使用的计算机：

其中该计算机存储着数据项目，各个数据项目被分配给多个虚拟目录之一；

其中该计算机具有至少一个用于目录查找的虚拟网的节点，所述节点包括

-用于识别出多个虚拟目录中与该节点相关联的一个虚拟目录的数据；

-链接数据，包括其它这样的节点的地址；和

-进行下列操作的软件：

(a)响应于识别多个虚拟目录中的另一个虚拟目录的查询消息，将该消息转送到该网络的另一个节点；

(b)响应于识别与该节点相关联的虚拟目录的查询消息，产生识别计算机的回复消息；

其中该计算机，对于存储于其上的各个项目，具有用于项目查询的虚拟网的节点，所述节点包括

-用于识别出与该节点相关联的项目的数据；

-链接数据，包括各自与分配给同一虚拟目录的项目相关联的其它这样的节点的地址，由此所述链接数据一起定义了用于项目查找的多个虚拟网，各个虚拟网对应于各个不同的虚拟目录；和

-进行下列操作的软件：

(a)响应于识别项目中的另一个项目的查询消息，将该消息转送到该网络的另一个节点；

(b)响应于识别与该节点相关联的项目的查询消息，产生包括该项目的回复消息；

其中该计算机具有对接收的识别目录和该目录内的项目的查询做出下列的响应的检索装置：

(i)向用于目录查找的虚拟网的节点发送识别该目录的查询消息；

(ii)在接收到发给它的回复消息的时候，向回复消息中识别的计算机发送识别该项目的查询消息；

(iii)接收包含该项目的回复消息。

7.一种在包括多个计算机的分布式计算机系统中使用的计算机：

其中该计算机存储着数据项目，各个数据项目被分配给多个虚拟目录之一；

其中该计算机具有至少一个用于目录查找的虚拟网的节点，所述节点包括

-用于识别出多个虚拟目录中与该节点相关联的一个虚拟目录的数据；

-链接数据，包括其它这样的节点的地址；和

-进行下列操作的软件：

(a)响应于识别多个虚拟目录中的另一个虚拟目录的查询消息，将该消息转送到该网络的另一个节点；

(b)响应于识别与该节点相关联的虚拟目录的查询消息，产生识别计算机的回复消息；

其中该计算机，对于存储于其上的各个项目，具有用于项目查询的虚拟网的节点，所述节点包括

-用于识别出与该节点相关联的项目的数据；

-链接数据，包括各自与分配给同一虚拟目录的项目相关联的其它这样的节点的地址，由此所述链接数据一起定义了用于项目查找的多个虚拟网，各个虚拟网对应于各个不同的虚拟目录；和

-进行下列操作的软件：

(a)响应于识别项目中的另一个项目的查询消息，将该消息转送到该网络的另一个节点；

(b)响应于识别与该节点相关联的项目的查询消息，产生识别计算机的回复消息；

(c)响应于识别与该节点相关联的项目的请求消息，产生包含该项目的回复消息；

其中该计算机具有对接收的识别目录和该目录内的项目的查询做出下列的响应的检索装置：

(i)向用于目录查找的虚拟网的节点发送识别该目录的查询消息；

(ii)在接收到发给它的回复消息的时候，向回复消息中识别的计算机发送识别该项目的查询消息；

(iii)在接收到发给它的回复消息的时候，向回复消息中识别的计算机发送请求该项目的消息。

8.根据权利要求6或7所述的计算机，还包括辅检索装置，该辅检索装置可进行这样的操作：

(a)在接收到识别出具有某一目录内的一个或更多个项目的计算机的回复消息的时候，识别具有该目录中的一个或更多个项目的其它计算机；和

(b)创建该目录内项目的列表。

9.根据权利要求6、7或8所述的计算机，其中将所述多个目录中的一部分作为子目录分配给所述多个目录中的另一个目录，并且所述计算机还包括：

第一子目录检索装置，响应于目录名的输入而识别具有分配给该目录的至少一个子目录中的项目的运算节点；和

第二子目录检索装置，连接成用来接收由第一子目录检索装置识别出的地址并且响应于此而进行下列的操作：识别具有分配给同一目录的至少一个子目录中的项目的其它运算节点。

10.根据权利要求9所述的计算机，其中检索装置进行编辑所述子目录的合成列表的操作。

11.一种分布式计算机系统，包括多个计算节点，其中各个计算机存储着数据项目，各个数据项目被分配给多个虚拟目录之一；

该网络具有

第一检索装置，响应于目录名的输入而识别具有该目录内的项目的运算节点；

第二检索装置，连接成用来接收由第一检索装置识别的地址，并且可响应于此而进行这样的操作：识别其它具有同一目录内的项目的运算节点；

其中各个具有给定目录内的项目的运算节点具有与其相关的数据存储区域，用来包含具有同一目录内的项目的其它运算节点的地址，并且所述运算节点响应于查询消息返回包含所述地址的列表的消息；

并且其中第二检索装置进行这样的操作：向由第一检索装置识别的节点发送查询消息，并且在接收到响应的时候，迭代地向针对该查询消息的响应中包含的地址发送查询消息，或视情况向针对后续查询消息的响应中包含的地址发送查询消息，从而识别具有所关注目录内的项目的多个运算节点。

12.根据权利要求11所述的分布式计算机系统，其中检索装置进行这样的操作：从所述识别出的多个运算节点中的各个运算节点中取回存储在其上的项目的列表，并且编辑成所述项目的合成列表。

13.一种分布式计算机系统，包括多个计算节点，其中各个计算机存储着数据项目，各个数据项目被分配给多个虚拟目录之一，所述多个目录中的一部分被作为子目录分配给所述多个目录中的其他目录；

该网络具有

第一检索装置，响应于目录名的输入而识别具有分配给该目录的至少一个子目录内的项目的运算节点；

第二检索装置，连接成用来接收由第一检索装置识别的地址，并且可响应于此而进行这样的操作：识别其它具有分配给同一目录的至少一个子目录内的项目的运算节点；

其中各个具有分配给给定目录的至少一个子目录内的项目的运算节点具有与其相关的数据存储区域，用来包含具有分配给同一目录的至少一个子目录内的项目的其它运算节点的地址，并且所述运算节点可响应于查询消息返回包含所述地址的列表的消息；

并且其中第二检索装置进行下列的操作：向由第一检索装置识别出的节点发送查询消息，并且在接收到响应的时候，迭代地向针对该查询消息的响应中包含的地址发送查询消息，或视情况向针对后续查询消息的响应中包含的地址发送查询消息，从而识别具有所关注目录的子目录内的项目的多个运算节点。

14.根据权利要求13所述的分布式计算机系统，其中检索装置可进行这样的操作：编辑所述子目录的合成列表。

15.根据权利要求11或12所述的计算机系统，其中将所述多个目录中的一部分作为子目录分配给所述多个目录中的另一个目录，并且其中具有检索装置的该计算机或各计算机还包括：

第一子目录检索装置，响应于目录名的输入识别具有分配给该目录的至少一个子目录中的项目的运算节点；和

第二子目录检索装置，连接成用来接收由第一子目录检索装置识别的地址并且响应于此而进行这样的操作：识别具有分配给同一目录的至少一个子目录中的项目的其它运算节点。

16.根据权利要求11到15中任何一项所述的计算机网络，其中第一检索装置是由主网络的虚拟节点构成的，各个节点由到辅网络的其它节点的链接的列表定义，该列表中的各个条目包括相应其它节点的标签和地址；并且其中各个节点包括：响应于接收的包含标签的请求消息在该网络内传播该请求消息的装置，和响应于接收的包含与接收请求消息的节点的标签相匹配的标签的请求消息而产生回复消息的装置。

17.根据权利要求11到16中任何一项所述的计算机网络，其中第二检索装置是由辅网络的虚拟节点构成的，各个节点是由到主网络的其它节点的链接的列表定义的；列表中的各条目包括各自的其它节点的地址；并且其中各个节点包括可响应于接收的请求消息产生包含列表中的地址的回复消息的装置。

18.根据从属于权利要求16的权利要求17所述的计算机网络，其中由主网络的节点产生的回复消息包括与产生回复消息的节点相关联的辅网络的节点的地址。

19.根据从属于权利要求16的权利要求17或者根据权利要求4所述的计算机网络，其中：

主网络的各个节点包括进行这样的操作的构件：发起和传播各自包含该主网络的发起节点的标签和地址的探察消息；

各个节点在接收到包含与接收节点的标签匹配的标签和与接收节点的地址不匹配的地址的探察消息的时候进行下列操作：产生用于增加到辅网络的链接的通知消息，所述通知消息识别发起探察消息的节点并且包含与接收节点相关联的辅网络的节点的地址。

20.根据权利要求19所述的计算机网络，其中通知消息包含作为目的地的发起节点的地址，并且发起节点在接收到通知消息的时候进行这样的操作：向与发起节点相关联的辅网络的节点转发请求在它与具有包含在通知消息中的地址的节点之间增加链接的消息。

21.根据权利要求10到20中任何一项所述的计算机网络，其中辅网络的各个节点包括被编程为用于执行下述操作的处理装置：

接收消息；

对请求与列表的内容有关的信息的消息做出响应；

按照所接收到的请求从列表中去除地址并且在列表中插入另一个地址；和

响应于接收的用于请求该节点与第二个节点之间链接的消息：

(A)产生到第二节点的、请求与其列表的内容有关的信息的消息；

(B)判断第一节点和第二节点是否在各种情况下在其列表中都仅有少于预定数量的多个地址；

(C)在这一条件得到满足的情况下，将第二个节点的地址插入到其列表中并且产生到第二个节点的、请求第二个节点将该节点的地址加入到其列表中的消息；

(D)在这一条件没有得到满足的情况下，判断该节点是否在其列表中有至少比所述预定数量少两个的多个地址，并且如果是，则

(a)从第二个节点的列表中选取第三个节点的地址；

(b)将第二个节点的地址插入到第一个节点的列表中并且将第三个节点的地址插入到第一个节点的列表中；

(c)产生到第二个节点的、请求从第二个节点的列表中去除第三个节点的地址并且插入该节点的地址的消息；和

(d)产生到第三个节点的、请求从第三个节点的列表中去除第二个节点的地址并且插入该节点的地址的消息。

Images