本發(fā)明涉及基于移動(dòng)互聯(lián)網(wǎng)內(nèi)容分發(fā)的技術(shù)，尤其涉及P2P的分發(fā)技術(shù)在移動(dòng)網(wǎng)絡(luò)下的應(yīng)用技術(shù)。

背景技術(shù)：

隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展，無(wú)線(xiàn)網(wǎng)絡(luò)帶寬越來(lái)越大，富媒體應(yīng)用隨之發(fā)展。而富媒體內(nèi)容如音頻、視頻，一般體積比較大，非常依賴(lài)內(nèi)容分發(fā)系統(tǒng)對(duì)其支持，才能保證這些富媒體應(yīng)用在移動(dòng)網(wǎng)絡(luò)下的用戶(hù)體驗(yàn)。當(dāng)前的集中式內(nèi)容分發(fā)系統(tǒng)一般在靠近用戶(hù)的地方部署緩存系統(tǒng)，通過(guò)改寫(xiě)域名指向，將請(qǐng)求導(dǎo)入緩存系統(tǒng)，這樣可以達(dá)到就近獲取內(nèi)容和緩解源站壓力的目的。但現(xiàn)有的集中式內(nèi)容分發(fā)方案存在不少弊端。例如，集中式內(nèi)容分發(fā)系統(tǒng)在用戶(hù)請(qǐng)求量大的時(shí)候容易造成瓶頸，導(dǎo)致可用性下降，用戶(hù)體驗(yàn)差。此外，傳統(tǒng)的集中式內(nèi)容分發(fā)方案容易造成單點(diǎn)故障失效。而且，集中式內(nèi)容分發(fā)方案需要較高的分發(fā)成本。

P2P(peer-to-peer，點(diǎn)對(duì)點(diǎn))技術(shù)已經(jīng)非常成熟，該技術(shù)已經(jīng)被廣泛應(yīng)用在固定網(wǎng)絡(luò)下的內(nèi)容分發(fā)。所謂P2P，即點(diǎn)對(duì)點(diǎn)傳輸數(shù)據(jù)，這里“點(diǎn)”指的是最終用戶(hù)端，在傳統(tǒng)的集中式內(nèi)容分發(fā)系統(tǒng)下，用戶(hù)獲取資源只能到源站或者緩存系統(tǒng)獲取，而P2P技術(shù)下獲取內(nèi)容主要是到已擁有資源的用戶(hù)端上獲取數(shù)據(jù)，這樣可以實(shí)現(xiàn)分布式下載數(shù)據(jù)，可以解決集中式分發(fā)系統(tǒng)所存在的弊端。

如果能夠?qū)2P技術(shù)應(yīng)用在移動(dòng)網(wǎng)絡(luò)下，那么移動(dòng)網(wǎng)絡(luò)下的內(nèi)容分發(fā)系統(tǒng)將更加高效。但移動(dòng)網(wǎng)絡(luò)與固定網(wǎng)絡(luò)有較大區(qū)別，固網(wǎng)下傳統(tǒng)的P2P技術(shù)并不適合移動(dòng)網(wǎng)絡(luò)應(yīng)用，主要體現(xiàn)在以下幾個(gè)方面。

首先，移動(dòng)網(wǎng)絡(luò)時(shí)延大、網(wǎng)絡(luò)抖動(dòng)大，相對(duì)固定網(wǎng)絡(luò)來(lái)說(shuō)更加不穩(wěn)定，在這種情況下傳統(tǒng)P2P技術(shù)無(wú)法保證數(shù)據(jù)及時(shí)供給，例如，首包不及時(shí)，進(jìn)而用戶(hù)體驗(yàn)無(wú)法得到有效保障。

其次，通常P2P需要數(shù)據(jù)源(P2P技術(shù)稱(chēng)該數(shù)據(jù)源為種子seed)永久在線(xiàn)。但移動(dòng)終端使用電池供電，各個(gè)移動(dòng)平臺(tái)一般都會(huì)限制后臺(tái)應(yīng)用的數(shù)據(jù)使用以達(dá)到節(jié)省電源使用的目的，在這種情況下種子服務(wù)沒(méi)辦法得到可靠的保障將會(huì)影響可用性。

再次，運(yùn)營(yíng)商對(duì)移動(dòng)流量收費(fèi)，傳統(tǒng)的P2P方案無(wú)法區(qū)分收費(fèi)流量和免費(fèi)流量，因此，會(huì)增加客戶(hù)端的使用成本。

因此，亟需一種能克服上述缺陷的適用于移動(dòng)智能終端應(yīng)用的P2P內(nèi)容分發(fā)的方法和系統(tǒng)。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明要解決的技術(shù)問(wèn)題有以下幾個(gè)。

首先，傳統(tǒng)的P2P內(nèi)容分發(fā)方案使得數(shù)據(jù)源邊緣化，但由于移動(dòng)網(wǎng)絡(luò)和移動(dòng)終端的限制，無(wú)法保證數(shù)據(jù)源永遠(yuǎn)在線(xiàn)的狀態(tài)。

其次，移動(dòng)網(wǎng)絡(luò)下網(wǎng)絡(luò)相對(duì)不穩(wěn)定，數(shù)據(jù)可能無(wú)法及時(shí)從特定的終端上獲取，從而影響用戶(hù)體驗(yàn)。

再次，傳統(tǒng)的P2P內(nèi)容分發(fā)方案無(wú)法識(shí)別收費(fèi)流量和免費(fèi)流量，可能造成用戶(hù)使用成本上升。

最后，傳統(tǒng)的P2P內(nèi)容分發(fā)方案未考慮移動(dòng)終端的電源使用情況，造成電源過(guò)快耗費(fèi)。

為了解決上述問(wèn)題，本發(fā)明結(jié)合了移動(dòng)網(wǎng)絡(luò)的特性提出改進(jìn)后的適用于移動(dòng)網(wǎng)絡(luò)應(yīng)用的P2P內(nèi)容分發(fā)方案。新方案主要結(jié)合了集中分發(fā)方案和P2P分發(fā)方案的優(yōu)點(diǎn)，規(guī)避了兩種方案的缺點(diǎn)，使得在移動(dòng)網(wǎng)絡(luò)下內(nèi)容分發(fā)更加高效可靠，并且能夠保證較好的用戶(hù)體驗(yàn)。

