CN103457972B - 一种p2p系统的节点信息处理方法和系统 - Google Patents

Abstract

本发明实施例公开了一种P2P系统的节点信息处理方法和系统。该方法包括：根据用户对文件的需求程度确定热门文件，将每个热门文件的在线对等节点Peer信息注册到两个以上的后端逻辑服务器TrackerApp；接收查询文件的在线Peer节点信息的请求，判断所述文件是否为热门文件，如果是热门文件，则从注册了该热门文件的在线Peer节点信息的两个以上TrackerApp服务器中选择TrackerApp服务器，从选出的TrackerApp服务器查询该热门文件的在线peer节点信息。应用本发明能够提高P2P系统的稳定性。

Description

一种P2P系统的节点信息处理方法和系统

技术领域

本发明涉及网络技术领域，尤其涉及一种P2P系统的节点信息处理方法和系统。

背景技术

随着互联网业务的发展，对带宽的需求与日俱增，例如，大型网络游戏的安装包达到几十G，下载安装包需要较大的带宽，随着网页游戏内容和场景越来越复杂，通过浏览器加载的网页游戏也需要较大的带宽。

目前，在不增加服务器带宽投入的情况下，降低互联网业务服务提供商带宽消耗最有效的办法，是采用端对端(P2P)技术，让终端之间相互传递大部分数据。

P2P技术，又称对等互联网络技术，是一种网络新技术，依赖网络中参与者的计算能力和带宽，而不是依赖较少几台服务器上的计算能力和带宽。参与节点之间是一种对等关系，节点在享受服务的同时，也为其他节点服务，他们共同组成了P2P网络。

在P2P网络中，如果对等节点(peer)除了包括用户计算机外，还包括服务器，则该P2P网络可以称为点对服务器和点(Peer to Server&Peer，P2SP)网络,也就是说P2SP网络还可以索引第三方服务器的资源。

目前，在P2P网络中，例如，在P2SP网络中，采用跟踪(Tracker)服务器实现P2P网络中节点信息的实时注册、在线心跳维持和节点索引信息的查询。Tracker服务器采用两层结构，包括前端接入服务器(TrackerConn)和后端逻辑服务器(TrackerApp)。其中，TrackerConn服务器设置有和客户端进行通讯的接口，负责接收客户端的下载请求，将客户端心跳和peer节点查询请求转发给后端的TrackerApp服务器；TrackerApp服务器负责索引对于每个文件当前有哪些peer节点在线、即有哪些peer节点已将下载或正在下载该文件，根据peer节点查询请求，选择相应的Peer节点，并将选择的peer节点通过TrackerConn服务器返回给客户端。

图1是目前的Tracker服务器架构图。

如图1所示，目前的Tracker服务器并行部署有多台TrackerConn服务器，每个TrackerConn服务器管理一些客户端节点，每个客户端节点只限跟一个TrackerConn服务器通信，根据TCP协议或UDP协议向TrackerConn服务器上报心跳信息、或发送节点查询请求。其中，每个TrackerConn服务器和每个TrackerApp服务器保持连接。

如图1所示，目前的Tracker服务器也部署有多个TrackerApp服务器，每个TrackerApp服务器负责索引一部分文件的在线peer节点信息，并提供更新和查询在线peer节点信息的功能。

具体地，每个TrackerApp服务器根据文件哈希(Hash)分段，索引一个Hash段的文件。例如，文件Hash的首字节取值范围是0-FF，转换为10进制数为0-255，如果Tracker服务器部署有4个TrackerApp服务器，则将文件Hash的首字节取值范围平均分为4段，根据文件Hash的首字节的取值所在的分段，每个TrackerApp服务器负责一个分段对应的文件的Peer节点索引信息，即负责其Hash首字节取值落在该分段的文件的Peer节点索引信息，并提供相应的Peer节点信息查询功能。

下面对现有技术中客户端与Tracker服务器之间的通信流程以及Tracker服务器的工作流程进行说明。

