基于RDP的声音传输服务程序设计

摘 要    本文是作者为 SEL System公司开发基于RDP的声音服务终端程序（Terminal Server）的总结，这个程序是建立在Microsoft 未公开的RDP协议之上的。文中描述了程序设计中遇到的各个方面，特别是针对声音数据数据量大的特点提出了我们的解决方法,这些方法也适用于其他的类似场合，具有一定的普遍意义。

关键字 RDP , 声音， DirectX，DirectSound COM , 环缓冲(ring buffer)

1 Remote Desktop Protocol (RDP)

RDP (Remote Desktop Protocol) 是微软根据ITU (International Telecommunications Union) 的T.120协议族制订的一套未公开发表的数据传输协议，是终端服务器 (Terminal Server) 和客户端之间的通信协议，它使得远程用户可以使用键盘和鼠标通过网络在应用程序之间进行通信。RDP的目的是把NT/2000终端服务器上的显示等数据信息平滑地传送到客户端。这里的客户端可以是使用各种系统的不同结构的PC或non-PC设备，如运行UNIX 、Linux 、DOS等各种不同OS平台的计算机。通过RDP协议客户端的计算机可以与远程服务器上正在运行的服务程序进行交互以获得相应的服务。

RDP的体系结构支持多点数据传输，能够实时地将数据从终端服务程序传送到各个客户点。RDP的数据传送使用的是一种栈(stack)，和通用的OSI七层模型相似。从服务方发送的数据顺序通过各层协议栈，形成网络包，最终通过网络送达终端客户；从终端客户发来的数据则以相反的顺序送达服务程序端。

值得一提的是，RDP没有为实时声音数据传输制订标准，它目前只支持简单的系统喇叭鸣叫（system beeps），我们的工作就是为了弥补这一不足，为终端服务程序添加上实时的声音传输功能。

2　基于RDP 的应用   

    基于RDP的应用一般包括三部分：终端服务器（Terminal Server），用户界面传输协议和客户端。其中用户界面传输协议允许客户机连接到终端服务器，获取服务器上正在运行的应用程序的信息。

终端服务器概念的提出是出于以下的考虑：尽量减小TCO(Total Cost of Ownership)和尽可能地在各种桌面平台上运行基于Windows和MS-DOS的16位或32位应用程序。终端服务器运行完整的应用程序，把运行信息传送到客户端，而客户端并不实际运行这个程序；服务器一般只接受客户端的鼠标和键盘输入，这种方式大大简化了整个系统的管理。

    我公司参考了有关的RDP信息制订了一套自己内部使用的"RDP"标准，以此为基础开发了一套家用产品，提供各种实时的多媒体信息服务。

3　协议的定义及简单描述

　　终端服务器程序要实现实时的多媒体数据流的传输必须遵守一套传输及控制标准，它使得我们的客户－服务程序得以协调一致地运行。下表简要地列出了服务程序中使用到的协议及其简单的功能描述。

协议名称	协议全称	描述
RDP	Remote Desktop Protocol	微软的Remote Desktop Protocol 提供了一套未公开发表的控制和传输标准
RTP	Real-Time Translation Protocol	该协议定义了基于网络包传输的实时传输标准
RTCP	Real-Time Translation Control Protocol	该协议定义了基于包传输的实时传输的控制标准
PPP	Parse Processing Protocol	本协议定义了一些原语，这些原语通过一套内定的规则被客户端和服务器端共同使用以进行数据通信
CP	Conference Process	这是一个过程或叫会话，该过程当然是指客户机与服务器之间的对话。一个会话在服务器端就表现为服务程序的一个线程

4 声音服务

声音服务是多媒体服务中很重要的一部分，在本项目中，我们的工作是把声音传输功能加入到已有的代码中，这些已有代码是本公司已经开发调试成功的运行在NT/2000服务器上的服务程序。我们的声音服务程序一方面要提供稳定可靠的声音等多媒体服务，另一方面，它要具有相当的容错能力，可以处理多个客户的异步服务请求。