本發(fā)明提供了一種用于移動(dòng)終端應(yīng)用的內(nèi)容分發(fā)的方法，其特征在于，包括以下步驟：

A.移動(dòng)終端應(yīng)用集成嵌入軟件開(kāi)發(fā)庫(kù)，并將一下載請(qǐng)求導(dǎo)入所述軟件開(kāi)發(fā)庫(kù)，并等待接收下載數(shù)據(jù)；

B.所述軟件開(kāi)發(fā)庫(kù)接收所述移動(dòng)終端應(yīng)用導(dǎo)入的所述下載請(qǐng)求，并根據(jù)所述請(qǐng)求向緩存系統(tǒng)或源站下載首包，并根據(jù)該首包來(lái)確定是否可以啟動(dòng)P2P下載，其中該首包為欲下載的數(shù)據(jù)的首個(gè)數(shù)據(jù)分片；

C.如果確定可以啟動(dòng)P2P下載，所述軟件開(kāi)發(fā)庫(kù)將剩余的未下載的數(shù)據(jù)切片成多個(gè)虛擬文件；

D.所述軟件開(kāi)發(fā)庫(kù)對(duì)所述多個(gè)虛擬文件逐一發(fā)起下載并緩存下載結(jié)果，直到所有的虛擬文件下載完成，其中，在下載所述虛擬文件過(guò)程中，所述軟件開(kāi)發(fā)庫(kù)將已下載的虛擬文件實(shí)時(shí)轉(zhuǎn)發(fā)給所述移動(dòng)終端應(yīng)用；

E.在下載所述虛擬文件過(guò)程中，所述軟件開(kāi)發(fā)庫(kù)根據(jù)分享策略將已下載并且已緩存的資源進(jìn)行分享。

在一個(gè)實(shí)施例中，步驟A中的所述移動(dòng)終端應(yīng)用將所述下載請(qǐng)求導(dǎo)入所述軟件開(kāi)發(fā)庫(kù)的方法包括通過(guò)主動(dòng)代理或者被動(dòng)劫持的方式的其中一種。

在一個(gè)實(shí)施例中，步驟D中的虛擬文件下載包括：

使用http協(xié)議向源站或者緩存系統(tǒng)下載和/或使用P2P的方式下載；其中所述軟件開(kāi)發(fā)庫(kù)計(jì)算使用http協(xié)議的下載速率和使用P2P方式的下載速率，并根據(jù)所述移動(dòng)終端應(yīng)用對(duì)數(shù)據(jù)的需求情況來(lái)決定當(dāng)前虛擬文件采用哪一種下載方式；如果使用P2P的方式無(wú)法下載到所需要的虛擬文件或者下載速率無(wú)法滿(mǎn)足所述移動(dòng)終端應(yīng)用的正常需要，并且P2P下載速率低于http下載速率，則需要使用http方式直接向所述緩存系統(tǒng)或者所述源站下載，除此之外均可使用P2P的方式下載數(shù)據(jù)。

在一個(gè)實(shí)施例中，步驟E中的分享策略包括：

根據(jù)所述移動(dòng)終端的網(wǎng)絡(luò)制式、所述移動(dòng)終端的剩余電量、所述移動(dòng)終端的內(nèi)存使用情況、所述移動(dòng)終端的cpu使用情況判斷所下載的數(shù)據(jù)是否可以作為種子進(jìn)行分享；若可以進(jìn)行分享，則對(duì)該分享進(jìn)行注冊(cè)，并等待接收其他移動(dòng)終端應(yīng)用的下載請(qǐng)求。

在一個(gè)實(shí)施例中，步驟B中確定是否可以啟動(dòng)P2P包括：

根據(jù)該首包數(shù)據(jù)中描述的文件長(zhǎng)度和傳輸編碼方式來(lái)確定是否啟動(dòng)P2P下載，如果不符合，則向該緩存系統(tǒng)或者該源站發(fā)送http請(qǐng)求，以下載剩余數(shù)據(jù)；如果符合，則執(zhí)行步驟C。

在一個(gè)實(shí)施例中，獲取終端應(yīng)用對(duì)數(shù)據(jù)的需求情況的方法包括：

所述軟件開(kāi)發(fā)庫(kù)向所述移動(dòng)終端應(yīng)用提供數(shù)據(jù)使用狀態(tài)通知接口，以此來(lái)獲取當(dāng)前移動(dòng)終端應(yīng)用對(duì)數(shù)據(jù)的消費(fèi)情況。

本發(fā)明還提供了一種用于移動(dòng)終端應(yīng)用的內(nèi)容分發(fā)的系統(tǒng)，其特征在于，包括：

多個(gè)移動(dòng)終端應(yīng)用模塊，每個(gè)移動(dòng)終端應(yīng)用模塊內(nèi)嵌軟件開(kāi)發(fā)庫(kù)，所述軟件開(kāi)發(fā)庫(kù)被配置成判斷數(shù)據(jù)下載請(qǐng)求是否滿(mǎn)足P2P下載的啟動(dòng)條件、實(shí)現(xiàn)P2P的下載、提供響應(yīng)數(shù)據(jù)的交付，以及提供數(shù)據(jù)分享；

P2P控制器，與所述多個(gè)移動(dòng)終端模塊相通信，所述P2P控制器被配置成管理所述軟件開(kāi)發(fā)庫(kù)、管理和推薦有效的peer、檢索下載資源、輔助P2Pp的NAT穿越。

在一個(gè)實(shí)施例中，所述軟件開(kāi)發(fā)庫(kù)包括：

P2P調(diào)度層模塊和P2P協(xié)議層模塊，該P(yáng)2P調(diào)度層模塊與該P(yáng)2P協(xié)議層模塊互相通信；

所述P2P調(diào)度層模塊包括：

本地代理接口模塊，被配置成將來(lái)自所述移動(dòng)終端應(yīng)用模塊的數(shù)據(jù)下載請(qǐng)求導(dǎo)入所述軟件開(kāi)發(fā)庫(kù)，并通過(guò)所述本地代理接口將下載的數(shù)據(jù)交付至所述移動(dòng)終端應(yīng)用模塊；

通知接口模塊，被配置成接收有關(guān)來(lái)自移動(dòng)終端應(yīng)用模塊的狀態(tài)的通知；

