基于多播的以太網(wǎng)文件傳送協(xié)議的設(shè)計(jì)與實(shí)現(xiàn)

張昆朋，呂延慶，謝華成

（1.洛陽(yáng)師范學(xué)院 信息技術(shù)學(xué)院，洛陽(yáng) 471022；2.信陽(yáng)師范學(xué)院 網(wǎng)絡(luò)信息與計(jì)算中心，信陽(yáng) 464000）

0 引言

在局域網(wǎng)中經(jīng)常會(huì)遇到把相同的數(shù)據(jù)復(fù)制到多臺(tái)主機(jī)上的情況，如果使用基于單播的FTP、HTTP等協(xié)議及軟件來(lái)傳送文件，會(huì)造成很多網(wǎng)絡(luò)流量的浪費(fèi)。在將文件數(shù)據(jù)從一臺(tái)主機(jī)復(fù)制到多臺(tái)主機(jī)的特定情況下，使用D類(lèi)多播地址可以有效的避免以上問(wèn)題，從而減少網(wǎng)絡(luò)流量，提高傳輸效率。

圖1 以太網(wǎng)上數(shù)據(jù)幀的單播和多播

以太局域網(wǎng)本身發(fā)送數(shù)據(jù)時(shí)就是以廣播的方式發(fā)送的，只是不需要該數(shù)據(jù)的客戶(hù)端根據(jù)MAC幀包含的目的地址來(lái)舍棄該數(shù)據(jù)。在使用FTP或HTTP等協(xié)議傳輸時(shí)，由于目的地址采用單播地址，丟棄了本不應(yīng)丟棄的數(shù)據(jù)，降低了傳輸效率；如果目的地址為多播地址，則該數(shù)據(jù)仍能正常被接收端主機(jī)接收和處理如圖1所示。目前網(wǎng)絡(luò)克隆的程序就是基于上述的多播原理完成工作的，但這些程序大多是基于磁盤(pán)或分區(qū)的。例如Ghost

軟件帶有的GhostCast程序，可以通過(guò)網(wǎng)絡(luò)對(duì)客戶(hù)機(jī)的整個(gè)硬盤(pán)或分區(qū)進(jìn)行克隆，一般都需要預(yù)先在多臺(tái)需要復(fù)制文件的客戶(hù)機(jī)的磁盤(pán)上專(zhuān)門(mén)劃分出分區(qū)，破壞了原有的磁盤(pán)結(jié)構(gòu)且設(shè)置較為繁瑣。

下面設(shè)計(jì)和實(shí)現(xiàn)一個(gè)基于單個(gè)文件或整個(gè)目錄的多播文件傳送程序，能夠較好地解決以上問(wèn)題。

1 多播文件傳送協(xié)議的設(shè)計(jì)

1.1 多播IP地址分析

多播通信中使用的D類(lèi)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類(lèi)IP地址224.0.0.1 表示在本子網(wǎng)上的所有參加多播的主機(jī)和路由器，當(dāng)使用這個(gè)IP地址時(shí)，不能跨越路由器，只能在以太網(wǎng)的相同網(wǎng)段內(nèi)使用多播，但這是能夠滿(mǎn)足本文針對(duì)的網(wǎng)絡(luò)實(shí)驗(yàn)室的要求的。因此本程序在實(shí)現(xiàn)時(shí)采用了224.0.0.1這個(gè)固定的地址，實(shí)際使用時(shí)需要跨越多播路由器通信也可以根據(jù)需要來(lái)調(diào)整多播IP地址。

1.2 傳輸層協(xié)議分析

首先，在傳輸層上具有可靠性保證的TCP不支持多播，因此傳輸層采用UDP協(xié)議，而數(shù)據(jù)的可靠傳輸由協(xié)議本身的設(shè)計(jì)來(lái)保證；其次，由于涉及到文件傳送，多播文件傳送協(xié)議參考了同樣基于UDP的TFTP協(xié)議(RFC1350) 的設(shè)計(jì)思路，但考慮到TFTP沒(méi)有列目錄的功能，因此針對(duì)其適用情況做了一些修改。

多播文件傳送協(xié)議在傳輸層使用的UDP數(shù)據(jù)報(bào)一共定義了六種協(xié)議數(shù)據(jù)單元(PDU) ，每種PDU的第一個(gè)字段是操作碼標(biāo)志字段(FLAG) , 根據(jù)該標(biāo)志字段的不同PDU的格式和作用各不相同如表1所示 。

表1 多播文件傳送協(xié)議定義的6種協(xié)議數(shù)據(jù)單元

客戶(hù)端使用“客戶(hù)端發(fā)現(xiàn)PDU”通知服務(wù)端，包含IP地址來(lái)標(biāo)識(shí)不同的客戶(hù)端。這樣在文件傳送未開(kāi)始之前，服務(wù)器收集所有客戶(hù)機(jī)IP地址，開(kāi)始文件傳送后可以監(jiān)測(cè)并保證傳送的文件數(shù)據(jù)被每個(gè)客戶(hù)端正確接收。文件傳送是切分成文件數(shù)據(jù)塊進(jìn)行的，每個(gè)“文件數(shù)據(jù)PDU”攜帶1K字節(jié)的文件數(shù)據(jù)(最后一個(gè)數(shù)據(jù)塊可能不足1K字節(jié))，這些文件數(shù)據(jù)塊使用了序號(hào)來(lái)保證順序，從而消除了UDP可能無(wú)序接收的問(wèn)題。