首先，客户端与Tracker服务器进行通信的第一步，是通过TCP方式或UDP方式，获取Tracker服务器的一个TrackerConn服务器的地址，以便客户端与该TrackerConn服务器进行通信。其中，Tracker服务器的各个TrackerConn服务器以轮询的方式，将其中一个TrackerConn服务器的地址发给客户端。

客户端与TrackerConn服务器的通信，包括向该TrackerConn服务器上报心跳消息、文件更新消息或文件下载请求等。

其中，TrackerConn服务器接收到客户端上报的心跳消息后，经过一个同步时间间隔，例如1分钟，再向TrackerApp服务器同步客户端的心跳消息，TrackerApp服务器根据客户端的心跳消息，更新在线Peer节点信息。

TrackerConn服务器接收客户端上报的文件更新消息，包括该客户端已添加新文件的消息、或已删除已有文件的消息等，文件更新消息中携带有已添加或已删除文件的Hash信息。TrackerConn服务器根据客户端上报的文件更新消息中携带的Hash信息所在的Hash分段，将该文件更新消息同步给负责该Hash分段的TrackerApp服务器，TrackerApp服务器根据该文件更新消息更新该文件的在线Peer节点信息。

TrackerConn服务器接收客户端上报的文件下载请求，根据客户端请求下载的文件的Hash值所在的Hash分段，向负责该Hash分段的TrackerApp服务器发送Peer节点查询请求，该Peer节点查询请求中携带有客户端请求下载的文件的Hash信息。TrackerApp服务器根据Peer节点查询请求中携带的文件Hash信息，查找对应的在线Peer节点列表，根据预定的选择方法，从该在线Peer节点列表中选择Peer节点信息，将选出的Peer节点信息通过TrackerConn服务器返回给客户端。

为了提高在线Peer节点信息的查询速度、减小TrackerApp服务器的负载压力，在实际运营中，还常常在TrackerConn服务器中设置缓存(Cache)模块，其中缓存有部分文件的部分在线Peer节点信息，其中缓存的每个文件的在线Peer节点信息的个数一般不大于30个。TrackerConn服务器接收到客户端的文件下载请求后，首先查询自身缓存模块中是否缓存有该文件的在线Peer节点信息，如果是，则直接从所述缓存模块中选取在线Peer节点信息返回给客户端。

在通常情况下，用户下载的内容文件Hash分布非常广泛，单个文件同时下载的并发人数只有几千，此时，图1所示的Tracker服务器工作得很好。但是在面对游戏或者系统软件补丁发布，短时间内单个文件有非常巨大下载需求时，例如，并发人数达到几万个，同时超过几十万个人共享同一个文件，此时请求下载的客户端很多，候选的peer节点也很多，图1所示的Tracker系统面对这种单个文件有大量客户端请求下载同一文件和大量Peer节点在线的场景，存在如下几个问题：

由于图1所示Tracker服务器依据文件Hash的首字节进行分段，每个TrackerApp服务器根据文件哈希(Hash)分段，索引一个Hash段的文件，因此，对于负责热门文件所在的Hash段的TrackerApp服务器，由于该TrackerApp服务器接收的Peer节点信息查询请求较多，候选的Peer节点信息也较多，因此很容易使得该TrackerApp服务器负载过高，无法提供正常的服务，而且，Peer节点的查询响应速度也较慢。

另外，当通过在TrackerConn服务器中设置Cache模块，来减轻TrackerApp服务器的负载压力时，由于Cache模块中缓存的Peer节点信息有限，因此将导致一段时间内从Cache模块中查询到的Peer节点信息也有限，此段时间内大量请求文件下载的客户端查询到的都是Cache模块中缓存的同一批Peer节点信息，导致该批Peer节点需要为大量的客户端提供服务，而其他Peer节点却可能出于空闲状态，一方面，该批Peer节点的服务能力无法保证，另一方面，Peer节点资源的利用效率也较低。

