一种用于移动终端应用的内容分发的方法和系统与流程

本发明涉及基于移动互联网内容分发的技术，尤其涉及P2P的分发技术在移动网络下的应用技术。

背景技术：

随着移动互联网的发展，无线网络带宽越来越大，富媒体应用随之发展。而富媒体内容如音频、视频，一般体积比较大，非常依赖内容分发系统对其支持，才能保证这些富媒体应用在移动网络下的用户体验。当前的集中式内容分发系统一般在靠近用户的地方部署缓存系统，通过改写域名指向，将请求导入缓存系统，这样可以达到就近获取内容和缓解源站压力的目的。但现有的集中式内容分发方案存在不少弊端。例如，集中式内容分发系统在用户请求量大的时候容易造成瓶颈，导致可用性下降，用户体验差。此外，传统的集中式内容分发方案容易造成单点故障失效。而且，集中式内容分发方案需要较高的分发成本。

P2P(peer-to-peer，点对点)技术已经非常成熟，该技术已经被广泛应用在固定网络下的内容分发。所谓P2P，即点对点传输数据，这里“点”指的是最终用户端，在传统的集中式内容分发系统下，用户获取资源只能到源站或者缓存系统获取，而P2P技术下获取内容主要是到已拥有资源的用户端上获取数据，这样可以实现分布式下载数据，可以解决集中式分发系统所存在的弊端。

如果能够将P2P技术应用在移动网络下，那么移动网络下的内容分发系统将更加高效。但移动网络与固定网络有较大区别，固网下传统的P2P技术并不适合移动网络应用，主要体现在以下几个方面。

首先，移动网络时延大、网络抖动大，相对固定网络来说更加不稳定，在这种情况下传统P2P技术无法保证数据及时供给，例如，首包不及时，进而用户体验无法得到有效保障。

其次，通常P2P需要数据源(P2P技术称该数据源为种子seed)永久在线。但移动终端使用电池供电，各个移动平台一般都会限制后台应用的数据使用以达到节省电源使用的目的，在这种情况下种子服务没办法得到可靠的保障将会影响可用性。

再次，运营商对移动流量收费，传统的P2P方案无法区分收费流量和免费流量，因此，会增加客户端的使用成本。

因此，亟需一种能克服上述缺陷的适用于移动智能终端应用的P2P内容分发的方法和系统。

技术实现要素：

本发明要解决的技术问题有以下几个。

首先，传统的P2P内容分发方案使得数据源边缘化，但由于移动网络和移动终端的限制，无法保证数据源永远在线的状态。

其次，移动网络下网络相对不稳定，数据可能无法及时从特定的终端上获取，从而影响用户体验。

再次，传统的P2P内容分发方案无法识别收费流量和免费流量，可能造成用户使用成本上升。

最后，传统的P2P内容分发方案未考虑移动终端的电源使用情况，造成电源过快耗费。

为了解决上述问题，本发明结合了移动网络的特性提出改进后的适用于移动网络应用的P2P内容分发方案。新方案主要结合了集中分发方案和P2P分发方案的优点，规避了两种方案的缺点，使得在移动网络下内容分发更加高效可靠，并且能够保证较好的用户体验。

本发明提供了一种用于移动终端应用的内容分发的方法，其特征在于，包括以下步骤：

A.移动终端应用集成嵌入软件开发库，并将一下载请求导入所述软件开发库，并等待接收下载数据；

B.所述软件开发库接收所述移动终端应用导入的所述下载请求，并根据所述请求向缓存系统或源站下载首包，并根据该首包来确定是否可以启动P2P下载，其中该首包为欲下载的数据的首个数据分片；

C.如果确定可以启动P2P下载，所述软件开发库将剩余的未下载的数据切片成多个虚拟文件；

D.所述软件开发库对所述多个虚拟文件逐一发起下载并缓存下载结果，直到所有的虚拟文件下载完成，其中，在下载所述虚拟文件过程中，所述软件开发库将已下载的虚拟文件实时转发给所述移动终端应用；

E.在下载所述虚拟文件过程中，所述软件开发库根据分享策略将已下载并且已缓存的资源进行分享。

