英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料
实时客户机-服务器系统中多媒体传输的反馈控制流量监管
加布里埃尔·米罗·蒙顿和利亚姆·墨菲
计算机科学系，
都柏林大学学院，
贝尔菲尔德，都柏林4号，爱尔兰。
加布里埃米罗·蒙滕@加州大学工业工程学院, 利亚姆·墨菲@加州大学工业工程学院
摘要 需要在现有网络结构上实时传输多媒体流的应用程序数量正在增加。大量连续的数字视频、音频和文本数据需要在有限的时间内进行交换，很容易造成网络过载过大。因此，本文提出了一种反馈控制的解决方案，确保即使在拥塞的网络条件下，也能保证MPEG流的连续传输和播放。双通道链路（TCP和UDP）允许数据从服务器发送到客户端，并控制描述在客户端和服务器之间发送的传输质量的信息。控制数据由位于客户端的特殊单元收集，该单元定期检查接收器和驱动器缓冲区。从客户端接收的控制数据由服务器上的反馈管理器处理，该反馈管理器控制传输监管器。后者可以通过修改传输缓冲区大小和传输频率等参数来影响传输过程。实验结果表明，在网络拥塞的情况下，系统的性能得到了改善。
1. 介绍
在互联网的早期，只传输文本文档，后来传输带有静态图片的文本，被大多数用户认为是足够使用的。但是现在，越来越多的客户机和服务器之间的多媒体数据传输请求正在迅速增加。所有组件（音频、视频、数据和文本）必须通过当前的基础设施进行传输，该基础设施仍使用基于窗口的流控制，不适合传输连续流。新的协议，如实时协议（RTP）[1]、实时流协议（RTSP）[2]和Xpress传输协议（XTP）[3]已经部署，以尝试改善多媒体流传输。他们主要关心的是如何满足用户的服务质量要求。不幸的是，它们都依赖于现有的IP网络元素，这些元素在所谓的“尽力而为”服务中平等地对待所有传输的数据包。针对这一问题，大家已经进行了广泛的研究，并提出了确保QoS的不同建议，例如集成服务、区分服务、多协议标签交换或基于约束的路由[4]。然后实施这些机制的成本过大，导致大多数用户迄今为止使用有限。因此，关于努力确保在现有基础设施上更好地提供连续媒体流传输的方案非常有意义。
除了多媒体流的连续性之外，它们的大尺寸也会导致问题。为了减少传输的数据量，开发了不同的压缩技术。其中，运动图像专家组（MPEG）编码[5，6]被证明是最好的编码方案之一，不仅从压缩比效率较高，而且因为它的结构，使得在随机分组丢失的情况下也能播放流[7]。不幸的是，MPEG传输非常繁忙，即使在压缩后，流的大小也不小。它在网络上的传输可能会造成拥塞，特别是当网络已经准备加载时。
本文提出了一种流量监管方案，以改善MPEG流在IP网络上从服务器到客户端的传输。该机制试图降低MPEG传输的突发性，降低网络拥塞的影响。它使用从客户端发送到服务器的反馈控制信息，通知它所接收流的大小。服务器使用此控制数据以调整其传输策略，同时客户端继续发送反馈信息。如下一节所述，所提出的机制已由客户机-服务器系统实现和测试。
2. 客户机-服务器系统概述
系统由两个应用程序组成：服务器和客户端（图1）。
图1。客户机-服务器系统的结构
服务器使用采集单元和MPEG编码卡对多媒体流进行采集和压缩。服务器的连接管理器帮助它侦听来自客户端的传入连接请求，并在这些请求被接受后对其进行维护。后者也是客户机连接管理器的用途。MPEG解码器、同步以及显示和播放单元负责将接收到的数据转换成多媒体流并将其显示或播放给客户端。反馈指示单元和反馈管理器在实施反馈控制方案中具有重要作用。服务器和客户机之间的通信通过TCP和UDP双通道完成，详见[8]。这结合了两种协议的优点：控制TCP连接的可靠性，以及用于数据传输的不可靠UDP通道的速度和多播。
客户端服务器系统已经在Visual C 6中实现，采用面向对象的方法。它利用了实验环境提供的多线程支持。Windows事件和消息传递系统支持客户端和服务器应用程序的消息和事件处理。Windows sockets 2（WinSock2）体系结构提供了套接字和应用程序间通信所需的所有机制。MPEG流媒体、缓冲、解码和播放[9]以及本文详细描述的机制已经实现并测试。
3. 服务器传输监管器
处理MPEG流（解码、播放、传输）对CPU、内存和带宽等资源要求很高[10]。最近高性能CPU（目前为1.5GHz）和每兆字节RAM内存不断降低的价格并没有让类似的带宽成本显著降低，这仍然是任何多媒体数据传输的瓶颈。I、P、B三种MPEG视频帧类型的相对大小使得视频流具有很强的突发性，对丢失和抖动非常敏感。此外，在大多数情况下，峰值和平均比特率之间的巨大差异会给MPEG视频流增加额外的突发性[11]。
我们提出的流量监管器通过引入发送过程的双重控制来降低传输的突发性。缓冲机制和传输方案都由反馈管理器监督和控制（图2）。
图2。流量监管器利用反馈信息调整传输参数
该方案实现了一种改进的令牌桶机制[12]，其中添加了一个可变令牌生成过程。作为传输控制单元的一部分，反馈控制定时器生成用于发送数据包的令牌。一旦计时器启动，它就会以一定的频率连续生成令牌。因此，在一段时间内，传输比特率可以被认为是恒定的。这种方案的主要优点是通过将要发送的数据扩展到更大的时间段来减少由发送MPEG视频帧引起的突发（图3）。这可能会增加属于某些帧的最后分组的延迟，但是实验发现分组延迟的平均值与使用普通传输方案时的平均值没有太大的差异（第5节）。我们反馈方案的客户端缓冲和其他特性弥补了这个小缺点，事实上计算的抖动减少了。
图3。传输流量监管器降低了传输的MPEG流的突发性
a） 正常传输情况b）使用流量监管器方案的传输
除了在降低MPEG传输的突发性方面的作用外，令牌的反馈控制生成还允许通过改变传输控制的定时器频率来修改传输比特率。计时器将重新初始化，并在分析从客户机收到的反馈数据后，在反馈管理器指示它执行的任何时间，以不同的频率生成令牌。它所采取的措施不仅取决于当前的反馈数据，而且还取决于它们在时间上的波动，从而防止服务器状态的频繁更改。对于多播传输，设计了一个简单的仲裁方案，考虑到哪种措施最适合大多数客户。
反馈管理器也控制传输缓冲。实验证明，如果发送流的大小大于丢失小数据包的大小，则丢失数据包的效果对其更为重要（图5）。发送大数据包也会给传输带来额外的负担。与较大的数据包大小相比，较小的数据包大小会增加开销。发送太小的包不仅要求客户端能够及时接收以避免丢失它们，而且还需要一些时间来重新排序。这是必要的，因为与较大的数据包相比，它们更有可能无序到达。因此，反馈管理器必须动态地在传输频率和数据包大小之间找到一个折衷点，以最大限度地提高传输性能。为了作出决定，反馈管理器依赖于从位于客户机的反馈指示单元接收并在下一节中描述的控制反馈数据。
4. 客户反馈指示单元
客户端应用程序由一个接收线程（具有更高的优先级）组成，该线程在每次传入数据包到达时由Windows框架调用，一个MPEG解码器线程对接收到的数据进行解码，另一个播放器线程负责显示和播放解码后的数据。客户端线程共享两个缓冲区：分别用于音频和视频流的接收器缓冲区和驱动程序缓冲区（图4）。
图4。客户的结构包括一个反馈指示单元
反馈指示单元的目的是收集关于传输质量的数据，在这里可以最好地判断传输质量：在客户端。分析了接收缓冲区和驱动缓冲区的占用情况，实时更新了丢失帧数、延迟帧数和无序帧数的统计数据。该单元反复向服务器发送控制消息，其中载有关于接收状态的报告。它们由服务器的反馈管理器进行处理，该管理器实时做出决策，从而提高传输质量。
5. 实验结果
在图5a中，我们绘制了当发送了不同的发送分组大小时丢失的分组的数目。虽然丢失的数据包的数量变化不大，但随着传输数据包的大小，丢失的数据包数量略有减少。但是，如第3节所述，如果大数据包没有到达，则丢失数据的百分比（图5b）要高得多。
图5。a） 丢失帧数与帧大小b）丢失帧数与帧大小的百分比
为了计算包的单向延迟，我们需要目标计算机和发送方计算机具有完全同步的时钟。为了实现非常精确的同步，需要特殊的设备，如GPS、原子钟或ISDN同步时钟板[13]。我们的实验需要处理毫秒级的延迟，因此我们可以使用NTP协议[14]来同步服务器和客户端的时钟，方法是连接到科罗拉多州博尔德的原子钟时间服务器，并调整两台计算机的时钟以匹配原子钟值。
图6。无业务成形方案的传输a）普通LAN上的单向帧延迟b）普通LAN上的单向传输抖动
图7无业务成形方案的传输a）单向帧延迟拥挤的局域网b）拥挤的局域网上的单向抖动
为了比较采用和不采用流量监管方案的客户机-服务器系统的行为，我们首先分析了在两种不同条件下，在局域网上传输9秒MPEG系统流（1.6 MB）时获得的结果。图6示出了在没有业务监管的正常加载LAN的情况下测量的单向延迟和抖动，而图7示出了在没有业务监管的拥塞LAN上传输的情况下获得的结果。
图8。采用业务成形方案的传输a）普通LAN上的单向帧延迟
b） 普通局域网上的单向传输抖动
在图8a和图9a中，我们使用业务成形方案在相同的两种情况下（正常加载的网络和拥塞的网络）在相同的LAN上绘制相同的9秒MPEG系统流的单向延迟。在这两种情况下，由流量监管器添加的额外延迟都很小，并且在这两种情况下，抖动都减小（图8b和图9b）。
图9。具有业务成形方案的传输a）拥塞情况下的单向帧延迟
LAN b）拥塞LAN上的单向抖动
我们的实验包括在一天中的非高峰时段和高峰时段，分别在正常负载和拥塞的情况下，在局域网上传输相同的MPEG流。客户端的反馈指示单元同时考虑了接收缓冲区的占用和在传输过程中丢失的数据包的数量、那些到达太晚而无法播放或无序的数据包的数量。在图10中，我们捕获了传输期间服务器状态的动态。服务器在接收和分析来自客户端的控制消息后会不对称地改变其状态。因此，如果接收到客户端接收质量下降的报告，服务器立即将其状态改变为具有较低质量传输的新状态。在反馈控制信息携带关于接收质量的改进的消息的情况下，服务器在将其状态增加到更高质量的传输状态之前等待多个连续的肯定报告。
因为服务器在开始时假设可以保持最高质量的传输状态，所以对于所有的传输，不管网络的状态如何，我们注意到服务器在搜索其正确状态时有一个过渡期。最终，在状态之间的一些转换之后，服务器会稳定下来并以一定的质量级别继续传输。在拥塞网络（图10b）的情况下，该电平低于在正常加载网络（图10a）中经历的电平。此外，在拥挤的网络中比在正常加载的网络中更可能有进一步的状态转换。
图10。服务器状态转换a）在正常LAN上b）在拥挤的LAN上
6. 结论和进一步工作
本文的主要思想是提出一种由客户端发送的反馈控制消息驱动的多媒体传输流量监管机制。使用不同的标准来生成由反馈控制消息携带的报告。同时考虑了接收器和驱动器缓冲区占用的动态性，以及丢失或延迟数据包的数量。其他指标的使用可能是未来调查的主题。反馈数据由作出决定的服务器收集和分析，以改进传输。改变传输包的大小和调整传输比特率被视为可能的服务器措施。它们被一个特别设计的传输流量监管器有效地应用。
我们的业务监管方案的应用使得在传输流的连续性与其质量之间进行权衡成为可能。在大多数情况下，与其在缓冲时停止整个流，不如继续传输流和显示或播放质量更差的流（最终由于一些丢失的包而发生改变）。
分析了有关传输包大小、传输单向延迟和抖动的实验结果。结果表明，即使在网络拥塞的情况下，所提出的流量监管方案也表现良好。测试是在局域网上传输时进行的，但正在进行广域网传输的实验。如果将其他一些反馈控制措施（例如MPEG编码速率的实时修改）与当前的措施结合使用，则可以改进结果。
工具书类
1. H. Schulzrinne，S.Casner，R.Frederick，V.Jacobson，RFC1889：“RTP：实时应用的传输协议”，1996年1月：http://www.ietf.org/rfc/rfc1889.txt
2. H. Schulzrinne，A.Rao，R.Lanphier：“实时流协议（RTSP）”，1998年4月，http://www.ietf.org/rfc/rfc2326.txt
3. Robert M.Sanders，Alfred C.Weaver，“Xpress传输协议（XTP）-教程”，ACM计算机通信评论，第20卷，第5期，1990年10月，第67-80页。
4. 肖希鹏，倪丽诺，“互联网服务质量：一个大的图景”，IEEE网络，第13卷，第2期，1999年3月/4月。
5. ISO/IEC国际标准11172，“MPEG-1-1.5 Mbits/s以下数字存储媒体的运动图像和相关音频编码”，1993年11月。
6. ISO/IEC国际标准13818，“MPEG-2-运动图像和相关音频信息的通用编码”，1994年11月。
7. Didier LeGall，“MPEG：多媒体应用的视频压缩标准”，《ACM通信》，第34卷，第4期，1991年4月，第46-58页。
8. Ga
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[410154]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
