CN103036964A - 一种基于p2p的网吧服务器数据更新方法 - Google Patents

Abstract

本发明公开了一种基于P2P的网吧服务器数据更新方法，包括：(1)获取索引文件和节点列表；(2)比较索引文件，得到下载列表；(3)根据节点列表，建立P2P连接；(4)建立数据块资源列表；(5)与P2P节点进行数据交互。本发明通过将P2P自助网络通过群落模型表现出来，解决了P2P网络动态组网及自我进化的完整过程，使得P2P网络自适应于动态变化的不同环境下，达成较优的组网效果和较高的资源同步效果；同时合理规划下载热度分布，均衡IDC带宽对于差异数据请求分布，合理利用用户的带宽，以达到提供同步速度的效果；组网效果优，数据分发分享效率高，能有效提高整个网络数据的同步速度。

Description

一种基于P2P的网吧服务器数据更新方法

技术领域

本发明属于网络通讯技术领域，具体涉及一种基于P2P的网吧服务器数据更新方法。

背景技术

P2P(Peer-to-Peer，点对点)作为一种新型的网络应用方式，其具有一些传统Client/Server模式所不具备的优势，主要表现在信息量的扩大以及匿名服务的自由开放性等。P2P最大的优点在于能够提供可靠、便捷的信息查询，但也由于P2P网络这种缺乏中心监管以及匿名服务的特性，P2P也存在着许多自身所无法克服的不足。绝大多数的P2P服务都将不可避免地遇到知识产权问题，同时，恶意代码的传播将更快、更隐蔽，更难以控制等。

P2P技术有许多应用，共享包含各种格式音频，视频，数据等的文件是非常普遍的，即时数据(如IP电话通信、视频会议系统)也可以使用P2P技术来传送。通用P2P技术有以下的几个关键点：

(1)资源定位：资源定位是节点通过一定方式找到资源在网络中的存放位置，P2P方式的资源定位主要有以下三种算法：

集中索引算法，用户都与一个中央服务器相连接，中央服务器上保存了共享文件的索引，由中央服务器对收到的用户请求进行匹配查找，直到找到保存了所需文件的目的用户。然后，由发起请求的用户与目的用户直接进行文件交换。这种算法的不足在于依赖一个集中式的结构，将会影响系统的可扩展性。

洪泛消息算法，每一个用户消息都将被广播给与该用户直接相连的若干其他用户，这些用户收到消息后，也同样地将消息广播给各自连接的用户，以此类推，直到请求被应答，消息的TTL值减少为0，或超过了最大的广播次数(通常为5～9)。这种算法的不足在于占用的网络带宽较大，因此也会影响可扩展性。

文件路由算法，算法的特点是采用基于哈希函数的映射。系统中的每一个用户都有一个随机的ID序列号，系统中的每一个文件也有一个ID序列号，该序列号是根据文件的内容和它的名字，经过哈希函数映射得来的。文件发布时，每一个用户都把文件转发到拥有与文件的ID最相近ID值的用户，直到最接近文件ID的用户就是该用户本身。转发过程中每经过的一个用户都将保持该文件的副本。索取文件时，每个用户都将请求消息转发给一个拥有与所需文件ID最相近的ID用户，直到文件或文件的一个拷贝被发现为止。这种算法的优势在于可扩展性较好，不足在于可能导致整个网络分裂成若干彼此不相连的子网络，形成所谓的孤岛，其查询也要比洪泛消息算法麻烦些。

(2)多源传输：为了提高一些多用户同时下载热点文件的传输速率，P2P网络普遍采用多源传输策略(MFTP协议)。该协议定义了一系列传输、压缩和打包的标准，甚至还定义了一套积分的标准，上传的数据量越大，积分越高，下载的速度也越快。MFTP协议允许用户之间多点下载文件，多用户同时下载一个文件时，将该文件分段，每个用户下载其中的一部分。P2P节点软件在网络上搜索下载同一个文件的用户，然后从这些用户那里下载该文件不同的块，并检查每一块是否受到破坏，以保证传输的正确性，最后将所有的块组合成原来的文件。MFTP充分利用下载用户之间的带宽传输数据，从而减轻服务器负担，提高下载速度和系统的可扩展性。多源传输机制的出现使得P2P技术在信息传输方面拥有网络层传输无法比拟的优势。