5 服务器端驻留程序的设计

RDP虽然是未公开的协议，但它遵守基于网络包(packet)的数据传输的基本规定，因而我们可以使用通用的TCP/IP 标准来实现声音数据的传输，而TCP/IP 的通用性又恰好能解决不同操作平台之间 (如我们的客户端的 Linux 和服务器端的 Windows NT/2000 ) 通信上的困难。

下面的RDP声音传输模块图显示了我们的程序的基本结构，它一方面描述了整个程序所应包含的基本功能及其相互间的关系，另一方面，它也显示了服务器端程序的模块构成情况和数据的处理流程。我们以模块的顺序承接关系为序介绍各个模块的基本功能及实现。

5.1 声音截取模块

5.1.1 DirectX

Microsoft的 DirectX 是一套低级APIs ，这些APIs控制着硬件的"底层功能"（low-level function ），DirectX按照功能划分成几大部分，即Microsoft DirectDraw?, Microsoft Direct3D?, Microsoft DirectInput?, Microsoft DirectSound?, Microsoft DirectPlay?, DirectShow?, and Microsoft DirectMusic?，他们从各个方面提供了高性能的底层硬件接口，通过HAL(Hardware Abstraction Layer)层为游戏软件和各种硬件建立联系，形成一个统一的而又高性能的接口。

正如上面提到的RDP（v1.0）不支持实时声音数据的传输，我们在这里就使用了DirecX 中的DirectSound提供的声音传输功能。DirectSound APIs只是DirectX APIs 的一个有关声音处理的子集，它包括的基本功能有：低级混音( low mixing ) ，硬件加速(hardware acceleration ) 及声音设备的直接存取。这些APIs在提供这些功能的同时还保持了与其它现存声音驱动程序的兼容，可以使原有的驱动程序获得更好的性能。当然，DirectSound 本身也支持高层次的声音回放功能。在C++中，DirectSound 还支持属性集 ( property sets ) , 从而使得开发者可以利用某块声卡或其驱动程序提供的扩展功能，优化程序的性能。

5.1.2用DirectSound 获取声音数据

    在Microsoft Windows的体系结构之下，声音数据的获取不是件容易的事情，原因是Microsoft Windows把与硬件相关的低层操作给屏蔽了，因而声音数据的操作对用户来说就变成透明得了。当我们想要获得某种"纯粹"的声音数据时，我们得另想办法。在这里我们有两条路可走，其一是自己编制一个小型的，完备的设备驱动程序代替Windows相应的驱动程序以处理声音数据，同时可以按我们的需要重定向声音数据以达到我们的要求。Windows提供的DDK（Device Driver Kits）就可以帮助我们来编制这个驱动程序实现我们的目的，然而这里还是存在着一个困难：我们不知道声音数据是如何被组织通过Windows中的管道(pipes)的，我们在接近硬件的操作层次上截获的声音数据是有特定的格式的，也有自己特定的相应的控制，而这些底层信息对我们仍然是透明的。在我们的服务器端程序中采用了另外一种方法，即利用DirectX COM，它是Windows DirectX SDK 提供的通用的二进制接口标准，事实证明这种方法是简洁而高效的。

下图表示了我们利用DirectX Sound COM 获取声音数据的过程，同时它也展示了程序的控制流程。图中右上角画图表示了一下有关PCM（Pulse Code Modulation ）的原理。

５.2 缓冲区的准备

5.2.1环缓冲（Ring buffer）

环缓冲的使用是应程序实时处理大量声音数据的特殊要求而提出的一个数据缓冲技巧。

