專(zhuān)利名稱(chēng)：大文件多點(diǎn)分發(fā)系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本申請(qǐng)涉及計(jì)算機(jī)技術(shù)領(lǐng)域，特別是涉及一種大文件多點(diǎn)分發(fā)系統(tǒng)。
背景技術(shù)：
文件分發(fā)是CDN服務(wù)提供商的業(yè)務(wù)與運(yùn)營(yíng)支撐系統(tǒng)必備的支持系統(tǒng)之一。傳統(tǒng) 的文件分發(fā)方式為，以單個(gè)設(shè)備為中心，將文件分發(fā)到多個(gè)設(shè)備上，通常采用的傳輸協(xié)議有 HTTP協(xié)議、FTP協(xié)議等。這種傳統(tǒng)的傳輸方式，在大量文件需要分發(fā)的情況下，因?yàn)樗袡C(jī)器都要從中心 設(shè)備下載或同步文件，例如全網(wǎng)有100臺(tái)設(shè)備需要分發(fā)文件，共有100個(gè)文件需要分發(fā)，每 個(gè)文件100MB，那么中心設(shè)備所需要盛載的壓力是100*100的并發(fā)量，并持續(xù)100MB/(總帶 寬/設(shè)備數(shù)/并發(fā)文件數(shù))的時(shí)間?？梢?jiàn)傳統(tǒng)的文件分發(fā)方式，僅僅從單個(gè)中心設(shè)備處分發(fā)文件，會(huì)迅速增大中心設(shè) 備的負(fù)載，最終導(dǎo)致該中心設(shè)備服務(wù)性能降低，甚至死機(jī)。