下載控制器，被配置成判斷該數(shù)據(jù)下載請(qǐng)求是否滿(mǎn)足P2P下載的啟動(dòng)條件，并且將根據(jù)配置或者當(dāng)前的條件決定下一個(gè)虛擬文件采用http下載方式還是P2P下載方式；

上傳控制器，被配置成確定當(dāng)前的緩存數(shù)據(jù)是否可以分享以及分享的條件；

緩存控制器，被配置成管理本地緩存，該管理包括對(duì)緩存規(guī)模進(jìn)行控制、對(duì)緩存數(shù)據(jù)的冷熱度進(jìn)行排序及刪除，以及管理所述移動(dòng)終端應(yīng)用模塊對(duì)緩存的重復(fù)利用。

在一個(gè)實(shí)施例中，所述P2P協(xié)議層模塊包括：

P2P內(nèi)容檢索模塊，被配置成實(shí)現(xiàn)所述軟件開(kāi)發(fā)庫(kù)與所述P2P控制器的交互管理，移動(dòng)終端的進(jìn)入和退出，下載數(shù)據(jù)的檢索以及處理P2P控制的peer推薦和更新。

P2P切片任務(wù)管理模塊，被配置成實(shí)現(xiàn)對(duì)已注冊(cè)的P2P文件進(jìn)行任務(wù)管理，切片并發(fā)管理，以實(shí)現(xiàn)最優(yōu)的P2P下載；

P2P NAT穿越控制模塊，被配置成確保peer之間的鏈路能夠建立；

peer交互協(xié)議模塊，被配置成實(shí)現(xiàn)peer之間的通訊協(xié)議。

在一個(gè)實(shí)施例中，所述P2P控制器包括：

peer管理模塊，被配置成記錄和管理peer的活動(dòng)狀態(tài)。

peer推薦模塊，被配置成向數(shù)據(jù)下載請(qǐng)求發(fā)出的請(qǐng)求方推薦擁有指定資源的健康的合適的peer列表；

NAT穿越輔助模塊，被配置成協(xié)助peer端發(fā)現(xiàn)自身的NAT環(huán)境，并對(duì)peer間建立連接提供通訊輔助；

軟件開(kāi)發(fā)庫(kù)管理模塊，被配置成對(duì)軟件開(kāi)發(fā)庫(kù)進(jìn)行配置和管理。

在一個(gè)實(shí)施例中，所述下載控制器被配置成判斷該數(shù)據(jù)下載請(qǐng)求是否滿(mǎn)足P2P下載的啟動(dòng)條件包括所述下載控制器根據(jù)首包數(shù)據(jù)中描述的文件長(zhǎng)度和傳輸編碼方式來(lái)確定是否啟動(dòng)P2P下載，如果不符合，則向該緩存系統(tǒng)或者該源站發(fā)送http請(qǐng)求，以下載剩余數(shù)據(jù)；如果符合，則啟動(dòng)P2P下載。

在一個(gè)實(shí)施例中，所述下載控制器根據(jù)配置或者當(dāng)前的條件決定下一個(gè)虛擬文件采用http下載方式還是P2P下載方式包括所述下載控制器計(jì)算使用http協(xié)議的下載速率和使用P2P方式的下載速率，并根據(jù)所述移動(dòng)終端應(yīng)用對(duì)數(shù)據(jù)的需求情況來(lái)決定當(dāng)前虛擬文件采用哪一種下載方式；如果使用P2P的方式無(wú)法下載到所需要的虛擬文件或者下載速率無(wú)法滿(mǎn)足所述移動(dòng)終端應(yīng)用的正常需要，并且P2P下載速率低于http下載速率，則需要使用http方式直接向所述緩存系統(tǒng)或者所述源站下載，除此之外均可使用P2P的方式下載數(shù)據(jù)。

在一個(gè)實(shí)施例中，所述上傳控制器根據(jù)所述移動(dòng)終端的網(wǎng)絡(luò)制式、所述移動(dòng)終端的剩余電量、所述移動(dòng)終端的內(nèi)存使用情況、所述移動(dòng)終端的cpu使用情況判斷所下載的數(shù)據(jù)是否可以作為種子進(jìn)行分享；若可以進(jìn)行分享，則對(duì)該分享進(jìn)行注冊(cè)，并等待接收其他移動(dòng)終端應(yīng)用的下載請(qǐng)求。

本發(fā)明的優(yōu)點(diǎn)有以下幾點(diǎn)。

首先，通用性強(qiáng)，與應(yīng)用耦合度較低，app可以在不改變業(yè)務(wù)邏輯的情況下透明使用。

其次，結(jié)合移動(dòng)智能終端的特點(diǎn)，能夠在完成P2P分發(fā)的同時(shí)確保應(yīng)用的用戶(hù)體驗(yàn)

再次，通過(guò)智能分析可以最大化P2P的下載率并保證下載的及時(shí)性。

此外，P2P模塊可以重復(fù)利用應(yīng)用的自有緩存提供P2P分享，節(jié)約了移動(dòng)終端的性能和存儲(chǔ)資源。

由于終端應(yīng)用分擔(dān)了中心緩存系統(tǒng)負(fù)載，這樣更加不容易導(dǎo)致中心緩存系統(tǒng)出現(xiàn)單點(diǎn)故障或者單點(diǎn)瓶頸。

另外本專(zhuān)利所提出的實(shí)現(xiàn)方案是使用sdk的方式來(lái)實(shí)現(xiàn)移動(dòng)終端應(yīng)用對(duì)P2P分發(fā)功能的集成，與終端的具體業(yè)務(wù)耦合度較低，這么做至少有以下兩個(gè)優(yōu)點(diǎn)：

與業(yè)務(wù)耦合度較低，適合在不同的業(yè)務(wù)終端應(yīng)用快速集成P2P內(nèi)容分發(fā)功能。

P2P模塊較為獨(dú)立，容易維護(hù)且便于控制。

附圖說(shuō)明

本發(fā)明的以上發(fā)明內(nèi)容以及下面的具體實(shí)施方式在結(jié)合附圖閱讀時(shí)會(huì)得到更好的理解。需要說(shuō)明的是，附圖僅作為所請(qǐng)求保護(hù)的發(fā)明的示例。在附圖中，相同的附圖標(biāo)記代表相同或類(lèi)似的元素。