而对于网吧行业游戏数据的更新业务，和一般意义上的数据同步共享业务有一些区别和特点：

网吧更新游戏时间集中；是一种单向的数据同步过程(即IDC端上传完成了一款最新版本的游戏数据，所有网吧的服务器都会在极短的时间段内，大量集中请求下载，且网吧本身不能发布资源供其他网吧下载)，个人用户的下载时间离散且规模不可控。

游戏更新量巨大；其中即包含需要更新的游戏数量巨大(每天100款)、也包含一款游戏本身需要更新的数据量巨大(魔兽世界大版本更新一般10GB以上)；个人用户下载数据更新量较离散，其中大更新量(100MB以上)数据下载频率不高。

网吧对下载时长超时的容忍度小；例如魔兽世界游戏大版本更新一般中间只有8～10个小时左右的停服时间。如果更新不及时会导致网吧安装的客户端由于版本失配的原因，无法正常使用；个人用户对下载及时性容忍度较大。

正是这些业务特点，使得基于大更新量的P2P下载技术改进比通用的P2P软件有了潜在的着力点。

结合网吧行业数据更新特点(大数据量，短时间大并发)，现有对于网吧服务器间P2P技术实质是基于传统Client/Server模式的变型(即需求方最大化的发现潜在资源并请求，服务方尽可能简单提供服务)，而P2P的实质是互助式的自适应网络系统，除了追求下载性能提高，同样重视信息的共享和服务。

现有技术的请求数据策略无法统筹规划，不能充分利用本行业的数据传播特性，使得P2P真正的利用率损失，同时IDC服务器请求量过大，使得短期内IDC服务器带宽被大量请求的少数热点数据撑满，导致差异化数据分发效率低，直接的影响是数据传播困难；没有充分利用用户间的网络贡献，来降低对IDC机房带宽的依赖，使得宝贵的IDC优质带宽资源没有提高数据分布规模，而被热点数据占用。

在P2P节点选点策略上，现有技术是在大量节点中随机选取一定范围的节点后，再做优先级排序的。用户间的P2P效果收到配对用户间的网络限制(即单位时间的网络传播速度由于网络原因限制，导致速度慢)，测试发现，同城同ISP的效率远比同城不同ISP的高。现有策略没有真正利用这些利用同城同ISP的点，而是随机选点后再排优先级，效果较差。

现有技术在P2P选点上还存在匹配后同步效果降低的问题，其原因是选点方不知道待选节点当前的下载情况，只能靠运气。例如A点和B点同时下载同一款资源，B点主动连接A点，A点下载总量的5％，B点下载完总量的6％，但是A和B下载完成的数据集合交集为5％，则B点无法从A点获取任何数据；并且下载完的数据分布是随机，导致请求方每次刷新节点后，可能效果更低。

在多源传输方面，现有技术简单处理的不同P2P节点间的贡献指标，以传统Client/Server的思维逻辑处理P2P节点间的供需关系。使得高质量的P2P节点处于上传流量持续攀高、迫使网管加入限速等技术，降低了用户使用P2P的积极性。

发明内容

针对现有技术所存在的上述技术缺陷，本发明提供了一种基于P2P的网吧服务器数据更新方法，组网效果优，数据分发分享效率高，能有效提高整个网络数据的同步速度。

一种基于P2P的网吧服务器数据更新方法，包括如下步骤：

(1)各网吧服务器向P2P服务器请求获取新版本数据的索引文件和节点列表；

所述的节点列表包含有所有向P2P服务器发送过请求的网吧服务器的IP信息以及拥有新版本数据的各IDC数据服务器的IP信息；

(2)网吧服务器对本地旧版本数据的索引文件与新版本数据的索引文件进行差异对比，得到下载列表；

所述的下载列表中包含有所有待下载数据块的ID信息；

(3)网吧服务器从节点列表中优选出多个P2P节点并与这些P2P节点进行信息交互，同时建立关于这些P2P节点的P2P列表；

