手机端
or

欢迎您加入我爱方案网QQ群

1.智能产品外包服务群(311606115)
2.嵌入式项目开发群(491609563)

一种互联网视频会议文件群发设计方案及其实现

饶辉; 贺贵明| 视频会议系统,文件群发,断点续传| 2010-12-27
638 收藏
分享到: 
每日精选
热门推荐

【中心议题】

  •        *提出了一种在互联网视频会议中使用UDP将文件分块进行群发的方法
  •        *给出了通讯协议的设计,提出了一种新的简便高效的断点续传的方案

【解决方案】

  •        *视频编解码采用MPEG4标准
  •        *采用基于H323协议族的多点视频会议系统

0 引 言

  在多点视频会议系统中,经常需要进行同时对多个与会方的文件传输(Multicast File Transfer,文件群发).如会议主持人向与会的多个参与者发送公文、通知等.另外,在许多视频会议系统中文件群发也是实现共享文档等协同工作的基础.对多点的文件群发现在已经成为视频会议系统中一个重要的功能.现有的基于Internet的文件传输技术成熟,方案众多,如使用邮件服务器、FTP,但是在视频会议系统中,如何利用有限的网络带宽,在保证视频、音频稳定流畅的传输前提下,快速、灵活、安全的进行对多点的文件群发仍然是一个值得探讨和研究的问题.

一种既有的方案是在会议服务器上提供FTP服务,将文件上传到服务器后,由各与会方在服务器上下载.但这种方法使用比较繁琐复杂,而且由于有上传文件过程使整个传输过程变长,不能很好的满足要求.在笔者参与开发的视频会议系统中,实现了一种较好的对多点的文件群发的方案,该方案利用较少的网络资源,在保证视频、音频的流畅传输下,能实现快速、灵活的文件群发,并能进行断点续传,很好的达到了我们的设计要求.

本文第一部分详细介绍了本文的设计方案,给出了通讯协议并提出了一种新的断点续传方案;第二部分针对不同的实验结果进行了分析,验证了方案具有群发文件灵活、占用网络资源少、传输速率高的特点,并得到了优化的传输参数;第三部分对全文进行了总结.

1 设计方案

1.1 总体设计

本工作的视频会议系统是基于H323协议族的多点视频会议系统,视频编解码采用MPEG4标准(20/s),音频编解码采用G729标准,构建在Windows操作系统下使用Visual C++ 6.0开发.

为了降低资源消耗,提高文件传输速度,采用UDP来进行文件的传输.UDP是无连接的、不可靠的传输协议,因此,需要在应用层采用特别的方法和措施来保证文件传输的可靠性.

Windows平台上的Winsock是在TCP/IP协议基础上的一种网络编程接口,它直接来源于Unix

平台下的著名的Berkeley(BSD)套接字方案.

Winsock是基于Socket模型的API,包括了许多基于Windows消息驱动机制的Windows扩展函数.功能强大的MFC为使用Windows Socket编写通信程序提供了两种模型,分别封装成两个类CAsyncSocketCSocket.由于有了MFCWinsock的支持,使基于Socket的程序编制更为简单和方便.

本文采用问答方式来保证文件的可靠传输.在文件的发送方,将文件分成固定长度的定长包,并给每个包按顺序编上序号,依次发送给每个接收方,接收方接收该数据包后判断是否是所需要接收的序号的数据包,如果是,接收方将该数据包的数据写入文件,并发送确认信息给发送方,同时将下一个需要接收的包序号“捎带”在确认信息中发给发送方;如果不是,接收方将丢弃该包,并发送“要求重发包”信息给发送方,同时将正确的需要接收的包序号“捎带”在确认信息中发给发送方.发送方接收到返回信息后,根据不同的情况进行处理,直到文件传输完毕.

1.2 主要数据结构的定义

视频会议系统中数据类型和数据结构相当多,如视频信息、音频信息、文本信息等.为了方便数据的管理和文件传输的设计,针对文件传输,定义了如下的几个数据结构.

数据包结构

typedef struct DataPackage;