圖1示出根據(jù)本發(fā)明的一實(shí)施例的系統(tǒng)結(jié)構(gòu)示意圖。

圖2示出根據(jù)本發(fā)明的一實(shí)施例的p2p軟件開(kāi)發(fā)庫(kù)結(jié)構(gòu)示意圖。

圖3示出根據(jù)本發(fā)明的一實(shí)施例的p2p控制器結(jié)構(gòu)示意圖。

圖4示出根據(jù)本發(fā)明的一實(shí)施例的數(shù)據(jù)下載流程示意圖。

圖5示出根據(jù)本發(fā)明的一實(shí)施例的用于移動(dòng)終端應(yīng)用的p2p內(nèi)容分發(fā)的流程圖。

具體實(shí)施方式

以下在具體實(shí)施方式中詳細(xì)敘述本發(fā)明的詳細(xì)特征以及優(yōu)點(diǎn)，其內(nèi)容足以使任何本領(lǐng)域技術(shù)人員了解本發(fā)明的技術(shù)內(nèi)容并據(jù)以實(shí)施，且根據(jù)本說(shuō)明書(shū)所揭露的說(shuō)明書(shū)、權(quán)利要求及附圖，本領(lǐng)域技術(shù)人員可輕易地理解本發(fā)明相關(guān)的目的及優(yōu)點(diǎn)。

本發(fā)明提供了一種用于移動(dòng)終端的p2p內(nèi)容分發(fā)的方法和系統(tǒng)。該方法和系統(tǒng)的關(guān)鍵技術(shù)點(diǎn)為：

(1)源服務(wù)器中的代碼結(jié)構(gòu)和業(yè)務(wù)邏輯無(wú)需做任何改變。

(2)緩存系統(tǒng)的代碼結(jié)果和業(yè)務(wù)邏輯無(wú)需做任何改變。

(3)終端應(yīng)用嵌入p2p sdk(軟件開(kāi)發(fā)庫(kù))，終端應(yīng)用將需要做p2p流量通過(guò)代理的方式導(dǎo)入p2p sdk。

(4)終端應(yīng)用以接口的形式將應(yīng)用的自有緩存開(kāi)放給p2p sdk，以便sdk能夠有效利用app的緩存提供p2p的分享，避免同一個(gè)應(yīng)用有雙緩存的出現(xiàn)。

(5)智能數(shù)據(jù)下載方式控制(一)：終端應(yīng)用如果是流媒體應(yīng)用，可以通過(guò)sdk提供的接口通知sdk當(dāng)前播放器的狀態(tài)(正常播放、暫停、當(dāng)前的播放位置)，sdk能夠據(jù) 此通知并結(jié)合當(dāng)前的下載情況確定未下載部分的數(shù)據(jù)使用什么方式(http、p2p)進(jìn)行下載。

(6)智能數(shù)據(jù)下載方式控制(二)：sdk通過(guò)分析http部分下載速率，對(duì)整體的下載提出總體要求，只要p2p的下載速率不低于http的下載速率的80％，即可持續(xù)進(jìn)行p2p下載。

(7)智能數(shù)據(jù)下載方式控制(三)：sdk通過(guò)分析http部分下載速率，并分析每一個(gè)p2p peer的下載質(zhì)量，僅選擇下載速率高于http下載速率的優(yōu)質(zhì)peer進(jìn)行p2p下載，并據(jù)此確定p2p的并發(fā)下載的數(shù)量。

(8)智能數(shù)據(jù)分享控制，當(dāng)移動(dòng)終端使用蜂窩網(wǎng)絡(luò)時(shí)、電量低于30％、cpu使用率高于60％、內(nèi)存使用率高于80％時(shí)關(guān)閉數(shù)據(jù)分享。

(9)對(duì)目標(biāo)下載文件進(jìn)行分片下載，p2p下載部分選在順序片下載，當(dāng)p2p下載部分無(wú)法完成，可以將剩余未下載部分作為一個(gè)連續(xù)整體切換成http方式向緩存系統(tǒng)或者源站請(qǐng)求，避免了隨機(jī)下載產(chǎn)生過(guò)多的不連續(xù)的小分片，進(jìn)而對(duì)緩存系統(tǒng)或者源站造成不必要的性能消耗。

(10)通過(guò)正則表達(dá)式從url中提取文件名稱(chēng)作為p2p下載的資源標(biāo)識(shí)，這樣可以避免因?yàn)椴煌膽?yīng)用擁有不同url結(jié)構(gòu)，導(dǎo)致sdk通用性不強(qiáng)的問(wèn)題。

下面具體結(jié)合附圖來(lái)描述本發(fā)明的具體實(shí)施例。

圖1示出根據(jù)本發(fā)明的一實(shí)施例的系統(tǒng)結(jié)構(gòu)示意圖。該系統(tǒng)包括源站101、緩存系統(tǒng)102、p2p控制器103、第一移動(dòng)終端內(nèi)的終端應(yīng)用模塊104、第二移動(dòng)終端內(nèi)的終端應(yīng)用模塊105。需要指出的是，該系統(tǒng)并不限于兩個(gè)移動(dòng)終端及其內(nèi)的終端應(yīng)用模塊，可以包括N個(gè)移動(dòng)終端及其內(nèi)的終端應(yīng)用模塊。

終端應(yīng)用模塊104、105在不改變?cè)紭I(yè)務(wù)邏輯的情況下內(nèi)嵌p2p軟件開(kāi)發(fā)庫(kù)(p2p sdk)。終端應(yīng)用模塊向p2p軟件開(kāi)發(fā)庫(kù)發(fā)起需要使用p2p下載的請(qǐng)求。在一個(gè)實(shí)施例中，該請(qǐng)求通過(guò)代理接口導(dǎo)入p2p軟件開(kāi)發(fā)庫(kù)。

p2p軟件開(kāi)發(fā)庫(kù)是實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)傳輸?shù)暮诵哪K，其負(fù)責(zé)實(shí)現(xiàn)p2p的下載并提供響應(yīng)數(shù)據(jù)的交付，另外提供數(shù)據(jù)分享。下文中將詳細(xì)介紹p2p軟件開(kāi)發(fā)庫(kù)。