可见，现有的Tracker服务器在有热门文件需要下载的场景下，部分TrackerApp服务器的负载压力过大，P2P系统稳定性较差，而且Peer节点信息查询的响应速度也较慢。

发明内容

有鉴于此，本发明提供了一种P2P系统的节点信息处理方法和系统，以便提高P2P系统的稳定性。

本发明的技术方案具体是这样实现的：

一种P2P系统的节点信息处理方法，该方法包括：

根据用户对文件的需求程度确定热门文件，将每个热门文件的在线对等节点(Peer)信息注册到两个以上的后端逻辑服务器(TrackerApp)；

接收查询文件的在线Peer节点信息的请求，判断所述文件是否为热门文件，如果是热门文件，则从注册了该热门文件的在线Peer节点信息的两个以上TrackerApp服务器中选择TrackerApp服务器，从选出的TrackerApp服务器查询该热门文件的在线peer节点信息；

在客户端与在线Peer节点交互数据之前，接收所述在线Peer节点发来的文件在线Peer节点信息。

一种P2P系统的节点信息处理系统，该系统包括确定模块、注册模块和查询模块；

所述确定模块，用于根据用户对文件的需求程度确定热门文件；

所述注册模块，用于将每个热门文件的在线对等节点(Peer)信息注册到两个以上的后端逻辑服务器(TrackerApp)；

所述查询模块，用于接收查询文件的在线Peer节点信息的请求，判断所述文件是否为热门文件，如果是热门文件，则从注册了该热门文件的在线Peer节点信息的两个以上TrackerApp服务器中选择TrackerApp服务器，从选出的TrackerApp服务器查询该热门文件的在线peer节点信息，在客户端与在线Peer节点交互数据之前，接收所述在线Peer节点发来的文件在线Peer节点信息。

由上述技术方案可见，本发明根据用户对文件的需求程度确定热门文件，将每个热门文件的在线Peer节点信息注册到两个以上的TrackerApp服务器上，在接收到查询文件的在线Peer节点信息的请求后，首先判断所述文件是否为热门文件，如果是热门文件，则从注册了该热门文件的在线Peer节点信息的两个以上TrackerApp服务器中选择TrackerApp服务器，从选出的TrackerApp服务器查询该热门文件的在线peer节点信息。

可见，本发明通过对文件进行区别对待，对于热门文件，将其在线Peer节点信息注册到了两个以上的TrackerApp服务器上，因此，当查询热门文件的在线Peer节点信息时，可以由两个以上的TrackerApp服务器提供相应的在线Peer节点信息，与现有技术中针对所有的文件，都根据文件Hash分段，将文件的在线Peer节点信息仅注册到一个TrackerApp服务器，对于所有文件，都仅由一个TrackerApp服务器提供在线Peer节点信息相比，本发明能够使得P2P系统在有热门文件需要下载的场景下，能够避免部分TrackerApp服务器负载压力过大，提高P2P系统的稳定性，而且，由于本发明可以由多个TrackerApp服务器提供热门文件的在线Peer节点信息，因此，也能够提高Peer节点信息查询的响应速度。

附图说明

图1是目前的Tracker服务器架构图。

图2是本发明提供的P2P系统的节点信息处理方法流程图。

图3是本发明提供的P2P系统的节点信息处理系统组成示意图。

图4是本发明提供的P2P系统架构以及通信流程示意图。

具体实施方式

图2是本发明提供的P2P系统的节点信息处理方法流程图。

如图2所示，该流程包括：

步骤201，根据用户对文件的需求程度确定热门文件。

步骤202，将每个热门文件的在线Peer节点信息注册到两个以上的TrackerApp服务器上。

步骤203，接收查询文件的在线Peer节点信息的请求。

步骤204，判断所述文件是否为热门文件，如果是热门文件，则执行步骤205，如果不是热门文件，执行步骤206。

