面向并发服务的流媒体访问控制技术研究

1、面向并发效劳的流媒体访问控制技术研究摘要本文提出一种基于实时协议的多媒体数据流并发效劳控制模型，介绍了数据并发传送的调度控制问题。由实时协议的反应机制动态调整控制参数，到达平滑时延的目的。最后通过对时延参数的测试，说明这一数据流控制方式的合理性，同时该方法也适用于网络视频的多点实时传输、网络多点实时监控，有较高的应用价值。关键词并发调度动态调整实时模型实时数据传输对于视频播放具有非常重要的意义，在各种网络特性中时延参数占有相当的份量。通常认为视频这类应用其时延要求小于20毫秒s，抖动限制在4毫左?SUP13。尽管进步网络带宽可以改善网络的吞吐量、传输延时等性能，由于视频数据的高容量和视频信源的

2、高比特率特性，对于客户端的效劳质量要求来说显得微缺乏道。目前针对视频效劳质量，从传送层协议的使用、数据的压缩/解压、协同计算到单播/组播等多方面提出了许多措施。考虑到网络传输状况的多样性，本文重点讨论效劳器端的数据传送调度控制，和并发效劳的关键技术，尽可能地降低传输中的时延抖动问题，进步并发效劳质量，文中最后给出了关键控制代码和测试结果。1信源数据的并发传输模型并发连接对于网络视频应用来说，有别于以往的EB页面式效劳和FTP效劳，每个视频数据流至少需要384kb/s的带宽甚至更高。同时传输效劳还需要具有一定的余量，防止并发客户恳求数到达峰值、或网络短期过载现象。因此适宜的效劳模型、良好的效劳策

3、略是优质效劳的保障。对即时的影像流压缩与传输要求来说，在效劳模型中还需要针对网络系统的资源限制条件，即网络带宽采取适应视频传输的策略，以便处理突发性事件。另一个需要考虑的限制是效劳器提供的并发连接数量以及等候处理的发送调用。因为并发连接数量越多，所消耗的未分页内存池也越多；等候处理的发送调用越多，被锁定的内存页面也越多，极易超过系统资源的极限。1.1效劳器的视频传输效劳特点视频传输需要较宽的网络带宽，其视频的压缩编码、传输信道和网络协议的选择、IP组播技术对传输质量具有重要的影响作用。基于计算机网络连接的视频点播系统，其关键就在于多个站点视频的网络通信问题，要求做到传输时延尽可能小，尽可能少地

4、占用现有的网络带宽，并具有较好的站点数量规模化特性。视频效劳器对于用户的恳求，需要在较短的时间间隔内响应并传送所要求的视频数据，同时随时准备响应新的恳求。因此视频效劳器的性能直接决定系统的总体性能，为了能同时响应多个用户的效劳恳求，视频效劳器需要调度效劳。并具备接纳控制、恳求处理、数据检索、按流传送等多种功能，提供实时、连续稳定的视频流，以确保用户恳求获得有效效劳。再者，视频效劳器还需要提供交互效劳，如快进和快倒等功能，因此视频效劳器必须满足视频流特性使用中的各种要求。1.2效劳器的并发效劳技术通常客户效劳器间的通信过程首先是建立点到点的直接联络方式，因此效劳器的负载才能决定了视频点播的并发容

5、量。在客户机/效劳器传输方式中，在面向连接的通信形式下，效劳器需要翻开监听端口，监听网络上其它客户机向该效劳器发出的连接恳求，当收到一个恳求信号时与该客户机建立一个连接，之后两者进展交互式的通信。这在客户端恳求较少，同时数据传输量不大的情况下传输延迟还可以忍受。对于实时性要求较高的视频应用，一般采用无连接的通信形式。如PEG-I按照1.5b/s传输在满足观看需要的情况下其帧数也要大于10帧以上。另外，当多个用户同时申请效劳的时候，效劳器建立连接分配资源等都需要产生延迟，也就是说对于用户的响应经过逐渐积累延迟会越来越大。假如恳求池缺乏的话，那么就会产生客户的恳求丧失。因此，同一时刻只能处理一个客

6、户恳求的循环效劳器方式不合适视频点播。假如采用并发效劳方式2，在效劳器端用主进程去监听客户机的连接恳求，当有客户机的连接恳求时通过创立线程的方式独立处理客户机通信，进步视频传输的实时性。视频数据的并发传输，本质依赖于效劳器中的传输线程，效劳器的操作以建立相应的线程实现效劳为目的，这种效劳形式非常合适复杂的多任务恳求。从计算机操作系统运行的角度来说，在典型的单处理器主机上，任务实际上并不是同时执行的。内核中称为调度程序的局部将工作换进换出，从而让所有工作都获得一轮执行。在同一个时间间隔内，并发模型常常基于事件的编程实现。通常情况下，线程数量取决于应用程序的特定需要，理想情况下线程数量与处理器数量

