專利名稱：：一種大容量文件傳輸方法
技術(shù)領(lǐng)域：
：本發(fā)明涉及計(jì)算機(jī)網(wǎng)絡(luò)
技術(shù)領(lǐng)域：
，具體地說(shuō)，本發(fā)明特別涉及一種文件傳輸方法。
背景技術(shù)：
：目前，大多數(shù)企業(yè)的經(jīng)營(yíng)都涉及到多種性質(zhì)不同的業(yè)務(wù),因此在企業(yè)內(nèi)部的計(jì)算機(jī)網(wǎng)絡(luò)中，通常形成多個(gè)業(yè)務(wù)應(yīng)用子網(wǎng)來(lái)分別滿足這些業(yè)務(wù)的需求，而數(shù)據(jù)需要在各子網(wǎng)之間需要共享或者傳輸。以廣電行業(yè)為例，當(dāng)前國(guó)內(nèi)外廣電行業(yè)在信息化方面的總體發(fā)展方向是網(wǎng)絡(luò)化、信息化，根據(jù)在電視臺(tái)的實(shí)際業(yè)務(wù)中涉及多種性質(zhì)不同的業(yè)務(wù)需求，電視臺(tái)內(nèi)部形成多個(gè)業(yè)務(wù)應(yīng)用子網(wǎng)來(lái)滿足電視臺(tái)"采、編、播、存、管，，的整個(gè)電視工藝流程。其中，節(jié)目素材需要子網(wǎng)之間共享或者傳輸，因此，對(duì)文件傳輸方式需要一種合理可行的模式，而現(xiàn)有技術(shù)沒(méi)有很好地解決這一問(wèn)題。首先，傳統(tǒng)的文件傳輸方式一般是在兩個(gè)子網(wǎng)不同應(yīng)用系統(tǒng)之間點(diǎn)對(duì)點(diǎn)的通信和傳輸，一般這種情況下，兩個(gè)系統(tǒng)都需要提供客戶端和服務(wù)端程序，當(dāng)需要進(jìn)行文件傳輸?shù)南到y(tǒng)個(gè)數(shù)增加時(shí)，增加各個(gè)系統(tǒng)負(fù)擔(dān)和運(yùn)行成本。此種模式下，系統(tǒng)之間關(guān)聯(lián)的數(shù)量是[N(N-l)]/2,每當(dāng)增加一個(gè)應(yīng)用系統(tǒng)時(shí)，系統(tǒng)的關(guān)聯(lián)度增加N(參考圖l和圖2)，并需要在所關(guān)聯(lián)系統(tǒng)上分別提供對(duì)新增系統(tǒng)的客戶端和服務(wù)端程序。再者，目前通用的文件傳輸協(xié)議不能很好的支持大容量文件傳輸。目前通用的文件傳輸技術(shù)包括文件拷貝、FTP文件傳輸協(xié)議、TCP/IP傳輸協(xié)議等。文件拷貝的方式，通常用于同一子網(wǎng)開(kāi)放權(quán)限的兩個(gè)傳輸終端之間的文件傳輸。而企業(yè)(如電視臺(tái))內(nèi)部的業(yè)務(wù)板塊網(wǎng)通常是各自組建，并且基于網(wǎng)絡(luò)安全和數(shù)據(jù)安全的需要，具有較為嚴(yán)格的權(quán)限控制策略。因此，文件拷貝的方式，不適合用來(lái)打通電視臺(tái)業(yè)務(wù)板塊之間的數(shù)據(jù)互通，而且也不具有跨平臺(tái)性。FTP(FileTransferProtocol)是Internet傳統(tǒng)的服務(wù)之一，但是如果在系統(tǒng)內(nèi)部架設(shè)FTP服務(wù)器，并不具有較好的擴(kuò)展性，如果專門(mén)開(kāi)發(fā)應(yīng)用程序使用FTP協(xié)議進(jìn)行文件傳輸在文件完整性校驗(yàn)上也不具備足夠的靈活性。最后，在文件傳輸過(guò)程中，有時(shí)會(huì)出現(xiàn)數(shù)據(jù)丟失(或損壞)的問(wèn)題，為解決這一問(wèn)題，需要對(duì)接收到的文件數(shù)據(jù)進(jìn)行完整性驗(yàn)證。常見(jiàn)的數(shù)據(jù)完整性驗(yàn)證算法包括MD5和SHA1。SHA1算法對(duì)路由器等網(wǎng)絡(luò)組件的要求較高。而MD5是由RSA發(fā)明的一種消息摘要算法，具有快速和高效的優(yōu)點(diǎn)。另夕卜，使用JAVA語(yǔ)言開(kāi)發(fā)的應(yīng)用程序，可以方便的嵌入MD5算法。目前，Internet上很多國(guó)外的網(wǎng)站提供的下載資源都會(huì)同時(shí)提供一個(gè)md5驗(yàn)證文件。在接收端對(duì)整個(gè)文件進(jìn)行一次md5編碼，一旦驗(yàn)證失敗，則將文件重新傳輸一遍。這種完整性校驗(yàn)方法能夠有效地防止數(shù)據(jù)丟失(或損壞)，但當(dāng)傳輸?shù)奈募?shù)據(jù)量較大時(shí)，特別是傳輸媒體文件時(shí)，重新傳輸整個(gè)文件將耗費(fèi)大量的資源，極大地影響傳輸速度，甚至還會(huì)造成網(wǎng)絡(luò)擁塞，因此，迫切需要一種適合于大數(shù)據(jù)量文件傳輸?shù)耐暾则?yàn)證方法。
發(fā)明內(nèi)容本發(fā)明的目的是克服現(xiàn)有技術(shù)的不足，解決跨網(wǎng)段數(shù)據(jù)傳輸、大數(shù)據(jù)量文件傳輸、文件數(shù)據(jù)的完整性保證和傳輸安全性等方面的技術(shù)問(wèn)題，從而提供一種適合于大容量數(shù)據(jù)的文件傳輸方法。為實(shí)現(xiàn)上述發(fā)明目的，本發(fā)明提供的大容量文件傳輸方法，該方法基于Xfer網(wǎng)絡(luò)構(gòu)架實(shí)現(xiàn)，該網(wǎng)絡(luò)構(gòu)架包括通過(guò)總線連接的主干網(wǎng)和多個(gè)板塊網(wǎng)；每個(gè)所述板塊網(wǎng)至少包括一個(gè)xPeer服務(wù)器和多個(gè)應(yīng)用節(jié)點(diǎn)，所述主干網(wǎng)包括M-Peer服務(wù)器；所述大容量文件傳輸方法包括如下步驟1)一個(gè)應(yīng)用節(jié)點(diǎn)(下文中將其稱為接收節(jié)點(diǎn))請(qǐng)求傳輸另一應(yīng)用節(jié)點(diǎn)(下文中將其稱為服務(wù)節(jié)點(diǎn))中的文件；2)所述接收節(jié)點(diǎn)所在板塊網(wǎng)的xPeer服務(wù)器對(duì)攜帶所述請(qǐng)求的信令進(jìn)行封裝，然后與所述服務(wù)節(jié)點(diǎn)所在板塊網(wǎng)的xPeer服務(wù)器進(jìn)行通信，在所述主干網(wǎng)的M-Peer服務(wù)器的調(diào)度下，將所述文件通過(guò)總線傳輸至所述接收節(jié)點(diǎn)所在板塊網(wǎng)的xPeer服務(wù)器上；3)所述接收節(jié)點(diǎn)從所在板塊網(wǎng)的xPeer服務(wù)器獲取所述文件。上述技術(shù)方案中，所述步驟2)中，各板塊網(wǎng)的xPeer服務(wù)器采用SimpleFTP協(xié)議進(jìn)行通信，所述SimpleFTP協(xié)議的程序包包括命令模塊、文件查驗(yàn)?zāi)K、數(shù)據(jù)傳輸模塊、完整性驗(yàn)證模塊和錯(cuò)誤重傳模塊。上述技術(shù)方案中，基于SimpleFTP協(xié)議的文件傳輸過(guò)程如下21)在所述命令模塊，發(fā)送獲取文件信息消息，該消息中攜帶需要驗(yàn)證的遠(yuǎn)程文件的文件名；22)在所述文件查驗(yàn)?zāi)K，返回服務(wù)應(yīng)答消息，該應(yīng)答消息中攜帶所述遠(yuǎn)程文件的數(shù)據(jù)量大小的信息；23)在所述命令模塊，根據(jù)文件的數(shù)據(jù)量大小，將文件分為多個(gè)數(shù)據(jù)段；24)在所述命令模塊，選取一個(gè)數(shù)據(jù)段，發(fā)送傳送文件消息，該傳送文件消息攜帶所述數(shù)據(jù)段傳輸?shù)钠鹗键c(diǎn)和結(jié)束點(diǎn)；25)在所述數(shù)據(jù)傳輸模塊，根據(jù)收到的傳送文件消息進(jìn)行數(shù)據(jù)傳輸；26)在所述完整性驗(yàn)證模塊，在接收完本次傳輸?shù)臄?shù)據(jù)段后，對(duì)該數(shù)據(jù)段進(jìn)行完整性驗(yàn)證；如通過(guò)完整性驗(yàn)證，則回到步驟4)繼續(xù)傳輸下一個(gè)數(shù)據(jù)段，直到所述遠(yuǎn)程文件傳輸完畢；27)在所述錯(cuò)誤重傳模塊，當(dāng)本次傳輸?shù)臄?shù)據(jù)段未能通過(guò)完整性驗(yàn)證時(shí)，客戶端重新發(fā)送傳送文件消息，請(qǐng)求重新傳輸該數(shù)據(jù)段。上述技術(shù)方案中，所述步驟23)中，所述每個(gè)數(shù)據(jù)段的數(shù)據(jù)量為256k的整數(shù)倍。上述技術(shù)方案中，所述每個(gè)數(shù)據(jù)段的數(shù)據(jù)量在1M至10M的范圍內(nèi)。上述技術(shù)方案中，所述文件為媒體文件。上述技術(shù)方案中，所述步驟27)中，為重新傳輸所述數(shù)據(jù)段設(shè)置一個(gè)最大次數(shù)，當(dāng)一個(gè)數(shù)據(jù)段重傳次數(shù)達(dá)到該最大次數(shù)時(shí)，則舍棄該數(shù)據(jù)段。上述技術(shù)方案中，所迷步驟26)中，所述完整性驗(yàn)證的方法可以采用MD5算法或CRC算法。與現(xiàn)有技術(shù)相比，本發(fā)明能夠達(dá)到如下技術(shù)效果本發(fā)明的網(wǎng)絡(luò)構(gòu)架能夠讓大容量文件(如i某體文件)在企業(yè)(如電視臺(tái))內(nèi)部各個(gè)板塊之間直接進(jìn)行快速、合理交換，降低勞動(dòng)成本，提高節(jié)目生產(chǎn)效率。另外，本發(fā)明能夠通過(guò)簡(jiǎn)單的注冊(cè)方式增加需要進(jìn)行文件傳輸?shù)南到y(tǒng)個(gè)數(shù)，維護(hù)方便。本發(fā)明的快速文件傳輸協(xié)議可以方便的組織、管理和調(diào)度文件傳輸?shù)倪^(guò)程。本發(fā)明的快速文件傳輸協(xié)議在傳輸?shù)耐瑫r(shí)，還對(duì)數(shù)據(jù)進(jìn)行摘要計(jì)算和驗(yàn)證，保證了數(shù)據(jù)傳輸?shù)陌踩?。另外，本發(fā)明的快速文件傳輸協(xié)議能夠更好地支持基于每個(gè)子文件塊的完整性校驗(yàn)，因此能夠以較小的代價(jià)進(jìn)行損壞數(shù)據(jù)的再傳輸，降低了大數(shù)據(jù)量文件重新傳輸?shù)膸捈百Y源占用率，在最大程度上降低網(wǎng)絡(luò)環(huán)境的設(shè)備壓力，又可以充分保證媒體文件的完整。本發(fā)明特別適合于應(yīng)用于大容量的企業(yè)(如電視臺(tái))媒體文件傳輸。圖1是傳統(tǒng)的文件傳輸網(wǎng)絡(luò)構(gòu)架示意圖2是傳統(tǒng)的文件傳輸網(wǎng)絡(luò)構(gòu)架進(jìn)行擴(kuò)展的示意圖3是本發(fā)明的網(wǎng)絡(luò)構(gòu)架示意圖4是M-Peer系統(tǒng)流程圖5是M-Peer調(diào)度流程圖6是本發(fā)明在各應(yīng)用系統(tǒng)間進(jìn)行文件傳輸?shù)氖疽鈭D7是本發(fā)明在進(jìn)行應(yīng)用系統(tǒng)擴(kuò)展的示意圖8是基于SimpleFTP協(xié)議進(jìn)行文件傳輸?shù)臅r(shí)序圖9是本發(fā)明在文件傳輸過(guò)程中進(jìn)行完整性校驗(yàn)的流程圖。具體實(shí)施例方式本發(fā)明提供的大容量文件傳輸方法基于Xfer網(wǎng)絡(luò)構(gòu)架實(shí)現(xiàn)，該網(wǎng)絡(luò)構(gòu)來(lái)包括通過(guò)總線連接的主干網(wǎng)和多個(gè)板塊網(wǎng)；每個(gè)所述板塊網(wǎng)至少包括一個(gè)xPeer服務(wù)器和多個(gè)應(yīng)用節(jié)點(diǎn)，所述主干網(wǎng)包括M-Peer服務(wù)器；所述大容量文件傳輸方法包括如下步驟1)一個(gè)應(yīng)用節(jié)點(diǎn)(下文中將其稱為接收節(jié)點(diǎn))請(qǐng)求傳輸另一應(yīng)用節(jié)點(diǎn)(下文中將其稱為服務(wù)節(jié)點(diǎn))中的文件；2)所述接收節(jié)點(diǎn)所在板塊網(wǎng)的xPeer服務(wù)器對(duì)攜帶所述請(qǐng)求的信令進(jìn)行封裝，然后與所述服務(wù)節(jié)點(diǎn)所在板塊網(wǎng)的xPeer服務(wù)器進(jìn)行通信，在所述主干網(wǎng)的M-Peer服務(wù)器的調(diào)度下，將所述文件通過(guò)總線傳輸至所述接收節(jié)點(diǎn)所在板塊網(wǎng)的xPeer服務(wù)器上；3)所述接收節(jié)點(diǎn)從所在板塊網(wǎng)的xPeer服務(wù)器獲取所述文件。下面結(jié)合附圖和具體實(shí)施方式對(duì)本發(fā)明作進(jìn)一步詳細(xì)描述實(shí)施例1本實(shí)施例中提供了一種新的企業(yè)網(wǎng)絡(luò)構(gòu)架。以電視臺(tái)為例，對(duì)企業(yè)網(wǎng)絡(luò)構(gòu)架的各細(xì)節(jié)進(jìn)行詳細(xì)描述。本實(shí)施例中所傳輸?shù)奈募饕侵钙髽I(yè)媒體文件。參考圖3，本實(shí)施例的網(wǎng)絡(luò)構(gòu)架包括通過(guò)企業(yè)媒體總線(EnterpriseMediaBus,EMB)連接的主干網(wǎng)和多個(gè)板塊網(wǎng)；每個(gè)所述板塊網(wǎng)至少包括一個(gè)xPeer服務(wù)器(以下簡(jiǎn)稱xPeer)，所述各板塊網(wǎng)通過(guò)xPeer和總線在板塊間進(jìn)行文件傳輸；所述主干網(wǎng)包括M-Peer服務(wù)器(以下筒稱M-Peer)，所述M-Peer對(duì)各xPeer的傳輸任務(wù)進(jìn)行調(diào)度。本實(shí)施例中將利用M-Peer和xPeer進(jìn)行文件傳輸?shù)捏w系稱為Xfer。另外，所述主干網(wǎng)還包括消息流服務(wù)器(MFS)。本實(shí)施例中，文件傳輸任務(wù)調(diào)度是由M-Peer完成的，M-Peer作為xPeer和傳輸任務(wù)調(diào)度的執(zhí)行部分，除起到Xfer與MFS交互作用外，同時(shí)完成對(duì)多個(gè)xPeer之間和對(duì)多個(gè)傳輸任務(wù)之間的調(diào)度作用。M-Peer的主要功能包4舌當(dāng)MFS發(fā)起一個(gè)任務(wù)時(shí)，M-Peer回調(diào)獲取傳輸任務(wù)；對(duì)xPeer端按照策略進(jìn)行調(diào)度，實(shí)現(xiàn)文件的傳輸；為xPeer提供具體的傳輸任務(wù)，接收xPeer傳輸信息；向MFS返回進(jìn)度狀態(tài)；傳輸任務(wù)優(yōu)先級(jí)處理，也就是任務(wù)的調(diào)度；對(duì)傳輸任務(wù)的干預(yù)，如暫停任務(wù)、停止任務(wù)；傳輸任務(wù)的監(jiān)控，初期不會(huì)實(shí)現(xiàn)管理(比如重試等)功能；對(duì)系統(tǒng)進(jìn)行配置。本實(shí)施中，調(diào)度策略如下1、任務(wù)調(diào)度當(dāng)MFS上發(fā)起一個(gè)任務(wù)時(shí)調(diào)用Xfer上的任務(wù)發(fā)起接口，Xfer解析任務(wù)中預(yù)計(jì)執(zhí)行時(shí)間(preStartTime)為任務(wù)分配不同級(jí)別(優(yōu)先級(jí))。M-Peer根據(jù)系統(tǒng)配置中的調(diào)度間隔時(shí)間去發(fā)現(xiàn)Xfer中哪些任務(wù)需要被啟動(dòng)，并按照預(yù)計(jì)執(zhí)行時(shí)間和優(yōu)先級(jí)分別啟動(dòng)任務(wù)。首先以執(zhí)行時(shí)間為啟動(dòng)任務(wù)的最基本要素，如果在同一執(zhí)行時(shí)間上，以優(yōu)先級(jí)高低為判斷基準(zhǔn)。2、任務(wù)啟動(dòng)后的xPeer調(diào)度任務(wù)啟動(dòng)后，Xfer解析任務(wù)中源端和目的端信息，通過(guò)任務(wù)中包含的源端所在應(yīng)用系統(tǒng)和目的端所在應(yīng)用系統(tǒng)，如果源端和目的端不在同一應(yīng)用系統(tǒng)，分別查詢?cè)炊撕湍康亩怂趹?yīng)用系統(tǒng)已經(jīng)在M-Peer注冊(cè)的xPeer的狀態(tài)，根據(jù)如下策略進(jìn)行xPeer的任務(wù)分配判斷源端(發(fā)送端、服務(wù)端)狀態(tài)為"服務(wù)端空閑"或者服務(wù)端的連接數(shù)小于系統(tǒng)設(shè)置的服務(wù)端最大連接數(shù)，則依次按照服務(wù)端空閑、服務(wù)端連接數(shù)最小、服務(wù)端連接數(shù)次小的順序選擇作為服務(wù)端的xPeer;判斷目的端(接收端、客戶端)狀態(tài)為"客戶端空閑"的xPeer做為客戶端xPeer，如果出現(xiàn)多個(gè)狀態(tài)為"客戶端空閑"的xPeer,查看其作為服務(wù)器端時(shí)的客戶端連接數(shù)，按照這個(gè)數(shù)量的從低到高的順序依次選擇xPeer(減低xPeer壓力)，如果出現(xiàn)此數(shù)值相等的xPeer,則隨機(jī)選擇其中一個(gè)作為客戶端xPeer;選擇完做傳輸?shù)膞Peer后，即開(kāi)始文件傳輸。(注如果源端和目的端所在同一個(gè)應(yīng)用系統(tǒng)，則不采用通過(guò)xPeer傳輸而是釆用同一個(gè)子網(wǎng)內(nèi)的文件拷貝模式，提高整個(gè)系統(tǒng)架構(gòu)中文件傳輸效率)本實(shí)施例中，M-Peer具有對(duì)外接口和對(duì)內(nèi)接口。M-Peer對(duì)外接口供MFS回調(diào)，主要提供啟動(dòng)傳輸任務(wù)、暫停傳輸、停止傳輸、任務(wù)優(yōu)先。下面逐個(gè)介紹各對(duì)外接口。任務(wù)發(fā)起接口(下文中的代碼均是以java風(fēng)格表示)publicStringstartTransfer(Stringtasklhformation);功能MFS上發(fā)起一個(gè)任務(wù)時(shí)調(diào)用Xfer上的任務(wù)發(fā)起接口。參數(shù)tasklnformation任務(wù)信息，包含該任務(wù)在mfs的實(shí)例ID、該任務(wù)在mfs上被創(chuàng)建的時(shí)間、發(fā)送方所在應(yīng)用系統(tǒng)、接受方所在應(yīng)用系統(tǒng)、源端文件名、源端路徑信息、目標(biāo)端存儲(chǔ)路徑、預(yù)計(jì)執(zhí)行時(shí)間。參數(shù)tasklnformation格式定義(XSD):<xmlversion="1.0"encoding="UTF-8"><schemaxmlns="http:〃www.w3.org/2001/XMLSchema"elementFormDefault="qualified">〈elementname="taskInformation"><complexType><ssqusnc6><elementname="mfsinstanceID"type="string"/><elementname="mfscreatetime"type="datetime"/>〈elementname="fromdn"type="string"/>〈elementname="todn"type="string7>〈elementname="resourceFilename"type="string'V>〈elementname="resourceFilePath"type="string"/>〈elementname="targetStorePath"type="string"/>〈elementname="preStartTime"type="datetime"/></sequence></complexType></element></schema>返回值返回的內(nèi)容為一個(gè)XML的字符串，任務(wù)的信息解析。任務(wù)暫停接口publicStringpauseWorkitems(stringitemID);功能暫停Xfer上發(fā)起的正在進(jìn)行的傳輸任務(wù)。參數(shù)itemID任務(wù)ID;返回值若返回零長(zhǎng)度字符串則表示暫停任務(wù)成功，否則返回包含錯(cuò)誤消息的XML。任務(wù)終止接口publicStringstop^Vorkitems(stringitemID);功能終止Xfer上發(fā)起的傳輸任務(wù)。參數(shù)itemID任務(wù)ID;返回值若返回零長(zhǎng)度字符串則表示終止任務(wù)成功，否則返回包含錯(cuò)誤消息的XML。任務(wù)優(yōu)先接口publicStringprioritizeWorkitems(StringitemID,IntpriorityLevel);功能通過(guò)對(duì)任務(wù)的優(yōu)先級(jí)別進(jìn)行更改的方式，優(yōu)先某傳輸任務(wù)。參數(shù)itemID任務(wù)ID，priorityLevel任務(wù)的優(yōu)先級(jí)信息；返回值若返回零長(zhǎng)度字符串則表示優(yōu)先任務(wù)成功，否則返回包含錯(cuò)誤消息的XML。M-Peer對(duì)內(nèi)接口采用WebService發(fā)布，主要指與xPeer的交互部分；由M-peer提供，xPeer調(diào)用，主要有xPeer的注冊(cè)登記、xPeer狀態(tài)匯報(bào)、xPeer文件傳輸進(jìn)度匯凈艮和任務(wù)狀態(tài)匯報(bào)。下面逐個(gè)介紹各對(duì)內(nèi)接口xPeer注冊(cè)登記4妄口publicStringpeerRegister(StringhostIP);功能向M-Peer注冊(cè)xPeer本身狀態(tài)。參數(shù)hostIP表示xPeer所在IP。返回值若返回零長(zhǎng)度字符串則表示注冊(cè)成功，否則返回包含錯(cuò)誤消息的XML。xPeer狀態(tài)匯報(bào)接口publicStringreportPeerstatus(StringhostIP,StringpeerStatus);功能xPeer向Xfer匯凈艮自身狀態(tài)信息；參數(shù)hostIP表示xPeer所在IP地址，peerStatus表示目前xPeer的狀態(tài)；返回值若返回零長(zhǎng)度字符串則表示匯報(bào)成功，否則返回包含錯(cuò)誤消息的XML。xPeer任務(wù)進(jìn)度接口publicStringpostProcess(StringitemID);功能xPeer向M-Peer匯才艮文件傳輸進(jìn)度；參數(shù)itemID表示任務(wù)ID;返回值返回該P(yáng)eer上某傳輸任務(wù)的傳輸進(jìn)度值。xPeer任務(wù)狀態(tài)匯才艮接口publicStringreportTaskStatus(StringitemID);功能各個(gè)xPeer通過(guò)WebService的方式向Xfer匯報(bào)文件傳輸進(jìn)度。參數(shù)itemID表示任務(wù)ID;返回值返回該P(yáng)eer上某傳輸4壬務(wù)的狀態(tài)。本實(shí)施例中，M-Peer的系統(tǒng)流程(參考圖4)如下1)Xfer啟動(dòng)后，接受傳輸服務(wù)端xPeer的注冊(cè)和注銷；2)M-Peer即時(shí)監(jiān)聽(tīng)任務(wù)，如果任務(wù)不被停止，執(zhí)行任務(wù)，并匯報(bào)任務(wù)狀態(tài)。本實(shí)施例中，M-Peer的調(diào)度流程(參考圖5)如下1)當(dāng)M-Peer監(jiān)聽(tīng)到任務(wù)時(shí)，根據(jù)任務(wù)優(yōu)先級(jí)發(fā)起傳輸任務(wù)；2)判斷任務(wù)xPeer的位置，獲取執(zhí)行該傳輸任務(wù)的xPeer的狀態(tài)，如果xPeer準(zhǔn)備就緒，發(fā)送任務(wù)到該xPeer;3)當(dāng)任務(wù)到達(dá)xPeer時(shí)，判斷是否有干預(yù)指令，如果有指令(暫停、恢復(fù)、停止)執(zhí)行相關(guān)干預(yù)動(dòng)作；若沒(méi)有干預(yù)指令，M-Peer接受xPeer狀態(tài)和進(jìn)度匯報(bào)，判斷有無(wú)異常，若有異常，返回異常，結(jié)束任務(wù)；若無(wú)異常，實(shí)時(shí)接受xPeer匯報(bào)狀態(tài)和進(jìn)度數(shù)據(jù)，判斷任務(wù)是否完成，若完成，結(jié)束任務(wù)，返回傳輸結(jié)果；若未完成，返回指令錯(cuò)誤；4)如果判斷任務(wù)xPeer的位置，獲取執(zhí)行該傳輸任務(wù)的xPeer的狀態(tài)時(shí)，xPeer準(zhǔn)備未就緒，判斷該任務(wù)的重試次數(shù)，如果超過(guò)系統(tǒng)配置的最大重試次數(shù)，返回異常，結(jié)束任務(wù)，如果未達(dá)到重試次數(shù)，獲取任務(wù)xPeer狀態(tài)，繼續(xù)傳輸流程。本實(shí)施例的基于總線的文件傳輸方式釆用文件傳輸命令在Xfer中的封裝，對(duì)外提供簡(jiǎn)單接口；傳輸是由Xfer自己完成，應(yīng)用系統(tǒng)只需要將相關(guān)信息傳遞給Xfer,Xfer對(duì)傳輸任務(wù)和傳輸端點(diǎn)(xPeer)進(jìn)行調(diào)度，完成傳輸。如圖6所示，該圖為Xfer調(diào)度應(yīng)用系統(tǒng)B傳輸文件到應(yīng)用系統(tǒng)C。如果繼續(xù)增加應(yīng)用系統(tǒng)，只需應(yīng)用系統(tǒng)上的傳輸端向Xfer注冊(cè)一次，即可完成系統(tǒng)的無(wú)縫插入，體現(xiàn)基于總線式的架構(gòu)模式，其優(yōu)點(diǎn)是不需要在應(yīng)用系統(tǒng)內(nèi)增加客戶端和服務(wù)端程序；當(dāng)增加系統(tǒng)應(yīng)用時(shí)不影響其他應(yīng)用系統(tǒng)的工作，也不會(huì)增加整個(gè)系統(tǒng)的運(yùn)行負(fù)擔(dān)和運(yùn)行成本(如圖7所示)。另外，本實(shí)施例中的主干網(wǎng)還包括一個(gè)內(nèi)建的小型Cache盤(pán)陣。用于支持文件數(shù)據(jù)的異步傳輸。即任務(wù)發(fā)起時(shí)，M-Peer的調(diào)度模塊發(fā)現(xiàn)目標(biāo)系統(tǒng)已經(jīng)離線，可將企業(yè)媒體文件傳輸?shù)紺ache中緩存，當(dāng)目標(biāo)網(wǎng)絡(luò)恢復(fù)連線后，再將緩存的企業(yè)媒體文件傳輸?shù)侥康亩?，以減少板塊間由于網(wǎng)絡(luò)故障造成的負(fù)載增長(zhǎng)。當(dāng)然，如果源網(wǎng)絡(luò)和目的網(wǎng)絡(luò)均為活動(dòng)狀態(tài)時(shí)，文件數(shù)據(jù)將直接在兩個(gè)板塊之間進(jìn)行傳輸。由于企業(yè)媒體數(shù)據(jù)的數(shù)據(jù)量較大，因此即使在寬帶網(wǎng)絡(luò)環(huán)境下傳輸，仍然要耗費(fèi)大量的時(shí)間。因此，本實(shí)施例中，還可以通過(guò)在板塊網(wǎng)絡(luò)中部署多個(gè)xPeer的方式，建立板塊間的多條傳輸通道，以滿足大數(shù)據(jù)量傳輸?shù)男枨蟆．?dāng)前國(guó)內(nèi)外廣電行業(yè)在信息化方面的總體發(fā)展方向是網(wǎng)絡(luò)化、信息化。本實(shí)施例采用企業(yè)媒體總線，能夠讓媒體文件在電視臺(tái)內(nèi)部各個(gè)板塊直接能夠進(jìn)行快速、合理交換，降低勞動(dòng)成本，提高節(jié)目生產(chǎn)效率，保證節(jié)目快速、準(zhǔn)時(shí)、準(zhǔn)確的進(jìn)行播出，提高節(jié)目生產(chǎn)播出安全性。本發(fā)明還提供一種快速文件傳輸協(xié)議，該協(xié)議是一種自定義的基于TCP/IP的簡(jiǎn)單文件傳輸協(xié)議(SimpleFTP)。SimpleFTP的程序包包括命令模塊、文件查驗(yàn)?zāi)K、數(shù)據(jù)傳輸模塊、完整性驗(yàn)證模塊和錯(cuò)誤重傳模塊等功能模塊。本實(shí)施例中，各板塊網(wǎng)中的節(jié)點(diǎn)之間進(jìn)行文件傳輸時(shí)，都是首先通過(guò)所在板塊網(wǎng)中的xPeer進(jìn)行Xfer封裝，然后利用SimpleFTP協(xié)議在各板塊網(wǎng)之間傳輸文件數(shù)據(jù)。在SimpleFTP協(xié)議中，文件提供者稱為服務(wù)端，文件獲取者稱為客戶端?？蛻舳税l(fā)送消息之后，服務(wù)端要返回消息對(duì)應(yīng)的應(yīng)答消息。本實(shí)施例中，SimpleFTP協(xié)議的消息以及其應(yīng)答的格式均為統(tǒng)一格式每個(gè)消息都包括兩個(gè)部分，消息頭和消息體。1.消息頭內(nèi)容消息頭的包含內(nèi)容包括以下幾個(gè)部分曰期本條消息的時(shí)間戳；消息ID:本條消息的ID;加密算法消息內(nèi)容如果是加密的，在這個(gè)地方指明使用的加密算法；長(zhǎng)度消息內(nèi)容的長(zhǎng)度。2.消息體的內(nèi)容登錄消息的消息體內(nèi)容包括以下幾個(gè)部分密碼登錄用戶的密碼；用戶名登錄用戶的名字。登錄應(yīng)答消息的消息體內(nèi)容包括以下幾個(gè)部分登錄結(jié)果成功或者失敗的標(biāo)識(shí)；用戶ID:用戶的會(huì)話ID,在整個(gè)傳輸過(guò)程中有效。獲取文件信息消息的消息體包括遠(yuǎn)程文件名需要查驗(yàn)的遠(yuǎn)程文件的文件名。獲取文件信息消息的服務(wù)應(yīng)答消息的消息體包括遠(yuǎn)程文件是否存在的標(biāo)識(shí)；遠(yuǎn)程文件如果存在，還給出該文件的大小(即該文件的容量)。傳送文件消息的消息體包括以下部分遠(yuǎn)程文件名需要傳送的遠(yuǎn)程文件的文件名；遠(yuǎn)程文件名的起始位置從文件的某一個(gè)起始點(diǎn)開(kāi)始傳送；遠(yuǎn)程文件名的結(jié)束位置從文件的某一個(gè)結(jié)束點(diǎn)，傳送結(jié)束傳送文件消息的服務(wù)應(yīng)答消息包括啟動(dòng)傳送進(jìn)程是否成功的標(biāo)識(shí)。注銷消息的消息體包括會(huì)話ID:用戶登錄時(shí)，系統(tǒng)分配的會(huì)話ID。注銷應(yīng)答消息的消息體包括注銷結(jié)果成功或者失敗的標(biāo)識(shí)?；谒鯯impleFTP協(xié)議的文件傳輸過(guò)程如下(參考圖8):1)命令通過(guò)登錄消息在客戶端登陸，向服務(wù)端發(fā)送獲取文件信息消息，該消息中攜帶需要驗(yàn)證的遠(yuǎn)程文件的文件名。2)文件查驗(yàn)服務(wù)端返回服務(wù)應(yīng)答消息，該應(yīng)答消息中攜帶所述遠(yuǎn)程文件的數(shù)據(jù)量大小的信息；3)命令客戶端根據(jù)文件的數(shù)據(jù)量大小，將文件分為多個(gè)數(shù)據(jù)段，多個(gè)數(shù)據(jù)段分為多次進(jìn)行傳輸，設(shè)定每次文件傳輸?shù)钠鹗键c(diǎn)和結(jié)束點(diǎn)，每次文件傳輸，客戶端都向服務(wù)端發(fā)送一次傳送文件消息；4)數(shù)據(jù)傳輸服務(wù)端收到傳送文件消息后，開(kāi)始進(jìn)行本次數(shù)據(jù)傳輸；5)完整性驗(yàn)證客戶端在接收完本次傳輸?shù)臄?shù)據(jù)段后，對(duì)該數(shù)據(jù)段進(jìn)行完整性驗(yàn)證；如通過(guò)完整性驗(yàn)證，則回到步驟3)繼續(xù)傳輸下一個(gè)數(shù)據(jù)段，直到所述遠(yuǎn)程文件傳輸完畢；6)錯(cuò)誤重傳當(dāng)本次傳輸?shù)臄?shù)據(jù)段未能通過(guò)完整性驗(yàn)證時(shí)，客戶端重新發(fā)送傳送文件消息，請(qǐng)求重新傳輸該數(shù)據(jù)段。其中，步驟5)的驗(yàn)證算法可以選擇使用MD5算法或CRC算法。在實(shí)際應(yīng)用中，常常使用的是MD5算法。但值得注意的是，本發(fā)明并不限定于這兩種算法。本實(shí)施例中，SimpleFTP協(xié)議需要對(duì)一些參數(shù)進(jìn)行配置，對(duì)協(xié)議的配置包括以下幾個(gè)方面文件讀取的配置讀寫(xiě)文件的各類參數(shù)；而每次讀、寫(xiě)的緩存最好在512KB以上。網(wǎng)絡(luò)傳送的配置網(wǎng)絡(luò)數(shù)據(jù)包的大小等等；網(wǎng)絡(luò)數(shù)據(jù)包大小(緩存)應(yīng)該在64KB以上；驗(yàn)證算法的配置驗(yàn)證算法的選擇，驗(yàn)證算法包的大?。粎f(xié)議自身特性配置是否支持?jǐn)帱c(diǎn)續(xù)傳，是否在傳輸之前進(jìn)行文件驗(yàn)證。一般情況下，在100Mb環(huán)境，以本協(xié)議進(jìn)行文件傳輸可以達(dá)到8MB/sec以上的速度。采用本發(fā)明的SimpleFTP協(xié)議，可以方便的組織、管理和調(diào)度文件傳輸?shù)倪^(guò)程；能夠提高文件傳輸?shù)陌踩浴Ｍ瑫r(shí)，該協(xié)議還能夠很好地支持錯(cuò)誤文件塊的重傳。安全性通常的FTP協(xié)議在傳送過(guò)程中，不能保證數(shù)據(jù)在傳送過(guò)程中不發(fā)生變化，本發(fā)明的SimpleFTP協(xié)議在傳輸?shù)耐瑫r(shí)，還對(duì)數(shù)據(jù)進(jìn)行摘要計(jì)算和驗(yàn)證，保證了數(shù)據(jù)傳輸?shù)陌踩?。錯(cuò)誤文件塊的重傳通常的FTP協(xié)議如果傳輸失敗，則需要重新傳輸整個(gè)文件。本發(fā)明的SimpleFTP協(xié)議在傳輸過(guò)程中，如果某個(gè)文件塊傳輸失敗，我們?cè)谧詈髠鬏斖瓿珊?，只?duì)這個(gè)文件塊重新進(jìn)行傳輸。下面詳細(xì)描述本發(fā)明所采用的完整性驗(yàn)證方法。在傳輸過(guò)程中，在正常的情況下，本實(shí)施例的服務(wù)器端(即數(shù)據(jù)發(fā)送端)需要做的工作如下讀取本地的物理文件的內(nèi)容到內(nèi)存；使用指定的完整性算法，計(jì)算內(nèi)存中的數(shù)據(jù)的消息摘要；將數(shù)據(jù)和it據(jù)消息只要發(fā)送到網(wǎng)絡(luò)。本實(shí)施例的客戶端(即數(shù)據(jù)接收端)需要做的工作如下接受來(lái)自網(wǎng)絡(luò)的數(shù)據(jù)傳輸；使用指定的完整性算法，驗(yàn)證接收到的數(shù)據(jù)；將驗(yàn)證成功的數(shù)據(jù)寫(xiě)入本地的物理文件。本實(shí)施例首先需要對(duì)文件進(jìn)行分塊。對(duì)文件分塊的每一塊大小，要同時(shí)考慮網(wǎng)絡(luò)、摘要、硬盤(pán)的各種要素。從整體上來(lái)講，子文件塊的數(shù)據(jù)量大小最好是256的整數(shù)倍，且子文件塊的數(shù)據(jù)量必須大于讀取文件塊大小和讀取網(wǎng)絡(luò)塊大小。(其中讀取文件塊就是把文件讀到內(nèi)存中的一次操作，比如IOM的文件，如果申請(qǐng)了1M的內(nèi)存，每次讀到內(nèi)存中后，處理完畢后，再次從文件中讀1M的內(nèi)容，連續(xù)讀10次；讀取網(wǎng)絡(luò)塊是指把網(wǎng)絡(luò)數(shù)據(jù)包讀到內(nèi)存當(dāng)中的一次操作)在分塊完畢后，對(duì)文件的讀、寫(xiě)操作，對(duì)網(wǎng)絡(luò)的收、發(fā)操作，對(duì)內(nèi)容的摘要、驗(yàn)證操作，每一種操作都是以文件塊作為操作單位，所以文件分塊的方式和每一塊的大小直接影響了傳輸、驗(yàn)證的效率。圖9是本實(shí)施例的流程圖，該圖示出了在完成文件分塊后，基于子文件塊進(jìn)行文件傳輸?shù)脑敿?xì)流程，簡(jiǎn)要描述如下a)開(kāi)始文件傳輸，選擇一子文件塊；b)判斷是否需要對(duì)文件進(jìn)行驗(yàn)證，如果判斷為是，則對(duì)該子文件塊進(jìn)行MD5編碼，并將所得MD5編碼傳輸給客戶端，同時(shí)將該子文件塊也傳輸給客戶端；如果判斷為否，則只需將子文件塊傳輸給客戶端即可；c)在客戶端接收到子文件塊后，再次判斷是否需要對(duì)文件進(jìn)行驗(yàn)證，如果判斷為否，則回到步驟a),選擇下一個(gè)子文件塊進(jìn)行傳輸；如果判斷為是，則對(duì)接收到的子文件塊重新進(jìn)行MD5編碼，然后判斷該MD5編碼與接收到的MD5編碼是否一致，當(dāng)編碼一致時(shí)，當(dāng)前子文件塊通過(guò)校馬全，回到步驟a),選擇下一個(gè)子文件塊進(jìn)行傳輸，當(dāng)編碼不一致時(shí)，則重新傳輸當(dāng)前子文件塊。不斷重復(fù)上述過(guò)程，直至待傳輸文件的所有子文件塊均傳輸完畢。另外，可以為重新傳輸子文件塊設(shè)置一個(gè)最大次數(shù)，當(dāng)一個(gè)子文件塊重傳次數(shù)達(dá)到最大次數(shù)時(shí)，舍棄該子文件塊。下面結(jié)合實(shí)驗(yàn)數(shù)據(jù)，進(jìn)一步分析本實(shí)施例的文件分塊方式及每一塊的大小對(duì)傳輸、驗(yàn)證的效率的影響。實(shí)驗(yàn)平臺(tái)的配置以及操作系統(tǒng)如下月良務(wù)端Windows2003Server3GCpu1G內(nèi)存千兆網(wǎng)卡客戶端Windows2003Server3GCpu1G內(nèi)存千兆網(wǎng)卡測(cè)試素材為10G的AVI文件關(guān)于讀取文件的測(cè)試參數(shù)。在實(shí)驗(yàn)環(huán)境下，使用EMCcx500的盤(pán)陣，多次實(shí)驗(yàn)10G的文件，使用本實(shí)施例的方法進(jìn)行文件傳輸，其讀寫(xiě)速度如表1所示。表l<table>tableseeoriginaldocumentpage17</column></row><table>在實(shí)驗(yàn)環(huán)境下，使用EMCcx500的盤(pán)陣，多次實(shí)驗(yàn)1G的文件，使用本實(shí)施例的方法進(jìn)行文件傳輸，其讀寫(xiě)速度如表2所示。表2<table>tableseeoriginaldocumentpage17</column></row><table>從表l、表2中，可以看出讀寫(xiě)的文件越小速度越快；分塊大小在1024KB左右，讀寫(xiě)速度最快(針對(duì)測(cè)試的EMCcx500盤(pán)陣)。關(guān)于讀取網(wǎng)絡(luò)的測(cè)試參數(shù)。測(cè)試方式為，在千兆網(wǎng)的環(huán)境下，服務(wù)端向客戶端不停的發(fā)送數(shù)據(jù)包，在客戶端計(jì)算綜合速度。測(cè)試結(jié)果如表3所示，表3<table>tableseeoriginaldocumentpage18</column></row><table>可以看出，分塊大小對(duì)網(wǎng)絡(luò)傳輸速度的影響不大，幾乎可以達(dá)到千兆網(wǎng)環(huán)境下的傳輸速度峰值。關(guān)于驗(yàn)證算法的測(cè)試參數(shù)，在實(shí)驗(yàn)環(huán)境下，使用md5算法，對(duì)存在于內(nèi)存中的塊進(jìn)行摘要計(jì)算。參數(shù)如下采用lMbuffer時(shí)31毫秒采用2Mbuffer時(shí)62毫秒釆用3Mbuffer時(shí)IIO毫秒采用4Mbuffer時(shí)94毫秒采用5Mbuffer時(shí)94毫秒采用6Mbuffer時(shí)125毫秒采用7Mbuffer時(shí)141毫秒采用8Mbuffer時(shí)172毫秒采用9Mbuffer時(shí)188毫秒其中buffer是指緩存，也就是指分塊(子文件塊)的大小?？梢钥闯龇謮K的大小越大，驗(yàn)證所需要的時(shí)間也越多；分塊大小在1M—IOM的范圍內(nèi)，所需要的時(shí)間都很短，不影響正常傳送。在傳輸?shù)倪^(guò)程中，需要客戶端、服務(wù)端同時(shí)使用相同的摘要算法，對(duì)已經(jīng)傳輸?shù)膬?nèi)容進(jìn)行校驗(yàn)。校驗(yàn)算法方面，可以對(duì)多種協(xié)議調(diào)用做了抽象，在傳輸協(xié)議看來(lái)，驗(yàn)證算法都是同一個(gè)抽象的接口。通過(guò)配置，使用者可以選擇使用MD5算法還是CRC算法等等。在實(shí)際應(yīng)用中，常常使用的是MD5算法。最后所應(yīng)說(shuō)明的是，以上實(shí)施例僅用以說(shuō)明本發(fā)明的技術(shù)方案而非限制。盡管參照實(shí)施例對(duì)本發(fā)明進(jìn)行了詳細(xì)說(shuō)明，本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解，對(duì)本發(fā)明的技術(shù)方案進(jìn)行修改或者等同替換，都不脫離本發(fā)明技術(shù)方案的精神和范圍，其均應(yīng)涵蓋在本發(fā)明的權(quán)利要求范圍當(dāng)中。權(quán)利要求1.一種大容量文件傳輸方法，該方法基于Xfer網(wǎng)絡(luò)構(gòu)架實(shí)現(xiàn)，該網(wǎng)絡(luò)構(gòu)架包括通過(guò)總線連接的主干網(wǎng)和多個(gè)板塊網(wǎng)；每個(gè)所述板塊網(wǎng)包括至少一個(gè)xPeer服務(wù)器和多個(gè)應(yīng)用節(jié)點(diǎn)，所述主干網(wǎng)包括M-Peer服務(wù)器；所述大容量文件傳輸方法包括如下步驟1)接收節(jié)點(diǎn)請(qǐng)求傳輸服務(wù)節(jié)點(diǎn)中的文件；2)所述接收節(jié)點(diǎn)所在板塊網(wǎng)的xPeer服務(wù)器對(duì)攜帶所述請(qǐng)求的信令進(jìn)行封裝，然后與所述服務(wù)節(jié)點(diǎn)所在板塊網(wǎng)的xPeer服務(wù)器進(jìn)行通信，在所述主干網(wǎng)的M-Peer服務(wù)器的調(diào)度下，將所述文件通過(guò)總線傳輸至所述接收節(jié)點(diǎn)所在板塊網(wǎng)的xPeer服務(wù)器上；3)所述接收節(jié)點(diǎn)從所在板塊網(wǎng)的xPeer服務(wù)器獲取所述文件。2.根據(jù)權(quán)利要求1所述的大容量文件傳輸方法，其特征在于，所述步驟2)中，各板塊網(wǎng)的xPeer服務(wù)器采用SimpleFTP協(xié)議進(jìn)行通信，所述SimpleFTP協(xié)議的程序包包括命令模塊、文件查驗(yàn)?zāi)K、數(shù)據(jù)傳輸模塊、完整性驗(yàn)證模塊和錯(cuò)誤重傳模塊。3.根據(jù)權(quán)利要求2所述的大容量文件傳輸方法，其特征在于，基于SimpleFTP協(xié)議的文件傳輸過(guò)程如下21)在所述命令模塊，發(fā)送獲取文件信息消息，該消息中攜帶需要驗(yàn)證的遠(yuǎn)程文件的文件名；22)在所述文件查驗(yàn)?zāi)K，返回服務(wù)應(yīng)答消息，該應(yīng)答消息中攜帶所述遠(yuǎn)程文件的數(shù)據(jù)量大小的信息；23)在所述命令模塊，根據(jù)文件的數(shù)據(jù)量大小，將文件分為多個(gè)數(shù)據(jù)段；24)在所述命令模塊，選取一個(gè)數(shù)據(jù)段，發(fā)送傳送文件消息，該傳送文件消息攜帶所述數(shù)據(jù)段傳輸?shù)钠鹗键c(diǎn)和結(jié)束點(diǎn)；25)在所述數(shù)據(jù)傳輸模塊，根據(jù)收到的傳送文件消息進(jìn)行數(shù)據(jù)傳輸；26)在所述完整性驗(yàn)證模塊，在接收完本次傳輸?shù)臄?shù)據(jù)段后，對(duì)該數(shù)據(jù)段進(jìn)行完整性驗(yàn)證；如通過(guò)完整性驗(yàn)證，則回到步驟4)繼續(xù)傳輸下一個(gè)數(shù)據(jù)段，直到所述遠(yuǎn)程文件傳輸完畢；27)在所述錯(cuò)誤重傳模塊，當(dāng)本次傳輸?shù)臄?shù)據(jù)段未能通過(guò)完整性驗(yàn)證時(shí)，客戶端重新發(fā)送傳送文件消息，請(qǐng)求重新傳輸該數(shù)據(jù)段。4.根據(jù)權(quán)利要求3所述的大容量文件傳輸方法，其特征在于，所述步驟23)中，所述每個(gè)數(shù)據(jù)段的數(shù)據(jù)量為256k的整數(shù)倍。5.根據(jù)權(quán)利要求3所述的大容量文件傳輸方法，其特征在于，所述每個(gè)數(shù)據(jù)段的數(shù)據(jù)量在1M至10M的范圍內(nèi)。6.根據(jù)權(quán)利要求1所述的大容量文件傳輸方法，其特征在于，所述文件為媒體文件。7.根據(jù)權(quán)利要求3所述的大容量文件傳輸方法，其特征在于，所述步驟27)中，為重新傳輸所述數(shù)據(jù)段設(shè)置一個(gè)最大次數(shù)，當(dāng)一個(gè)數(shù)據(jù)段重傳次數(shù)達(dá)到該最大次數(shù)時(shí)，則舍棄該數(shù)據(jù)段。8.根據(jù)權(quán)利要求3所述的大容量文件傳輸方法，其特征在于，所述步驟26)中，所述完整性驗(yàn)證的方法可以采用MD5算法或CRC算法。全文摘要本發(fā)明提供一種大容量文件傳輸方法，該方法基于Xfer網(wǎng)絡(luò)構(gòu)架實(shí)現(xiàn)，該網(wǎng)絡(luò)構(gòu)架包括通過(guò)總線連接的主干網(wǎng)和多個(gè)板塊網(wǎng)；每個(gè)所述板塊網(wǎng)包括至少一個(gè)xPeer服務(wù)器和多個(gè)應(yīng)用節(jié)點(diǎn)，所述主干網(wǎng)包括M-Peer服務(wù)器；所述大容量文件傳輸方法包括如下步驟接收節(jié)點(diǎn)請(qǐng)求傳輸服務(wù)節(jié)點(diǎn)中的文件；接收節(jié)點(diǎn)所在板塊網(wǎng)的xPeer服務(wù)器對(duì)攜帶所述請(qǐng)求的信令進(jìn)行封裝，然后與服務(wù)節(jié)點(diǎn)所在板塊網(wǎng)的xPeer服務(wù)器進(jìn)行通信，在M-Peer服務(wù)器的調(diào)度下，將所述文件通過(guò)總線傳輸至接收節(jié)點(diǎn)所在板塊網(wǎng)的xPeer服務(wù)器上；3)接收節(jié)點(diǎn)從所在板塊網(wǎng)的xPeer服務(wù)器獲取所述文件。本發(fā)明的網(wǎng)絡(luò)構(gòu)架能夠讓大容量文件在企業(yè)內(nèi)部各個(gè)板塊之間直接進(jìn)行快速、合理交換，降低勞動(dòng)成本，提高節(jié)目生產(chǎn)效率。文檔編號(hào)H04L1/16GK101447856SQ20071017824公開(kāi)日2009年6月3日申請(qǐng)日期2007年11月28日優(yōu)先權(quán)日2007年11月28日發(fā)明者偉孫,王弋珵,祎趙申請(qǐng)人:新奧特(北京)視頻技術(shù)有限公司