在一个实施例中，步骤A中的所述移动终端应用将所述下载请求导入所述软件开发库的方法包括通过主动代理或者被动劫持的方式的其中一种。

在一个实施例中，步骤D中的虚拟文件下载包括：

使用http协议向源站或者缓存系统下载和/或使用P2P的方式下载；其中所述软件开发库计算使用http协议的下载速率和使用P2P方式的下载速率，并根据所述移动终端应用对数据的需求情况来决定当前虚拟文件采用哪一种下载方式；如果使用P2P的方式无法下载到所需要的虚拟文件或者下载速率无法满足所述移动终端应用的正常需要，并且P2P下载速率低于http下载速率，则需要使用http方式直接向所述缓存系统或者所述源站下载，除此之外均可使用P2P的方式下载数据。

在一个实施例中，步骤E中的分享策略包括：

根据所述移动终端的网络制式、所述移动终端的剩余电量、所述移动终端的内存使用情况、所述移动终端的cpu使用情况判断所下载的数据是否可以作为种子进行分享；若可以进行分享，则对该分享进行注册，并等待接收其他移动终端应用的下载请求。

在一个实施例中，步骤B中确定是否可以启动P2P包括：

根据该首包数据中描述的文件长度和传输编码方式来确定是否启动P2P下载，如果不符合，则向该缓存系统或者该源站发送http请求，以下载剩余数据；如果符合，则执行步骤C。

在一个实施例中，获取终端应用对数据的需求情况的方法包括：

所述软件开发库向所述移动终端应用提供数据使用状态通知接口，以此来获取当前移动终端应用对数据的消费情况。

本发明还提供了一种用于移动终端应用的内容分发的系统，其特征在于，包括：

多个移动终端应用模块，每个移动终端应用模块内嵌软件开发库，所述软件开发库被配置成判断数据下载请求是否满足P2P下载的启动条件、实现P2P的下载、提供响应数据的交付，以及提供数据分享；

P2P控制器，与所述多个移动终端模块相通信，所述P2P控制器被配置成管理所述软件开发库、管理和推荐有效的peer、检索下载资源、辅助P2Pp的NAT穿越。

在一个实施例中，所述软件开发库包括：

P2P调度层模块和P2P协议层模块，该P2P调度层模块与该P2P协议层模块互相通信；

所述P2P调度层模块包括：

本地代理接口模块，被配置成将来自所述移动终端应用模块的数据下载请求导入所述软件开发库，并通过所述本地代理接口将下载的数据交付至所述移动终端应用模块；

通知接口模块，被配置成接收有关来自移动终端应用模块的状态的通知；

下载控制器，被配置成判断该数据下载请求是否满足P2P下载的启动条件，并且将根据配置或者当前的条件决定下一个虚拟文件采用http下载方式还是P2P下载方式；

上传控制器，被配置成确定当前的缓存数据是否可以分享以及分享的条件；

缓存控制器，被配置成管理本地缓存，该管理包括对缓存规模进行控制、对缓存数据的冷热度进行排序及删除，以及管理所述移动终端应用模块对缓存的重复利用。

在一个实施例中，所述P2P协议层模块包括：

P2P内容检索模块，被配置成实现所述软件开发库与所述P2P控制器的交互管理，移动终端的进入和退出，下载数据的检索以及处理P2P控制的peer推荐和更新。

P2P切片任务管理模块，被配置成实现对已注册的P2P文件进行任务管理，切片并发管理，以实现最优的P2P下载；

P2P NAT穿越控制模块，被配置成确保peer之间的链路能够建立；

peer交互协议模块，被配置成实现peer之间的通讯协议。

在一个实施例中，所述P2P控制器包括：

peer管理模块，被配置成记录和管理peer的活动状态。

peer推荐模块，被配置成向数据下载请求发出的请求方推荐拥有指定资源的健康的合适的peer列表；

NAT穿越辅助模块，被配置成协助peer端发现自身的NAT环境，并对peer间建立连接提供通讯辅助；

软件开发库管理模块，被配置成对软件开发库进行配置和管理。

