基于多播的以太網文件傳送協議的設計與實現

張昆朋，呂延慶，謝華成

（1.洛陽師范學院 信息技術學院，洛陽 471022；2.信陽師范學院 網絡信息與計算中心，信陽 464000）

0 引言

在局域網中經常會遇到把相同的數據復制到多臺主機上的情況，如果使用基于單播的FTP、HTTP等協議及軟件來傳送文件，會造成很多網絡流量的浪費。在將文件數據從一臺主機復制到多臺主機的特定情況下，使用D類多播地址可以有效的避免以上問題，從而減少網絡流量，提高傳輸效率。

圖1 以太網上數據幀的單播和多播

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

軟件帶有的GhostCast程序，可以通過網絡對客戶機的整個硬盤或分區進行克隆，一般都需要預先在多臺需要復制文件的客戶機的磁盤上專門劃分出分區，破壞了原有的磁盤結構且設置較為繁瑣。

下面設計和實現一個基于單個文件或整個目錄的多播文件傳送程序，能夠較好地解決以上問題。

1 多播文件傳送協議的設計

1.1 多播IP地址分析

多播通信中使用的D類IP地址范圍在224.0.0.1～239.255.255.255之間，采用多播進行通信需要使用能夠進行多播通信的網絡接口，如果是通常的以太網接口，自然的就可以進行多播通信。多播通信與以太網中的廣播網不同，屬于OSI第三層的網絡層協議，可以跨越支持多播協議的路由器進行通信。其中D類IP地址224.0.0.1 表示在本子網上的所有參加多播的主機和路由器，當使用這個IP地址時，不能跨越路由器，只能在以太網的相同網段內使用多播，但這是能夠滿足本文針對的網絡實驗室的要求的。因此本程序在實現時采用了224.0.0.1這個固定的地址，實際使用時需要跨越多播路由器通信也可以根據需要來調整多播IP地址。

1.2 傳輸層協議分析

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

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

表1 多播文件傳送協議定義的6種協議數據單元

客戶端使用“客戶端發現PDU”通知服務端，包含IP地址來標識不同的客戶端。這樣在文件傳送未開始之前，服務器收集所有客戶機IP地址，開始文件傳送后可以監測并保證傳送的文件數據被每個客戶端正確接收。文件傳送是切分成文件數據塊進行的，每個“文件數據PDU”攜帶1K字節的文件數據(最后一個數據塊可能不足1K字節)，這些文件數據塊使用了序號來保證順序，從而消除了UDP可能無序接收的問題。

1.3 對PDU超時重傳的處理

考慮到了網絡的質量問題，UDP可能出現丟包，因此對于“文件名PDU”、“文件名確認PDU”、“文件數據PDU”、“文件數據確認PDU”都作了超時重傳的處理。

需要做超時重傳處理的場合包括。

1）在客戶端接收“文件數據PDU”超時的情況

（1）如果該“文件數據PDU”是文件的第一個數據塊，重傳該文件的“文件名確認PDU”；

（2）如果該“文件數據PDU”不是文件的第一個數據報，重傳上一個文件數據塊的“文件數據確認PDU”。

2）在服務端接收“文件名確認PDU”超時的情況，重傳該文件的“文件名PDU”。

3）在服務端接收“文件數據確認PDU”超時的情況，重傳該文件數據塊的“文件數據PDU”。

對于“客戶端發現PDU”，由于可以在服務端看到是否所有客戶端都連接上，并控制發送開始的時間，所以不用重傳。發現有“客戶端發現PDU”丟失，即服務端無法發現客戶端的情況，只需要重新啟動客戶端程序就可以，或者檢查客戶端程序的IP設置是否是與服務端程序在同一以太網段內。

對于“全部傳送結束PDU”，因為服務端程序運行到發送該PDU時已經能夠保證所有文件數據已經被正確發送到所有多播客戶端，因此直接把該PDU數據重傳多次，使得客戶端程序能夠接收到該PDU能夠退出運行即可。如果出現該PDU無法被有些多播客戶端接收的情況，客戶端強行退出即可。

2 本多播程序實現概述

Java平臺對多播協議提供了支持，本程序使用Java語言來開發。本多播程序分為服務端程序和客戶端程序兩部分。其中，服務端程序用來實現多播數據的發送，而客戶端程序用來接收多播數據。典型的情況是在同一以太網段內運行一個服務端程序和多個客戶端程序。程序流程框圖如圖2、3所示。

圖2 服務器端多播文件傳送流程

圖3 客戶端接收數據流程

3 測試

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

表2 本程序與FlashFXP對比表

4 結論

在此多播文件傳送協議的設計和實現中，參考了成熟的協議，從測試結果來看，達到了預想的效果，在以太網的同一網段內，保證數據可靠傳輸的前提下提高了傳輸效率，具有較好的實用性。為了進一步提高其實用性，可在以下方面做出改進。

1）在程序中，文件數據塊的大小(默認取1K字節) 、超時時間(默認取5秒) 等參數都可以調整以適應網絡情況，以獲得最大的傳輸效率。可通過在不同網絡條件下，針對不同大小和個數的多次的文件傳送實驗獲得最優的參數。

2）在多播傳送過程中，能夠動態調整多播客戶端的個數，以避免在傳送時間比較長的情況下，某些客戶端出現意外情況，服務端程序無法繼續傳送數據的情況。

3）因為本多播程序在沒有Java運行環境的機器上運行時，首先需要安裝JRE(Java Runtime Environment)，可以將本程序使用C來實現并可以加上圖形界面，以利于Windows平臺下的部署和使用。

[1]謝希仁.計算機網絡(第4版)[M].北京: 電子工業出版社,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網絡編程技術[M].北京: 清華大學出版社, 2010.

[5]Robert Flenner etc.Java P2P Unleashed[M].Sams Publishing, 2002.

[6]吳勝浩, 鐘亦平, 等.JXTA: 新型的網絡計算環境[J].計算機工程, 2004, 5(9): 4-6.

[7]孫東.IP多播技術在實時測控軟件中的應用[J].計算機工程與科學, 2004, (03).

[8]黃坤, 郭書明.IP多播技術在雷達信息交互中的應用[J].電子設計工程, 2011, (17) .