發(fā)明內(nèi)容
為解決上述技術(shù)問(wèn)題，本申請(qǐng)實(shí)施例提供一種大文件多點(diǎn)分發(fā)系統(tǒng)，客戶端可以 從中心服務(wù)器或任務(wù)處理服務(wù)器進(jìn)行文件的下載或上傳，避免了文件只能從中心服務(wù)器下 載或上傳導(dǎo)致中心服務(wù)器性能降低或死機(jī)的問(wèn)題。技術(shù)方案如下—種大文件多點(diǎn)分發(fā)系統(tǒng)，包括客戶端、中心服務(wù)器、上傳服務(wù)器及若干任務(wù)處 理服務(wù)器；當(dāng)客戶端需要上傳文件時(shí)，客戶端向中心服務(wù)器發(fā)送文件上傳請(qǐng)求，中心服務(wù)器 接收到所述上傳請(qǐng)求后，為所述客戶端確定目標(biāo)任務(wù)處理服務(wù)器，所述客戶端將需要上傳 的文件通過(guò)上傳服務(wù)器上傳至所述中心服務(wù)器或目標(biāo)任務(wù)處理服務(wù)器；當(dāng)客戶端需要下載文件時(shí)，客戶端向中心服務(wù)器發(fā)送文件下載請(qǐng)求，中心服務(wù)器 接收到所述下載請(qǐng)求后，分發(fā)下載任務(wù)至所述任務(wù)處理服務(wù)器，所述中心服務(wù)器或任務(wù)處 理服務(wù)器將所述客戶端需要下載的文件發(fā)送至客戶端。上述的系統(tǒng)，優(yōu)選的，所述客戶端上傳文件至所述任務(wù)處理服務(wù)器或從所述任務(wù) 處理服務(wù)器下載文件的過(guò)程中，文件以分片傳輸?shù)姆绞竭M(jìn)行傳輸。上述的系統(tǒng)，優(yōu)選的，所述任務(wù)處理服務(wù)器包括任務(wù)接收模塊、任務(wù)處理模塊和任 務(wù)反饋模塊；所述任務(wù)接收模塊用于接收中心服務(wù)器發(fā)送的文件任務(wù)；所述任務(wù)處理模塊用于對(duì)所述任務(wù)接收模塊接收的文件任務(wù)進(jìn)行處理，接收所述 客戶端上傳的文件或發(fā)送所述客戶端需要的文件至所述客戶端；所述任務(wù)反饋模塊用于將所述任務(wù)處理模塊對(duì)文件任務(wù)的處理結(jié)果反饋至所述 中心服務(wù)器。
上述的系統(tǒng)，優(yōu)選的，所述任務(wù)處理模塊接收所述客戶端上傳的文件或發(fā)送所述 客戶端需要的文件至所述客戶端的過(guò)程中，文件傳輸采用P2P形式傳送。上述的系統(tǒng)，優(yōu)選的，所述文件傳輸過(guò)程中，若P2P形式傳輸效率低或無(wú)法傳送， 客戶端向中心服務(wù)器請(qǐng)求申請(qǐng)http協(xié)議或UDT協(xié)議進(jìn)行傳輸。上述的系統(tǒng)，優(yōu)選的，在文件傳輸過(guò)程中，若文件傳輸在同一網(wǎng)絡(luò)下傳輸，采用P2P 形式傳輸；若文件傳輸在不同網(wǎng)絡(luò)下傳輸，采用UDT協(xié)議進(jìn)行傳輸。上述的系統(tǒng)，優(yōu)選的，在文件傳輸過(guò)程中，中心服務(wù)器可根據(jù)任務(wù)處理服務(wù)器的地 址確定距離所述中心服務(wù)器最近的任務(wù)處理服務(wù)器。上述的系統(tǒng)，優(yōu)選的，所述上傳服務(wù)器包括上傳管理模塊；所述上傳管理模塊以動(dòng)態(tài)探索鏈路協(xié)議為基礎(chǔ)，對(duì)上傳文件進(jìn)行分塊管理。由以上本申請(qǐng)實(shí)施例提供的技術(shù)方案可見(jiàn)，本發(fā)明提供的大文件多點(diǎn)分發(fā)系統(tǒng)， 客戶端上傳或下載文件時(shí)，中心服務(wù)器會(huì)對(duì)任務(wù)處理服務(wù)器進(jìn)行目標(biāo)確定或分發(fā)任務(wù)，任 務(wù)處理服務(wù)器接收用戶上傳的文件，或?qū)⒂脩粜枰螺d的文件下發(fā)到客戶端，由于任務(wù)處 理服務(wù)器的加入，很大程度上緩解了中心服務(wù)器的工作壓力，提高了整個(gè)系統(tǒng)的服務(wù)性能， 并且避免了所有文件的處理都經(jīng)過(guò)中心服務(wù)器，最終導(dǎo)致中心服務(wù)器服務(wù)性能降低，甚至 死機(jī)的現(xiàn)象。


