数据包组播技术在广播教学中的应用

李香云, 葛 华

(1. 安徽科技学院 计算机系, 安徽 凤阳, 233100; 2. 安徽科技学院 计算中心, 安徽 凤阳, 233100)

数据包组播技术在广播教学中的应用

李香云1, 葛 华2

(1. 安徽科技学院 计算机系, 安徽 凤阳, 233100; 2. 安徽科技学院 计算中心, 安徽 凤阳, 233100)

针对目前流行的文件传输技术的不足, 提出采用组播模式和UDP协议实现文件传输. 并分析了UDP协议实现文件传输时的可靠性、有序性等方面的问题. 并从数据拆分、数据组包、数据有序和数据重传4个方面阐述其设计方法和设计过程.

组播; 数据拆包; 数据重传

文件快速传输在网络中得到广泛应用. 在多媒体网络教室软件中, 文件快速传输尤为重要, 不仅要保证文件传输的稳定性和正确性, 还要考虑大文件传输时文件包拆分、文件包差错校验、文件包重传、文件传输可靠性[1]等问题, 并运用UDP实现文件广播传输和文件包拆分传输.

1 系统设计思想

文件传输技术在广播教学中的应用主要从两个方面考虑, 首先是通讯模式的选择, 然后是传输协议的选择. 为了提高文件的传输应采用组播技术. UDP协议不提供数据传送的保证机制, 从发送方到接收方的传递过程中出现数据报的丢失, 协议本身并不能做出任何检测或提示, 也不进行恢复. 所以要提高UDP协议的可靠性与安全性[2-4], 就必须增加差错处理、有序保证和数据重传机制, 通过增加差错处理机制, 使得数据报在传输过程中出错、或者丢失后能马上检测出来并被迅速地重传.

1.1 数据拆包机制

考虑UDP协议网络传输[5-6]单包传送的最大数据为1 024字节, 当我们需要传送的数据超过1 024字节时, 只能将其拆分成小于1 024的数据包分别进行传送. 数据报报头包含有文件类型和序列号的信息, 所以实际的用户数据设计大小为1 000字节. 当应用层需要传送的数据超过1 000字节时, 拆包机制开始执行.它将原始数据拆分成 1 000字节大小的数据块, 然后为每包数据加上文件类型和序列号信息. 这样方便客户端在接收到数据包后的组包机制的实施. 比如将文件名和文件长度等信息作为第一个发送的数据包, 设置文件类型为 HEAD, 序列号为 0, 数据为文件长度和文件名; 之后开始拆分原始数据, 设置文件类型为DATA, 序列号从1开始加1递增, 数据为1 000字节的实际数据; 最后拆分成的是文件尾部, 设置文件类型为TAIL, 序列号为正常递增后的序列号, 数据为原始数据最后剩余下的字节数.

1.2 数据组包及有序机制

当服务器端传送的数据大于 1 000字节时, 在服务器端发送前会进行拆包机制, 于是当客户端接收到服务器端发送来的拆分后的数据包时, 需要进行组包. 客户端接收到数据后, 会对数据进行组包, 这样就可以实现较大数据量的传输, 组包的过程也就是保证数据有序的过程.

在网络不稳定的情况下, UDP数据包在传送过程中有可能出现乱序问题, 所以要想保证数据的顺序是完全正确的, 就必须保证每一个拆分后的数据包在传送过程中是按顺序到达的. 有序机制是通过检测接收到的数据包的序列号来实现的, 如果接收到的序列号是期望接收的序列号, 则将此包存入等待写入磁盘链表; 如果不是, 在接收此包并存入等待写入磁盘链表时服务器端会同时发出包含有期望的数据包的序列号的重传请求. 当等待写入磁盘链表中有数据时, 就启动写入磁盘线程将链表中的数据写入到磁盘中. 如果是正确接收到的数据, 则一个一个写入, 并在写完一个数据包后将等待写入磁盘链表中的此包清除; 如果写入的是请求重传后收到的的重传数据包, 则需要根据包的序列号将文件的指针指向此包应该写入的位置,正确写入, 之后也将等待写入磁盘队列中的此包清除. 这样就可以保证接收端的数据包的有序性.

1.3 数据重发机制

UDP协议不提供错误检测机制, 自然也不提供错误数据重传服务, 所以必须提供一套数据重传机制使数据在出错后可以及时地修正, 保证数据可以可靠地到达目的地, 数据重传机制包括两种情况, 第一种情况是客户端发送的重传请求的数据包在服务器端的等待重传链表中, 则从等待重传链表中找到该包并立即重传到客户端. 第二种情况是客户端发送的重传请求的数据包不在服务器端的等待重传链表中, 服务器端则向客户端发送包含有此数据包序列号的等待最后重传消息, 最后调用统一重传函数, 统一的重传这些数据包.

1.4 机制的合并

