网络上请求资源的位置信息的方法、用户节点和服务器

摘要

公开了一种在P2P网络上请求资源的位置信息的方法、用户节点和相应的服务器，其允许用户以较快的速度获得其想要的网络资源。把对流行文件和非流行文件的管理分开来对待，将流行文件的元数据按区域在多个SN上存储，而采用集中的方式存储和查询非流行文件的元数据。在SN上增加重定向消息的功能以通知请求用户SN-R的存在。同时，为增加查询的效率，避免重复的重定向消息，在用户节点侧配备一个服务器路由表，用以指示要下载哪些文件，应该向哪些服务器发出请求。由于流行文件和非流行文件被分开存储，并且所有的非流行文件被集中存储，使得当P2P网络中的用户在请求不太流行的文件时，能够快速获得该文件的位置信息和相应的文件。

说明书

技术领域

本申请涉及网络资源的定位，具体涉及一种在P2P网络上请求资源的位置信息的方法、用户节点和相应的服务器，其允许用户以较快的速度获得其想要的网络资源。

背景技术

P2P网络是一种分布式网络系统，它由许多个互联的用户以自组织的方式构成。这些用户间可以分享各种资源，如：数据文件，计算能力，存储能力和带宽。在P2P网络中，一个关键的问题是数据的定位，即当一个用户想要下载一个文件时，它应该首先知道P2P网络中的哪些用户有该文件。一个直观的想法就是在以洪泛的方式在网络中广播查询消息以定位该文件，但这种方式会带来很大的应答延迟和网络流量。因此，现在的P2P系统通常采用的方法是用集中式的索引服务器来存储文件的元数据信息(即该数据是对文件属性的描述，如文件的大小，文件被哪些用户所拥有等信息)，这种方式可以大大加快查询用户的响应速度。

现在的索引服务器通常从已有的元数据集合中随机的选出一个子集返回给查询用户，这种随机的答案通常会带来严重的跨域流量问题。如图1所示，在ISP#1中的用户会向ISP#2中的用户请求数据，即使本域中的服务器也有该文件。为了降低跨域流量，已经提出了一些新的位置感知(location-aware)的存储结构用以大规模的P2P网络系统。

非专利文献1(CCSA TC1WG4会议-一种可管理可运营的P2P网络架构草案，2008年10月30日)提出了一种分布式超级节点的方法，该方法将元数据表存储在多个被称为超级节点的服务器上，每个服务器负责一个特定区域的元数据的存储和查询。区域的划定可以是灵活的。一个区域可以是一个ISP，也可以是一个ISP中的一个AS。例如：对中国的互连网络而言，一个超级节点可以管理中国电信的所有用户和文件信息，若这个量很大，可以进一步用多个节点细分，一个节点负责北京电信，一个节点负责上海电信...。

如图2所示，超级节点I(Super Node I：SN-I)管理ISP1中的用户，超级节点II(Super Node II：SN-II)管理ISP2中的用户。例如，对于存储过程而言，ISP1中的用户A，B，C将他们共享的文件D1的元数据信息(例如文件ID和地址)报告给SNI，在SNI的元数据表(Peers info table)中存储为D1：A，B，C(表示用户A，B，C有文件D1)。

同理，ISP2中的用户E，F，G，H把共享文件D1的元数据信息报告给SN-II，同时用户G把共享的另一文件D2的元数据信息也报告给SN-II。可以看出，在这一示例中D1是流行文件，D2是非流行文件。

图3示出根据现有技术的元数据的请求和搜索过程的示意图。对应图2中的存储，在步骤S11，当用户D请求文件D1时，由于用户并不知道该文件是流行文件还是非流行文件，因此用户D只会把请求消息发给SN-I。在步骤S12，SN-I判断其上是否存储有该文件D1的位置信息。在该例中，由于SN-I的元数据表中已经有足够多的用户信息，在步骤S13，SN-I直接应答用户D的请求。由于用户A，B，C和D都在同一ISP中，因此用户D下载文件D1时不会产生跨域流量。因为P2P网络中用户状态是非常动态的(有时上线、有时下线)，因此用户D需周期性的请求SN-I，以更新自己所知道的用户信息。