(4)网吧服务器根据下载列表、P2P列表以及与各P2P节点交互得到的信息，建立数据块资源列表并对其实时更新；

所述的数据块资源列表包含有当前所有待下载数据块的ID信息和客户信息，待下载数据块的客户信息包括P2P列表中拥有该数据块的P2P节点的IP信息和缺少该数据块的P2P节点的IP信息；

(5)网吧服务器根据数据块资源列表与P2P列表中的P2P节点进行数据交互。

优选地，所述的步骤(3)中，网吧服务器根据节点列表向IDC数据服务器发送下载请求，IDC数据服务器根据网吧服务器的IP信息确定其起始下载切入位置，网吧服务器根据起始下载切入位置从新版本数据中对应的切入位置开始下载数据块；群落(同属相邻或相同的下载切入点，具备相似请求策略的P2P节点集合)间下载的数据是错开的，故热点数据不会太集中，提高了IDC服务程序初始时传播数据的范围，这样同步一定时间后，即使IDC数据服务器全部断开也不影响P2P节点正确同步完所有数据。

优选地，所述的步骤(3)中，网吧服务器从节点列表中优选出多个P2P节点的方法为：按同城同ISP(互联网服务提供商)-同省同ISP-同城不同ISP-同省不同ISP的优先级次序从节点列表中挑选出多个网吧服务器作为优选出的多个P2P节点；相邻IP的节点大部分情况是同ISP的相邻地域，网络互连互通性较好。

所述的步骤(5)中，网吧服务器与各P2P节点进行数据交互的方法如下：

关于下载：

网吧服务器对当前所有待下载数据块进行优先级排序，根据优先级依次下载各数据块；当下载任一数据块时，网吧服务器通过数据块资源列表确定拥有该数据块的P2P节点，从中选取一P2P节点向其下载该数据块；

关于上传：

当任一数据块下载完成后，网吧服务器先标记该数据块为已下载数据块，然后通过数据块资源列表确定缺少该数据块的P2P节点，并通知这些P2P节点该数据块已完成；P2P节点根据通知查询本地是否缺少该数据块，若缺少则向网吧服务器下载该数据块。

优选地，网吧服务器通过缓存下载数据块。能够提高请求响应的能力。

优选地，网吧服务器根据数据块资源列表对当前所有待下载数据块进行优先级排序，拥有者越少的数据块优先级越高。拥有者越少的块，表示此块需求量越大，即此块被请求的概率越高，本节点可以充分利用这些块的上传服务，有助于对端提高服务节点性能评价值，以提高本节点在其社交网络(与该节点交互的其他P2P节点集合)中地位；从整个网络来看，优先对于稀缺资源的下载，有利用差异数据在整个网络中的均匀分布，提高了数据冗余性，有益于不同数据在网络内的传播。

优选地，当下载任一数据块时，网吧服务器通过数据块资源列表确定拥有该数据块的P2P节点，从中选取单位时间P2P数据交互量最大的一P2P节点向其下载该数据块。选取P2P数据交互量最大的P2P节点，首先表示对方拥有此数据，其次说明最近一段时间内，本点和对端的网络通讯及响应速度相比其他点更好，即通过最近一段时间内的成功交互次数来预测未来一段时间内，响应最快且可靠性最高的点，结合上面优先请求稀缺数据，一旦得到此数据，将能迅速提供给大量需求方服务；反之，会出现请求时是稀缺数据，等到下载后已经不是稀缺数据了。

优选地，当任一数据块下载完成后，网吧服务器通过数据块资源列表确定缺少该数据块的P2P节点，并将提供该数据块的P2P节点推荐给缺少该数据块的P2P节点。主动通知此节点社交网络中其他需求方数据更新状态，有利于短时间内提高数据冗余度，增加数据传播强度，提高数据在整个网络的传播速度。

