張昆朋,呂延慶,謝華成
(1.洛陽師范學(xué)院 信息技術(shù)學(xué)院,洛陽 471022;2.信陽師范學(xué)院 網(wǎng)絡(luò)信息與計(jì)算中心,信陽 464000)
在局域網(wǎng)中經(jīng)常會遇到把相同的數(shù)據(jù)復(fù)制到多臺主機(jī)上的情況,如果使用基于單播的FTP、HTTP等協(xié)議及軟件來傳送文件,會造成很多網(wǎng)絡(luò)流量的浪費(fèi)。在將文件數(shù)據(jù)從一臺主機(jī)復(fù)制到多臺主機(jī)的特定情況下,使用D類多播地址可以有效的避免以上問題,從而減少網(wǎng)絡(luò)流量,提高傳輸效率。
圖1 以太網(wǎng)上數(shù)據(jù)幀的單播和多播
以太局域網(wǎng)本身發(fā)送數(shù)據(jù)時(shí)就是以廣播的方式發(fā)送的,只是不需要該數(shù)據(jù)的客戶端根據(jù)MAC幀包含的目的地址來舍棄該數(shù)據(jù)。在使用FTP或HTTP等協(xié)議傳輸時(shí),由于目的地址采用單播地址,丟棄了本不應(yīng)丟棄的數(shù)據(jù),降低了傳輸效率;如果目的地址為多播地址,則該數(shù)據(jù)仍能正常被接收端主機(jī)接收和處理如圖1所示。目前網(wǎng)絡(luò)克隆的程序就是基于上述的多播原理完成工作的,但這些程序大多是基于磁盤或分區(qū)的。例如Ghost
軟件帶有的GhostCast程序,可以通過網(wǎng)絡(luò)對客戶機(jī)的整個硬盤或分區(qū)進(jìn)行克隆,一般都需要預(yù)先在多臺需要復(fù)制文件的客戶機(jī)的磁盤上專門劃分出分區(qū),破壞了原有的磁盤結(jié)構(gòu)且設(shè)置較為繁瑣。
下面設(shè)計(jì)和實(shí)現(xiàn)一個基于單個文件或整個目錄的多播文件傳送程序,能夠較好地解決以上問題。
多播通信中使用的D類IP地址范圍在224.0.0.1~239.255.255.255之間,采用多播進(jìn)行通信需要使用能夠進(jìn)行多播通信的網(wǎng)絡(luò)接口,如果是通常的以太網(wǎng)接口,自然的就可以進(jìn)行多播通信。多播通信與以太網(wǎng)中的廣播網(wǎng)不同,屬于OSI第三層的網(wǎng)絡(luò)層協(xié)議,可以跨越支持多播協(xié)議的路由器進(jìn)行通信。其中D類IP地址224.0.0.1 表示在本子網(wǎng)上的所有參加多播的主機(jī)和路由器,當(dāng)使用這個IP地址時(shí),不能跨越路由器,只能在以太網(wǎng)的相同網(wǎng)段內(nèi)使用多播,但這是能夠滿足本文針對的網(wǎng)絡(luò)實(shí)驗(yàn)室的要求的。因此本程序在實(shí)現(xiàn)時(shí)采用了224.0.0.1這個固定的地址,實(shí)際使用時(shí)需要跨越多播路由器通信也可以根據(jù)需要來調(diào)整多播IP地址。
首先,在傳輸層上具有可靠性保證的TCP不支持多播,因此傳輸層采用UDP協(xié)議,而數(shù)據(jù)的可靠傳輸由協(xié)議本身的設(shè)計(jì)來保證;其次,由于涉及到文件傳送,多播文件傳送協(xié)議參考了同樣基于UDP的TFTP協(xié)議(RFC1350) 的設(shè)計(jì)思路,但考慮到TFTP沒有列目錄的功能,因此針對其適用情況做了一些修改。
多播文件傳送協(xié)議在傳輸層使用的UDP數(shù)據(jù)報(bào)一共定義了六種協(xié)議數(shù)據(jù)單元(PDU) ,每種PDU的第一個字段是操作碼標(biāo)志字段(FLAG) , 根據(jù)該標(biāo)志字段的不同PDU的格式和作用各不相同如表1所示 。
表1 多播文件傳送協(xié)議定義的6種協(xié)議數(shù)據(jù)單元
客戶端使用“客戶端發(fā)現(xiàn)PDU”通知服務(wù)端,包含IP地址來標(biāo)識不同的客戶端。這樣在文件傳送未開始之前,服務(wù)器收集所有客戶機(jī)IP地址,開始文件傳送后可以監(jiān)測并保證傳送的文件數(shù)據(jù)被每個客戶端正確接收。文件傳送是切分成文件數(shù)據(jù)塊進(jìn)行的,每個“文件數(shù)據(jù)PDU”攜帶1K字節(jié)的文件數(shù)據(jù)(最后一個數(shù)據(jù)塊可能不足1K字節(jié)),這些文件數(shù)據(jù)塊使用了序號來保證順序,從而消除了UDP可能無序接收的問題。
考慮到了網(wǎng)絡(luò)的質(zhì)量問題,UDP可能出現(xiàn)丟包,因此對于“文件名PDU”、“文件名確認(rèn)PDU”、“文件數(shù)據(jù)PDU”、“文件數(shù)據(jù)確認(rèn)PDU”都作了超時(shí)重傳的處理。
需要做超時(shí)重傳處理的場合包括。
1)在客戶端接收“文件數(shù)據(jù)PDU”超時(shí)的情況
(1)如果該“文件數(shù)據(jù)PDU”是文件的第一個數(shù)據(jù)塊,重傳該文件的“文件名確認(rèn)PDU”;
(2)如果該“文件數(shù)據(jù)PDU”不是文件的第一個數(shù)據(jù)報(bào),重傳上一個文件數(shù)據(jù)塊的“文件數(shù)據(jù)確認(rèn)PDU”。
2)在服務(wù)端接收“文件名確認(rèn)PDU”超時(shí)的情況,重傳該文件的“文件名PDU”。
3)在服務(wù)端接收“文件數(shù)據(jù)確認(rèn)PDU”超時(shí)的情況,重傳該文件數(shù)據(jù)塊的“文件數(shù)據(jù)PDU”。
對于“客戶端發(fā)現(xiàn)PDU”,由于可以在服務(wù)端看到是否所有客戶端都連接上,并控制發(fā)送開始的時(shí)間,所以不用重傳。發(fā)現(xiàn)有“客戶端發(fā)現(xiàn)PDU”丟失,即服務(wù)端無法發(fā)現(xiàn)客戶端的情況,只需要重新啟動客戶端程序就可以,或者檢查客戶端程序的IP設(shè)置是否是與服務(wù)端程序在同一以太網(wǎng)段內(nèi)。
對于“全部傳送結(jié)束PDU”,因?yàn)榉?wù)端程序運(yùn)行到發(fā)送該P(yáng)DU時(shí)已經(jīng)能夠保證所有文件數(shù)據(jù)已經(jīng)被正確發(fā)送到所有多播客戶端,因此直接把該P(yáng)DU數(shù)據(jù)重傳多次,使得客戶端程序能夠接收到該P(yáng)DU能夠退出運(yùn)行即可。如果出現(xiàn)該P(yáng)DU無法被有些多播客戶端接收的情況,客戶端強(qiáng)行退出即可。
Java平臺對多播協(xié)議提供了支持,本程序使用Java語言來開發(fā)。本多播程序分為服務(wù)端程序和客戶端程序兩部分。其中,服務(wù)端程序用來實(shí)現(xiàn)多播數(shù)據(jù)的發(fā)送,而客戶端程序用來接收多播數(shù)據(jù)。典型的情況是在同一以太網(wǎng)段內(nèi)運(yùn)行一個服務(wù)端程序和多個客戶端程序。程序流程框圖如圖2、3所示。
圖2 服務(wù)器端多播文件傳送流程
圖3 客戶端接收數(shù)據(jù)流程
為了測試該多播程序的有效性,測試分三步進(jìn)行。在安裝了Windows Server 2003的計(jì)算機(jī)上使用1個多播服務(wù)端程序,而多播客戶端程序分別使用1個、2個和25個,也就是安裝多播客戶端的計(jì)算機(jī)數(shù)量逐步增多,以測試該多播程序的傳送效果。測試結(jié)果如表2所示。
表2 本程序與FlashFXP對比表
在此多播文件傳送協(xié)議的設(shè)計(jì)和實(shí)現(xiàn)中,參考了成熟的協(xié)議,從測試結(jié)果來看,達(dá)到了預(yù)想的效果,在以太網(wǎng)的同一網(wǎng)段內(nèi),保證數(shù)據(jù)可靠傳輸?shù)那疤嵯绿岣吡藗鬏斝?,具有較好的實(shí)用性。為了進(jìn)一步提高其實(shí)用性,可在以下方面做出改進(jìn)。
1)在程序中,文件數(shù)據(jù)塊的大小(默認(rèn)取1K字節(jié)) 、超時(shí)時(shí)間(默認(rèn)取5秒) 等參數(shù)都可以調(diào)整以適應(yīng)網(wǎng)絡(luò)情況,以獲得最大的傳輸效率??赏ㄟ^在不同網(wǎng)絡(luò)條件下,針對不同大小和個數(shù)的多次的文件傳送實(shí)驗(yàn)獲得最優(yōu)的參數(shù)。
2)在多播傳送過程中,能夠動態(tài)調(diào)整多播客戶端的個數(shù),以避免在傳送時(shí)間比較長的情況下,某些客戶端出現(xiàn)意外情況,服務(wù)端程序無法繼續(xù)傳送數(shù)據(jù)的情況。
3)因?yàn)楸径嗖コ绦蛟跊]有Java運(yùn)行環(huán)境的機(jī)器上運(yùn)行時(shí),首先需要安裝JRE(Java Runtime Environment),可以將本程序使用C來實(shí)現(xiàn)并可以加上圖形界面,以利于Windows平臺下的部署和使用。
[1]謝希仁.計(jì)算機(jī)網(wǎng)絡(luò)(第4版)[M].北京: 電子工業(yè)出版社,2003.
[2]K.Sollins.The TFTP Protocol(Revision 2)[EB/OL].http://www.javvin.com/protocol/rfc1350.pdf, 2010.
[3]Sun Microsystem.JXTA v2.3x: JavaTM Programmer’s Guide[EB/OL].http://www.jxta.org/docs/ JxtaProgGuide_v2.3.pdf, 2010.
[4]許斌.JXTA-Java P2P網(wǎng)絡(luò)編程技術(shù)[M].北京: 清華大學(xué)出版社, 2010.
[5]Robert Flenner etc.Java P2P Unleashed[M].Sams Publishing, 2002.
[6]吳勝浩, 鐘亦平, 等.JXTA: 新型的網(wǎng)絡(luò)計(jì)算環(huán)境[J].計(jì)算機(jī)工程, 2004, 5(9): 4-6.
[7]孫東.IP多播技術(shù)在實(shí)時(shí)測控軟件中的應(yīng)用[J].計(jì)算機(jī)工程與科學(xué), 2004, (03).
[8]黃坤, 郭書明.IP多播技術(shù)在雷達(dá)信息交互中的應(yīng)用[J].電子設(shè)計(jì)工程, 2011, (17) .