在一个实施例中，所述下载控制器被配置成判断该数据下载请求是否满足P2P下载的启动条件包括所述下载控制器根据首包数据中描述的文件长度和传输编码方式来确定是否启动P2P下载，如果不符合，则向该缓存系统或者该源站发送http请求，以下载剩余数据；如果符合，则启动P2P下载。

在一个实施例中，所述下载控制器根据配置或者当前的条件决定下一个虚拟文件采用http下载方式还是P2P下载方式包括所述下载控制器计算使用http协议的下载速率和使用P2P方式的下载速率，并根据所述移动终端应用对数据的需求情况来决定当前虚拟文件采用哪一种下载方式；如果使用P2P的方式无法下载到所需要的虚拟文件或者下载速率无法满足所述移动终端应用的正常需要，并且P2P下载速率低于http下载速率，则需要使用http方式直接向所述缓存系统或者所述源站下载，除此之外均可使用P2P的方式下载数据。

在一个实施例中，所述上传控制器根据所述移动终端的网络制式、所述移动终端的剩余电量、所述移动终端的内存使用情况、所述移动终端的cpu使用情况判断所下载的数据是否可以作为种子进行分享；若可以进行分享，则对该分享进行注册，并等待接收其他移动终端应用的下载请求。

本发明的优点有以下几点。

首先，通用性强，与应用耦合度较低，app可以在不改变业务逻辑的情况下透明使用。

其次，结合移动智能终端的特点，能够在完成P2P分发的同时确保应用的用户体验

再次，通过智能分析可以最大化P2P的下载率并保证下载的及时性。

此外，P2P模块可以重复利用应用的自有缓存提供P2P分享，节约了移动终端的性能和存储资源。

由于终端应用分担了中心缓存系统负载，这样更加不容易导致中心缓存系统出现单点故障或者单点瓶颈。

另外本专利所提出的实现方案是使用sdk的方式来实现移动终端应用对P2P分发功能的集成，与终端的具体业务耦合度较低，这么做至少有以下两个优点：

与业务耦合度较低，适合在不同的业务终端应用快速集成P2P内容分发功能。

P2P模块较为独立，容易维护且便于控制。

附图说明

本发明的以上发明内容以及下面的具体实施方式在结合附图阅读时会得到更好的理解。需要说明的是，附图仅作为所请求保护的发明的示例。在附图中，相同的附图标记代表相同或类似的元素。

图1示出根据本发明的一实施例的系统结构示意图。

图2示出根据本发明的一实施例的p2p软件开发库结构示意图。

图3示出根据本发明的一实施例的p2p控制器结构示意图。

图4示出根据本发明的一实施例的数据下载流程示意图。

图5示出根据本发明的一实施例的用于移动终端应用的p2p内容分发的流程图。

具体实施方式

以下在具体实施方式中详细叙述本发明的详细特征以及优点，其内容足以使任何本领域技术人员了解本发明的技术内容并据以实施，且根据本说明书所揭露的说明书、权利要求及附图，本领域技术人员可轻易地理解本发明相关的目的及优点。

本发明提供了一种用于移动终端的p2p内容分发的方法和系统。该方法和系统的关键技术点为：

(1)源服务器中的代码结构和业务逻辑无需做任何改变。

(2)缓存系统的代码结果和业务逻辑无需做任何改变。

(3)终端应用嵌入p2p sdk(软件开发库)，终端应用将需要做p2p流量通过代理的方式导入p2p sdk。

(4)终端应用以接口的形式将应用的自有缓存开放给p2p sdk，以便sdk能够有效利用app的缓存提供p2p的分享，避免同一个应用有双缓存的出现。

(5)智能数据下载方式控制(一)：终端应用如果是流媒体应用，可以通过sdk提供的接口通知sdk当前播放器的状态(正常播放、暂停、当前的播放位置)，sdk能够据 此通知并结合当前的下载情况确定未下载部分的数据使用什么方式(http、p2p)进行下载。

(6)智能数据下载方式控制(二)：sdk通过分析http部分下载速率，对整体的下载提出总体要求，只要p2p的下载速率不低于http的下载速率的80％，即可持续进行p2p下载。

(7)智能数据下载方式控制(三)：sdk通过分析http部分下载速率，并分析每一个p2p peer的下载质量，仅选择下载速率高于http下载速率的优质peer进行p2p下载，并据此确定p2p的并发下载的数量。