上述的几种机制只有整合在一起才可以保证 UDP数据报在传输过程中是安全可靠的. 整合的基本设计思路是这样的: 在服务器端程序中创建了一个线程, 该线程中的线程函数负责读取数据并根据数据的大小决定是否拆包, 然后调用相应的发送函数进行发送, 发送后立即将发送过的数据保存入一个等待重传链表, 并立即启动接收反馈线程, 等待接收客户端的文件类型为NACK反馈数据. 若收到客户端的文件类型为NACK的重传请求, 则进入等待重传链表寻找此数据包, 如果找到此数据包, 调用相应的重传函数进行重新发送数据, 如果没有在重传链表中找到需要重传的数据包, 服务器端向客户端发送等待最后重传消息,并在最后调用统一重传函数重传数据. 在客户端程序中创建了一个接收线程, 该线程中的线程函数负责接收数据, 并将接收到的数据存入一个等待写入磁盘链表中, 如果发现接收到的数据包不是期望的, 则在将此数据包存入等待写入磁盘链表中后, 调用请求重传函数, 向服务器端发出重传请求. 如果等待写入磁盘链表中有数据, 就启动写入磁盘线程将链表中的数据写入磁盘中. 在写入磁盘的过程中实现了数据的组包及有序.

2 数据报报头设计

数据报报头应该包含数据传送过程中需要的基本信息, 本文用文件类型标识传送的是文件头部信息,还是实际数据信息或是文件尾部信息. 用拆包序列号来满足回传请求及组包机制的实现需求, 最后要包括的就是实际传送的数据. 考虑到UDP数据包在网络传输时最大字节的限制, 数据的实际内容用了1 000字节, 报报头设计如图1所示.数据报报头的的结构体设计如下:

图1 数据报报头设计图

3 系统处理流程图

3.1 服务器端发送线程

服务器端的发送线程先发送文件的头部信息, 如果客户端没能正确的接收文件的头部信息, 则继续等待接收文件的头部信息. 服务器端重新发送, 直到客户端正确接收到文件的头部信息为止. 接下来发送文件的正文信息, 发送后立即将发送过的数据保存入一个等待重传链表. 如果某数据包未能正确接收, 服务器端会收到客户端的带有包的序列号的重传请求. 服务器端接收到重传请求后, 会先进入等待重传链表中寻找此包, 如果找到, 则调用重传函数立即重传此包. 如果没有在重传链表中找到此包, 则向客户端发送等待统一最后重传消息, 等所有数据全部发送完后, 再调用统一重传函数将没有正确接收的包重新发送,服务器端的发送线程如图2所示.

3.2 客户端接收线程

客户端的接收线程先接收服务器端发送来的文件的头部信息, 如果没有正确接收文件的头部信息, 则一直不停的接收服务器端发送来的头部信息, 直到正确接收到为止. 然后开始接收服务器端发送来的每包的数据, 接收到数据后先将接收到的数据存入一个等待写入磁盘链表, 如果发现接收到的包的序列号与期望接收到的包的序列号不同, 即说明接收到的包不是期望接收的包, 则先将此包保存入等待写入磁盘链表,同时向服务器端发送带有期望包序列号的重传请求. 如果接收到服务器端发送的带有重传标志RSED的包,先判断此包是否是期望重传的包, 如果确实请求过重传此包, 则接收此包, 并存入等待写入磁盘链表. 如果没有请求重传过此包, 则丢弃. 最后接收服务器端传送的文件类型为TAIL的包, 其处理方式与文件类型为DATA的方式相同. 客户端接收线程的流程图如图3所示.

图2 服务器端发送线程流程图

图3 客户端接收线程流程图

3.3 服务器端的接收反馈线程和重传函数流程图

由于采用UDP传送数据时, 会有丢包、乱序等数据差错问题, 所以服务器端在发送数据后立即调用接收反馈线程, 准备接收客户端发送来的重传消息. 如果客户端有重传请求, 接收反馈线程接收此请求. 首先对接收到的重传请求的文件类型位进行判断, 如果文件类型设置的是 NACK, 说明此数据是客户端的重传请求. 则调用重传函数重新传送客户端请求的包. 如果不是 NACK, 则服务器端的接收反馈线程不对接收到的此消息做出响应, 而是直接将此消息丢弃. 接收反馈线程的执行流程如图4所示.

服务器端的重传函数首先判断重传NUM是否大于零以决定是否有需要重传的数据包. 如果重传NUM大于零, 说明有需要重传的数据, 则进入服务器端保存重传数据的重传链表, 在此队列中寻找序列号等于请求重传的序列号的包, 如果在重传队列中找到此包, 则立即重传此包, 如果没有找到此包, 就向客户端发送等待最后统一重传消息, 等待最后统一重传这些数据. 重传结束后, 再次判断是否有需要重传的包.依次传送, 直至全部传送完需要重传的包. 重传函数的流程图如图5所示:

图4 服务器端的接收反馈线程

图5 服务器端的重传函数流程图

3.4 客户端的写入线程

客户端接收到数据后, 就启动写入线程将数据写入到磁盘中. 写入的数据分为两种类型, 一种是正确接收到的数据包, 一种是接收到的重传的数据包.