步骤205，从注册了该热门文件的在线Peer节点信息的两个以上TrackerApp服务器中选择TrackerApp服务器，从选出的TrackerApp服务器查询该热门文件的在线peer节点信息，结束本流程。

步骤206，从注册了所述文件的在线Peer节点信息的TrackerApp服务器查询该文件的在线Peer节点信息，结束本流程。

图2所示方法中，根据用户对文件的需求程度确定热门文件的具体方法可以有多种，例如，接收客户端上报的文件下载信息，根据客户端上报的文件下载信息统计文件下载频率，根据统计出的文件下载频率确定热门文件，例如，判断某文件的文件下载频率是否大于预定阈值，如果大于，则判定该文件为热门文件，否则判定该文件不是热门文件；或者，也可以根据TrackerConn服务器上的文件注册频率确定热门文件，例如，判断某文件的文件注册频率是否大于预定阈值，如果大于，则判定该文件为热门文件，否则判定该文件不是热门文件。再例如，也可以根据用户习惯等预测某一文件是否为热门文件，例如可以预测某一系统软件的补丁文件为热门文件。

其中，在将热门文件的在线Peer节点信息注册到两个以上的TrackerApp服务器上时，也可以根据文件的下载频率或注册频率确定需要注册的TrackerApp服务器个数，热门文件的下载频率或注册频率越高，则注册的TrackerApp服务器个数越多。

图2所示方法中，TrackerApp服务器可以向TrackerConn服务器发送注册消息，所述注册消息包括所述TrackerApp服务器允许注册的文件信息，则所述将每个热门文件的在线Peer节点信息注册到两个以上的TrackerApp服务器具体可以包括：TrackerConn服务器根据TrackerApp服务器的注册消息，将每个热门文件的在线Peer节点信息注册到两个以上的TrackerApp服务器。

对于非热门文件，TrackerConn服务器也可以根据TrackerApp服务器的注册消息，将非热门文件的在线Peer节点信息注册到允许注册该非热门文件的在线Peer节点信息的TrackerApp服务器上。

其中，TrackerApp服务器允许注册的文件信息可以有多种形式，例如可以是允许注册的文件的Hash信息、或允许注册的文件的名称、或其他能够区分不同文件的唯一标识。

TrackerApp服务器可以有多种方法获知哪些文件是热门文件，从而在发给TrackerConn服务器的允许注册的文件信息中，携带热门文件信息。

例如，可以在潜在热门文件发布以前，将该潜在热门文件信息携带在两个以上的TrackerApp服务器发送的允许注册的文件信息中，例如，在游戏或系统软件补丁文件发布以前，可以确定该补丁文件为潜在热门文件，将该补丁文件的文件信息携带在第一TrackerApp服务器发送的允许注册的文件信息中、以及第二TrackerApp服务器发送的允许注册的文件信息中。

再例如，也可以通过在TrackerConn服务器中新增统计模块，利用该统计模块接收客户端上报的文件下载信息，根据客户端上报的文件下载信息统计文件下载频率，根据统计出的文件下载频率确定热门文件，或者，根据TrackerConn服务器上的文件注册频率确定热门文件。然后根据统计模块统计出的热门文件信息，配置两个以上的TrackerApp服务器允许注册该热门文件的在线Peer节点信息。

TrackerApp服务器也可以不用获知哪些文件是热门文件，即不用在发给TrackerConn服务器的允许注册的文件信息中携带热门文件信息，而是默认所有或若干个TrackerApp服务器允许注册任意热门文件的在线Peer节点信息、或由TrackerApp服务器在允许注册的文件信息中携带一标识，用于表示该TrackerApp服务器允许注册任意热门文件的在线Peer节点信息，则TrackerConn服务器可以将热门文件注册到允许注册任意热门文件的在线Peer节点信息的任意TrackerApp服务器上，并且记录将哪些热门文件的在线Peer节点信息注册到了哪些TrackerApp服务器上。