p2p控制器103負(fù)責(zé)有效peer的管理和推薦、下載資源的檢索并且實(shí)現(xiàn)p2p的NAT穿越的技術(shù)輔助。另外，p2p控制器103還對(duì)p2p軟件開(kāi)發(fā)庫(kù)進(jìn)行管理，該管理至少包含配置信息的下發(fā)和數(shù)據(jù)的收集和分析。

緩存系統(tǒng)102一般是靠近最終用戶(hù)就近部署，提供源站數(shù)據(jù)的緩存。在本發(fā)明的一個(gè)實(shí)施例中，該緩存系統(tǒng)102主要為終端應(yīng)用模塊104、105提供首包和應(yīng)急包。在一個(gè)實(shí)施例中，首包可以是下載目標(biāo)的首個(gè)256KB分片數(shù)據(jù)，應(yīng)急包可以是當(dāng)使用p2p下載速率較低而導(dǎo)致數(shù)據(jù)無(wú)法及時(shí)交付情況出現(xiàn)后的后續(xù)下載數(shù)據(jù)包。

源站101負(fù)責(zé)內(nèi)容的管理和權(quán)威交付。如果終端應(yīng)用模塊所請(qǐng)求的內(nèi)容沒(méi)有在緩存系統(tǒng)中存在備份，那么緩存系統(tǒng)102會(huì)轉(zhuǎn)發(fā)該請(qǐng)求至源站101，在獲取數(shù)據(jù)后轉(zhuǎn)發(fā)給終端應(yīng)用模塊，并且將響應(yīng)數(shù)據(jù)緩存在緩存系統(tǒng)102中，下一個(gè)請(qǐng)求相同內(nèi)容的請(qǐng)求則可到緩存系統(tǒng)獲得數(shù)據(jù)而不再需要回源站請(qǐng)求數(shù)據(jù)。

圖2示出根據(jù)本發(fā)明的一實(shí)施例的p2p軟件開(kāi)發(fā)庫(kù)的結(jié)構(gòu)示意圖。

p2p軟件開(kāi)發(fā)庫(kù)與終端應(yīng)用模塊的原始應(yīng)用層模塊230可通信。p2p軟件開(kāi)發(fā)庫(kù)主要包括p2p調(diào)度層模塊210和p2p協(xié)議層模塊220。p2p調(diào)度層模塊210包括本地代理接口模塊211、接口通知模塊212、下載控制器213、上傳控制器214、緩存控制器215。

本地代理接口模塊211被配置成將原始應(yīng)用層模塊230的數(shù)據(jù)下載請(qǐng)求導(dǎo)入p2p軟件開(kāi)發(fā)庫(kù)，并通過(guò)此接口模塊將下載數(shù)據(jù)交付至原始應(yīng)用層模塊230。

通知接口模塊212，被配置成接收有關(guān)來(lái)自終端應(yīng)用模塊的狀態(tài)的通知。例如，播放器的當(dāng)前播放位置、可用剩余緩存時(shí)長(zhǎng)、播放狀態(tài)(暫停、播放)等。該狀態(tài)將作為數(shù)據(jù)需求緊急度主要參考依據(jù)。

下載控制器213，被配置成判斷該數(shù)據(jù)下載請(qǐng)求是否滿(mǎn)足p2p下載的啟動(dòng)條件，并且將根據(jù)配置或者當(dāng)前的條件決定下一片虛擬文件下載的方式(http或者p2p)。

上傳控制器214，被配置成確定當(dāng)前的緩存數(shù)據(jù)是否可以分享以及分享的條件。

緩存控制器215，被配置成管理本地緩存。例如，緩存控制器215對(duì)緩存規(guī)模進(jìn)行控制、對(duì)緩存數(shù)據(jù)的冷熱度進(jìn)行排序及刪除，以及管理原始應(yīng)用層模塊230對(duì)緩存的重復(fù)利用等。

p2p協(xié)議層模塊220包括p2p內(nèi)容檢索模塊221、p2p切片任務(wù)管理模塊222、p2p NAT穿越控制模塊223以及peer交互協(xié)議模塊224。

p2p內(nèi)容檢索模塊221，被配置成實(shí)現(xiàn)p2p軟件開(kāi)發(fā)庫(kù)與p2p控制器103的交互管理，終端的進(jìn)入和退出，下載內(nèi)容檢索以及處理p2p控制器向終端發(fā)出的peer推薦和更新。

其中，終端進(jìn)入與退出，是指終端啟動(dòng)需要通過(guò)該模塊向p2p注冊(cè)終端，意味著新終端加入。同理，終端應(yīng)用退出，也需要向p2p控制器報(bào)備標(biāo)記為不可用，這樣該終端就不會(huì)再作為peer端推薦給其他終端。

p2p切片任務(wù)管理模塊222，被配置成實(shí)現(xiàn)對(duì)已注冊(cè)的p2p文件進(jìn)行任務(wù)管理，切片并發(fā)管理，以實(shí)現(xiàn)最優(yōu)的p2p下載。

p2p NAT穿越控制模塊223，被配置成確保peer之間的鏈路能夠建立。在一個(gè)實(shí)施例中，該p2p NAT穿越控制模塊233主要負(fù)責(zé)在NAT環(huán)境下peer成功建立通訊鏈路。

peer交互協(xié)議模塊224，被配置成實(shí)現(xiàn)peer之間的通訊協(xié)議。

圖3示出根據(jù)本發(fā)明的一實(shí)施例的p2p控制器結(jié)構(gòu)示意圖。

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

peer管理模塊311，被配置成記錄和管理peer的活動(dòng)狀態(tài)。

peer推薦模塊312，被配置成向數(shù)據(jù)下載請(qǐng)求發(fā)出的請(qǐng)求方推薦擁有指定資源的健康的合適的peer列表。在一個(gè)實(shí)施例中，該推薦可以根據(jù)peer的位置、健康度、運(yùn)營(yíng)商歸屬、NAT類(lèi)型等指標(biāo)做出。

NAT穿越輔助模塊313，被配置成協(xié)助peer端發(fā)現(xiàn)自身的NAT環(huán)境，并對(duì)peer間建立連接提供通訊輔助。