在RDP的声音传输服务程序里，我们要考虑的不仅仅是普通的数据包的传输，我们要传输的是大量的声音数据，而且要具备实时性。环缓冲就是为了实现实时声音数据的传送而在软件上采用的方法。在环缓冲方式下，截取到的声音数据被立即送往终端服务器（Terminal Server）的缓冲区中，等缓冲区中积累了一定量的声音数据后，立即把它们做成包通过TCP/IP网络向客户端传送；客户机接受到声音数据后，把它放入同样的环形缓冲中，等收到一定量的数据后，则从缓冲中取出声音数据通过客户端的浏览器加以播放。在这一过程中，我们理想的情况应该是两端的环缓冲的运作达到某种意义上的同步，从而在软件结构方面达到声音数据的实时的传输。

下图可以帮助我们理解环缓冲的工作原理。

model A 简要地表示了A地与B地之间的基于包的传送过程。

model B 形象表示了环缓冲的工作方式，图中，Locus A代表服务器端的声音数据以环形缓冲的方式发送数据，Locus B则表示客户端以环缓冲的方式接受声音数据。

5.2.2缓冲的操作

环缓冲区就是一块使用动态方式申请的内存区域，利用数学中的取余运算，我们可以把它建构成一个抽象的环形域。

下图就表示了这种运算及形成的环形结构。

有了这种环缓冲，我们就可以把截获的大量声音数据不断地，连续地存入缓冲中，同时实时地由缓冲区发送到最终的客户端的环缓冲中。

　 在这种环缓冲操作中，要注意的一个问题是防止缓冲区数据的重叠，以及由此而造成的数据的丢失。

５.3 Socket　的准备

　　关于Socket 的标准定义在BSD中有详细的说明，Socket 的准备主要的就是初始化及异常处理等问题，为了保证服务程序的稳定性可靠性，应当尽量考虑到潜在的各种问题，妥善地做好各种差错处理。

５.4 结构解析

当我们要传送某种结构化的数据（如控制信息等）时，该结构通常在传送端被填入到一定大小的网络包中，当接受端收到这种包时，它应当能够解析其中的数据，重建在发送端时的结构，并依此结构执行相应的动作。下图表示了这个过程。

为了提供高质量的多媒体服务，服务程序应当考虑到各种可能情况并做出相应的处理，但在我们的服务程序中只实现了最基本的控制功能，这主要是由于我们的应用环境要求不是很苛刻，不必进行复杂精确的控制。因而我们的结构解析工作相对简单。

6　结 语

RDP协议提供了一种在各种低端PC或non-PC设备上运行基于Windows的32位应用的标准，它在企业内部的应用升级以及网络会议（NetMeeting）等方面都有广阔的应用前景。本公司基于RDP的这套应用尽管还有不少待改进之处，但它的设计和实现的思想及方法都有一定的可值得借鉴的地方。

我们所作的关于声音传输服务的部分是针对RDP(Version 1.0) 协议中未给出声音传输标准而作的一种间接性的补偿。它要处理的数据的量是相当大的，为了尽可能地保证实时性，减少声音的延迟停顿，我们在软件方面作了种种努力。实际结果表明，这些措施还是有效的，但是声音的延迟停顿还不能有效消除，代码还有相当的改进的余地，这些工作将在以后的维护和使用中逐步加以解决。

参考文献

［1］ Maricia Alforque, Remote Desktop Protocol in Windows CE, Microsoft Corporation, December 2000

［2］ Frank Kim, Run Your Applications on a Variety of Desktop Platforms with Terminal Server, Microsoft System Journal

［3］ White papers on DirectX and Related technologies:
    http://www.microsoft.com/hwdev/devdes/ (hardware-related information)
    http://www.microsoft.com/mediadev/ (API-related information)
    http://www.microsoft.com/win32dev/ (Win32 API information)

［4］ Windows Hardware Quality Labs (driver teset and logo qualification)    Internet:

［5］ Microsoft Corporation, Microsoft Windows NT 4.0, Terminal Server Edition: An Architectural Overview, June 1998

［6］ Microsoft Corporation, MSDN library, 2000