7、相当为好，虽然线程数量无法保证传输质量，但线程太少又会造成传输效率低，特别是用户数量较多的情况下更为明显。从视频应用来说，影响视频传输性能的根本原因在于视频数据的连续传送和用户提交给效劳器的恳求无法及时响应，超过了网络资源节点容量或效劳器的处理才能。这样就造成网络系统的数据包时延增加、丢弃概率增大、上层应用系统性能下降等。主要表如今以下几方面：并发连接数决定系统内存资源的消耗，并与PU的处理才能亲密相关。视频效劳要求效劳器尽快地把数据通过网络发送，尽量减少对连接恳求的处理延迟，以免效劳恳求的重发和丧失。物理链路的实际承载才能也影响并发连接的处理才能。根据香农信息理论，任何信道带宽最大值即信道容

8、量:=Blg2(1+S/N)N为信道白噪声的平均功率，S为信源节点的平均功率,B为信道带宽。所有信源节点发送的速率R必须小于或等于信道容量。假如R，那么在理论上无过失传输就是不可能的，所以效劳器与网络的联结处会形成传输瓶颈。交换机或路由器的处理才能弱：假如路由器的PU在执行排队缓存、更新路由表等功能时，处理速度无法与高速链路匹配，就会造成效劳失效。随着网络规模的扩大和用户数的激增，数据流传输更趋于频繁，线程数量不可能无限制增加。假如效劳器和客户之间没有缓冲余地必然会出现丢弃数据包的情况。当数据包丢弃时，源节点端会超时、重传该包。由于没有得到确认，源节点端只能保存数据包，结果缓存会进一步消耗。因

9、此，采用合理的算法与机制,按需分配传输线程占用的网络资源对于网络传输至关重要。值得指出的是，带宽保证是视频实时传输的根底，带宽假如完全均分，每个站点都得到总带宽的1/n设存在n个站点，显然不能适应实际的带宽需求；因此，有必要根据重要性、实时性分配带宽使用的优先级，利用“流控技术到达带宽管理的有效性、确保并发任务的顺利施行。采用单播、播送和组播可以减轻效劳器负担，也能进步并发数。组播的多点投递方式，使所有机器可以接收每个分组的同一拷贝减少了资源浪费。而常规的点对点通信方式下，N个视频站点的视频传输至少要重复发送N-1次一样的数据包，发送时延大，而且随着播放站点数量增长，时延就会迅速增长，这样就不

10、能适应要求短时延的多点视频传输。1.3基于实时传输的协议机制由于TP需要较多的开销，它的重传机制和拥塞控制机制ngestinntrlehanis不可防止地产生了传输延时和占用了较多的网络带宽，故不合适传输实时视频音频。在视音频的流式传输实现方案中，一般采用HTTP/TP来传输控制信息，用RTP/UDP来传输实时声音数据。实时传输协议RTPReal-tietransprtprtl4是用于internet上针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。通常利用低层的UDP协议对实时视音频数据进展组播ultiast或单播Uniast

11、,从而实现多点或单点视音频数据的传输，当然RTP也可以在TP或AT等其他协议之上工作。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，而是依靠RTP提供这些效劳保证实时传输的操作。实时传输控制协议RTP(Real-tietransprtntrlprtl)和RTP一起提供流量控制和拥塞控制效劳。在RTP会话期间，各参与者周期性地传送RTP包。RTP包中含有已发送的数据包的数量、丧失的数据包的数量等统计资料，因此，效劳器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP是RTP的控制协议，RTP和RTP配合使用能以有效的反应和最小的开销使传输效率最正

12、确化，因此特别合适传送网上的实时数据。RTP单独运行在底层协议上监视效劳质量并与会话者传递信息，RTP是由接收方向发送的报文，它负责监视网络的效劳质量、通信带宽以及网上传送的信息，并将这些信息反应给发送端，并提供QS的检测，提供不同媒体间的同步信息和会话参与者的标识信息。基于事件处理的多线程多缓冲区机制显得更胜一筹。但是当在广域网中进展视频数据传输时，此时的传输性能极大地取决于可用的带宽，由于TP是面向连接的传输层协议，它的重传机制和拥塞控制机制，将使网络状况进一步恶化，从而带来灾难性的延时。同时，在这种网络环境下，通过TP传输的视频数据，在接收端重建、回放时，断点非常明显，表达为明显的断断续

13、续，传输的实时性和传输质量都无法保障。相对而言，采用RTP传输的视频数据的实时性和传输质量就要好得多。2并发效劳的任务调度策略面对越来越宏大的流应用需求，系统必须拥有良好的可伸缩性。随着业务的增加和用户的增多，系统需要灵敏地增加现场直播流的数量，并通过增加带宽集群和接近最终用户端的边缘流媒体效劳器的数量，增加并发用户的数量，不断满足用户对系统的扩展要求。通常情况下一个视频流的播放准备需要的准备时间是比拟长的。按照进程方式提供效劳的话，假如不断接收到客户的恳求，同时又不断地创立子进程处理，必然会影响客户的接收，其效劳器并发数也大打折扣。因此，采用“预创立prefrk技术可以缓解这种情况的产生。效