但是，当用户D请求的文件是文件D2时，在步骤S14，由于SN-I中没有关于文件D2的足够的用户信息，SN-I不得不去其它SN上查询，例如向SN-II发出查询请求。如果该SN-II上存储了该文件D2的位置信息，则在步骤S16，SN-II向SN-I返回查询结果，然后SN-I向用户D返回查询结果。

如果在步骤S15的判断结果是否定的，也算就是SN-II上同样没有该文件D2的位置信息(元数据)，则在步骤S17，SN-II例如向SN-III发出查询请求。然后，在步骤S18，判断SN-III上是否存在该文件的位置信息。如果存在，则在步骤S19，SN-III向SN-II返回查询结果，然后SN-II向SN-I，SN-I向用户节点返回查询结果。如果在步骤S18的判断结果是否定的，则在步骤S20，SN-III不得不向其他的SN发出查询请求，...。

因此，对于非流行文件，上述方法的搜索过程没有很好的可扩展性，需要在多个服务器(超级节点)间反复查询，因此对于用户的请求的响应会产生很大的时延。这种响应时延会影响用户侧使用性能，例如，在P2P VoD点播系统中，如果用户点播的是一个非流行的影片，在影片播放之前他将等待很长的一段时间。

发明内容

本发明的目的是提供一种在P2P网络上请求资源的位置信息的方法、用户节点和相应的服务器，允许用户以较快的速度获得其想要的网络资源。

在本发明的第一方面，提出了一种请求P2P网络上的资源的位置信息的方法，所述P2P网络包括：至少一个第一服务器，每个第一服务器都存储各自域内的第一流行等级的资源的位置信息和第二流行等级的资源的位置信息的存储地址；至少一个第二服务器，每个第二服务器都存储第二流行等级的资源的位置信息，所述方法包括步骤：从用户节点向其域内的第一服务器请求一资源的位置信息；在所述第一服务器未存储所请求的位置信息的情况下，从第一服务器向用户节点发送哪个第二服务器存储了所请求的位置信息的消息；所述用户节点基于所述消息向第二服务器请求所述位置信息。

在本发明的第二方面，提出了一种在P2P网络中上传资源的位置信息的方法，所述P2P网络包括：至少一个第一服务器，每个第一服务器都存储各自域内的第一流行等级的资源的位置信息和第二流行等级的资源的位置信息的存储地址；至少一个第二服务器，每个第二服务器都存储第二流行等级的资源的位置信息，所述方法包括步骤：从用户节点向其域内的第一服务器报告要共享的资源的标识信息和该用户节点的地址；如果该资源是第一流行等级的资源，则将该资源的标识信息和该用户节点的地址存储在第一服务器；如果该资源是第二流行等级的资源，则从第一服务器向用户节点发送该资源应该存储在哪个第二服务器的消息；从用户节点向所述消息所包含的第二服务器发送该资源的标识信息和该用户节点的地址。

在本发明的第三方面，提出了一种在P2P网络中请求资源的位置信息的用户节点，所述P2P网络包括：至少一个第一服务器，每个第一服务器都存储各自域内的第一流行等级的资源的位置信息和第二流行等级的资源的位置信息的存储地址；至少一个第二服务器，每个第二服务器都存储第二流行等级的资源的位置信息，所述用户节点包括：存储装置，存储一列表，该列表要记录或记录了请求的资源的位置信息的存储地址；以及查询装置，在要请求的资源的位置信息的存储地址未存在于所述列表中的情况下，向其域内的第一服务器请求该位置信息，并且在从第一服务器接收到指示该位置信息存储在哪个第二服务器的消息的情况下，基于所述消息向第二服务器请求所述位置信息。

在本发明的第四方面，提出了一种P2P网络上的节点，包括：存储装置，存储各自域内的第一流行等级的资源的位置信息和第二流行等级的资源的位置信息的存储地址；查询消息处理装置，接收来自用户节点的对资源的位置消息的请求；以及重定向消息创建装置，在所述存储装置未存储所请求的位置信息的情况下，向用户节点发送在P2P网络上的哪个位置存储了所请求的位置信息的消息，以允许所述用户节点从该位置请求该位置消息。