根据TrackerApp服务器的注册消息，将热门文件的在线Peer节点信息注册到两个以上的TrackerApp服务器的方法，便于实现对TrackerApp服务器的灵活配置和调度。

除了可以根据TrackerApp服务器的注册消息，将热门文件的在线Peer节点信息注册到两个以上的TrackerApp服务器以外，还可以一方面根据文件Hash信息分段，将文件的在线Peer节点信息注册到该文件的Hash值所在Hash分段对应的TrackerApp服务器，另一方面，对于热门文件，还将该热门文件的在线Peer节点信息注册到预设的若干个TrackerApp服务器上，并且记录每个TrackerApp服务器上都注册有哪些文件的在线Peer节点信息。

图2所示方法中，可以由TrackerConn服务器将每个热门文件的在线Peer节点信息注册到两个以上的TrackerApp服务器，记录每个TrackerApp服务器上都注册有哪些文件的在线Peer节点信息，并且，也由TrackerConn服务器接收客户端发来的查询文件的在线Peer节点信息的请求，由该TrackerConn服务器判断所述文件是否为热门文件，如果是热门文件，则从注册了该热门文件的在线Peer节点信息的两个以上TrackerApp服务器中选择TrackerApp服务器，从选出的TrackerApp服务器查询该热门文件的在线peer节点信息。

图2所示方法中，也可以将查询文件的在线Peer节点信息的功能从TrackerConn服务器上独立出来，由另一查询服务器(TrackerQuery)实现文件在线Peer节点信息的查询，即将客户端的注册信息(包括心跳信息、文件更新信息等)与客户端的在线Peer节点查询信息相隔离，二者走不同的服务器入口，从而进一步降低TrackerConn服务器的负载。

具体地，由前端接入服务器(TrackerConn)将每个热门文件的在线Peer节点信息注册到两个以上的TrackerApp服务器，TrackerConn服务器将每个TrackerApp服务器上注册有哪些文件的在线Peer节点信息同步给查询服务器(TrackerQuery)。由TrackerQuery服务器接收查询文件的在线Peer节点信息的请求，判断所述文件是否为热门文件，如果是热门文件，则从注册了该热门文件的在线Peer节点信息的两个以上TrackerApp服务器中选择TrackerApp服务器，从选出的TrackerApp服务器查询该热门文件的在线peer节点信息。

其中，当从注册了热门文件的在线Peer节点信息的两个以上TrackerApp服务器中选择TrackerApp服务器时，为了保证选出的TrackerApp服务器是当前在线的TrackerApp服务器，本发明提出，TrackerQuery服务器根据TrackerApp服务器注册的心跳信息，确定在线的TrackerApp服务器，从注册了该热门文件的在线Peer节点信息的两个以上TrackerApp服务器中，根据预定原则选择在线的TrackerApp服务器。

其中，所述预定原则可以有多种，典型地，可以随机选择在线的TrackerApp服务器、或根据负载均衡的原则选择TrackerApp服务器，或者根据发送查询请求的客户端与提供在线Peer节点信息的TrackerApp服务器属于同一地理区域的原则选择TrackerApp服务器。

为了进一步降低TrackerConn服务器和TrackerApp服务器的负载压力，提高系统的容错性，使得在TrackerConn服务器或TrackerApp服务器出现问题时，客户端仍然能够查询到有效的Peer节点信息，本发明还提出，客户端在与在线Peer节点交互数据之前，还可以接收所述在线Peer节点发来的文件在线Peer节点信息、和/或向所述在线Peer节点发送该客户端存储的文件在线Peer节点信息，实现在线Peer节点之间交互彼此的在线Peer节点信息。其中，当客户端主动提供文件的在线peer节点信息时，如果对方感兴趣，可以接受该在线Peer节点信息，如果不感兴趣，也可以直接拒绝接收该在线Peer节点信息。