(8)智能数据分享控制，当移动终端使用蜂窝网络时、电量低于30％、cpu使用率高于60％、内存使用率高于80％时关闭数据分享。

(9)对目标下载文件进行分片下载，p2p下载部分选在顺序片下载，当p2p下载部分无法完成，可以将剩余未下载部分作为一个连续整体切换成http方式向缓存系统或者源站请求，避免了随机下载产生过多的不连续的小分片，进而对缓存系统或者源站造成不必要的性能消耗。

(10)通过正则表达式从url中提取文件名称作为p2p下载的资源标识，这样可以避免因为不同的应用拥有不同url结构，导致sdk通用性不强的问题。

下面具体结合附图来描述本发明的具体实施例。

图1示出根据本发明的一实施例的系统结构示意图。该系统包括源站101、缓存系统102、p2p控制器103、第一移动终端内的终端应用模块104、第二移动终端内的终端应用模块105。需要指出的是，该系统并不限于两个移动终端及其内的终端应用模块，可以包括N个移动终端及其内的终端应用模块。

终端应用模块104、105在不改变原始业务逻辑的情况下内嵌p2p软件开发库(p2p sdk)。终端应用模块向p2p软件开发库发起需要使用p2p下载的请求。在一个实施例中，该请求通过代理接口导入p2p软件开发库。

p2p软件开发库是实现点对点传输的核心模块，其负责实现p2p的下载并提供响应数据的交付，另外提供数据分享。下文中将详细介绍p2p软件开发库。

p2p控制器103负责有效peer的管理和推荐、下载资源的检索并且实现p2p的NAT穿越的技术辅助。另外，p2p控制器103还对p2p软件开发库进行管理，该管理至少包含配置信息的下发和数据的收集和分析。

缓存系统102一般是靠近最终用户就近部署，提供源站数据的缓存。在本发明的一个实施例中，该缓存系统102主要为终端应用模块104、105提供首包和应急包。在一个实施例中，首包可以是下载目标的首个256KB分片数据，应急包可以是当使用p2p下载速率较低而导致数据无法及时交付情况出现后的后续下载数据包。

源站101负责内容的管理和权威交付。如果终端应用模块所请求的内容没有在缓存系统中存在备份，那么缓存系统102会转发该请求至源站101，在获取数据后转发给终端应用模块，并且将响应数据缓存在缓存系统102中，下一个请求相同内容的请求则可到缓存系统获得数据而不再需要回源站请求数据。

图2示出根据本发明的一实施例的p2p软件开发库的结构示意图。

p2p软件开发库与终端应用模块的原始应用层模块230可通信。p2p软件开发库主要包括p2p调度层模块210和p2p协议层模块220。p2p调度层模块210包括本地代理接口模块211、接口通知模块212、下载控制器213、上传控制器214、缓存控制器215。

本地代理接口模块211被配置成将原始应用层模块230的数据下载请求导入p2p软件开发库，并通过此接口模块将下载数据交付至原始应用层模块230。

通知接口模块212，被配置成接收有关来自终端应用模块的状态的通知。例如，播放器的当前播放位置、可用剩余缓存时长、播放状态(暂停、播放)等。该状态将作为数据需求紧急度主要参考依据。

下载控制器213，被配置成判断该数据下载请求是否满足p2p下载的启动条件，并且将根据配置或者当前的条件决定下一片虚拟文件下载的方式(http或者p2p)。

上传控制器214，被配置成确定当前的缓存数据是否可以分享以及分享的条件。

缓存控制器215，被配置成管理本地缓存。例如，缓存控制器215对缓存规模进行控制、对缓存数据的冷热度进行排序及删除，以及管理原始应用层模块230对缓存的重复利用等。

p2p协议层模块220包括p2p内容检索模块221、p2p切片任务管理模块222、p2p NAT穿越控制模块223以及peer交互协议模块224。

p2p内容检索模块221，被配置成实现p2p软件开发库与p2p控制器103的交互管理，终端的进入和退出，下载内容检索以及处理p2p控制器向终端发出的peer推荐和更新。