軟件開(kāi)發(fā)庫(kù)管理模塊314，被配置成對(duì)軟件開(kāi)發(fā)庫(kù)進(jìn)行配置和管理。該配置和管理包括配置下發(fā)、配置變更等、收集和分析軟件開(kāi)發(fā)庫(kù)的p2p的數(shù)據(jù)。在一個(gè)實(shí)施例中，所述數(shù)據(jù)主要是指p2p行為數(shù)據(jù)，比如哪些請(qǐng)求使用了p2p下載，哪些請(qǐng)求使用http下載，以及如果p2p下載失敗，記錄下載失敗原因等等。

圖4示出根據(jù)本發(fā)明的一實(shí)施例的數(shù)據(jù)下載流程示意圖。

步驟401：終端應(yīng)用模塊的應(yīng)用層發(fā)起數(shù)據(jù)下載請(qǐng)求，并將此請(qǐng)求通過(guò)代理接口導(dǎo)入p2p軟件開(kāi)發(fā)庫(kù)。步驟402：軟件開(kāi)發(fā)庫(kù)的本地代理接口模塊接收數(shù)據(jù)下載請(qǐng)求。

步驟403：軟件開(kāi)發(fā)庫(kù)的下載控制器分析該請(qǐng)求中的url，以判斷該請(qǐng)求是否是p2p請(qǐng)求，例如該URL是否符合預(yù)先設(shè)定的p2p url的正則式設(shè)定。如果不符合，則進(jìn)入步驟404；如果符合，則進(jìn)入步驟405。

步驟404：軟件開(kāi)發(fā)庫(kù)的下載控制器使用http方式下載完整數(shù)據(jù)，例如，采用普通代理管道，轉(zhuǎn)發(fā)請(qǐng)求至緩存系統(tǒng)或者源站，并轉(zhuǎn)交來(lái)自緩存或者源站的響應(yīng)數(shù)據(jù)。

步驟405：軟件開(kāi)發(fā)庫(kù)的下載控制器根據(jù)預(yù)先設(shè)定的提取資源標(biāo)識(shí)的方法提取資源標(biāo)識(shí)，該標(biāo)識(shí)將作為將來(lái)p2p檢索資源的唯一標(biāo)識(shí)。

步驟406：軟件開(kāi)發(fā)庫(kù)的下載控制器組織新的請(qǐng)求，向緩存系統(tǒng)或者源站發(fā)起獲取首包的請(qǐng)求，其中所述首包為欲下載的數(shù)據(jù)的首包。在一個(gè)實(shí)施例中，該請(qǐng)求可以是獲取首片長(zhǎng)度為256KB的range下載請(qǐng)求。

步驟407：軟件開(kāi)發(fā)庫(kù)的下載控制器接收來(lái)自源站或者緩存系統(tǒng)的響應(yīng)數(shù)據(jù)。

步驟408：軟件開(kāi)發(fā)庫(kù)的下載控制器根據(jù)該接收到的響應(yīng)數(shù)據(jù)確定是否可以啟動(dòng)p2p下載。在一個(gè)實(shí)施例中，可以根據(jù)該數(shù)據(jù)的文件長(zhǎng)度和傳輸編碼方式來(lái)確定是否啟動(dòng)p2p下載。如果不符合，則進(jìn)入步驟409；如果符合，則進(jìn)入步驟410，以進(jìn)行p2p下載。

步驟409：軟件開(kāi)發(fā)庫(kù)的下載控制器向緩存系統(tǒng)或者源站發(fā)送http請(qǐng)求，以下載剩余數(shù)據(jù)。

步驟410：軟件開(kāi)發(fā)庫(kù)的P2P切片任務(wù)管理模塊將剩余未下載的數(shù)據(jù)切片成多個(gè)虛擬文件。

步驟411：軟件開(kāi)發(fā)庫(kù)的P2P切片任務(wù)管理模塊向p2p任務(wù)管理器注冊(cè)其中一個(gè)虛擬文件并啟動(dòng)p2p下載。

步驟412：軟件開(kāi)發(fā)庫(kù)的p2p內(nèi)容檢索模塊使用該文件的資源標(biāo)識(shí)向p2p控制器發(fā)起檢索，如果收到來(lái)自p2p控制發(fā)來(lái)的推薦的peer列表便進(jìn)入步驟413；否則，p2p失敗，轉(zhuǎn)交下載剩余文件的請(qǐng)求至緩存系統(tǒng)或者源站，并交付相應(yīng)響應(yīng)數(shù)據(jù)。

步驟413：軟件開(kāi)發(fā)庫(kù)的p2p NAT穿越控制模塊向推薦的peer發(fā)起連接，必要時(shí)通過(guò)p2p控制器的NAT穿越輔助模塊實(shí)現(xiàn)peer的通信鏈路的建立。

步驟414：軟件開(kāi)發(fā)庫(kù)的p2p切片任務(wù)管理模塊成功連接peer后向peer索取所需的資源分片，即當(dāng)前的虛擬文件，并記錄p2p下載的速率，供后續(xù)peer的質(zhì)量排序和并發(fā)控制提供必要數(shù)據(jù)。

步驟415：軟件開(kāi)發(fā)庫(kù)的本地代理接口模塊得到peer的響應(yīng)數(shù)據(jù)后，先向終端應(yīng)用模塊交付響應(yīng)數(shù)據(jù)。

步驟416：軟件開(kāi)發(fā)庫(kù)的緩存控制器將響應(yīng)的數(shù)據(jù)進(jìn)行緩存。如果是重用終端應(yīng)用自有緩存的，則不需要在軟件開(kāi)發(fā)庫(kù)內(nèi)部實(shí)現(xiàn)緩存；如果是軟件開(kāi)發(fā)庫(kù)內(nèi)部實(shí)現(xiàn)緩存的，則要按照緩存控制器的設(shè)定以及終端當(dāng)前的存儲(chǔ)空間來(lái)判定當(dāng)前可用存儲(chǔ)空間是否充足，如果不充足，則可以刪除最冷門(mén)的分享文件再進(jìn)行緩存新文件。在一個(gè)實(shí) 施例中，可以根據(jù)按照LRU(Least Recently Used近期最少使用算法)算法來(lái)刪除最冷門(mén)的分享文件。