為了更清楚地說(shuō)明本申請(qǐng)實(shí)施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對(duì)實(shí)施例或現(xiàn) 有技術(shù)描述中所需要使用的附圖作簡(jiǎn)單地介紹，顯而易見(jiàn)地，下面描述中的附圖僅僅是本 申請(qǐng)中記載的一些實(shí)施例，對(duì)于本領(lǐng)域普通技術(shù)人員來(lái)講，在不付出創(chuàng)造性勞動(dòng)的前提下， 還可以根據(jù)這些附圖獲得其他的附圖。圖1為本申請(qǐng)實(shí)施例提供的大文件多點(diǎn)分發(fā)系統(tǒng)的結(jié)構(gòu)示意圖；圖2為本申請(qǐng)實(shí)施例提供的任務(wù)處理服務(wù)器的結(jié)構(gòu)示意圖；圖3為本申請(qǐng)實(shí)施例提供的大文件多點(diǎn)分發(fā)系統(tǒng)的連接關(guān)系圖；圖4為本申請(qǐng)實(shí)施例提供的大文件多點(diǎn)分發(fā)系統(tǒng)的一詳細(xì)結(jié)構(gòu)示意圖。
具體實(shí)施例方式為了使本技術(shù)領(lǐng)域的人員更好地理解本申請(qǐng)方案。下面將結(jié)合本申請(qǐng)實(shí)施例中的 附圖，對(duì)本申請(qǐng)實(shí)施例中的技術(shù)方案進(jìn)行清楚、完整地描述，顯然，所描述的實(shí)施例僅僅是 本申請(qǐng)一部分實(shí)施例，而不是全部的實(shí)施例?；诒旧暾?qǐng)中的實(shí)施例，本領(lǐng)域普通技術(shù)人員 在沒(méi)有做出創(chuàng)造性勞動(dòng)前提下所獲得的所有其他實(shí)施例，都應(yīng)當(dāng)屬于本申請(qǐng)保護(hù)的范圍。本申請(qǐng)實(shí)施例提供的大文件多點(diǎn)分發(fā)系統(tǒng)的結(jié)構(gòu)示意圖如圖1所示，包括客戶 端101、中心服務(wù)器102、上傳服務(wù)器103和若干任務(wù)處理服務(wù)器104 ；當(dāng)客戶端101需要上傳文件時(shí)，客戶端向中心服務(wù)器102發(fā)送文件上傳請(qǐng)求，中心 服務(wù)器102接收到上傳請(qǐng)求后，為客戶端101確定目標(biāo)任務(wù)處理服務(wù)器，客戶端101將需要 上傳的文件通過(guò)上傳服務(wù)器103上傳至所述中心服務(wù)器102或目標(biāo)任務(wù)處理服務(wù)器；當(dāng)客戶端101需要下載文件時(shí)，客戶端101向中心服務(wù)器102發(fā)送文件下載請(qǐng)求， 中心服務(wù)器102接收到下載請(qǐng)求后，分發(fā)下載任務(wù)至任務(wù)處理服務(wù)器104，中心服務(wù)器102或任務(wù)處理服務(wù)器104將客戶端需要下載的文件發(fā)送至客戶端101。需要說(shuō)明的是中心服務(wù)器是系統(tǒng)的核心，負(fù)責(zé)管理整個(gè)系統(tǒng)的文件任務(wù)，上傳 任務(wù)和下載任務(wù)，將文件下達(dá)至任務(wù)處理服務(wù)器，實(shí)現(xiàn)多線程下對(duì)文件的多線程上傳或下 載；客戶端和中心服務(wù)器的交互包括客戶端向中心服務(wù)器查詢?nèi)蝿?wù)狀態(tài)、中心服務(wù) 器反饋任務(wù)狀態(tài)至客戶端、客戶端向中心服務(wù)器請(qǐng)求API或獲得狀態(tài)報(bào)告。本申請(qǐng)實(shí)施例提供的文件多點(diǎn)分發(fā)系統(tǒng)中，客戶端上傳文件至任務(wù)處理服務(wù)器或 從所述任務(wù)處理服務(wù)器下載文件的過(guò)程中，文件以分片傳輸?shù)姆绞竭M(jìn)行傳輸；在傳輸過(guò)程中，上傳服務(wù)器通過(guò)動(dòng)態(tài)計(jì)算獲得最優(yōu)鏈路設(shè)備進(jìn)行文件上傳，在數(shù) 據(jù)文件上傳成功后，會(huì)同時(shí)上傳一個(gè)任務(wù)文件，任務(wù)處理服務(wù)器掃描到有新的任務(wù)文件上 傳時(shí)，通知中心服務(wù)器生成文件任務(wù)即生成任務(wù)接口 ；將文件以分片傳輸?shù)男问竭M(jìn)行傳輸。本申請(qǐng)實(shí)施例提供的任務(wù)處理服務(wù)器的結(jié)構(gòu)示意圖如圖2所示，包括任務(wù)接收 模塊201、任務(wù)處理模塊202和任務(wù)反饋模塊203 ；其中任務(wù)接收模塊201用于接收中心服務(wù)器發(fā)送的文件任務(wù)；任務(wù)處理模塊用于對(duì)任務(wù)接收模塊201接收的文件任務(wù)進(jìn)行處理，接收客戶端上 傳的文件或發(fā)送客戶端需要的文件至客戶端；任務(wù)反饋模塊203用于將任務(wù)處理模塊對(duì)文件任務(wù)的處理結(jié)果反饋至中心服務(wù)
ο需要說(shuō)明的是任務(wù)接收模塊從中心服務(wù)器接收到任務(wù)后，將其序列化到本地服 務(wù)器進(jìn)行保存；任務(wù)反饋模塊使用http協(xié)議，將操作成功或失敗的任務(wù)反饋給中心服務(wù)器；文件傳輸時(shí)，系統(tǒng)默認(rèn)采用分片P2P傳輸對(duì)文件進(jìn)行傳輸，有效提高傳輸效率；本 申請(qǐng)實(shí)施例提供的大文件多點(diǎn)分發(fā)系統(tǒng)的連接關(guān)系圖如圖3所示，中心服務(wù)器與任務(wù)處理 服務(wù)器之間采用P2P方式進(jìn)行連接；同步的所有任務(wù)處理服務(wù)器為一個(gè)共享組，當(dāng)一個(gè)文件在該共享組內(nèi)的一臺(tái)任務(wù) 處理服務(wù)器上存在了，所有任務(wù)處理服務(wù)器開(kāi)始對(duì)文件進(jìn)行同步，每個(gè)任務(wù)處理服務(wù)器從 已經(jīng)存在該文件的任務(wù)處理服務(wù)器上獲取一部分文件，取文件的同時(shí)并將自己獲得的文件 共享給其它組內(nèi)任務(wù)處理服務(wù)器使用，這樣中心服務(wù)器在傳輸一個(gè)文件的過(guò)程中所耗費(fèi)的 流量大大降低，一般情況下中心服務(wù)器在向組內(nèi)共享1 2份文件即可退出傳輸，組內(nèi)所有 設(shè)備會(huì)先后從其它設(shè)備處獲取文件，最終形成整個(gè)文件。這樣中心服務(wù)器的壓力會(huì)隨之減少，因?yàn)樗械耐轿募娜蝿?wù)處理服務(wù)器都會(huì) 分享自己的一部分內(nèi)容給其它任務(wù)處理服務(wù)器，所以不是所有的任務(wù)處理服務(wù)器都會(huì)從中 心服務(wù)器獲取文件；采用P2P形式進(jìn)行傳輸，避免了單臺(tái)服務(wù)器到中心服務(wù)器鏈路不正常 導(dǎo)致的整體速度降低的情況。圖3中中心服務(wù)器還主要負(fù)責(zé)告訴每個(gè)需要同步文件的任務(wù)處理服務(wù)器哪里有 該任務(wù)處理服務(wù)器需要的文件。中心服務(wù)器是整個(gè)P2P傳輸?shù)目刂浦行?，中心服?wù)器存儲(chǔ)了所有任務(wù)處理服務(wù)器 的文件信息以及持有量的信息；中心服務(wù)器會(huì)根據(jù)所有任務(wù)處理服務(wù)器的IP地址，分析出 哪些任務(wù)處理服務(wù)器時(shí)最近的，并將這些信息通知需要獲取文件的任務(wù)處理服務(wù)器；該任務(wù)處理服務(wù)器獲取到同一網(wǎng)段的任務(wù)處理服務(wù)器存在自己需要的信息后，會(huì)嘗試詢問(wèn)被下 載的任務(wù)處理服務(wù)器的內(nèi)網(wǎng)IP，如果可以成功使用IP進(jìn)行傳輸，那么任務(wù)處理服務(wù)器會(huì)優(yōu) 先選擇內(nèi)網(wǎng)IP，此功能將大量降低同局域網(wǎng)內(nèi)任務(wù)處理服務(wù)器之間傳輸文件所消耗的外網(wǎng) 帶寬資源。同時(shí)需要得到文件的任務(wù)處理服務(wù)器在不通過(guò)中心服務(wù)器的情況下依然可以進(jìn) 行內(nèi)網(wǎng)任務(wù)處理服務(wù)器尋找。該任務(wù)處理服務(wù)器會(huì)使用內(nèi)網(wǎng)IP向內(nèi)網(wǎng)進(jìn)行廣播，并告知自 己所需要的文件的hash編碼，當(dāng)有其它任務(wù)處理服務(wù)器受到消息并判斷自己存在此文件 時(shí)，將回應(yīng)該任務(wù)處理服務(wù)器，該任務(wù)處理服務(wù)器可以順利通過(guò)內(nèi)網(wǎng)進(jìn)行文件傳輸，從而有 效的降低中心服務(wù)器的服務(wù)壓力。本申請(qǐng)實(shí)施例提供的文件多點(diǎn)分發(fā)系統(tǒng)，采用跨網(wǎng)使用傳統(tǒng)方式同步，同網(wǎng)使用 P2P形式同步的方式，系統(tǒng)會(huì)在文件要同步的時(shí)候首先對(duì)需要同步的任務(wù)處理服務(wù)器進(jìn)行 運(yùn)營(yíng)商區(qū)分，動(dòng)態(tài)的獲得跨網(wǎng)傳輸路由最好的線路進(jìn)行跨網(wǎng)文件傳輸，一般采用UDT協(xié)議 進(jìn)行傳輸，因?yàn)閁DT協(xié)議在網(wǎng)絡(luò)狀況不好的情況下相對(duì)于TCP而言可有效的提高傳輸效率， 當(dāng)某個(gè)運(yùn)營(yíng)商的網(wǎng)內(nèi)已經(jīng)存在了該文件，那么服務(wù)器會(huì)立即開(kāi)始進(jìn)行P2P傳輸，這樣既解 決了跨網(wǎng)的問(wèn)題，又省去了租用跨運(yùn)營(yíng)商機(jī)房的高額成本。UDT協(xié)議是以UDP協(xié)議為底層封 裝的一個(gè)向TCP協(xié)議一樣的安全傳輸協(xié)議。系統(tǒng)在傳輸文件的時(shí)候，首先使用P2P協(xié)議進(jìn)行文件傳輸，此時(shí)如果傳輸?shù)男?很低或者更本無(wú)法傳輸?shù)臅r(shí)候，客戶端會(huì)向中心服務(wù)器申請(qǐng)一個(gè)可提供http協(xié)議或UDT協(xié) 議進(jìn)行傳輸?shù)牡刂罚讷@得了新上層服務(wù)器后，任務(wù)處理服務(wù)器會(huì)向中心服務(wù)器提交某文 件的分發(fā)申請(qǐng)，如果存在服務(wù)器有空閑資源可提供分發(fā)服務(wù)器，那么該服務(wù)器會(huì)主動(dòng)向被 分發(fā)服務(wù)器發(fā)送接收文件請(qǐng)求，這樣，任務(wù)處理服務(wù)器則通過(guò)新的傳輸協(xié)議進(jìn)行文件分發(fā)。本申請(qǐng)實(shí)施例提供的大文件多點(diǎn)分發(fā)系統(tǒng)的一詳細(xì)結(jié)構(gòu)示意圖如圖4所示，上傳 服務(wù)器包括上傳管理模塊204 ；所述上傳管理模塊以動(dòng)態(tài)探索鏈路協(xié)議為基礎(chǔ)，對(duì)上傳文件進(jìn)行分塊管理；一個(gè) 高效的上傳工具是必不可少的。因?yàn)榭蛻艋蚓W(wǎng)民會(huì)在整個(gè)國(guó)家任何地方上傳文件，網(wǎng)絡(luò)情 況，運(yùn)營(yíng)商情況相當(dāng)復(fù)雜，為解決此問(wèn)題，此系統(tǒng)設(shè)計(jì)了一個(gè)動(dòng)態(tài)探索鏈路多協(xié)議上傳工 具，此工具在用戶登錄后，會(huì)主動(dòng)請(qǐng)求中心服務(wù)器，從服務(wù)器處得到可用的上傳接收服務(wù) 器，在得到服務(wù)器列表后，上傳工具會(huì)客戶點(diǎn)擊上傳后動(dòng)態(tài)的計(jì)算所有服務(wù)器的實(shí)際傳輸 速度，主要測(cè)試2種協(xié)議TCP和UDT，在同網(wǎng)甚至同地區(qū)的情況下會(huì)優(yōu)先使用TCP協(xié)議進(jìn)行 傳輸測(cè)試，跨運(yùn)營(yíng)商的情況下會(huì)優(yōu)先使用UDT協(xié)議進(jìn)行測(cè)試，在測(cè)試過(guò)程中，為了提高客戶 的體驗(yàn)會(huì)同時(shí)進(jìn)行文件校驗(yàn)，供后面的分發(fā)使用，在獲得到最高效的上傳節(jié)點(diǎn)后，程序會(huì)并 行進(jìn)行文件分塊上傳，這也是一個(gè)高效利用CPU資源的地方，傳統(tǒng)的傳輸工具一般不會(huì)采 用分塊文件上傳的方式上傳文件。在分塊后，啟動(dòng)多線程進(jìn)行文件上傳，文件上傳過(guò)程中，工具會(huì)根據(jù)實(shí)際每個(gè)線程 的傳輸效率動(dòng)態(tài)的修改傳輸塊的大小，得以讓最快的線程多傳一些文件。本說(shuō)明書(shū)中的各個(gè)實(shí)施例均采用遞進(jìn)的方式描述，各個(gè)實(shí)施例之間相同相似的部 分互相參見(jiàn)即可，每個(gè)實(shí)施例重點(diǎn)說(shuō)明的都是與其他實(shí)施例的不同之處。以上所述僅是本 申請(qǐng)的具體實(shí)施方式
，應(yīng)當(dāng)指出，對(duì)于本技術(shù)領(lǐng)域的普通技術(shù)人員來(lái)說(shuō)，在不脫離本申請(qǐng)?jiān)?理的前提下，還可以做出若干改進(jìn)和潤(rùn)飾，這些改進(jìn)和潤(rùn)飾也應(yīng)視為本申請(qǐng)的保護(hù)范圍。
權(quán)利要求
一種大文件多點(diǎn)分發(fā)系統(tǒng)，其特征在于，包括客戶端、中心服務(wù)器、上傳服務(wù)器及若干任務(wù)處理服務(wù)器；當(dāng)客戶端需要上傳文件時(shí)，客戶端向中心服務(wù)器發(fā)送文件上傳請(qǐng)求，中心服務(wù)器接收到所述上傳請(qǐng)求后，為所述客戶端確定目標(biāo)任務(wù)處理服務(wù)器，所述客戶端將需要上傳的文件通過(guò)上傳服務(wù)器上傳至所述中心服務(wù)器或目標(biāo)任務(wù)處理服務(wù)器；當(dāng)客戶端需要下載文件時(shí)，客戶端向中心服務(wù)器發(fā)送文件下載請(qǐng)求，中心服務(wù)器接收到所述下載請(qǐng)求后，分發(fā)下載任務(wù)至所述任務(wù)處理服務(wù)器，所述中心服務(wù)器或任務(wù)處理服務(wù)器將所述客戶端需要下載的文件發(fā)送至客戶端。
2.根據(jù)權(quán)利要求1所述的系統(tǒng)，其特征在于，所述客戶端上傳文件至所述任務(wù)處理服 務(wù)器或從所述任務(wù)處理服務(wù)器下載文件的過(guò)程中，文件以分片傳輸?shù)姆绞竭M(jìn)行傳輸。
3.根據(jù)權(quán)利要求1所述的系統(tǒng)，其特征在于，所述任務(wù)處理服務(wù)器包括任務(wù)接收模塊、 任務(wù)處理模塊和任務(wù)反饋模塊；所述任務(wù)接收模塊用于接收中心服務(wù)器發(fā)送的文件任務(wù)；所述任務(wù)處理模塊用于對(duì)所述任務(wù)接收模塊接收的文件任務(wù)進(jìn)行處理，接收所述客戶 端上傳的文件或發(fā)送所述客戶端需要的文件至所述客戶端；所述任務(wù)反饋模塊用于將所述任務(wù)處理模塊對(duì)文件任務(wù)的處理結(jié)果反饋至所述中心 服務(wù)器。
4.根據(jù)權(quán)利要求3所述的系統(tǒng)，其特征在于，所述任務(wù)處理模塊接收所述客戶端上傳 的文件或發(fā)送所述客戶端需要的文件至所述客戶端的過(guò)程中，文件傳輸采用P2P形式傳送。
5.根據(jù)權(quán)利要求4所述的系統(tǒng)，其特征在于，所述文件傳輸過(guò)程中，若P2P形式傳輸效 率低或無(wú)法傳送，客戶端向中心服務(wù)器請(qǐng)求申請(qǐng)http協(xié)議或UDT協(xié)議進(jìn)行傳輸。
6.根據(jù)權(quán)利要求4所述的系統(tǒng)，其特征在于，在文件傳輸過(guò)程中，若文件傳輸在同一網(wǎng) 絡(luò)下傳輸，采用P2P形式傳輸；若文件傳輸在不同網(wǎng)絡(luò)下傳輸，采用UDT協(xié)議進(jìn)行傳輸。
7.根據(jù)權(quán)利要求4所述的系統(tǒng)，其特征在于，在文件傳輸過(guò)程中，中心服務(wù)器可根據(jù)任 務(wù)處理服務(wù)器的地址確定距離所述中心服務(wù)器最近的任務(wù)處理服務(wù)器。
8.根據(jù)權(quán)利要求1所述的系統(tǒng)，其特征在于，所述上傳服務(wù)器包括上傳管理模塊；所述上傳管理模塊以動(dòng)態(tài)探索鏈路協(xié)議為基礎(chǔ)，對(duì)上傳文件進(jìn)行分塊管理。
全文摘要
本申請(qǐng)公開(kāi)了一種大文件多點(diǎn)分發(fā)系統(tǒng)，包括客戶端、中心服務(wù)器、上傳服務(wù)器及若干任務(wù)處理服務(wù)器；當(dāng)客戶端需要上傳文件時(shí)，客戶端向中心服務(wù)器發(fā)送文件上傳請(qǐng)求，中心服務(wù)器接收到上傳請(qǐng)求后，為客戶端確定目標(biāo)任務(wù)處理服務(wù)器，客戶端將需要上傳的文件通過(guò)上傳服務(wù)器上傳至中心服務(wù)器或目標(biāo)任務(wù)處理服務(wù)器；當(dāng)客戶端需要下載文件時(shí)，客戶端向中心服務(wù)器發(fā)送文件下載請(qǐng)求，中心服務(wù)器接收到下載請(qǐng)求后，分發(fā)下載任務(wù)至任務(wù)處理服務(wù)器，中心服務(wù)器或任務(wù)處理服務(wù)器將客戶端需要下載的文件發(fā)送至客戶端；有效避免了文件只能從中心服務(wù)器下載或上傳導(dǎo)致中心服務(wù)器性能降低或死機(jī)的問(wèn)題。
文檔編號(hào)H04L29/08GK101977236SQ20101053442
公開(kāi)日2011年2月16日 申請(qǐng)日期2010年11月5日 優(yōu)先權(quán)日2010年11月5日
發(fā)明者劉賓, 周福, 楊凡, 蔣建平 申請(qǐng)人:北京云快線軟件服務(wù)有限公司;北京世紀(jì)互聯(lián)工程技術(shù)服務(wù)有限公司