其中，终端进入与退出，是指终端启动需要通过该模块向p2p注册终端，意味着新终端加入。同理，终端应用退出，也需要向p2p控制器报备标记为不可用，这样该终端就不会再作为peer端推荐给其他终端。

p2p切片任务管理模块222，被配置成实现对已注册的p2p文件进行任务管理，切片并发管理，以实现最优的p2p下载。

p2p NAT穿越控制模块223，被配置成确保peer之间的链路能够建立。在一个实施例中，该p2p NAT穿越控制模块233主要负责在NAT环境下peer成功建立通讯链路。

peer交互协议模块224，被配置成实现peer之间的通讯协议。

图3示出根据本发明的一实施例的p2p控制器结构示意图。

p2p控制器103可包括peer管理模块311、peer推荐模块312、nat穿越辅助模块313、sdk配置辅助模块314。

peer管理模块311，被配置成记录和管理peer的活动状态。

peer推荐模块312，被配置成向数据下载请求发出的请求方推荐拥有指定资源的健康的合适的peer列表。在一个实施例中，该推荐可以根据peer的位置、健康度、运营商归属、NAT类型等指标做出。

NAT穿越辅助模块313，被配置成协助peer端发现自身的NAT环境，并对peer间建立连接提供通讯辅助。

软件开发库管理模块314，被配置成对软件开发库进行配置和管理。该配置和管理包括配置下发、配置变更等、收集和分析软件开发库的p2p的数据。在一个实施例中，所述数据主要是指p2p行为数据，比如哪些请求使用了p2p下载，哪些请求使用http下载，以及如果p2p下载失败，记录下载失败原因等等。

图4示出根据本发明的一实施例的数据下载流程示意图。

步骤401：终端应用模块的应用层发起数据下载请求，并将此请求通过代理接口导入p2p软件开发库。步骤402：软件开发库的本地代理接口模块接收数据下载请求。

步骤403：软件开发库的下载控制器分析该请求中的url，以判断该请求是否是p2p请求，例如该URL是否符合预先设定的p2p url的正则式设定。如果不符合，则进入步骤404；如果符合，则进入步骤405。

步骤404：软件开发库的下载控制器使用http方式下载完整数据，例如，采用普通代理管道，转发请求至缓存系统或者源站，并转交来自缓存或者源站的响应数据。

步骤405：软件开发库的下载控制器根据预先设定的提取资源标识的方法提取资源标识，该标识将作为将来p2p检索资源的唯一标识。

步骤406：软件开发库的下载控制器组织新的请求，向缓存系统或者源站发起获取首包的请求，其中所述首包为欲下载的数据的首包。在一个实施例中，该请求可以是获取首片长度为256KB的range下载请求。

步骤407：软件开发库的下载控制器接收来自源站或者缓存系统的响应数据。

步骤408：软件开发库的下载控制器根据该接收到的响应数据确定是否可以启动p2p下载。在一个实施例中，可以根据该数据的文件长度和传输编码方式来确定是否启动p2p下载。如果不符合，则进入步骤409；如果符合，则进入步骤410，以进行p2p下载。

步骤409：软件开发库的下载控制器向缓存系统或者源站发送http请求，以下载剩余数据。

步骤410：软件开发库的P2P切片任务管理模块将剩余未下载的数据切片成多个虚拟文件。

步骤411：软件开发库的P2P切片任务管理模块向p2p任务管理器注册其中一个虚拟文件并启动p2p下载。

步骤412：软件开发库的p2p内容检索模块使用该文件的资源标识向p2p控制器发起检索，如果收到来自p2p控制发来的推荐的peer列表便进入步骤413；否则，p2p失败，转交下载剩余文件的请求至缓存系统或者源站，并交付相应响应数据。

步骤413：软件开发库的p2p NAT穿越控制模块向推荐的peer发起连接，必要时通过p2p控制器的NAT穿越辅助模块实现peer的通信链路的建立。

步骤414：软件开发库的p2p切片任务管理模块成功连接peer后向peer索取所需的资源分片，即当前的虚拟文件，并记录p2p下载的速率，供后续peer的质量排序和并发控制提供必要数据。

步骤415：软件开发库的本地代理接口模块得到peer的响应数据后，先向终端应用模块交付响应数据。