步驟417：軟件開(kāi)發(fā)庫(kù)的上傳控制器確定數(shù)據(jù)是否可以共享。在一個(gè)實(shí)施例中，可判斷當(dāng)前的終端環(huán)境是否符合數(shù)據(jù)分享的設(shè)定，該判斷的依據(jù)主要是考察終端的網(wǎng)絡(luò)制式、終端當(dāng)前電量、終端的內(nèi)存使用情況等進(jìn)行綜合判定。如果判斷可以作為種子進(jìn)行分享，則進(jìn)入步驟418；如果不符合，則直接進(jìn)入其他虛擬文件的下載。

步驟418：軟件開(kāi)發(fā)庫(kù)的上傳控制器向p2p控制器進(jìn)行分享注冊(cè)，然后等待接受其他peer的下載請(qǐng)求，同時(shí)進(jìn)入其他虛擬文件下載準(zhǔn)備。

步驟419：軟件開(kāi)發(fā)庫(kù)的下載控制器判定是否已經(jīng)下載完畢，如果是就結(jié)束下載，如果不是則繼續(xù)下載。

步驟420：軟件開(kāi)發(fā)庫(kù)的下載控制器通過(guò)當(dāng)前情況的判定來(lái)決定下一片虛擬文件的下載方式，判定的依據(jù)主要來(lái)自應(yīng)用層狀態(tài)通知以及下載控制器的控制策略，并結(jié)合當(dāng)前的下載情況來(lái)決定下一片虛擬文件的下載方式(通過(guò)http向緩存系統(tǒng)或者源站取數(shù)據(jù)，或者是p2p下載方式)，總之主要是考慮當(dāng)前數(shù)據(jù)下載速率是否滿(mǎn)足數(shù)據(jù)交付的及時(shí)性。如果當(dāng)前下載速率無(wú)法滿(mǎn)足應(yīng)用層需求或者無(wú)法滿(mǎn)足預(yù)設(shè)的下載要求，則使用http方式則直接向緩存系統(tǒng)或者源站發(fā)起長(zhǎng)度為256K數(shù)據(jù)下載請(qǐng)求即可(步驟421)。如果滿(mǎn)足，則通過(guò)對(duì)已有的peer列表中所有peer的下載測(cè)速，進(jìn)行排序，確定可用的peer列表，并確定并發(fā)的數(shù)量。并注冊(cè)相應(yīng)數(shù)量虛擬文件至p2p任務(wù)管理器中，即重復(fù)步驟411及后續(xù)步驟。

按照上述的方式進(jìn)行逐片下載，循環(huán)至下載結(jié)束。這樣可以在確保數(shù)據(jù)可靠、及時(shí)交付的同時(shí)最大化使用p2p下載。

圖5示出根據(jù)本發(fā)明的一實(shí)施例的用于移動(dòng)終端應(yīng)用的p2p內(nèi)容分發(fā)的流程圖。該流程圖包括，但不限于，以下幾個(gè)步驟。步驟501：移動(dòng)終端應(yīng)用集成嵌入軟件開(kāi)發(fā)庫(kù)，并將一下載請(qǐng)求導(dǎo)入所述軟件開(kāi)發(fā)庫(kù)，并等待接收下載數(shù)據(jù)；

步驟502：所述軟件開(kāi)發(fā)庫(kù)接收所述移動(dòng)終端應(yīng)用導(dǎo)入的所述下載請(qǐng)求，并根據(jù)所述請(qǐng)求向緩存系統(tǒng)或源站下載首包，并根據(jù)該首包來(lái)確定是否可以啟動(dòng)p2p下載，其中該首包為欲下載的數(shù)據(jù)的首個(gè)數(shù)據(jù)分片；

步驟503：如果確定可以啟動(dòng)p2p下載，所述軟件開(kāi)發(fā)庫(kù)將剩余的未下載的數(shù)據(jù)切片成多個(gè)虛擬文件；

步驟504：所述軟件開(kāi)發(fā)庫(kù)對(duì)所述多個(gè)虛擬文件逐一發(fā)起下載并緩存下載結(jié)果，直到所有的虛擬文件下載完成，其中，在下載所述虛擬文件過(guò)程中，所述軟件開(kāi)發(fā)庫(kù)將已下載的虛擬文件實(shí)時(shí)轉(zhuǎn)發(fā)給所述移動(dòng)終端應(yīng)用；

步驟505：在下載所述虛擬文件過(guò)程中，所述軟件開(kāi)發(fā)庫(kù)根據(jù)分享策略將已下載并且已緩存的資源進(jìn)行分享。

在一個(gè)實(shí)施例中，所述移動(dòng)終端應(yīng)用將所述下載請(qǐng)求導(dǎo)入所述軟件開(kāi)發(fā)庫(kù)的方法包括通過(guò)主動(dòng)代理或者被動(dòng)劫持的方式的其中一種。

在一個(gè)實(shí)施例中，虛擬文件下載的方式可包括使用http協(xié)議向源站或者緩存系統(tǒng)下載和/或使用p2p的方式下載；其中所述軟件開(kāi)發(fā)庫(kù)計(jì)算使用http協(xié)議的下載速率和使用p2p方式的下載速率，并根據(jù)所述移動(dòng)終端應(yīng)用對(duì)數(shù)據(jù)的需求情況來(lái)決定當(dāng)前虛擬文件采用哪一種下載方式；如果使用p2p的方式無(wú)法下載到所需要的虛擬文件或者下載速率無(wú)法滿(mǎn)足所述移動(dòng)終端應(yīng)用的正常需要，并且p2p下載速率低于http下載速率，則需要使用http方式直接向所述緩存系統(tǒng)或者所述源站下載，除此之外均可使用p2p的方式下載數(shù)據(jù)。在一個(gè)實(shí)施例中，移動(dòng)終端應(yīng)用對(duì)數(shù)據(jù)的需求情況的獲取方法包括所述軟件開(kāi)發(fā)庫(kù)向所述移動(dòng)終端應(yīng)用提供數(shù)據(jù)使用狀態(tài)通知接口，以此來(lái)獲取當(dāng)前移動(dòng)終端應(yīng)用對(duì)數(shù)據(jù)的消費(fèi)情況。