对于正确接收到的数据包, 又分为文件类型为DATA的数据包和文件类型为TAIL的尾部数据包. 在写入文件类型为 DATA的数据包时, 先判断等待写入链表是否为空, 如果链表不为空, 说明链表中有数据可以写入到磁盘中, 再判断此时是否已经到等待写入链表的尾部, 若没有到链表的尾部, 则取出链表中的数据, 向磁盘中写入1 000字节大小的数据. 然后删除等待写入链表中的此数据包, 即从链表的头部删除, 接着判断等待写入链表中的下一个数据包, 如上依次写入磁盘, 直到等待写入链表为空或者到达链表的尾部.在写入文件类型为TAIL的数据包时, 取出链表中的数据, 向磁盘中写入最后一包大小的数据, 然后从等待写入链表中删除此数据包. 执行流程如图6所示.

对于接收到的文件类型为 RSED的包, 在重传链表不为空并且没有到达链表尾部的情况下, 还需通过包的序列号定位此包在磁盘中的正确位置, 找到此数据包在磁盘中的正确位置后, 将此包的数据写入到磁盘中, 删除重传链表中此数据包, 然后再次判断重传链表是否为空或已经到达链表的尾部, 如果为空或已到达尾部, 则结束此次写入操作. 执行流程如图7所示.

3.5 发送线程代码

因编码较多这里只给出发送数据线程代码, 其编码如下:

图6 客户端接收正常数据的写入流程图

图7 客户端接收重传数据的写入流程图

4 实验结果

在实验中, 我们在一个80台计算机实验室利用组播技术文件传输程序, 将一个100 MB文件分发到实验室的其他机器中, 实验结果表明: 一个100 MB的文件无差错快速传输, 耗时为12秒.

5 小结

本文介绍了文件传输技术在广播教学中的应用, 使用组播和UDP协议针对UDP的无连接、不可靠等方面进行了改进, 采用数据拆包、数据组包、数据有序控制和数据重传等机制解决此问题, 使得文件在局域网内可以有序的、可靠的进行传输, 满足了广播教学的需求. 本文所介绍技术虽满足了教师的多媒体教学之需, 但还存在一些不足, 比如文件传输的速度方面还可以有所提高, 以及多文件传输[7-9]在具体实现中采用超时机制. 可以在文件的每个数据包发送后设置超时, 当超时发生时, 自动重传超时的数据包, 以解决丢包问题, 但由于超时时间的设置与网络有密切的关系, 具体的参数设置需要通过针对具体的网络进行估算与计算, 而且需要有一定的经验, 可以说是在某种程度上是一个经验值, 并且有一定的复杂性和难度,需要进一步进行研究.

[1] 李国, 巩光志, 王冬冬. 一种提高UDP可靠性的数据传输方法研究[J]. 中国民航大学学报, 2012(1): 41-45.

[2] 尹然然. 基于UDP协议的可靠性改进协议[J]. 电脑知识与技术, 2010(16): 4379-4380.

[3] 王大羽, 陈莹. 基于UDP的协议可靠性传输设计与实现[J]. 福建电脑, 2009(8): 132-133.

[4] 王继刚, 顾国昌, 徐立峰, 等. 可靠UDP数据传输协议的研究与设计[J]. 计算机工程与应用, 2006(15): 113-116.

[5] 李永胜, 黄兰红, 刘红军. 基于UDP协议的多文件传输[J]. 广西民族大学学报: 自然科学版, 2007(2): 68-71, 93.

[6] 曹婧华, 赵飞, 冉彦中. 局域网文件传输的Delphi编程实现[J]. 长春师范学院学报, 2011(2): 40-42.

[7] 唐彰国, 钟明全, 李焕洲, 等. 基于数据流的启发式文件传输识别系统设计[J]. 计算机工程与设计, 2011(9): 2929-2933, 2949.

[8] 董淑松, 康慕宁. 基于可靠组播文件传输协议的设计与分析[J]. 科学技术与工程, 2010(9): 2195-2198, 2206.

[9] 祝红琴, 王芳, 黎智军. 基于文件传输中文件损坏的检测和恢复办法[J]. 硅谷, 2010(20): 188.

(责任编校: 谭长贵)

DataPacket file multicasting technology in broadcasting teaching application

LI Xiang-yun1, GE Hua2
(1. The Computer center, Anhui Scrience and Technology University, Fengyang 233100, China; 2. The Department of computer, Anhui Scrience and Technology University, Fengyang 233100, China)

In view of current popular file transmission technology insufficiency, this article provided a method which realize process to carry on reliable and fast multiple file transmission by the multicast mode and UDP protocol file transfer, and UDP protocol file transfer reliability, ordering and other aspects of the problem. And its design methods and design process were discussed from four aspects: the data, the data group packet, data orderly and retransmission.

Multicast; Data unpacking; Data retransmission

TP 317

1672-6146(2012)02-0086-06

10.3969/j.issn.1672-6146.2012.02.021

2012-05-02

安徽科技学院青年科学研究基金(ZRC2011273), 安徽科技学院引进人才基金资助(ZRC2010255).

李香云(1982-), 助理实验师, 硕士生, 主研领域: 信息管理系统、实验室管理、计算机网络.

E-mail:bluecomputing@126.com