优选地，所述的步骤(5)中，网吧服务器与P2P节点进行数据交互的过程中，定时更新P2P列表：建立推荐列表，所述的推荐列表用于接收P2P列表中的P2P节点向网吧服务器推荐的其他P2P节点的IP信息；网吧服务器定时从P2P列表中删除若干P2P节点，并从推荐列表中补充相应数量的P2P节点至P2P列表中。一旦本节点由于非程序原因，无法提供请求方数据时，通过介绍其他有请求数据的节点信息，使得群落之间存在个体交流，对于某个节点社交网络里需要定期调整，实现新陈代谢，保证整个群落中的社交网络动态进化，保证群落的健康度，通过个体社交网络的调整，使的群落间数据也有渠道能相互流通。

进一步优选地，网吧服务器定时从P2P列表中删除单位时间P2P数据交互量最小的若干P2P节点。从P2P互助网络的性质看，数据贡献率的影响指标为数据下载率和上传率。每个节点社交网络淘汰交互低的点，目的是允许新的节点进入，同时为社交网络动态重组提供动力。

本发明的有益技术效果：

(1)本发明通过将P2P自助网络通过群落模型表现出来，解决了P2P网络动态组网及自我进化的完整过程，使得P2P网络自适应于动态变化的不同环境下，达成较优的组网效果和较高的资源同步效果。

(2)本发明尊重真实网络拓扑结构对网络通讯影响的事实，在选点初期就规避网络拓扑对P2P的影响。

(3)本发明合理规划下载热度分布，均衡IDC带宽对于差异数据请求分布，合理利用用户的带宽，以达到提供同步速度的效果。

(4)本发明重视资源互助行为，将整个互助网络的整体效果提高到合理水平。

(5)本发明能够及时同步资源到达信息以介绍可利用节点，提高了资源分享感知力，加强了P2P节点的感知维度和灵敏度。

附图说明

图1为本发明数据更新方法的步骤流程图。

图2为相同下载策略的P2P节点Downing写窗口的数据交互示意图。

图3为相同下载策略的P2P节点服务方下载进程快于请求方时Downing写窗口的数据交互示意图。

图4为不同且邻近下载策略的P2P节点Downing写窗口的数据交互示意图。

图5为不同且非邻近下载策略的P2P节点Downing写窗口的数据交互示意图。

图6为在本发明机制下和在现有机制下同机房和异地机房中各节点的平均下载速率直方图。

具体实施方式

为了更为具体地描述本发明，下面结合附图及具体实施方式对本发明的数据更新方法进行详细说明。

在数据更新传播前，先把所有的P2P节点(网吧服务器)分成若干个群落，群落的分布依赖于用户的IP或资源ID等属性；通过Hash这些信息属性将IP较近的节点分在同一群落中(如可以使IP尾号相同的节点归为同一群落)。不同的群落率先请求新版本数据的不同部分，最终达到所有群落在初始请求后就能通过P2P数据共享方式能组织成完整正确的数据，即在同步一定时间后IDC数据服务器全部断开也不影响P2P节点正确同步完所有数据。

本实施例中，运营商为全国8万家网吧提供某款游戏的数据更新业务，当该款游戏需要更新时，运营商将新版游戏的数据上传至各IDC数据服务器(全国部署五台)上，将新版本游戏数据的索引文件上传至P2P服务器上；并根据网吧服务器的IP信息通过Hash将这8万家网吧分成5个群落，每个群落为1.5万家。

如图1所示，一种基于P2P的网吧服务器数据更新方法，包括如下步骤：

(1)获取索引文件和节点列表。

所有网吧服务器均向P2P服务器请求获取新版本游戏数据的索引文件和节点列表；

索引文件是记录一个版本数据所有数据块标识映射信息的集合；不同版本的游戏数据一定对应一个版本的索引文件。

节点列表包含有所有向P2P服务器发送过请求的网吧服务器的IP信息以及拥有新版本游戏数据的各IDC数据服务器的IP信息。

(2)比较索引文件，得到下载列表。

网吧服务器对本地旧版本游戏数据的索引文件与新版本游戏数据的索引文件进行差异对比，产生差异需求量，得到下载列表；下载列表包含了存在差异部分的数据块的ID信息；故对于各网吧服务器，只要下载差异部分的数据就可以完成版本升级。

(3)根据节点列表，建立P2P连接。