步骤416：软件开发库的缓存控制器将响应的数据进行缓存。如果是重用终端应用自有缓存的，则不需要在软件开发库内部实现缓存；如果是软件开发库内部实现缓存的，则要按照缓存控制器的设定以及终端当前的存储空间来判定当前可用存储空间是否充足，如果不充足，则可以删除最冷门的分享文件再进行缓存新文件。在一个实 施例中，可以根据按照LRU(Least Recently Used近期最少使用算法)算法来删除最冷门的分享文件。

步骤417：软件开发库的上传控制器确定数据是否可以共享。在一个实施例中，可判断当前的终端环境是否符合数据分享的设定，该判断的依据主要是考察终端的网络制式、终端当前电量、终端的内存使用情况等进行综合判定。如果判断可以作为种子进行分享，则进入步骤418；如果不符合，则直接进入其他虚拟文件的下载。

步骤418：软件开发库的上传控制器向p2p控制器进行分享注册，然后等待接受其他peer的下载请求，同时进入其他虚拟文件下载准备。

步骤419：软件开发库的下载控制器判定是否已经下载完毕，如果是就结束下载，如果不是则继续下载。

步骤420：软件开发库的下载控制器通过当前情况的判定来决定下一片虚拟文件的下载方式，判定的依据主要来自应用层状态通知以及下载控制器的控制策略，并结合当前的下载情况来决定下一片虚拟文件的下载方式(通过http向缓存系统或者源站取数据，或者是p2p下载方式)，总之主要是考虑当前数据下载速率是否满足数据交付的及时性。如果当前下载速率无法满足应用层需求或者无法满足预设的下载要求，则使用http方式则直接向缓存系统或者源站发起长度为256K数据下载请求即可(步骤421)。如果满足，则通过对已有的peer列表中所有peer的下载测速，进行排序，确定可用的peer列表，并确定并发的数量。并注册相应数量虚拟文件至p2p任务管理器中，即重复步骤411及后续步骤。

按照上述的方式进行逐片下载，循环至下载结束。这样可以在确保数据可靠、及时交付的同时最大化使用p2p下载。

图5示出根据本发明的一实施例的用于移动终端应用的p2p内容分发的流程图。该流程图包括，但不限于，以下几个步骤。步骤501：移动终端应用集成嵌入软件开发库，并将一下载请求导入所述软件开发库，并等待接收下载数据；

步骤502：所述软件开发库接收所述移动终端应用导入的所述下载请求，并根据所述请求向缓存系统或源站下载首包，并根据该首包来确定是否可以启动p2p下载，其中该首包为欲下载的数据的首个数据分片；

步骤503：如果确定可以启动p2p下载，所述软件开发库将剩余的未下载的数据切片成多个虚拟文件；

步骤504：所述软件开发库对所述多个虚拟文件逐一发起下载并缓存下载结果，直到所有的虚拟文件下载完成，其中，在下载所述虚拟文件过程中，所述软件开发库将已下载的虚拟文件实时转发给所述移动终端应用；

步骤505：在下载所述虚拟文件过程中，所述软件开发库根据分享策略将已下载并且已缓存的资源进行分享。

在一个实施例中，所述移动终端应用将所述下载请求导入所述软件开发库的方法包括通过主动代理或者被动劫持的方式的其中一种。

在一个实施例中，虚拟文件下载的方式可包括使用http协议向源站或者缓存系统下载和/或使用p2p的方式下载；其中所述软件开发库计算使用http协议的下载速率和使用p2p方式的下载速率，并根据所述移动终端应用对数据的需求情况来决定当前虚拟文件采用哪一种下载方式；如果使用p2p的方式无法下载到所需要的虚拟文件或者下载速率无法满足所述移动终端应用的正常需要，并且p2p下载速率低于http下载速率，则需要使用http方式直接向所述缓存系统或者所述源站下载，除此之外均可使用p2p的方式下载数据。在一个实施例中，移动终端应用对数据的需求情况的获取方法包括所述软件开发库向所述移动终端应用提供数据使用状态通知接口，以此来获取当前移动终端应用对数据的消费情况。