{short command; //包头

int serialnumb; //包的序列号

int currentlen; //包数据大小

int index ; //在文件中的序号

long ID; //ID

char filename[50]; //文件名

char data[256]; //数据}

其中command是包的类型标志符,程序将通过它判断该包的性质(是重传包、丢弃包)和进行相应的操作.index是包在文件中的序号,通过index接收方可判断是否是需要接收的包.

 

与会的成员信息结构

typedef struct _USER;

{long ID; //对方ID

char remoteip[17]; //对方IP

long port; //对方端口号

int index; //对方当前要发送的序列号

int resn; //发送次数

DataPackage pack; //数据包

……}

本文还构建了两个重要_USER型的集合gUsergSendUser,其中gUser是参与会议的成员集合,gSendUser是要发送文件的成员集合.

1.3 协议的设计

为了保证在UDP上实现可靠的传输,需要制定相应的通讯协议.首先文件发送方需要知道,哪些与会方需要接收文件,哪些拒绝接收文件,另外传输双方还需要知道何时开始传输文件,何时文件传输结束,以及是否需要重传包等.本文设计了如表1的通讯协议.为了简化协议的设计和应用,可以通过数据包的包头command来确定包的类型和相应的操作.

1.4 具体设计

设计了如下的传输方案:

1.4.1 文件发送准备

为了便于说明,设发送方(终端)A,接收方(终端)分别为B,C,D.首先A通过会议中心服务器获取参加会议的与会者BCD的相关通讯信息(包括IDIP、端口号等),然后A将向所有与会者发送包头为80的数据包,广播自己的文件传输端口号.

同时程序给出对话框,让文件发送方灵活的选择需要发送文件的与会方.

1.4.2 文件的传输

文件传输过程如下:

A发送包头为11,包含文件名和文件长度信息的包给BCD.

BCD收到包头11的包后,若同意接收则选定接收目录,打开文件,准备接收数据.发包头21,index1的包给A,同时接收包号指针从0递增为1.

A收到包头21,读文件第1个数据块,发送包头为12,数据为第1个数据块的包给接收方.

④接收方收到包头为12的包后,比较接收到的包中index是否等于接收文件指针.若相等,则将收到的数据写入文件,同时接收包号指针递增为2.发包头为21,index=2的包给A.

⑤直到读文件的最后一个包,A发送包头为13的包、数据为文件的最后一块给接收方.同时将该接收方从集合gSendUser中删除.完成对一个接收方的发送请求.

⑥接收方收到包头13的包后(文件最后一个包),写文件,并关闭文件,完成文件的传输.

 

几种特殊情况的处理:

①当由于网络和其他原因,接收方收到的包不是当前需要的包时,接收方将发送包头为31,index为需要的包序号的包给A,要求重发包.

②当A在没有将文件发送完毕的情况下,取消发送时,它将给未发送完毕的所有接收方发送包头为14的包,提示接收方文件未发送完毕.

③当某一接收方,在文件没有接收完毕的情况下,取消接收时,它将给A发送包头为41的包.A收到该包后将其从发送集合gSendUser中删除.在具体的程序设计中,设计了两个线程来完成接收和发送,它们共用一个端口(作者也设计了多端口多线程的程序,这里为了便于说明只介绍了单线程的设计情况).其中接收线程监视网络事件FD_READ(有数据到达),如果有事件FD_READ发生,就调用相应的接收处理函数处理;发送线程获得自定义的发送消息后,则执行发送过程,发送数据包.

1.5 文件断点续传的实现

文件的断点续传是视频会议文件传输中一个必需的功能.如果没有断点续传的功能,在网络质量不稳定或较差的情况下,一些较大的文件很可能不能成功的传送到接收方.一般断点续传的功能是通过在接收方或是在发送方记录下文件的传输断点位置来实现的.在认真分析了实际需求和总结各种断点续传方法后,设计的一种独特、简便的断点续传的方案如下.

在发送方给接收方发出文件发送申请时,在接收方本地产生是否接收该文件传输的消息框.接收方首先在选定的接收目录查找是否有同名文件存在.如果没有同名文件存在,则接着在默认的接收目录下查找是否有同名文件存在.如果没有,则通知发送方从文件首(index=1)开始传输.如果有同名文件存在,则获取文件大小,询问用户是否要续传该文件.若要续传文件,则接收方直接通过比较已经存在的文件大小和需要接收的文件大小,确定断点位置,将断点位置通知给发送方.发送方将从该断点位置开始给接收方发送数据包.

另外如果文件已经传输完毕,发送方给接收方发出同一个文件的发送申请时,则通知接收方用户是否要重传这个文件.若用户选择重传文件,则从文件首开始发送文件.

这一文件断点续传的机制,不需要发送方或接收方记录断点位置,方法简单,实现简便.尤其是对多个接收方都需要进行断点续传时,实现更为简单有效,非常适合文件群发的断点续传的实现.

2 结果及分析

由于实验条件所限,作者使用实验室的局域网来模拟广域网的视频会议系统.对基于互联网的文件群发来说,所不同的只是网络的带宽较广域网而言要大的多,但是对文件传输而言有重要影响的Socket5个参数:套接字的个数、传输延时、传输块大小、套接字体接收缓冲区和发送缓冲区大小对传输速度的影响是相似的.基于这一分析我们设计了不同的实验来得到最佳的传输参数.本文对10台不同配置(主频533 MHz)的由10/100 Mb/s交换机和10 Mb/s网卡构成的局域网进行了实验.在同时传输视频和音频的情况下,我们以文件的平均传输速率(总传输大小/总时间)作为评判指标.初始的实验参数是:1个套接字,传输块大小256 B,接收发送缓冲区大小8 792 B.

首先进行接收方数量对传输速率的影响的实验,结果如图1.由图1可见,接收端少量增加时,传输速率小幅增加,到最大值后,随着接收端增多,传输速率明显的减小.这是易于理解的,传输速率的下降主要是受限于发送端的带宽限制.在实际实施中,当一次发送的客户端过多时(10~20)可以通过优先将文件传给各分会场的一个或多个与会方,然后由这个与会方在分会场“分发”文件的方式来有效的提高传输速率.

 

2是对5个客户端传输文件时,不同传输块的大小对传输速度的影响变化图.从图中可以看出,传输块的大小对传输速率也有较大的影响.综合考虑传输视音频的质量问题,笔者认为传输块取512B768 B是比较好的选择.

本文还进行了套接字个数对传输速率影响的实验,以及使用TCP传输的对比实验.限于篇幅,这里不一一列出实验数据,只给出了分析结果.增加套接字个数,也就是采用多线程(一个线程一个套接字)对传输速率有较大的影响.适当增加套接字个数(3~5个即3~5个线程)可以明显增加传输速率,但使用过多的套接字(线程)对传输性能的改善将越来越小,当增大到临界值之后甚至会对传输速度有负面影响.其原因主要是因为线程的增多,增加了系统资源的消耗,多线程的调度浪费了CPU的处理能力,并不能有效提高端口的吞吐率.TCP对比实验证明,在接收端较少(1~6)的情况下,UDP实现比TCP实现要快20%~30%,但在客户端较多的时候UDP实现和TCP实现传输速率大致相当.

3 结 论

本文实现的文件群发主要有如下的优点:

①文件长度可以不受限制.

②由于网络或其他原因造成的包丢失,程序

可以自动进行重传,不需要用户的干预.

③所有与会方都可以进行文件的发送和接收,使用灵活方便.

④能方便的进行断点的续传和重传.

⑤占用网络资源少,对视频会议视频、音频传送的影响小.

在本视频会议系统中,使用UDP分块传输文件的方法,实现对多点的文件群发取得了较好的效果.特别是当会议规模较大,进行同一文件群发时,可以灵活的实现先发送到各分会场,然后在分会场“分发”的分层传输方式,从而缩短整个传输时间.

深圳市中电网络技术有限公司 Copyright© www.52solution.com 粤ICP备10202284号