在本发明的第五方面，提出了一种P2P网络上的节点，包括：存储装置，存储资源的位置信息；监视装置，用于监视P2P网络上的资源的流行等级的变化；信息转移装置，在资源的流行等级从该流行等级变化到高于该流行等级的另一流行等级的情况下，向其他节点发送该资源的标识信息和位置信息。

利用上述方法和结构，由于流行文件和非流行文件被分开存储，并且所有的非流行文件被集中存储，使得当P2P网络中的用户在请求不太流行的文件时，能够快速获得该文件的位置信息和相应的文件。

另外，根据本发明的实施例，在用户节点具备一个位置信息列表，使得用户再次请求相关的资源时，进一步减少了获得网络资源的时间。

另外，根据本发明的实施例，当文件的流行性发生变化时，能够在不同的超级节点之间转移文件的位置信息，进一步缩短了用户请求资源所需的时间。

附图说明

通过下面结合附图说明本发明的优选实施例，将使本发明的上述及其它目的、特征和优点更加清楚，其中：

图1是描述根据现有技术的方法中跨域流量的产生过程的示意图；

图2是描述根据现有技术的分布式超级节点对元数据进行管理的示意图；

图3是描述根据现有技术的分布式超级节点对元数据的请求和搜索的示意图；

图4是根据本发明实施例的网络结构的示意图；

图5是根据本发明实施例的网络中的用户节点和网络服务器的结构示意图；

图6是描述根据本发明实施例的上报要共享的文件的过程的流程图；

图7是描述根据本发明实施例的请求位置信息的过程的流程图；以及

图8是根据本发明另一实施例的网络中网络服务器的结构示意图。

具体实施方式

下面参照附图对本发明的优选实施例进行详细说明，在描述过程中省略了对于本发明来说是不必要的细节和功能，以防止对本发明的理解造成混淆。

根据本发明的实施例，把对流行文件和非流行文件的管理分开来对待，将流行文件的元数据按区域在多个SN上存储，而采用集中的方式存储和查询非流行文件的元数据，将这样的存储和查询非流行文件的服务器(超级节点)称为SNR。

这里，流行文件和非流行文件是相对而言的，本领域的普通技术人员也可以按照流行等级将文件分成更多的类别。

根据本发明的实施例，当P2P网络中的非流行文件较多时，也可用多个SN-R，例如SN-R1和SN-R2存储，但同一个非流行文件的元数据会存在同一个SNR上。

当用户请求文件的位置信息时，并不知道所请求的文件是流行的还是非流行的，按缺省的动作，用户仍然会向负责本域的SN发出请求。为此，在SN上增加重定向消息的功能以通知请求用户SN-R的存在。同时，为增加查询的效率，避免重复的重定向消息，在用户节点侧配备一个服务器路由表，用以指示要下载哪些文件，应该向哪些服务器发出请求。通过该路由表，用户若下载流行文件，会向本域的SN发出请求；若下载非流行文件，会向相应的SN-R发出请求。这样就避免了在多个服务器间搜索非流行文件的元数据，大大缩短了非流行文件的响应时间。同时保持了对流行文件的可扩展性和位置感知特性。

图4是根据本发明实施例的网络结构的示意图。如图4所示，文件D2的用户信息(G)存储在SN-R1中，同时在SN-I和SN-II的元数据表中，文件D2的对应节点为SN-R1，当有用户向它们请求文件D2时，它们会用重定向消息通知请求文件D2的用户。当收到对文件D2的重定向消息后，用户(图中用户D)会在他的服务器路由表(SN-routing table)中增添一项，这样用户以后周期性的关于文件D2的请求可以直接发给SN-R1。

图5是根据本发明实施例的网络中的用户节点和网络服务器的结构示意图。如图5所示，根据本发明实施例的用户节点包括报告消息创建单元11、存储单元12、重定向消息处理单元13、查询消息创建单元14、响应消息处理单元15和通信单元16。

如图5所示，该报告消息创建单元11在用户要共享其某个文件时构造元数据报告消息并通过通信单元16发送给相应服务器SN。报告消息包括i)共享的文件信息(DataID)；ii)用户的地址，即IP，端口，协议等信息。

