摘要 本文提出一种基于实时协议的多媒体数据流并发服务控制模型，介绍了数据并发传送的调度控制目前针对视频服务质量，从传送层协议的使用、数据的压缩/解压、协同计算到单播/组播等多方面提出了许多措施。考虑到网络传输状况的多样性，本文重点讨论服务器端的数据传送调度控制，和并发服务的关键技术，尽可能地降低传输中的时延抖动问题，提高并发服务质量，文中最后给出了关键控制代码和测试结果。
1 信源数据的并发传输模型
并发连接对于网络视频应用来说，有别于以往的WEB页面式服务和FTP服务，每个视频数据流至少需要384kb/s的带宽甚至更高。同时传输服务还需要具有一定的余量，防止并发客户请求数达到峰值、或网络短期过载现象。因此合适的服务模型、良好的服务策略是优质服务的保障。对即时的影像流压缩与传输要求来说，在服务模型中还需要针对网络系统的资源限制条件，即网络带宽采取适应视频传输的策略，以便处理突发性事件。
另一个需要考虑的限制是服务器提供的并发连接数量以及等候处理的发送调用。因为并发连接数量越多，所消耗的未分页内存池也越多；等候处理的发送调用越多，被锁定的内存页面也越多，极易超过系统资源的极限。
1.1 服务器的视频传输服务特点
视频传输需要较宽的网络带宽，其视频的压缩编码、传输信道和网络协议的选择、IP组播技术对传输质量具有重要的影响作用。基于计算机网络连接的视频点播系统，其关键就在于多个站点视频的网络通信问题，要求做到传输时延尽可能小，尽可能少地占用现有的网络带宽，并具有较好的站点数量规模化特性。
视频服务器对于用户的请求，需要在较短的时间间隔内响应并传送所要求的视频数据，同时随时准备响应新的请求。因而视频服务器的性能直接决定系统的总体性能，为了能同时响应多个用户的服务请求，视频服务器需要调度服务。并具备接纳控制、请求处理、数据检索、按流传送等多种功能，提供实时、连续稳定的视频流，以确保用户请求获得有效服务。再者，视频服务器还需要提供交互服务，如快进和快倒等功能，因此视频服务器必须满足视频流特性使用中的各种要求。
1.2 服务器的并发服务技术
通常客户－－服务器间的通信过程首先是建立点到点的直接联系方式，因此服务器的负载能力决定了视频点播的并发容量。在客户机/服务器传输方式中，在面向连接的通信模式下，服务器需要打开监听端口，监听网络上其它客户机向该服务器发出的连接请求，当收到一个请求信号时与该客户机建立一个连接，之后两者进行交互式的通信。这在客户端请求较少，同时数据传输量不大的情况下传输延迟还可以忍受。
对于实时性要求较高的视频应用，一般采用无连接的通信模式。如MPEG-I按照1.5Mb/s传输在满足观看需要的情况下其帧数也要大于10帧以上。另外，当多个用户同时申请服务的时候，服务器建立连接分配资源等都需要产生延迟，也就是说对于用户的响应经过逐渐积累延迟会越来越大。如果请求池不足的话，那么就会产生客户的请求丢失。因此，同一时刻只能处理一个客户请求的循环服务器方式不适合视频点播。
如果采用并发服务方式[2]，在服务器端用主进程去监听客户机的连接请求，当有客户机的连接请求时通过创建线程的方式独立处理客户机通信，提高视频传输的实时性。
视频数据的并发传输，实质依赖于服务器中的传输线程，服务器的操作以建立相应的线程实现服务为目的，这种服务模式非常适合复杂的多任务请求。从计算机操作系统运行的角度来说，在典型的单处理器主机上，任务实际上并不是同时执行的。内核中称为调度程序的部分将工作换进换出，从而让所有工作都获得一轮执行。在同一个时间间隔内，并发模型常常基于事件的编程实现。
通常情况下，线程数量取决于应用程序的特定需要，理想情况下线程数量与处理器数量相当为好，虽然线程数量无法保证传输质量，但线程太少又会造成传输效率低，特别是用户数量较多的情况下更为明显。
从视频应用来说，影响视频传输性能的根本原因在于视频数据的连续传送和用户提交给服务器的请求无法及时响应，超过了网络资源节点容量或服务器的处理能力。这样就造成网络系统的数据包时延增加、丢弃概率增大、上层应用系统性能下降等。主要表现在以下几方面：
⑴ 并发连接数决定系统内存资源的消耗，并与CPU的处理能力密切相关。
⑵ 视频服务要求服务器尽快地把数据通过网络发送，尽量减少对连接请求的处理延迟，以免服务请求的重发和丢失。
⑶ 物理链路的实际承载能力也影响并发连接的处理能力。根据香农信息理论，任何信道带宽最大值即信道容量:
C=Blog2(1+S/N)（N为信道白噪声的平均功率，S为信源节点的平均功率,B为信道带宽）。所有信源节点发送的速率R必须小于或等于信道容量C。如果R>C，则在理论上无差错传输就是不可能的，所以服务器与网络的联结处会形成传输瓶颈。
⑷ 交换机或路由器的处理能力弱：如果路由器的CPU在执行排队缓存、更新路由表等功能时，处理速度无法与高速链路匹配，就会造成服务失效。
随着网络规模的扩大和用户数的激增，数据流传输更趋于频繁，线程数量不可能无限制增加。如果服务器和客户之间没有缓冲余地必然会出现丢弃数据包的情况。当数据包丢弃时，源节点端会超时、重传该包。由于没有得到确认，源节点端只能保留数据包，结果缓存会进一步消耗。因此，采用合理的算法与机制,按需分配传输线程占用的网络资源对于网络传输至关重要。值得指出的是，带宽保证是视频实时传输的基础，带宽如果完全均分，每个站点都得到总带宽的1/n（设存在n个站点），显然不能适应实际的带宽需求；因此，有必要根据重要性、实时性分配带宽使用的优先级，利用“流控技术”达到带宽管理的有效性、确保并发任务的顺利实施。
采用单播、广播和组播可以减轻服务器负担，也能提高并发数。组播的多点投递方式，使所有机器能够接收每个分组的同一拷贝减少了资源浪费。而常规的点对点通信方式下，N个视频站点的视频传输至少要重复发送N-1次相同的数据包，发送时延大，而且随着播放站点数量增长，时延就会迅速增长，这样就不能适应要求短时延的多点视频传输。
1.3 基于实时传输的协议机制
由于TCP需要较多的开销，它的重传机制和拥塞控制机制（Congestion Control Mechanism）不可避免地产生了传输延时和占用了较多的网络带宽，故不适合传输实时视频音频。在视音频的流式传输实现方案中，一般采用HTTP/TCP来传输控制信息，用RTP/UDP来传输实时声音数据。
实时传输协议RTP（Real-time transport protocol）[4]是用于internet上针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。通常利用低层的UDP协议对实时视音频数据进行组播（Multicast）或单播（Unicast）,从而实现多点或单点视音频数据的传输，当然RTP也可以在TCP或ATM等其他协议之上工作。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，而是依靠RTCP提供这些服务保证实时传输的操作。
实时传输控制协议RTCP(Real-time transport control protocol)和RTP一起提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTCP是RTP的控制协议，RTP和RTCP配合使用能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。
RTCP单独运行在底层协议上监视服务质量并与会话者传递信息，RTCP是由接收方向发送的报文，它负责监视网络的服务质量、通信带宽以及网上传送的信息，并将这些信息反馈给发送端，并提供QoS的检测，提供不同媒体间的同步信息和会话参与者的标识信息。
基于事件处理的多线程多缓冲区机制显得更胜一筹。但是当在广域网中进行视频数据传输时，此时的传输性能极大地取决于可用的带宽，由于TCP是面向连接的传输层协议，它的重传机制和拥塞控制机制，将使网络状况进一步恶化，从而带来灾难性的延时。同时，在这种网络环境下，通过TCP传输的视频数据，在接收端重建、回放时，断点非常明显，体现为明显的断断续续，传输的实时性和传输质量都无法保障。相对而言，采用RTP传输的视频数据的实时性和传输质量就要好得多。
转贴于 范文论文吧 http://www.fwlw8.com[1] [2] 下一页