1.3 對(duì)PDU超時(shí)重傳的處理

考慮到了網(wǎng)絡(luò)的質(zhì)量問(wèn)題，UDP可能出現(xiàn)丟包，因此對(duì)于“文件名PDU”、“文件名確認(rèn)PDU”、“文件數(shù)據(jù)PDU”、“文件數(shù)據(jù)確認(rèn)PDU”都作了超時(shí)重傳的處理。

需要做超時(shí)重傳處理的場(chǎng)合包括。

1）在客戶(hù)端接收“文件數(shù)據(jù)PDU”超時(shí)的情況

（1）如果該“文件數(shù)據(jù)PDU”是文件的第一個(gè)數(shù)據(jù)塊，重傳該文件的“文件名確認(rèn)PDU”；

（2）如果該“文件數(shù)據(jù)PDU”不是文件的第一個(gè)數(shù)據(jù)報(bào)，重傳上一個(gè)文件數(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”。

對(duì)于“客戶(hù)端發(fā)現(xiàn)PDU”，由于可以在服務(wù)端看到是否所有客戶(hù)端都連接上，并控制發(fā)送開(kāi)始的時(shí)間，所以不用重傳。發(fā)現(xiàn)有“客戶(hù)端發(fā)現(xiàn)PDU”丟失，即服務(wù)端無(wú)法發(fā)現(xiàn)客戶(hù)端的情況，只需要重新啟動(dòng)客戶(hù)端程序就可以，或者檢查客戶(hù)端程序的IP設(shè)置是否是與服務(wù)端程序在同一以太網(wǎng)段內(nèi)。

對(duì)于“全部傳送結(jié)束PDU”，因?yàn)榉?wù)端程序運(yùn)行到發(fā)送該P(yáng)DU時(shí)已經(jīng)能夠保證所有文件數(shù)據(jù)已經(jīng)被正確發(fā)送到所有多播客戶(hù)端，因此直接把該P(yáng)DU數(shù)據(jù)重傳多次，使得客戶(hù)端程序能夠接收到該P(yáng)DU能夠退出運(yùn)行即可。如果出現(xiàn)該P(yáng)DU無(wú)法被有些多播客戶(hù)端接收的情況，客戶(hù)端強(qiáng)行退出即可。

2 本多播程序?qū)崿F(xiàn)概述

Java平臺(tái)對(duì)多播協(xié)議提供了支持，本程序使用Java語(yǔ)言來(lái)開(kāi)發(fā)。本多播程序分為服務(wù)端程序和客戶(hù)端程序兩部分。其中，服務(wù)端程序用來(lái)實(shí)現(xiàn)多播數(shù)據(jù)的發(fā)送，而客戶(hù)端程序用來(lái)接收多播數(shù)據(jù)。典型的情況是在同一以太網(wǎng)段內(nèi)運(yùn)行一個(gè)服務(wù)端程序和多個(gè)客戶(hù)端程序。程序流程框圖如圖2、3所示。

圖2 服務(wù)器端多播文件傳送流程

圖3 客戶(hù)端接收數(shù)據(jù)流程

3 測(cè)試

為了測(cè)試該多播程序的有效性，測(cè)試分三步進(jìn)行。在安裝了Windows Server 2003的計(jì)算機(jī)上使用1個(gè)多播服務(wù)端程序，而多播客戶(hù)端程序分別使用1個(gè)、2個(gè)和25個(gè)，也就是安裝多播客戶(hù)端的計(jì)算機(jī)數(shù)量逐步增多，以測(cè)試該多播程序的傳送效果。測(cè)試結(jié)果如表2所示。

表2 本程序與FlashFXP對(duì)比表

4 結(jié)論

在此多播文件傳送協(xié)議的設(shè)計(jì)和實(shí)現(xiàn)中，參考了成熟的協(xié)議，從測(cè)試結(jié)果來(lái)看，達(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ò)情況，以獲得最大的傳輸效率?？赏ㄟ^(guò)在不同網(wǎng)絡(luò)條件下，針對(duì)不同大小和個(gè)數(shù)的多次的文件傳送實(shí)驗(yàn)獲得最優(yōu)的參數(shù)。

2）在多播傳送過(guò)程中，能夠動(dòng)態(tài)調(diào)整多播客戶(hù)端的個(gè)數(shù)，以避免在傳送時(shí)間比較長(zhǎng)的情況下，某些客戶(hù)端出現(xiàn)意外情況，服務(wù)端程序無(wú)法繼續(xù)傳送數(shù)據(jù)的情況。

3）因?yàn)楸径嗖コ绦蛟跊](méi)有Java運(yùn)行環(huán)境的機(jī)器上運(yùn)行時(shí)，首先需要安裝JRE(Java Runtime Environment)，可以將本程序使用C來(lái)實(shí)現(xiàn)并可以加上圖形界面，以利于Windows平臺(tái)下的部署和使用。

[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í)測(cè)控軟件中的應(yīng)用[J].計(jì)算機(jī)工程與科學(xué), 2004, (03).

[8]黃坤, 郭書(shū)明.IP多播技術(shù)在雷達(dá)信息交互中的應(yīng)用[J].電子設(shè)計(jì)工程, 2011, (17) .