根据本发明提供的上述方法，本发明还提供了一种P2P系统的节点信息处理系统，具体请参见图3。

图3是本发明提供的P2P系统的节点信息处理系统组成示意图。

如图3所示，该系统包括确定模块301、注册模块302和查询模块303。

确定模块301，用于根据用户对文件的需求程度确定热门文件。

注册模块302，用于将每个热门文件的在线Peer节点信息注册到两个以上的TrackerApp服务器上。

查询模块303，用于接收查询文件的在线Peer节点信息的请求，判断所述文件是否为热门文件，如果是热门文件，则从注册了该热门文件的在线Peer节点信息的两个以上TrackerApp服务器中选择TrackerApp服务器，从选出的TrackerApp服务器查询该热门文件的在线peer节点信息。

其中的注册模块302可以位于TrackerConn服务器中，查询模块303可以位于TrackerQuery服务器中，注册模块302将每个TrackerApp服务器上注册有哪些文件的在线Peer节点信息同步给所述TrackerQuery服务器。

其中，TrackerQuery服务器可以根据TrackerApp服务器注册的心跳信息，确定在线的TrackerApp服务器，从注册了该热门文件的在线Peer节点信息的两个以上TrackerApp服务器中，根据预定原则选择在线的TrackerApp服务器，从而从选出的TrackerApp服务器查询热门文件的在线Peer节点信息。

其中，确定模块301具体可以包括统计模块。

所述统计模块，用于接收客户端上报的文件下载信息，根据客户端上报的文件下载信息统计文件下载频率，根据统计出的文件下载频率确定热门文件，或者，根据TrackerConn服务器上的文件注册频率确定热门文件。

其中，TrackerApp服务器可以向TrackerConn服务器发送注册消息，所述注册消息包括所述TrackerApp服务器允许注册的文件信息，TrackerConn服务器根据TrackerApp服务器的注册消息，将每个热门文件的在线Peer节点信息注册到两个以上的TrackerApp服务器。

客户端在与在线Peer节点交互数据之前，可以接收在线Peer节点发来的文件在线Peer节点信息、和/或向所述在线Peer节点发送该客户端存储的文件在线Peer节点信息。

另外，本发明提供的上述方法和系统中，不需要在TrackerConn服务器上设置缓存模块，而是直接从TrackerApp服务器上查询在线Peer节点信息，因此，能够有效利用所有的在线Peer节点信息，避免在一段时间内大量客户端共用少部分在线Peer节点信息的问题。

下面举一个具体的例子，对本发明提供的技术方案进行示例性说明，具体请参见图4。需要说明的是，图4所示例子并不用于限制本发明。

图4是本发明提供的P2P系统架构以及通信流程示意图。

如图4所示，该P2P系统包括下载客户端、TrackerConn服务器、TrackerApp服务器、TrackerQuery服务器和统计服务器。其中，TrackerQuery服务器和统计服务器是新增的服务器。

下面对上述P2P系统中的各个组成部分及其相互之间的通信流程进行详细介绍。

下载客户端，一方面定期向TrackerConn服务器上报该下载客户端的在线情况和本地拥有的资源信息，即向TrackerConn服务器注册心跳信息和本地的文件信息；另一方面，向TrackerQuery服务器查询文件的在线Peer节点信息；再一方面，作为从TrackerQuery服务器查询在线Peer节点信息的有益补充，还可以在和其他下载客户端交互数据之前，相互交互文件的在线Peer节点信息。下载客户端从查询到的Peer节点下载自己需要的数据分块，还可以在下载完成后，向统计服务器上报本次下载任务的文件信息、下载时间、下载速度、下载结果、文件大小、下载耗时等信息。