在一个实施例中，分享策略可包括，但不限于，根据所述移动终端的网络制式、所述移动终端的剩余电量、所述移动终端的内存使用情况、所述移动终端的cpu使用情况判断所下载的数据是否可以作为种子进行分享；若可以进行分享，则对该分享进行注册，并等待接收其他移动终端应用的下载请求。

在一个实施例中，确定是否可以启动p2p包括：根据该首包数据中描述的文件长度和传输编码方式来确定是否启动p2p下载，如果不符合，则向该缓存系统或者该源站发送http请求，以下载剩余数据；如果符合，则执行步骤503。

下面举一个具体的实施例来说明本发明是如何应用的。

一个具体的应用场景可以是：某音乐应用其计划做p2p流量是download.a.com域名下所有以mp3为后缀的文件，设定p2p sdk共享app缓存。

一、进行流量导入及流量过滤

app嵌入p2p sdk，并启动sdk，sdk监听本地127.0.0.1:8888接收导入数据，在p2p控制器上配置该app的p2p请求正则匹配式：http://download.a.com/.*\.mp3，并将配置下发至sdk。app应用层将将要做p2p下载的流量导入sdk，具体的url是http://download.a.com/1.mp3，sdk根据正则规则进行匹配，发现可以匹配则进入p2p预检流程。

二、p2p预检流程

重组请求，向缓存系统或者源站发起下载目标0～262143的片段请求。接收响应后，分析响应头部Content-Range字段的值，发现目标总长度为1435642，超过1MB的p2p最小文件长度的设定，判定可以使用p2p下载剩余文件。sdk向app应用层递交已下载部分，完成以后将剩下的未下载部分按照每片262144的长度切成5个虚拟文件，最后一个文件长度为124922。

三、资源标识提取&虚拟文件命名

在p2p控制器上配置该app资源标识的提取规则：http://download.a.com/$1\.mp3，sdk根据该规则提取出资源标识为1.mp3，并将这些文件重新命名为1_01.mp3，1_02.mp3…1_05.mp3。完成后向p2p模块注册1_01.mp3的下载任务。

四、p2p下载

p2p sdk向p2p控制器检索1_01.mp3的资源，p2p控制器返回检索结果，并返回拥有该资源的peer列表。Sdk向列表中所有peer发起连接，并将下载目标分解成64KB的小片，分别向已建立连接的peer发起资源请求并下载。同时对peer的下载速度进行排序，以便后续的下载任务可以选择最优peer进行下载。

五、数据紧急度检查&下载方式选择

播放器调用sdk状态通知接口告知sdk当前的播放偏移位置。Sdk解析已下载的mp3文件得到已下载文件的时间长度，从而可以得出已下载的数据是否足够播放器流畅播放。如果能够流畅播放，将1_0x.mp3的文件注册为p2p，如果缓存不充足，则将此虚拟文件切换为普通的range请求直接向缓存系统请求数据，以缓解缓存不足的情况。

六、app和p2p sdk共享缓存

app与sdk约定缓存定位符(一个md5字符串)，将定位符放在响应头部中返回给app，app开放标准的缓存提取接口，sdk调用该接口并且传入缓存定位符便可获取完整缓存文件。

七、缓存分享

sdk下载完1.mp3，可以考察当前终端是否具备分享条件，当前手机终端使用wifi网络，电量还剩下90％，内存使用率56％，cpu使用率为60％，具备了缓存分享的条件，向p2p控制器注册分享资源，等待资源下载请求。

这里采用的术语和表述方式只是用于描述，本发明并不应局限于这些术语和表述。使用这些术语和表述并不意味着排除任何示意和描述(或其中部分)的等效特征，应认识到可能存在的各种修改也应包含在权利要求范围内。其他修改、变化和替换也可能存在。相应的，权利要求应视为覆盖所有这些等效物。

同样，需要指出的是，虽然本发明已参照当前的具体实施例来描述，但是本技术领域中的普通技术人员应当认识到，以上的实施例仅是用来说明本发明，在没有脱离本发明精神的情况下还可做出各种等效的变化或替换，因此，只要在本发明的实质精神范围内对上述实施例的变化、变型都将落在本申请的权利要求书的范围内。