基于多播的以太网文件传送协议的设计与实现

张昆朋，吕延庆，谢华成

（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) .