其中的TrackerConn服务器，向下载客户端提供其他TrackerConn服务器的列表，供下载客户端选择其进行接入的TrackerConn服务器；和通过该TrackerConn服务器接入的下载客户端维持节点心跳信息、添加或删除等文件注册信息的通信；根据下载客户端发来的文件注册信息，统计通过该TrackerConn服务器注册的文件的注册频率，根据文件的注册频率确定热门文件，并向多个TrackerApp服务器注册热门文件的在线Peer节点信息，同时记录注册对应列表，即在每个TrackerApp上都注册有哪些文件的在线Peer节点信息，并将注册对应列表同步给TrackerQuery服务器。

其中的TrackerApp服务器，接收TrackerConn服务器注册的在线Peer节点信息，存储文件的在线Peer节点信息列表；实现具体的在线Peer节点信息选择功能，从而为TrackerQuery服务器提供在线Peer节点查询服务；和TrackerQuery服务器之间维持心跳信息，主动向TrackerQuery服务器注册心跳信息。

其中的TrackerQuery服务器，接收下载客户端的在线Peer节点信息查询请求，根据TrackerConn同步的注册对应列表，向多个TrackerApp服务器中的任意TrackerApp服务器查询热门文件的在线Peer节点信息；接收TrackerApp服务器注册的心跳信息，如果根据心跳信息确定出某一TrackerApp服务器不在线，则不向该TrackerApp服务器发送在线Peer节点信息查询请求。

其中的统计服务器，接收下载客户端下载完成后或下载过程中上报的文件下载信息，包括下载的文件信息、下载速度、下载结果、下载耗时等信息，将下载客户端上报的文件下载信息写成流水日志，以供统计分析，例如，可以用于确定热门文件。

可见，本发明通过将热门文件的在线Peer节点信息注册到多个TrackerApp服务器上，使得可以从多个TrackerApp服务器查询热门文件的在线Peer节点信息，避免了现有技术中注册有热门文件的在线Peer节点信息的TrackerApp服务器负载压力过大的问题；另外，通过下载客户端之间交互在线Peer节点信息，也可以减轻对TrackerConn服务器和TrackerApp服务器的依赖，提高系统的整体容错性和可靠性，下载客户端在高峰时候能够获取更多有效的peer种子，实现高效下载客户端数据信息的传播；再者，通过直接从TrackerApp服务器获得在线Peer节点信息，可以避免现有技术中对缓存模块的依赖，提升查询到的peer种子总体的联通效率。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (10)

1.一种P2P系统的节点信息处理方法，其特征在于，该方法包括：

根据用户对文件的需求程度确定热门文件；

将每个热门文件的在线对等节点Peer信息注册到两个以上的后端逻辑服务器TrackerApp；

接收查询文件的在线对等节点Peer信息的请求，判断所述文件是否为热门文件，如果是热门文件，则从注册了该热门文件的在线对等节点Peer信息的两个以上后端逻辑服务器TrackerApp中选择后端逻辑服务器TrackerApp，从选出的后端逻辑服务器TrackerApp查询该热门文件的在线对等节点Peer信息；

在客户端与在线Peer节点交互数据之前，接收所述在线Peer节点发来的文件在线对等节点Peer信息；

所述方法进一步包括：

所述后端逻辑服务器TrackerApp向前端接入服务器TrackerConn发送注册消息，所述注册消息包括所述后端逻辑服务器TrackerApp允许注册的文件信息；

所述将每个热门文件的在线对等节点Peer信息注册到两个以上的后端逻辑服务器TrackerApp包括：

所述前端接入服务器TrackerConn根据所述后端逻辑服务器TrackerApp发送的注册消息，将每个热门文件的在线对等节点Peer信息注册到两个以上的后端逻辑服务器TrackerApp。

2.根据权利要求1所述的方法，其特征在于，根据用户对文件的需求程度确定热门文件包括：

接收客户端上报的文件下载信息，根据客户端上报的文件下载信息统计文件下载频率，根据统计出的文件下载频率确定热门文件；

或者，根据所述前端接入服务器TrackerConn上的文件注册频率确定热门文件。

3.根据权利要求1所述的方法，其特征在于，