网吧服务器从节点列表中按照同城同ISP-同省同ISP-同城不同ISP-同省不同ISP的优先级次序选取出多个P2P节点(网吧服务器)并与这些P2P节点进行信息交互，了解别的网吧服务器拥有哪些数据块，也告诉别的网吧服务器自己拥有哪些数据块。

网吧服务器同时还建立关于这些P2P节点的P2P列表；P2P列表包含有这些P2P节点的IP信息。

当数据更新的初始阶段，网吧服务器会根据节点列表向IDC数据服务器发送下载请求，IDC数据服务器根据网吧服务器的IP信息确定其归属于哪个群落以及其起始下载切入位置。

IDC数据服务器将新版本游戏数据分成五个块组A～E，块组是数据块的集合，则5个群落会分别对应有5种下载切入顺序：1-2-3-4-5、2-3-4-5-1、3-4-5-1-2、4-5-1-2-3和5-1-2-3-4。

网吧服务器根据下载切入顺序下载需要更新的游戏数据。

将新版本游戏的块请求策略散列出不同请求顺序的集合，就能让某一群落种的P2P节点向另一个群落的P2P节点请求P2P数据共享，从而达到了增加P2P交互节点数的效果。

(4)建立数据块资源列表。

网吧服务器根据下载列表、P2P列表以及与各P2P节点交互得到的信息，建立数据块资源列表并对其实时更新；

数据块资源列表包含有当前所有待下载数据块的ID信息和客户信息，待下载数据块的客户信息包括P2P列表中拥有该数据块的P2P节点的IP信息和缺少该数据块的P2P节点的IP信息。

(5)与P2P节点进行数据交互。

关于下载：

网吧服务器根据数据块资源列表对当前所有待下载数据块进行优先级排序，拥有者越少的数据块优先级越高，根据优先级依次下载各数据块；

当下载任一数据块时，网吧服务器通过数据块资源列表确定拥有该数据块的P2P节点，从中选取单位时间P2P数据交互量最大的一P2P节点向其下载该数据块。

关于上传：

当任一数据块下载完成后，网吧服务器先标记该数据块为已下载数据块，然后通过数据块资源列表确定缺少该数据块的P2P节点，并通知这些P2P节点该数据块已完成；P2P节点根据通知查询本地是否缺少该数据块，若缺少则向网吧服务器下载该数据块。

当网吧服务器上传量受限的情况下，作为另外一种方案，网吧服务器会将提供该数据块的P2P节点推荐给缺少该数据块的P2P节点。

网吧服务器与P2P节点进行数据交互的过程中，定时更新P2P列表：建立推荐列表，推荐列表用于接收P2P列表中的P2P节点向网吧服务器推荐的其他P2P节点的IP信息；网吧服务器定时从P2P列表中删除单位时间P2P数据交互量最小的若干P2P节点，并从推荐列表中补充相应数量的P2P节点至P2P列表中。

其中，网吧服务器是通过缓存下载数据块的；网吧服务器的内存中开设有块组下载滚动窗口，其用于缓存下载的数据块，窗口存放4个块组(由1024个数据块组成)，默认每个块组大小为32MB，故需要占用128MB的内存。

窗口存放的4个块组对应归属于四个子窗口：两个读窗口、Finish写窗口和Downing写窗口；在每个子窗口中都有相应的位表来标识哪些数据块被下载，哪些块没有被下载；虽然Finish写窗口和Downing写窗口都有写操作，但是对于具体的数据块来说，都是读写分离的。

读窗口中的数据块用于提供P2P传播服务；Finish写窗口中未下载的数据块向IDC数据服务器或DownFinish状态的P2P节点请求下载；Downing写窗口中未下载的数据块向Downing状态的P2P节点请求下载。

读窗口内的块组数据，在内存持有过程中除提供P2P传播服务外，还要做写磁盘的操作，并且不要求读窗口中所有数据块都下载完成。

从IDC数据服务器和DownFinish的P2P节点中，可以稳定的请求到新版本数据的任意数据块，即稳定完备数据源。而从Downing的P2P节点中只能请求其内存4个子窗口块组中已下载的数据块，即非稳定完备数据源。