存储单元12包含一个路由表。该路由表中记录着文件(用DataID标识)和管理服务器(用地址标识)的对应信息，每次报告消息创建单元11通过通信单元16发送报告消息之前先查找该路由表，然后将消息发送到对应的服务器(SN或SN-R)。

重定向消息处理单元13从网络中获取重定向消息，例如从SN发送的重定向消息，从中提取DataID和服务器地址信息，并更新存储单元中的路由列表。

查询消息创建单元14构造文件请求消息并发送给相应服务器，该请求消息包括：i)要下载的文件ID；ii)本用户的地址；iii)要获取的用户信息的数量。在发送查询消息之前，查询消息创建单元14先从存储单元12中包含的列表中确定是否要请求的文件的地址信息已经存在该列表中。如果没有，则向本域的SN发出请求，否则，向确定的地址或者服务器发出请求。

响应消息处理单元15从网络中获取来自服务器的文件请求应答消息，从中提取用户该文件的用户地址信息，并将这些信息转给下载模块(未示出)，由下载模块去这些用户上下载该文件。

如图5所示，在服务器端，根据本发明实施例的SN包括：报告消息处理单元21、存储单元22、重定向消息创建单元23、查询消息处理单元24、响应消息创建单元和通信单元26。鉴于SN和SN-R有相同的组件结构，因此这里给出的详细描述可以看作是对两种超级节点的描述。

如图5所示，报告消息处理单元21通过通信单元26从网络获取来自用户的元数据报告消息，从中提出DataID和用户地址，并且用DataID查询存储单元22中存储的用户信息，如果返回查询结果为SNR，则用重定向消息创建单元23创建向用户表明该文件的位置信息存储在哪个超级节点上，例如哪个SN-R上的重定向消息。否则，报告消息处理单元21在存储单元22中增加一条记录。

如上所述，存储单元22包含一个元数据表，该元数据表中记录了各个文件(用DataID)和用户信息(用地址标识)或SNR的对应信息。

重定向消息创建单元23构造重定向消息，并发送给相应的请求用户。构造的重定向消息包括：i)DataID；ii)SNR的地址。

查询消息处理单元24通过通信单元26从网络中获取来自用户的文件请求消息，并查找存储单元22中的元数据表，若返回的结果是用户信息，则从中选取T个位置上离请求用户最近的用户信息并转给响应消息创建单元25。若是SNR信息，则通过重定向消息创建单元23创建并发送重定向消息。

响应消息创建单元25构造应答消息并发送给请求用户。应答消息包括：i)DataID；ii)拥有该文件的用户的地址列表。

下面对照附图6和7详细说明上述各个单元的结构。图6是描述根据本发明实施例的上报要共享的文件的过程的流程图。

如图6所示，在步骤S61，如果用户已经准备好要共享某个资源，例如视频文件，则在步骤S62，报告消息创建单元11首先在存储单元12存储的服务器路由列表中查找是否该文件的ID以及位置信息的存储地址已经存在于列表中。

如果在步骤S62的判断结果是肯定的，则在步骤S63，报告消息创建单元11直接向确定的地址发送该要共享的文件的ID和该用户节点的地址，例如IP，端口号和协议等等。

如果在步骤S63的判断结果是否定的，则在步骤S64，则报告消息创建单元11直接将该文件的ID和用户的地址通过报告消息发送给本域中的SN。

在步骤S65，本域的SN中的报告消息处理单元21接收到报告消息后，判断该要共享的资源是流行的还是非流行的。如果是流行文件，则在步骤S66将该资源的信息存储在SN的存储单元中，如果是非流行文件，则在步骤S67将该资源的信息存储在SN-R1的存储单元中。

图7是描述根据本发明实施例的请求位置信息的过程的流程图。如图7所示，在步骤S71，用户节点准备查询某个资源，例如一个视频文件。在步骤S72，该用户节点的查询消息创建单元14首先确定存储单元12存储的服务器路由列表中是否有该资源的ID和存储该资源的位置信息的服务器。

如果在步骤S72的判断结果是肯定的，则在步骤S73，查询消息创建单元14创建查询消息，并且向确定的服务器请求该资源的位置信息，然后在步骤S74该服务器将该资源的位置信息发送给用户节点。