14、劳器事先创立一定数目的子进程，每个子进程分别承受连接队列中已建立连接的客户连接。这样，就由子进程快速响应并处理客户恳求。并发与调度亲密相关，如何分配任务给PU、如何调度任务直接影响到效率和可行性。效率较高的并发方法之一是“多线程，也就是“线程化。但线程化并不是唯一的并发构造，它的实现依赖于资源的可用情况并有一定的局限性。文献5中提到了多种可行的并发应用模型，除线程化外，还有多处理、协同例程和基于事件的编程，以及连续ntinuatin、生成器和其它一些构造。调度的任务就是合理划分时间片和循环执行各个线程，并能有效地监测线程阻塞和消除。每个线程都占用一局部PU时间片，每个时间片上一个线程运行，另一

15、个时间片又可能是另外的线程在工作。根据视频流的传送要求，并发效劳的优先级调度方式不合适专用于视频效劳的工作，这会造成优先级高的视频流侵占低优先级的视频流效劳。因此，为了到达每个视频流效劳的公平性，采用带有可变加权的循环调度。其循环顺序由申请效劳的先后次序决定，以效劳的时延最小进展调整控制，实现各个效劳的最小允许延迟保证优质效劳。3实现方案与测试验证并发操作在同一时刻可以处理多个客户恳求，从RTP/RTP协议使用的角度来说，其实现方法也有多种，如效劳器对每个接收到的客户连接创立一个线程处理；或者预先创立多个线程，由这些线程处理恳求。当然，使用多处理硬件更能较好地实现多任务的并发操作，特别是对于L

16、inux使用多个处理器处理不同的线程时，并发效果要好的多。值得注意的是防止多个线程在单个处理器上造成瓶颈，而其它处理器却处于空闲状态，当然其它并发方法有时也会造成类似的问题。这方面有赖于操作系统的性能，对Linux2.4来说其缺省的“内核线程可以很好地调度线程，并将这些线程分配给不同的PU。3.1实时传输的信息控制线程建立通信连接关系后，根据RTP提供的时间信息实现流同步，通过RTP反应的信息进展数据流控制并动态调整传输率，保证数据延迟符合预定要求。效劳器监听端口，根据实际客户恳求量确定恳求队列的允许最大连接数目。aept(客户恳求)提取并分析恳求队列中的某一任务；寻找具有一样视频信号标志的任

17、务，使用组播技术设置ip地址由子进程处理播放；否那么后置单位时间t。处理时间t的任务(Pr_lient()。hile(客户机与效劳器成功连接成功返回通信文件描绘符)reateThread()/创立线程读出当前时间，并将当前时间写入通信文件描绘符；比拟RTP中资源信息与现有资源的差异，调整数据包发送大小和发送速度；假如子进程的数据传送完，那么关闭通信文件描绘符；反之，继续传送。UDP层检查其目的端口假如其UDP套接口已连接，也可能检查源端口，将数据报放到相应套接口的接收队列。假如需要，就唤醒线程，由线程读取这个新接收的数据报。3.2线程的调度控制线程间通过互斥锁，实现循环控制，即在线程处理视频数

18、据前通过互斥变量、信号灯加锁，主要代码如下：se_ait();pthread_utex_lk();thread_next_flag=true;/设置下一个可执行线程标志pthread_utex_unlk();se_pst();为了实现有效的效劳，需要保证视频数据流的传输具有相对的数据完好性。接收端常根据数据的到达情况通过RTP/RTP协议的信息反应，为效劳器提供数据包接收情况的质量统计反应信息和QS检测的资料；对于接收端而言，数据的存放需要占用一定数量的缓存，以承受网络带宽波动，并在传输中增加一定冗余信息来重建丧失或受损的数据，减少数据重传。按照上述策略，在Linux9.0系统下编程实现了数据的传输，效劳器的配置赛扬为2.0GHz,网卡为10/100自适应。接收端为赛扬1.0GHz，网卡同样为10/100，通过交换机互联。效劳器预创立5个传输效劳线程，图中为两个接收端的数据接收延迟情况，均传送2000个数据包，从统计的结果图来看，除了起始端出现较大的延迟外，延迟抖动均没有过大的变化。但在没有使用本文提出的调度控制的情况下，常常出现时延的急剧变化，即某一数据流出现了较大时延。因此，本文的并发传输调度到达了使用要求，效果比拟令人满意。图1多线程数据传送调度控制测试结果4结论由于视