由于窗口可能滚动且具有一定的时效性，由此我们的需求请求策略是：先用Downing的P2P节点共享来的数据打底，能下多少下多少(数据来自内存)，在窗口滚动后，DownFinish的P2P节点和IDC数据服务器上同步的数据扫底，查漏补缺，将未下载的数据块精确下载(内存中没有去磁盘读取)。

将下载数据行为分开，也是保证尽量少的出现重复数据的反复传输。为了节省内存空间，要求窗口滚动一定是单向的；只有当Finish写窗口中所有的需求块下载完成、Downing写窗口中的定时发现下载率超过60％或者Finish写窗口工作超时，窗口才会滚动。

与Finish写窗口的请求对象不同，Downing写窗口的请求对象不知道下载了什么数据。所以，网吧服务器在与P2P节点进行信息交互时，会先绑定连接，在回复绑定连接包中加载当前正在下载的块组ID，有利于确认自己所处的下载位置。

请求方发送QueryP2PBlockList(请求正在下载的块组中所有的块下载状态)，回复包中是P2P节点此块组中已经下载完成的BlockId的列表，供请求方做请求规划。由于一个块组最多1024个块，ACK最大4KB左右，所以此交互带来的网络负荷不高。

此时，请求方会收到许多Downing的P2P节点发回来的已下载完成的BlockId的列表；一般情况下，先回复QueryP2PBlockListAck的先处理。说明网络、工作状态较好。优先请求Downing写窗口处于同一块组的P2P节点：可以认为这些P2P节点是处在同一个群落状态中(此状态是真正的P2P互助状态)。

如图2所示，请求方下载策略为1-2-3-4-5，目前Downing写窗口对应的块组ID为4。我们希望大幅提高P2P下载中的数据传播率，开启定时器，定时主动通知定时周期内Downing写窗口中下载完成的BlockId的列表给部分保持连接的平行互助节点(因为每次传播30％-50％的节点是效率较高的，我们并不希望一个块传播的源头来自一个节点，传播来源越接近50％即分布越均匀)。

优先请求QueryP2PBlockListAck中可利用Blockid列表多节点，因为要考虑窗口滚动。如图3所示，当前请求方下载策略为1-2-3-4-5，并开始掉队；2个节点的下载策略一致，但是服务方速度快于请求方。优先请求这些节点的一个好处的，请求方会长期保持和服务方的连接，无需频繁连接新的节点。

另一种情况是，选择邻近下载策略的节点，如图4所示，2个节点的下载策略分别为1-2-3-4-5和2-3-4-5-1；出现这种情况，说明当前的此节点已经落到其他梯队了。此节点开始逐步批量重连新的梯队中服务节点，并开始长期持有这些连接(前提是保持在这个梯队中)。

以上策略无法获取需求块的可利用服务节点，全局P2P列表中计算可利用的节点信息。

如图5所示，请求方当前下载策略是1-2-3-4-5，请求方速度最快，同策略中没有可利用的P2P节点。只有下载策略为5-1-2-3-4的节点可以利用。

这种方式的P2P，由于共享的块组只是交叉，所以会导致大量的连接操作，只是在没办法的时候使用。需要考虑成本，是延时向同梯队节点重新请求块列表还是放弃P2P，交由Finish写窗口完成。

对于P2PDowing下载过程中下载完成的数据块，由于窗口滚动后丢失的数据块或P2P限速导致不能回复的情况，我们将其最近提供过服务的请求方P2P节点信息回复给当前请求方。

图6给出的数据是在生产环境IDC内部做P2P性能比较获取的。P2P同机房表示本实施方式机制下P2P节点在同机房内有一个完整的数据源，P2P异地机房表示本实施方式机制下P2P节点在同机房内没有完整数据源，SSN同机房表示现有机制下节点在同机房内有一个完整数据源，SSN同机房表示现有机制下节点在同机房内没有一个完整数据源。在本实施方式机制下各P2P节点的下载信息如表1所示；其有效速率＝更新量/更新时长。

表1

由图6和表1可见，在本实施方式机制下，各节点的下载速率以及下载更新时长均比现有机制有明显的提升。