如果在步骤S72的判断结果是否定的，则在步骤S75，用户节点的查询消息创建单元14向其域内的SN发送对该资源的位置信息的请求消息。然后，在步骤S76，SN中的查询消息处理单元24从存储单元22存储的用户信息列表中确认该文件的位置信息是否在该列表中。如果在该列表中，则在步骤S74，响应消息创建单元25通过通信单元26向该用户节点发送该资源的位置信息。如果不在该列表中，而该列表中仅仅给出了该位置信息存储在SN-R1上，则在步骤S77，SN的重定向消息创建单元24创建表示该位置信息存储在SN-R1上的重定向消息，并且通过通信单元26发送给用户节点。

然后，在步骤S78，用户节点的重定向消息处理单元13接收到重定向消息后，更新存储单元12中的服务器列表，并且由查询消息创建单元14向SN-R1发出查询请求。

接下来，在步骤S74，SN-R1向用户节点返回该资源的位置信息。

可见，根据本发明的实施例，对于流行文件(图4中D1)的查询的过程，由用户(图中D)请求本域中的服务器(图4中SNI)，由服务器直接返回相关的用户信息。对于非流行文件(图4中D2)，用户的第一次请求，也是发给本域中的服务器(SN-I)，SN-I查询它的元数据路由表，发现文件D2的对应项为SN-R1的地址，SN-I向用户D发出重定向消息，用户D收到消息该消息后修改本地的服务器路由表，然后向SN-R1发出请求。由于所有关于文件D2的用户信息都在SN-R1上，因此SN-R1直接应答用户D的请求，以后用户D的请求，通过查询服务器路由表，都可直接发给SN-R1，这样就避免了在多个服务器上查询，从而大大缩短了请求的响应时间。

根据本发明的实施例，一个文件是否流行取决于它的内容，但在某些特殊的情况下，文件的流行性也会发生变化，例如在夜间P2P网络系统中大多数用户都会下线，这时流行文件在每个SN上的用户信息都会变少，成为非流行文件。在这个时候，将这些信息集中在SNR上，会给请求用户带来性能上的提高。因此，需要在SN和SN-R之间相互转移流行性发生变化的文件位置信息。

图8是根据本发明另一实施例的网络中网络服务器的结构示意图。如图8所示，除了与图5所示的相同的组件之外，根据本发明实施例的超级节点还包括信息监视单元27、转移消息创建单元28和转移消息处理单元29。根据本实施例，在根据前一实施例的SN上添加信息监视单元27来监视文件资源的流行性(即同时访问该文件的用户数量)以及相关的转移文件的位置信息的转移消息创建单元28和处理来自其他SN的转移消息的转移消息处理单元29。如果文件由流行变为非流行，则由转移消息创建单元29将存储单元22存储的本地元数据表中相应的用户信息转移到对应的SN-R上，并将该SN-R的地址设置在本地元数据表中，这以后若有用户请求该文件，SN的重定向消息创建单元23创建重定向消息并通知用户，反之亦然。

如图8所示，信息监视单元27监视元数据表中文件流行性的变化。根据本发明的实施例，判断文件流行性变化的原则是：在SN上，如果指定时间段内，文件访问或拥有用户数量始终小于指定的阈值，则认为文件变为非流行；在SNR上，如果指定时间段内，文件访问或拥有用户数量始终高于指定的阈值，则认为文件变为流行。

转移消息创建单元28构造转移消息，并发送给相应的SNR。根据本发明的实施例，SN-R的选取是通过对文件DataID进行哈希后得到的值决定的，本发明实施例中，采用的哈希算法为一致性哈希(Consistent Hash)算法。对网络中的n个非流行文件和k个SN-R，该算法能够保证每个SN-R近似的处理n/k个文件，从而解决了SN-R的负载平衡问题。SN-R上的该组件将消息发给缓存中的该文件对应的所有SN。

转移消息处理单元29从网络中获取转移消消息，从中提取转移的资源的位置信息，并将它们插入到本地存储单元的元数据表中，在SN-R上的该组件同时缓存SN的地址。

上面的描述仅用于实现本发明的实施方式，本领域的技术人员应该理解，在不脱离本发明的范围的任何修改或局部替换，均应该属于本发明的权利要求来限定的范围，因此，本发明的保护范围应该以权利要求书的保护范围为准。