由所述前端接入服务器TrackerConn将每个热门文件的在线对等节点Peer信息注册到两个以上的后端逻辑服务器TrackerApp，所述前端接入服务器TrackerConn将每个后端逻辑服务器TrackerApp上注册有哪些文件的在线对等节点Peer信息同步给查询服务器TrackerQuery；

由查询服务器TrackerQuery接收查询文件的在线对等节点Peer信息的请求，判断所述文件是否为热门文件，如果是热门文件，则从注册了该热门文件的在线对等节点Peer信息的两个以上后端逻辑服务器TrackerApp中选择后端逻辑服务器TrackerApp，从选出的后端逻辑服务器TrackerApp查询该热门文件的在线对等节点Peer信息。

4.根据权利要求1所述的方法，其特征在于，从注册了该热门文件的在线对等节点Peer信息的两个以上后端逻辑服务器TrackerApp中选择后端逻辑服务器TrackerApp包括：

查询服务器TrackerQuery根据后端逻辑服务器TrackerApp注册的心跳信息，确定在线的后端逻辑服务器TrackerApp，从注册了该热门文件的在线对等节点Peer信息的两个以上后端逻辑服务器TrackerApp中，根据预定原则选择在线的后端逻辑服务器TrackerApp。

5.根据权利要求1所述的方法，其特征在于，该方法还包括：

客户端在与在线Peer节点交互数据之前，向所述在线Peer节点发送该客户端存储的文件在线对等节点Peer信息。

6.一种P2P系统的节点信息处理系统，其特征在，该系统包括确定模块、注册模块和查询模块；

所述确定模块，用于根据用户对文件的需求程度确定热门文件；

所述注册模块，用于将每个热门文件的在线对等节点Peer信息注册到两个以上的后端逻辑服务器TrackerApp；

所述查询模块，用于接收查询文件的在线对等节点Peer信息的请求，判断所述文件是否为热门文件，如果是热门文件，则从注册了该热门文件的在线对等节点Peer信息的两个以上后端逻辑服务器TrackerApp中选择后端逻辑服务器TrackerApp，从选出的后端逻辑服务器TrackerApp查询该热门文件的在线对等节点Peer信息，在客户端与在线Peer节点交互数据之前，接收所述在线Peer节点发来的文件在线对等节点Peer信息；

其中，所述后端逻辑服务器TrackerApp发送注册消息，所述注册消息包括所述后端逻辑服务器TrackerApp允许注册的文件信息；

所述注册模块根据所述后端逻辑服务器TrackerApp发送的注册消息，将每个热门文件的在线对等节点Peer信息注册到两个以上的后端逻辑服务器TrackerApp。

7.根据权利要求6所述的系统，其特征在于，所述确定模块包括统计模块；

所述统计模块，用于接收客户端上报的文件下载信息，根据客户端上报的文件下载信息统计文件下载频率，根据统计出的文件下载频率确定热门文件，或者，根据前端接入服务器TrackerConn上的文件注册频率确定热门文件。

8.根据权利要求6所述的系统，其特征在于，

所述注册模块位于前端接入服务器TrackerConn中，所述查询模块位于查询服务器TrackerQuery中，所述注册模块将每个后端逻辑服务器TrackerApp上注册有哪些文件的在线对等节点Peer信息同步给所述查询服务器TrackerQuery。

9.根据权利要求6所述的系统，其特征在于，

查询服务器TrackerQuery根据后端逻辑服务器TrackerApp注册的心跳信息，确定在线的后端逻辑服务器TrackerApp，从注册了该热门文件的在线对等节点Peer信息的两个以上后端逻辑服务器TrackerApp中，根据预定原则选择在线的后端逻辑服务器TrackerApp。

10.根据权利要求6所述的系统，其特征在于，

客户端在与在线Peer节点交互数据之前，向所述在线Peer节点发送该客户端存储的文件在线对等节点Peer信息。