Claims (10)

1.一种基于P2P的网吧服务器数据更新方法，包括如下步骤：

(1)各网吧服务器向P2P服务器请求获取新版本数据的索引文件和节点列表；

(2)网吧服务器对本地旧版本数据的索引文件与新版本数据的索引文件进行差异对比，得到下载列表；

(3)网吧服务器从节点列表中优选出多个P2P节点并与这些P2P节点进行信息交互，同时建立关于这些P2P节点的P2P列表；

(4)网吧服务器根据下载列表、P2P列表以及与各P2P节点交互得到的信息，建立数据块资源列表并对其实时更新；

所述的数据块资源列表包含有当前所有待下载数据块的ID信息和客户信息，待下载数据块的客户信息包括P2P列表中拥有该数据块的P2P节点的IP信息和缺少该数据块的P2P节点的IP信息；

(5)网吧服务器根据数据块资源列表与P2P列表中的P2P节点进行数据交互。

2.根据权利要求1所述的基于P2P的网吧服务器数据更新方法，其特征在于：所述的步骤(3)中，网吧服务器根据节点列表向IDC数据服务器发送下载请求，IDC数据服务器根据网吧服务器的IP信息确定其起始下载切入位置，网吧服务器根据起始下载切入位置从新版本数据中对应的切入位置开始下载数据块。

3.根据权利要求1所述的基于P2P的网吧服务器数据更新方法，其特征在于：所述的步骤(3)中，网吧服务器从节点列表中优选出多个P2P节点的方法为：按同城同ISP-同省同ISP-同城不同ISP-同省不同ISP的优先级次序从节点列表中挑选出多个网吧服务器作为优选出的多个P2P节点。

4.根据权利要求1所述的基于P2P的网吧服务器数据更新方法，其特征在于：所述的步骤(5)中，网吧服务器与各P2P节点进行数据交互的方法如下：

关于下载：

网吧服务器对当前所有待下载数据块进行优先级排序，根据优先级依次下载各数据块；当下载任一数据块时，网吧服务器通过数据块资源列表确定拥有该数据块的P2P节点，从中选取一P2P节点向其下载该数据块；

关于上传：

当任一数据块下载完成后，网吧服务器先标记该数据块为已下载数据块，然后通过数据块资源列表确定缺少该数据块的P2P节点，并通知这些P2P节点该数据块已完成；P2P节点根据通知查询本地是否缺少该数据块，若缺少则向网吧服务器下载该数据块。

5.根据权利要求4所述的基于P2P的网吧服务器数据更新方法，其特征在于：网吧服务器通过缓存下载数据块。

6.根据权利要求4所述的基于P2P的网吧服务器数据更新方法，其特征在于：网吧服务器根据数据块资源列表对当前所有待下载数据块进行优先级排序，拥有者越少的数据块优先级越高。

7.根据权利要求4所述的基于P2P的网吧服务器数据更新方法，其特征在于：当下载任一数据块时，网吧服务器通过数据块资源列表确定拥有该数据块的P2P节点，从中选取单位时间P2P数据交互量最大的一P2P节点向其下载该数据块。

8.根据权利要求4所述的基于P2P的网吧服务器数据更新方法，其特征在于：当任一数据块下载完成后，网吧服务器通过数据块资源列表确定缺少该数据块的P2P节点，并将提供该数据块的P2P节点推荐给缺少该数据块的P2P节点。

9.根据权利要求1所述的基于P2P的网吧服务器数据更新方法，其特征在于：所述的步骤(5)中，网吧服务器与P2P节点进行数据交互的过程中，定时更新P2P列表：建立推荐列表，所述的推荐列表用于接收P2P列表中的P2P节点向网吧服务器推荐的其他P2P节点的IP信息；网吧服务器定时从P2P列表中删除若干P2P节点，并从推荐列表中补充相应数量的P2P节点至P2P列表中。

10.根据权利要求9所述的基于P2P的网吧服务器数据更新方法，其特征在于：网吧服务器定时从P2P列表中删除单位时间P2P数据交互量最小的若干P2P节点。

Images