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