在一個(gè)實(shí)施例中，分享策略可包括，但不限于，根據(jù)所述移動(dòng)終端的網(wǎng)絡(luò)制式、所述移動(dòng)終端的剩余電量、所述移動(dòng)終端的內(nèi)存使用情況、所述移動(dòng)終端的cpu使用情況判斷所下載的數(shù)據(jù)是否可以作為種子進(jìn)行分享；若可以進(jìn)行分享，則對(duì)該分享進(jìn)行注冊(cè)，并等待接收其他移動(dòng)終端應(yīng)用的下載請(qǐng)求。

在一個(gè)實(shí)施例中，確定是否可以啟動(dòng)p2p包括：根據(jù)該首包數(shù)據(jù)中描述的文件長(zhǎng)度和傳輸編碼方式來(lái)確定是否啟動(dòng)p2p下載，如果不符合，則向該緩存系統(tǒng)或者該源站發(fā)送http請(qǐng)求，以下載剩余數(shù)據(jù)；如果符合，則執(zhí)行步驟503。

下面舉一個(gè)具體的實(shí)施例來(lái)說(shuō)明本發(fā)明是如何應(yīng)用的。

一個(gè)具體的應(yīng)用場(chǎng)景可以是：某音樂(lè)應(yīng)用其計(jì)劃做p2p流量是download.a.com域名下所有以mp3為后綴的文件，設(shè)定p2p sdk共享app緩存。

一、進(jìn)行流量導(dǎo)入及流量過(guò)濾

app嵌入p2p sdk，并啟動(dòng)sdk，sdk監(jiān)聽(tīng)本地127.0.0.1:8888接收導(dǎo)入數(shù)據(jù)，在p2p控制器上配置該app的p2p請(qǐng)求正則匹配式：http://download.a.com/.*\.mp3，并將配置下發(fā)至sdk。app應(yīng)用層將將要做p2p下載的流量導(dǎo)入sdk，具體的url是http://download.a.com/1.mp3，sdk根據(jù)正則規(guī)則進(jìn)行匹配，發(fā)現(xiàn)可以匹配則進(jìn)入p2p預(yù)檢流程。

二、p2p預(yù)檢流程

重組請(qǐng)求，向緩存系統(tǒng)或者源站發(fā)起下載目標(biāo)0～262143的片段請(qǐng)求。接收響應(yīng)后，分析響應(yīng)頭部Content-Range字段的值，發(fā)現(xiàn)目標(biāo)總長(zhǎng)度為1435642，超過(guò)1MB的p2p最小文件長(zhǎng)度的設(shè)定，判定可以使用p2p下載剩余文件。sdk向app應(yīng)用層遞交已下載部分，完成以后將剩下的未下載部分按照每片262144的長(zhǎng)度切成5個(gè)虛擬文件，最后一個(gè)文件長(zhǎng)度為124922。

三、資源標(biāo)識(shí)提取&虛擬文件命名

在p2p控制器上配置該app資源標(biāo)識(shí)的提取規(guī)則：http://download.a.com/$1\.mp3，sdk根據(jù)該規(guī)則提取出資源標(biāo)識(shí)為1.mp3，并將這些文件重新命名為1_01.mp3，1_02.mp3…1_05.mp3。完成后向p2p模塊注冊(cè)1_01.mp3的下載任務(wù)。

四、p2p下載

p2p sdk向p2p控制器檢索1_01.mp3的資源，p2p控制器返回檢索結(jié)果，并返回?fù)碛性撡Y源的peer列表。Sdk向列表中所有peer發(fā)起連接，并將下載目標(biāo)分解成64KB的小片，分別向已建立連接的peer發(fā)起資源請(qǐng)求并下載。同時(shí)對(duì)peer的下載速度進(jìn)行排序，以便后續(xù)的下載任務(wù)可以選擇最優(yōu)peer進(jìn)行下載。

五、數(shù)據(jù)緊急度檢查&下載方式選擇

播放器調(diào)用sdk狀態(tài)通知接口告知sdk當(dāng)前的播放偏移位置。Sdk解析已下載的mp3文件得到已下載文件的時(shí)間長(zhǎng)度，從而可以得出已下載的數(shù)據(jù)是否足夠播放器流暢播放。如果能夠流暢播放，將1_0x.mp3的文件注冊(cè)為p2p，如果緩存不充足，則將此虛擬文件切換為普通的range請(qǐng)求直接向緩存系統(tǒng)請(qǐng)求數(shù)據(jù)，以緩解緩存不足的情況。

六、app和p2p sdk共享緩存

app與sdk約定緩存定位符(一個(gè)md5字符串)，將定位符放在響應(yīng)頭部中返回給app，app開(kāi)放標(biāo)準(zhǔn)的緩存提取接口，sdk調(diào)用該接口并且傳入緩存定位符便可獲取完整緩存文件。

七、緩存分享

sdk下載完1.mp3，可以考察當(dāng)前終端是否具備分享?xiàng)l件，當(dāng)前手機(jī)終端使用wifi網(wǎng)絡(luò)，電量還剩下90％，內(nèi)存使用率56％，cpu使用率為60％，具備了緩存分享的條件，向p2p控制器注冊(cè)分享資源，等待資源下載請(qǐng)求。

這里采用的術(shù)語(yǔ)和表述方式只是用于描述，本發(fā)明并不應(yīng)局限于這些術(shù)語(yǔ)和表述。使用這些術(shù)語(yǔ)和表述并不意味著排除任何示意和描述(或其中部分)的等效特征，應(yīng)認(rèn)識(shí)到可能存在的各種修改也應(yīng)包含在權(quán)利要求范圍內(nèi)。其他修改、變化和替換也可能存在。相應(yīng)的，權(quán)利要求應(yīng)視為覆蓋所有這些等效物。

同樣，需要指出的是，雖然本發(fā)明已參照當(dāng)前的具體實(shí)施例來(lái)描述，但是本技術(shù)領(lǐng)域中的普通技術(shù)人員應(yīng)當(dāng)認(rèn)識(shí)到，以上的實(shí)施例僅是用來(lái)說(shuō)明本發(fā)明，在沒(méi)有脫離本發(fā)明精神的情況下還可做出各種等效的變化或替換，因此，只要在本發(fā)明的實(shí)質(zhì)精神范圍內(nèi)對(duì)上述實(shí)施例的變化、變型都將落在本申請(qǐng)的權(quán)利要求書(shū)的范圍內(nèi)。